Re: [DNSOP] Status of draft-ietf-dnsop-terminology-bis
Stuart Cheshire <cheshire@apple.com> Sat, 07 April 2018 05:07 UTC
Return-Path: <cheshire@apple.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 9F1AE124319 for <dnsop@ietfa.amsl.com>; Fri, 6 Apr 2018 22:07:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.31
X-Spam-Level:
X-Spam-Status: No, score=-4.31 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=apple.com
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 ptGInaFu0hCa for <dnsop@ietfa.amsl.com>; Fri, 6 Apr 2018 22:07:19 -0700 (PDT)
Received: from mail-in24.apple.com (mail-out24.apple.com [17.171.2.34]) (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 04A7812420B for <dnsop@ietf.org>; Fri, 6 Apr 2018 22:07:18 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1523077638; x=2386991238; h=From:Sender:Reply-To:Subject:Date:Message-id:To:Cc:MIME-version:Content-type: Content-transfer-encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-reply-to:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=UPZX0alFWUWRtufYktdM/QA6kmrUWHZhTYIuG8ah5WQ=; b=mJI8+h/DvirnBNzpOEJTsu2WT2NG7wVTMjTE4tRoXm7ITnJ3qqEZ8eB8oyOryheg 122EIvj1p9gi9O6Q008/VwdzNJVtqz2bSv8JpM2fiGtUpQ+alRXGBi8CxlrDSgvQ c6d7q2Wespi38oYd4fmOEHWgG71d8RZ6RGumF8obtLp6e176upqhgfOEWAqJ1Sll zfExgz/gQnF5eqw+4wip/kmuTl7J0CBCBv/3sezD1boFnI4bDPmAPmBh1GKyfy/C +217/hJOH+AsRTRyvyfhBVax5BHmWV28SqNG8DtYhgZzuzJGTegY557zkxy8g0ug cvL82G4iGurYGbp3T9KF1Q==;
Received: from relay24.apple.com (relay24.apple.com [17.171.128.105]) (using TLS with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mail-in24.apple.com (Apple Secure Mail Relay) with SMTP id 21.A3.10828.60258CA5; Fri, 6 Apr 2018 22:07:18 -0700 (PDT)
X-AuditID: 11ab0218-d45ff70000002a4c-75-5ac8520631c9
Received: from ma1-mmpp-sz07.apple.com (ma1-mmpp-sz07.apple.com [17.171.128.149]) (using TLS with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by relay24.apple.com (Apple SCV relay) with SMTP id D1.95.12120.50258CA5; Fri, 6 Apr 2018 22:07:17 -0700 (PDT)
MIME-version: 1.0
Content-type: text/plain; charset="utf-8"
Received: from [17.234.171.61] (unknown [17.234.171.61]) by ma1-mmpp-sz07.apple.com (Oracle Communications Messaging Server 8.0.2.2.20180130 64bit (built Jan 30 2018)) with ESMTPSA id <0P6S00366U84A140@ma1-mmpp-sz07.apple.com>; Fri, 06 Apr 2018 22:07:17 -0700 (PDT)
Sender: cheshire@apple.com
From: Stuart Cheshire <cheshire@apple.com>
In-reply-to: <7C873271-A784-4594-91A3-48C697EEC613@vpnc.org>
Date: Fri, 06 Apr 2018 22:07:14 -0700
Cc: dnsop <dnsop@ietf.org>
Content-transfer-encoding: quoted-printable
Message-id: <B8CBB1B1-FCA4-40E9-BAC9-027D89920AD0@apple.com>
References: <7C873271-A784-4594-91A3-48C697EEC613@vpnc.org>
To: Paul Hoffman <paul.hoffman@vpnc.org>
X-Mailer: Apple Mail (2.3445.5.20)
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrJLMWRmVeSWpSXmKPExsUiuLohU5ct6ESUwaPTwhZ331xmsbi1/gur A5PHkiU/mTw+z77KHMAUxWWTkpqTWZZapG+XwJUx+wN3weP0is4jfSwNjAsCuhg5OSQETCTm X5rH3sXIxSEksJ5J4sjvO0wwib9zz4PZQgIbmSRO/6gFsXkFBCV+TL7H0sXIwcEsoC4xZUou RO9EJol1+9+ygtQIC0hJvFr5mRnCtpeY3/aDBcRmE9CSePH5ChtIL6eAjcSduWDjWQRUJZat 2MwGYjMDtU6aMo8VwtaWePLuAivEWhuJX09uMkKcYy2x/dIEdhBbREBD4sLDHewQJytJTP9+ mw3kHgmBRjaJ0/O3MU9gFJ6F5OxZCGfPQrJiASPzKkbh3MTMHN3MPCMTvcSCgpxUveT83E2M 4LBmktjB+OW14SFGAQ5GJR5eic7jUUKsiWXFlbmHGKU5WJTEea8+b4wSEkhPLEnNTk0tSC2K LyrNSS0+xMjEwSnVwJhoVFIeFyHzUDV3+Vf73wsM6w3fbD30I/vpyyfsNjt++kwKyhT5+G/l jNjPcqtDGdWv+Ej9eDzz5B4DvtrrJge6H9w6K2VbKHrU4rDssjVLGVvdmhj9sn4dvda+/PR6 1n13d/xt3Fk5vz2r5NaeKw+rPI79XRHt768lvkTUvMrCadKusn1789cpsRRnJBpqMRcVJwIA IlxvoUwCAAA=
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrDLMWRmVeSWpSXmKPExsUiuLphqi5b0Ikog6efeSzuvrnMYnFr/RdW ByaPJUt+Mnl8nn2VOYApissmJTUnsyy1SN8ugStj9gfugsfpFZ1H+lgaGBcEdDFyckgImEj8 nXueCcQWEtjIJHH6Ry2IzSsgKPFj8j2WLkYODmYBdYkpU3K7GLmASiYySazb/5YVpEZYQEri 1crPzBC2vcT8th8sIDabgJbEi89X2EB6OQVsJO7MBRvPIqAqsWzFZjYQmxmoddKUeawQtrbE k3cXWCHW2kj8enKTEeIca4ntlyawg9giAhoSFx7uYIc4WUli+vfbbBMYBWYhuXQWwqWzkExd wMi8ilGwKDUnsdLIRC+xoCAnVS85P3cTIyQMM3cw3rppdohRgINRiYdXovN4lBBrYllxZe4h RgkOZiUR3h6bE1FCvCmJlVWpRfnxRaU5qcWHGKU5WJTEeQ24d0YJCaQnlqRmp6YWpBbBZJk4 OKUaGA98U5xyZkfFkVDhgFi21Uxqa16bazz/Fn5O6uQHY5HXryewKu7cZJSkcMTNbu6s8rxF n6aenGWypqc4eG6GTdWEhC0sLY/f8y/MPKXztq6i+eCGrW5H9Z/w/Nw5+8SZzvfP363N26PP F3img1v9ofIysQlpG9IyNXMUl6XXffW+sso2oGPWL2slluKMREMt5qLiRAD/yuOnPwIAAA==
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/0HRmHO15MzTa8nt_I8pB04w7NC4>
Subject: Re: [DNSOP] Status of draft-ietf-dnsop-terminology-bis
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.22
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: Sat, 07 Apr 2018 05:07:21 -0000
On 5 Mar 2018, at 08:14, Paul Hoffman <paul.hoffman@vpnc.org> wrote: > Greetings. As you can see, draft-ietf-dnsop-terminology-bis-09.txt is out. Reading the diff might be a bit difficult because of the reorganization of some sections that y'all asked for, but I think the result is worth the extra effort. > > We're still not done yet. I took a hiatus from finishing the list of definitions that people wanted more scrutiny on, but will start that again soon. I hope we'll be done with that list by mid-April and then be ready for WG last call. > > As a side note, some of the changes in this version came from people reading the document fresh. I encourage folks who were maybe waiting for WG Last Call to do a first deep reading of the document to instead do so now. The work that everyone is doing on this document will go a long way to making the final RFC more valuable for lots of folks entering the field. I’ve reviewed this, and I think it is a very useful document. Here are my suggestions, which I hope will help. My main suggestion is to recommend that people always avoid using the term “DNS server” or “name server”, since there are two very different kinds of “DNS server” or “name server”. Instead, people should diligently use the terms “authoritative server”, and “recursive resolver” to indicate which kind they are talking about. They have very different rôles, despite the fact that both can often be done with the same software package. In your definition of “recursive resolver” I’d also include a note that this is a misnomer. It’s not recursive, in the classic computer science use of that term. A true “recursive resolver” would be one that forwarded its query to a different “recursive resolver”, and so on, until some terminating condition. That’s recursion in the classic computer science sense. Actually, a DNS “recursive resolver” is one that performs iterative resolution on behalf of the requester. The Recursion Desired (RD) bit might have been better specified as the Iteration Desired (ID) bit. I realize that’s not going to change, but we should document that dubious use of the term “recursive”. In the abstract, expand the first mention of DNS: The Domain Name System (DNS) is defined in literally dozens of different RFCs. In this text: Naming system: A naming system associates names with data. Naming systems have many significant facets that help differentiate them. Some commonly-identified facets include: * Composition of names I don’t know what “Composition of names” means in this context. Label: An ordered list of zero or more octets and which makes up a portion of a domain name. Using graph theory, a label identifies one node in a portion of the graph of all possible domain names. A label alone does not uniquely identify a node in the graph. A label identifies one specific *child* node of the parent at that point in the graph. A domain name in the global DNS has a maximum total length of 255 octets in the wire format; the root represents one octet for this calculation. Include a reference to Appendix C of RFC 6762 which discusses this topic: <https://tools.ietf.org/html/rfc6762#appendix-C> You may conclude that the assessment in RFC 6762 was wrong, but if so, the terminology document should say so explicitly, rather than just ignoring RFC 6762. in both English and C the first label in the ordered list is right-most; but in Arabic it may be left-most It’s not clear what “first” means here. Maybe write “root label” or “TLD” instead? Note that any label in a domain name can contain any octet value; hostnames are generally considered to be domain names where every label follows the rules in the "preferred name syntax", with the amendment that labels can start with ASCII digits (this amendment comes from Section 2.1 of [RFC1123]). This might be a good point to describe the "preferred name syntax" of letters, digits and hyphens. Canonical name: A CNAME resource record "identifies its owner name as an alias, and specifies the corresponding canonical name in the RDATA section of the RR." This might be a good point to introduce the concept of a CNAME chain. The intention of a CNAME resource record is to give the canonical name, but the purported “canonical name” may itself be an alias of some other “canonical name”. Public suffix: "A domain that is controlled by a public registry." (Quoted from [RFC6265], Section 5.3) A common definition for this term is a domain under which subdomains can be registered I would say: “a domain under which subdomains can be registered by third parties”. Any domain can have subdomains registered. It’s the third-party aspect that makes a public registry different. If a name server does not find an RRset that matches a query, but it finds the same name in the same class with a CNAME record, then the name server "includes the CNAME record in the response and restarts the query at the domain name specified in the data field of the CNAME record. I think this is an example of where “name server” means “recursive resolver”. 3. DNS Response Codes This lists NOERROR, FORMERR, SERVFAIL, etc. What about NOTAUTH? RRset: A set of resource records with the same label, class and type, but with different data. I think this should say: A set of resource records with the same owner name... Why state a wrong definition (saying “label”), and then add a clarification correcting it? Similarly, an imputed definition of "resolution" might be "the answer received from resolving". I would add that "resolution" might mean “the act of resolving”. While strictly the difference between these is that one of them sends queries to another recursive server and the other does not One of them? One of what? Which one sends queries to another recursive server, and which does not? Full resolver: This term is used in [RFC1035], but it is not defined there. RFC 1123 defines a "full-service resolver" that may or may not be what was intended by "full resolver" in [RFC1035]. This term is not properly defined in any RFC. So? What do we conclude from this? Recursive query: A query with the Recursion Desired (RD) bit set to 1 in the header.(See Section 4.1.1 of [RFC1035].) Missing space. Iterative query: Synonym for non-recursive query that happens to be a query in a series of recursive queries I think you need to delete the word “recursive” here. “series of recursive queries” should just be “series of queries” the first server pursues the query for the client I would say, “the first server pursues the query on behalf of the client” Note that it is possible for an authoritative server to respond to a query without the parent zone delegating authority to that server. Can you elaborate how? Hidden master: A stealth server that is a primary server for zone transfers. "In this arrangement, the master name server that processes the updates is unavailable to general hosts on the Internet; it is not listed in the NS RRset." The mention of “updates” here appears out of the blue. Can you elaborate? A hidden master can also be a secondary server itself. I would say, “A hidden master for a zone can also be a secondary server for that zone itself.” Forwarding: The process of one server sending a DNS query with the RD bit set to 1 to another server to resolve that query. How about, “The process of one server sending a DNS query with the RD bit set to 1 to another recursive resolver to resolve that query.” That definition appears to suggest that forwarders normally only query authoritative servers. I would say, “normally only query authoritative servers, which would make them recursive resolvers.” Anycast: "The practice of making a particular service address available in multiple, discrete, autonomous locations, such that datagrams sent are routed to one of several available locations." (Quoted from [RFC4786], Section 2) State that anycast means that the same IP address routes to different locations. Instance: "When anycast routing is used... Instead of “Instance” I would say, “Anycast Instance” Split DNS: "Where a corporate network serves up partly or completely different DNS inside and outside its firewall. I would say, “different DNS *views* inside and outside its firewall”. * In-domain: an adjective to describe a name server whose name is either subordinate to... I would say, “whose name is either a subdomain of...” * Sibling domain: a name server's name that is either subordinate to or (rarely) the same as the zone origin and not subordinate to or the same as the owner name of the NS resource records. I found this confusing. How about: * Sibling domain: a name server's name that is either a subdomain of or (rarely) the same as the *parent* zone origin and not a subdomain of or the same as the owner name of the *child* NS resource records. And here: "Out-of-bailiwick" is the antonym of in-bailiwick. An adjective to describe a name server whose name is not subordinate to or the same as the zone origin. Does this mean “a name server whose name is not a subdomain of or the same as the *parent* zone origin”? Glue records for out-of-bailiwick name servers are useless. I would add: “... are useless, and possibly fraudulent.” It is noted that this definition might inadvertently also include any NS records that appear in the zone What does “inadvertently” mean? Inadvertently how? Closest provable encloser: "The longest ancestor of a name that can be proven to exist. Note that this is only different from the Would it be informative to say, “that can be *cryptographically* proven to exist” ? Fast flux DNS: ... It is often used to deliver malware. Is this the whole story? I think short TTLs are also used to achive load balancing. The name “www.google.com” has a short TTL, but that’s not so that it can deliver malware. Reverse DNS, reverse lookup: "The process of mapping an address to a I would add that this is *not* IQUERY. During 2000, the abbreviation was redesignated to 'Address and Routing Parameter Area' in the hope of reducing confusion with the earlier network name." This is mysterious and unenlightening. Please state what the earlier network name was. Please say, “the abbreviation was redesignated from 'xxxx' to 'Address and Routing Parameter Area'”. Otherwise, this text is just mysterious and confusing to the reader. These terms are strictly ways of referring to the relationship standing of two domains where one is a subdomain of the other. Maybe we should state explicitly that “subordinate” is a synonym for “subdomain”? Zone enumeration is different from zone content guessing where the guesser uses a large dictionary of possible labels Can we elaborate on *how* it is different? DNSSEC Policy (DP): A statement that "sets forth the security requirements and standards to be implemented for a DNSSEC-signed zone." (Quoted from [RFC6841], Section 2) DNSSEC Practice Statement (DPS): "A practices disclosure document that may support and be a supplemental document to the DNSSEC Policy (if such exists), and it states how the management of a given zone implements procedures and controls at a high level." (Quoted from [RFC6841], Section 2) I’m unclear on what these mean. Can we add more explanatory text? These states are defined in [RFC4033] and [RFC4035], although the two definitions differ a bit. Can we elaborate with more details about *how* these definitions differ? Stuart Cheshire
- [DNSOP] Status of draft-ietf-dnsop-terminology-bis Paul Hoffman
- Re: [DNSOP] Status of draft-ietf-dnsop-terminolog… Matthijs Mekking
- Re: [DNSOP] Status of draft-ietf-dnsop-terminolog… Matthew Pounsett
- Re: [DNSOP] Status of draft-ietf-dnsop-terminolog… Paul Vixie
- Re: [DNSOP] Status of draft-ietf-dnsop-terminolog… Matthijs Mekking
- Re: [DNSOP] Status of draft-ietf-dnsop-terminolog… Stuart Cheshire
- Re: [DNSOP] Status of draft-ietf-dnsop-terminolog… John Dickinson
- Re: [DNSOP] Status of draft-ietf-dnsop-terminolog… Paul Hoffman
- Re: [DNSOP] Status of draft-ietf-dnsop-terminolog… Paul Hoffman
- Re: [DNSOP] Status of draft-ietf-dnsop-terminolog… Paul Hoffman
- [DNSOP] Lameness terminology (was: Status of draf… Shane Kerr
- Re: [DNSOP] [Ext] Lameness terminology (was: Stat… Edward Lewis
- Re: [DNSOP] [Ext] Lameness terminology (was: Stat… Amreesh Phokeer
- Re: [DNSOP] [Ext] Lameness terminology (was: Stat… David Huberman
- Re: [DNSOP] [Ext] Lameness terminology (was: Stat… Mark Andrews
- Re: [DNSOP] [Ext] Lameness terminology (was: Stat… David Huberman
- Re: [DNSOP] [Ext] Lameness terminology (was: Stat… Bill Woodcock
- Re: [DNSOP] [Ext] Lameness terminology (was: Stat… Frederico A C Neves
- Re: [DNSOP] [Ext] Lameness terminology (was: Stat… Mark Andrews
- Re: [DNSOP] [Ext] Lameness terminology (was: Stat… David Huberman
- Re: [DNSOP] [Ext] Lameness terminology (was: Stat… Mark Andrews
- Re: [DNSOP] [Ext] Lameness terminology (was: Stat… David Huberman
- Re: [DNSOP] [Ext] Lameness terminology (was: Stat… Mark Andrews
- Re: [DNSOP] [Ext] Lameness terminology (was: Stat… Bill Woodcock
- Re: [DNSOP] [Ext] Lameness terminology (was: Stat… Bill Woodcock
- Re: [DNSOP] [Ext] Lameness terminology (was: Stat… Bill Woodcock
- Re: [DNSOP] Fixing lame delegations Paul Hoffman
- Re: [DNSOP] [Ext] Lameness terminology (was: Stat… Mark Andrews
- Re: [DNSOP] [Ext] Lameness terminology (was: Stat… Mark Andrews
- Re: [DNSOP] [Ext] Lameness terminology (was: Stat… John Kristoff
- Re: [DNSOP] [Ext] Lameness terminology Paul Vixie
- Re: [DNSOP] [Ext] Lameness terminology Shane Kerr
- Re: [DNSOP] [Ext] Lameness terminology Shane Kerr
- Re: [DNSOP] [Ext] Lameness terminology Matthew Pounsett
- Re: [DNSOP] [Ext] Lameness terminology (was: Stat… Edward Lewis
- Re: [DNSOP] [Ext] Lameness terminology Joe Abley
- Re: [DNSOP] [Ext] Lameness terminology Joe Abley
- Re: [DNSOP] [Ext] Lameness terminology Edward Lewis
- Re: [DNSOP] [Ext] Lameness terminology Paul Hoffman
- Re: [DNSOP] [Ext] Lameness terminology Edward Lewis