Re: [DNSOP] Brief addition to terminology-bis draft

Martin Hoffmann <martin@opennetlabs.com> Tue, 04 September 2018 09:29 UTC

Return-Path: <martin@opennetlabs.com>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA15C130E80; Tue, 4 Sep 2018 02:29:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.9
X-Spam-Level:
X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t3MTA0USWaPM; Tue, 4 Sep 2018 02:29:27 -0700 (PDT)
Received: from dicht.nlnetlabs.nl (open.nlnetlabs.nl [185.49.140.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 26294130E6F; Tue, 4 Sep 2018 02:29:27 -0700 (PDT)
Received: by dicht.nlnetlabs.nl (Postfix, from userid 58) id 49F7A1DBB8; Tue, 4 Sep 2018 11:29:25 +0200 (CEST)
Received: from smaug.local.partim.de (unknown [84.245.51.209]) by dicht.nlnetlabs.nl (Postfix) with ESMTPSA id 887BE1DBB5; Tue, 4 Sep 2018 11:29:24 +0200 (CEST)
Authentication-Results: dicht.nlnetlabs.nl; dmarc=none (p=none dis=none) header.from=opennetlabs.com
Date: Tue, 04 Sep 2018 11:29:24 +0200
From: Martin Hoffmann <martin@opennetlabs.com>
To: Paul Vixie <paul@redbarn.org>
Cc: Suzanne Woolf <suzworldwide@gmail.com>, dnsop@ietf.org, draft-ietf-dnsop-terminology-bis.all@ietf.org
Message-ID: <20180904112924.685a42d7@smaug.local.partim.de>
In-Reply-To: <5B8D548E.5080205@redbarn.org>
References: <4AA8656A-7D2F-4584-B84D-47E97483CCC2@gmail.com> <5B8D548E.5080205@redbarn.org>
Organization: Open Netlabs
X-Mailer: Claws Mail 3.16.0 (GTK+ 2.24.32; x86_64-pc-linux-gnu)
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/6Di1KartZGn6kZ0XSAa9AkTvR-o>
Subject: Re: [DNSOP] Brief addition to terminology-bis draft
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.27
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 04 Sep 2018 09:29:29 -0000

Paul Vixie wrote:
> Suzanne Woolf wrote:
> >
> > Here's the definition that the authors would like to add to the
> > document:
> >
> >
> >     Class:
> >     A class "identifies a protocol family or instance of a protocol"
> >     (Quoted from [RFC1034], Section 3.6). "The DNS tags all data
> > with a class as well as the type, so that we can allow parallel use
> > of different formats for data of type address." (Quoted from
> > [RFC1034], Section 2.2). In practice, the class for nearly every
> > query is "IN". There are some queries for "CH", but they are
> > usually for the purposes of information about the server itself
> > rather than for a different type of address.

I think I would call out here more clearly that CH has been "hijacked"
by name server vendors for server status information and that one cannot
expect regular DNS name resolution to be performed for queries with
this class.

> >
> > Please let us know your opinions yea or nay by Monday, Sept. 10,
> > midnight UTC.  
> 
> i don't think this def'n serves the need. we need to speak more truth:
> 
> "The Class tag was weakly defined, such that either a zone can have
> data in multiple classes, or each class can have its own zone cut
> hierarchy, and so neither interpretation can be relied upon by DNS
> protocol implementers."
> 
> then go on to "in practice..."

RFC 1034, section 4.2 seems pretty clear that each class has its own
hierarchy. It also says that cuts are made within each class's
hierarchy separately. My reading is that each class has its own zones,
but that indeed isn't called out explicitly in that section.

Kind regards,
Martin