Re: [DNSOP] Working Group Last Call on draft-ietf-dnsop-terminology-bis
On 9 Jul 2018, at 19:28, Suzanne Woolf wrote: Thanks to all who commented. The WGLC is over and the chairs have seen strong support for this document and lots of participation in getting it right, so we’ll be advancing it for publication. The authors will be spinning up a new version, incorporating the last call comments, and we’ll submit that revision. We have now turned in -11; please turn the crank so that this can go to IETF Last Call and become RFCized. --Paul Hoffman ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Working Group Last Call on draft-ietf-dnsop-terminology-bis
Thanks to Vladimír, > From: Vladimír Čunát > "Bailiwick" definition: I have (also) seen use like "in-bailiwick > records" in the sense being in a subdomain. I can't really judge how > common that usage is, but it has already been discussed wrt. this draft: > https://mailarchive.ietf.org/arch/msg/dnsop/MyEdXXdUKKyTTfX3_4_7AnhE3Io > My understanding of that thread is that the meaning was planned to be extended > in the draft, but the current text seems still restricted to name servers. I missed updating the part. It's too late, but if possible, I would like to update the part a follows. --- "In-bailiwick" is an adjective indicating that a domain name is a subdomain of or (rarely) the same as another domain name. "Out-of-bailiwick" is the antonym of in-bailiwick. (The term "bailiwick" means the district or territory where a bailiff or policeman has jurisdiction.) "In-bailiwick" and "out-of-bailiwick" are usually used for name servers' names. "In-bailiwick" name server is a name server whose name is either a subdomain of or (rarely) the same as the origin of the zone that contains the delegation to the name server. In-bailiwick name servers may have glue records in their parent zone (using the first of the definitions of "glue records" in the definition above). "In-bailiwick" names are divided into two type of name server names: "in-domain" names and "sibling domain" names. In-domain: sibling domain: examples - -- Kazunori Fujiwara, JPRS ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Working Group Last Call on draft-ietf-dnsop-terminology-bis
Thanks to all who commented. The WGLC is over and the chairs have seen strong support for this document and lots of participation in getting it right, so we’ll be advancing it for publication. The authors will be spinning up a new version, incorporating the last call comments, and we’ll submit that revision. Best, Suzanne (For the chairs) > On Jun 22, 2018, at 4:01 PM, Suzanne Woolf wrote: > > Colleagues, > > This begins the working group last call for > draft-ietf-dnsop-terminology-bis-10, "DNS Terminology”. The document has > gotten significant feedback and the editors have worked hard to document > current terminology usage, both among practitioners and for broader > audiences; we’d like to advance it. > > We’re seeking consensus to advance it to the IESG with an intended status of > Best Current Practice. Note that it’s intended to obsolete RFC 7719 ( the > earlier “DNS Terminology” document). > > If you support it, please say so. If you don’t, please say why. > > The current version is at: > https://datatracker.ietf.org/doc/draft-ietf-dnsop-terminology-bis/ > > Last Call will run for two weeks, closing on Friday July 6. This will allow > for discussion of any major outstanding issues at IETF 102. > > > thanks, > Suzanne, Tim, & Benno ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Working Group Last Call on draft-ietf-dnsop-terminology-bis
On Jul 5, 2018, at 19:38, George Michaelson wrote: > Only the zone authority can publish a DNSSEC signed zone. I don't know what this means exactly, but I think it's wrong. I will illustrate my thinking by using some of these words (like "publish") in the way that I understand them, to see if that helps. So I am not arguing; I'm describing different usage. Any nameserver can publish any zone they want. There is no claim, there is only do. DNSSEC RRSets are not special in this regard. They are just RRSets. A client might send a query to a particular server because it was sent that way by referrals or by local configuration. Clients might not send queries to a server at all. The server can still be said to publish a zone. Only someone able to exercise the private key that corresponds to a published trust anchor can generate signatures that anybody can validate. Signing RRSets is a different function from publishing a zone. Multiple copies of a private key might be exercised by multiple different actors who can each produce different signed zones with the same alex owner name, which clients can successfully validate using the same trust anchor. You could argue that such a key is not very private, and I might agree. (See also the multiple-ZSK experiments conducted in the Yeti project for other examples.) Root server operators publish the signed root zone. They are not able to exercise private keys used by PTI and Verisign to generate the various RRSIGs in the root zone. That is ok. Many TLD operators generate signed zones that are published on nameservers operated by third parties (e.g. as commercial DNS operators, for fee). Those third party operators publish the zones, but don't have access to the private key. That is ok. > Anyone can claim to publish a view of a non-DNSSEC signed zone. I don't know what "publish a view" means. A "view" is BIND8/9 terminology that describes which zone data to publish to particular sets of clients. The things being published are the zone data, not the views. Joe ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Working Group Last Call on draft-ietf-dnsop-terminology-bis
Only the zone authority can publish a DNSSEC signed zone. Anyone can claim to publish a view of a non-DNSSEC signed zone. On Thu, Jul 5, 2018 at 7:11 PM, Dick Franks wrote: > > On 3 July 2018 at 16:40, Joe Abley wrote: >> >> On 3 Jul 2018, at 09:11, Matthew Pounsett wrote: >> >> > This is not a complete review of the latest revision.. I'm hoping to get >> > to that in a day or two. But I've got a question about whether something >> > should be added to the document.. >> > >> > A question came up in conversation recently about the use of the verb >> > "to publish" in reference to managing DNS data. It quickly became clear >> > that there may be a common overloading of terms, where the same word means >> > different things to different people. I wasn't sure this fell into the >> > scope of the terminology document, but I just checked and it does use >> > "publish" in reference to DNS data, so perhaps we should come up with a >> > definition for that. >> > >> > To me, publishing DNS data has always meant the generation of the zone >> > and the data it contains, as distinct from distributing the zone (to name >> > servers, possibly though zone transfer) and serving the zone (making it >> > available to be queried on a name server). To the person I was speaking >> > to, >> > "publishing" meant putting that data on Internet-facing name servers that >> > would answer queries about it. >> >> To me, DNS data is published when it is made available to actors who wish >> to consume it. That means serving the data (i.e. having servers with the >> data available to answer queries). I have never heard "publish" used to mean >> zone generation. A zone, once generated, is not published until it is >> available for access by others. > > > agree, the word carries the usual dictionary meaning: > > publish v.t. to make public; to divulge; to announce; to proclaim; to set > forth to the public; >to put forth and offer for sale orig. any article, now books, newspapers, > etc.; >to put into circulation. > > zone generation without the "setting forth" does not appear to qualify. > > > Dick > > ___ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop > ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Working Group Last Call on draft-ietf-dnsop-terminology-bis
On 3 July 2018 at 16:40, Joe Abley wrote: > On 3 Jul 2018, at 09:11, Matthew Pounsett wrote: > > > This is not a complete review of the latest revision.. I'm hoping to get > to that in a day or two. But I've got a question about whether something > should be added to the document.. > > > > A question came up in conversation recently about the use of the verb > "to publish" in reference to managing DNS data. It quickly became clear > that there may be a common overloading of terms, where the same word means > different things to different people. I wasn't sure this fell into the > scope of the terminology document, but I just checked and it does use > "publish" in reference to DNS data, so perhaps we should come up with a > definition for that. > > > > To me, publishing DNS data has always meant the generation of the zone > and the data it contains, as distinct from distributing the zone (to name > servers, possibly though zone transfer) and serving the zone (making it > available to be queried on a name server). To the person I was speaking > to, "publishing" meant putting that data on Internet-facing name servers > that would answer queries about it. > > To me, DNS data is published when it is made available to actors who wish > to consume it. That means serving the data (i.e. having servers with the > data available to answer queries). I have never heard "publish" used to > mean zone generation. A zone, once generated, is not published until it is > available for access by others. > agree, the word carries the usual dictionary meaning: publish v.t. to make public; to divulge; to announce; to proclaim; to set forth to the public; to put forth and offer for sale orig. any article, now books, newspapers, etc.; to put into circulation. zone generation without the "setting forth" does not appear to qualify. Dick ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Working Group Last Call on draft-ietf-dnsop-terminology-bis
On 4/7/18 1:40 am, Joe Abley wrote: On 3 Jul 2018, at 09:11, Matthew Pounsett wrote: This is not a complete review of the latest revision.. I'm hoping to get to that in a day or two. But I've got a question about whether something should be added to the document.. A question came up in conversation recently about the use of the verb "to publish" in reference to managing DNS data. It quickly became clear that there may be a common overloading of terms, where the same word means different things to different people. I wasn't sure this fell into the scope of the terminology document, but I just checked and it does use "publish" in reference to DNS data, so perhaps we should come up with a definition for that. To me, publishing DNS data has always meant the generation of the zone and the data it contains, as distinct from distributing the zone (to name servers, possibly though zone transfer) and serving the zone (making it available to be queried on a name server). To the person I was speaking to, "publishing" meant putting that data on Internet-facing name servers that would answer queries about it. To me, DNS data is published when it is made available to actors who wish to consume it. That means serving the data (i.e. having servers with the data available to answer queries). I have never heard "publish" used to mean zone generation. A zone, once generated, is not published until it is available for access by others. If there is actually widespread confusion about this I agree it might make sense to clarify (but if there's widespread difference in usage, the best we can probably do in a non-prescriptive dictionary is describe the conflicting uses, and I have my doubts that that in and of itself will reduce confusion). Joe That has been my colloquial use of 'publish'. Until my discussion with Matt I had not encountered an alternative meaning. But his use seemed equally sensible. I don't feel strongly about either interpretation. The context of our discussion was making a zone available from the edge of a DNS network. It seems to me you could also quite intuitively use the term to describe making the zone available to systems within that network. Since there will also be consumers of the zone within that DNS network. So in my use, publishing has been done by a single system or a collective of systems depending on perspective. -- Kal Feher Melbourne, Australia ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Working Group Last Call on draft-ietf-dnsop-terminology-bis
On 3 Jul 2018, at 09:11, Matthew Pounsett wrote: > This is not a complete review of the latest revision.. I'm hoping to get to > that in a day or two. But I've got a question about whether something > should be added to the document.. > > A question came up in conversation recently about the use of the verb "to > publish" in reference to managing DNS data. It quickly became clear that > there may be a common overloading of terms, where the same word means > different things to different people. I wasn't sure this fell into the scope > of the terminology document, but I just checked and it does use "publish" in > reference to DNS data, so perhaps we should come up with a definition for > that. > > To me, publishing DNS data has always meant the generation of the zone and > the data it contains, as distinct from distributing the zone (to name > servers, possibly though zone transfer) and serving the zone (making it > available to be queried on a name server). To the person I was speaking to, > "publishing" meant putting that data on Internet-facing name servers that > would answer queries about it. To me, DNS data is published when it is made available to actors who wish to consume it. That means serving the data (i.e. having servers with the data available to answer queries). I have never heard "publish" used to mean zone generation. A zone, once generated, is not published until it is available for access by others. If there is actually widespread confusion about this I agree it might make sense to clarify (but if there's widespread difference in usage, the best we can probably do in a non-prescriptive dictionary is describe the conflicting uses, and I have my doubts that that in and of itself will reduce confusion). Joe signature.asc Description: Message signed with OpenPGP ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Working Group Last Call on draft-ietf-dnsop-terminology-bis
This is not a complete review of the latest revision.. I'm hoping to get to that in a day or two. But I've got a question about whether something should be added to the document.. A question came up in conversation recently about the use of the verb "to publish" in reference to managing DNS data. It quickly became clear that there may be a common overloading of terms, where the same word means different things to different people. I wasn't sure this fell into the scope of the terminology document, but I just checked and it does use "publish" in reference to DNS data, so perhaps we should come up with a definition for that. To me, publishing DNS data has always meant the generation of the zone and the data it contains, as distinct from distributing the zone (to name servers, possibly though zone transfer) and serving the zone (making it available to be queried on a name server). To the person I was speaking to, "publishing" meant putting that data on Internet-facing name servers that would answer queries about it. However, using such a broad definition of "publishing" seems, to me, to introduce confusion in that it removes a clear distinction between the steps of generating data, distributing those data, and then making them available to be queried. To draw a comparison, one might look to the steps of writing, publishing, distributing, and selling a book (although I'm not sure how the first two would map differently to publishing DNS data.. they seem like the same step to me in this context). ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Working Group Last Call on draft-ietf-dnsop-terminology-bis
Hi all, Two questions came up recently when writing the DNS Privacy BCP with respect to terminology (and on the dns-operations list): 1) What do folks think about adding a new definition to this document for a shortened term for DNS-over-TLS? Since we now have DoH I’ve often taken to referring to DNS-over-TLS as DoT in talks and presentations. But this isn’t an acronym used in any standard and it is also potentially confused with meaning DNS-over-TCP (and there is also a DOTS WG at IETF). DoTLS and DoTCP have also been proposed which work well in written form, but don’t sound as good, so we could consider DoT and DoTCP? Other ideas? 2) The second questions is if it is worth including DoH client/server definitions here and also updating the definition of 'Privacy-enabling DNS server’ from RFC8310 in this draft to include servers that implement DoH and/or DNS-over-TLS. I suspect having one term for such servers might make some of the anticipated DRUI work easier, but I realise including DoH could create dependancy problems :-) Regards Sara. > On 22 Jun 2018, at 21:01, Suzanne Woolf wrote: > > Colleagues, > > This begins the working group last call for > draft-ietf-dnsop-terminology-bis-10, "DNS Terminology”. The document has > gotten significant feedback and the editors have worked hard to document > current terminology usage, both among practitioners and for broader > audiences; we’d like to advance it. > > We’re seeking consensus to advance it to the IESG with an intended status of > Best Current Practice. Note that it’s intended to obsolete RFC 7719 ( the > earlier “DNS Terminology” document). > > If you support it, please say so. If you don’t, please say why. > > The current version is at: > https://datatracker.ietf.org/doc/draft-ietf-dnsop-terminology-bis/ > > Last Call will run for two weeks, closing on Friday July 6. This will allow > for discussion of any major outstanding issues at IETF 102. > > > thanks, > Suzanne, Tim, & Benno > ___ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Working Group Last Call on draft-ietf-dnsop-terminology-bis
On 2 July 2018 at 00:03, Paul Hoffman wrote >8 > Well, RFC 1035 *does* say that it is in ASCII, whether we like that or not. Perhaps we need to remind ourselves what RFC1035 actually *does* say. ASCII is mentioned in three places only: 2.3.3 para 1, initially about case-insensitive character string comparisons, but then wanders off-topic: However, future additions beyond current usage may need to use the full binary octet capabilities in names, so attempts to store domain names in 7-bit ASCII or use of special bytes to terminate labels, etc., should be avoided. 3.1 para 3, supposedly dealing with preferred name syntax, also has another crack at case-insensitive comparisons: Name servers and resolvers must compare labels in a case-insensitive manner (i.e., A=a), assuming ASCII with zero parity. Non-alphabetic codes must match exactly. 6.1.2 para 3, in a section dealing with nameserver internal data structures, yet again gets fixated on character case issues: One way to solve the case problem is to store the labels for each node in two pieces: a standardized-case representation of the label where all ASCII characters are in a single case, together with a bit mask that denotes which characters are actually of a different case. 3.1 para 1, dealing with domain names in DNS messages, which being an external interface, one might expect character encoding to be specified, does not mention ASCII at all. Furthermore, in the whole of section 5, which specifies the format of master files, there is no mention of the character encoding of the files themselves. There is only one other occurrence of "encoding" remotely relevant to the present discussion. 5.1 last para, dealing with special characters and escape sequences: Because these files are text files several special encodings are necessary to allow arbitrary data to be loaded. There is nothing in the subsequent \DDD description to indicate that the decimal number represents an ASCII code point, which it clearly must if labels are ASCII encoded. The other occurrences of "encoding" are in section 8, and deal with mailbox addresses and related matters of no interest here. The proposition that RFC1035 mandates ASCII "presentation format" is demonstrably false. >8 > ... An application could choose to encode the presentation format using a > different encoding, but that's outside the scope of the protocol. Application programs do not "choose the encoding"; that "choice" is inflicted upon them by the I/O system provided by the platform on which they run. If the platform uses EBCDIC, then "presentation format" is EBCDIC encoded, constrained (in this instance) to use the same printable character repertoire as on an ASCII platform. --Dick ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Working Group Last Call on draft-ietf-dnsop-terminology-bis
Thanks Paul! I'm very happy with all the proposed formulation changes (your commit 0fqxn1k41). --Vladimir ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Working Group Last Call on draft-ietf-dnsop-terminology-bis
On 27 Jun 2018, at 12:56, Dick Franks wrote: The document appears to be in good shape. However, I have some difficulty with the wording of these two paragraphs in section 2. The basic wire format for names in the global DNS is a list of labels ordered by decreasing distance from the root, with the root label last. Each label is preceded by a length octet. [RFC1035] also defines a compression scheme that modifies this format. The presentation format for names in the global DNS is a list of labels ordered by decreasing distance from the root, encoded as ASCII, with a "." character between each label. In presentation format, a fully-qualified domain name includes the root label and the associated separator dot. For example, in presentation format, a fully-qualified domain name with two non-root labels is always shown as "example.tld." instead of "example.tld". [RFC1035] defines a method for showing octets that do not display in ASCII. The character encoding of "presentation format" depends on the context in which it is used. The protocol mandates ASCII encoding of labels on the wire. It cannot say anything about the internal character encoding conventions of application programs or related master files, which can, in the general case, be different. Well, RFC 1035 *does* say that it is in ASCII, whether we like that or not. An application could choose to encode the presentation format using a different encoding, but that's outside the scope of the protocol. --Paul Hoffman ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Working Group Last Call on draft-ietf-dnsop-terminology-bis
On 26 Jun 2018, at 10:09, Vladimír Čunát wrote: Greetings! I really like the draft, and I'm sorry to be so late. This is not late, especially if you really like the draft. :-) I see one minor issue just below and then a few nitpicks that I don't feel strongly about. I'm marking these in the GitHub repo. NXDOMAIN: "Name Error - Meaningful only for responses from an authoritative name server, this code signifies that the domain name referenced in the query does not exist." (Quoted from [RFC1035], Section 4.1.1.) [RFC2308] established NXDOMAIN as a synonym for Name Error. I dislike keeping this formulation; it might confuse people. It seems to imply that NXDOMAIN from a resolver isn't "meaningful", and that's clearly not true, at least not nowadays. (I develop a resolver.) The quoted definition makes sense without the "Meaningful only for responses from an authoritative name server" phrase, so we can remove it and still have it be useful. "Resolver" definition: I don't think the word really implies it runs on the same machine as the program asking it. In particular, the purpose of stub resolvers is to ask a recursive *resolver* that is typically on another machine. Perhaps I misunderstand that RFC1034 part. I found one comment on this particular point but no reactions: https://mailarchive.ietf.org/arch/msg/dnsop/tCZD120ehRkK52ikTWuZ-t5Tf2w We did indeed miss this. In staring at that longer, I agree that the quote from 1034 is not true for the current understanding of a resolver. We can remove it. "Authoritative-only server" definition: "ignores requests for recursion" might mislead into thinking the DNS request is not replied to, whereas the server is supposed to return either REFUSED or a referral. Maybe I'd say something like "ignores the RD bit being set to 1". Well, the authoritative server doesn't ignore the RD bit, either: it just doesn't do the recursion that was asked for. Thus you want the terminology document to (a) update an RFC that (b) is a BCP that (c) was co-written by my boss. Trifecta! Instead of changing the wording of the BCP, we can instead add "In this case 'ignores requests for recursion' means 'responds to requests for recursion with responses indicating that recursion was not performed'". Does this work for you? "Slave server", "Master server": I'm surprised to read that current common usage has shifted to "secondary" and "primary" instead, but that is better judged by people working with authoritative servers (and not me). Open resolver: A full-service resolver that accepts and processes queries from any (or nearly any) stub resolver. [...] Perhaps not from any "stub resolver" but from any "client". *Who* asks really isn't the point. Very good point! In fact, many open resolvers allow forwarding from other recursive resolvers. "Authoritative data" definition: there might be a mention of special cases added later or perhaps switch quotation to one from rfc4033#section-2 Yes; will add pointer there. "Bailiwick" definition: I have (also) seen use like "in-bailiwick records" in the sense being in a subdomain. I can't really judge how common that usage is, but it has already been discussed wrt. this draft: https://mailarchive.ietf.org/arch/msg/dnsop/MyEdXXdUKKyTTfX3_4_7AnhE3Io My understanding of that thread is that the meaning was planned to be extended in the draft, but the current text seems still restricted to name servers. We opened a discussion for bailiwick and incorporated what we could from that discussion. "NSEC3" definition, this is clearly a typo (missing "3"): NSEC resource records require associated NSEC3PARAM resource records. Good catch! I'm not really sure if a best-practice RFC is really allowed to "update" a standards-track RFC (2308), but I assume the authors and chairs know the process much better than me. (From my point of view it's OK.) It is indeed OK. BCPs are considered "standards track" themselves. --Paul Hoffman ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Working Group Last Call on draft-ietf-dnsop-terminology-bis
The document appears to be in good shape. However, I have some difficulty with the wording of these two paragraphs in section 2. The basic wire format for names in the global DNS is a list of labels ordered by decreasing distance from the root, with the root label last. Each label is preceded by a length octet. [RFC1035] also defines a compression scheme that modifies this format. The presentation format for names in the global DNS is a list of labels ordered by decreasing distance from the root, encoded as ASCII, with a "." character between each label. In presentation format, a fully-qualified domain name includes the root label and the associated separator dot. For example, in presentation format, a fully-qualified domain name with two non-root labels is always shown as "example.tld." instead of "example.tld". [RFC1035] defines a method for showing octets that do not display in ASCII. The character encoding of "presentation format" depends on the context in which it is used. The protocol mandates ASCII encoding of labels on the wire. It cannot say anything about the internal character encoding conventions of application programs or related master files, which can, in the general case, be different. Consider the following perl fragment: use Net::DNS 1.11; my $resolver = new Net::DNS::Resolver(); my ($rr) = $resolver->query( 'www.example.com.', 'A' )->answer; $rr->print; print unpack( 'H*', $rr->string ), "\n"; executed in an ASCII-based environment: www.example.com.600INA93.184.216.34 772e6578616d706c652e636f6d2e0936303009494e09410939332e3138342e3231362e3334 in an OS390 EBCDIC environment: www.example.com.600INA93.184.216.34 a6a6a64b85a781949793854b8396944b05f6f0f005c9d505c105f9f34bf1f8f44bf2f1f64bf3f4 (output converted to ASCII to preserve your sanity) Suggested replacement text: The basic wire format for names in the global DNS is a list of labels ordered by decreasing distance from the root, with the root label last. Each label is ASCII encoded and preceded by a single length octet. [RFC1035] also defines a compression scheme that modifies this format. The presentation format for names in the global DNS is a list of labels ordered by decreasing distance from the root, represented by printable characters from the ASCII repertoire, irrespective of the local character encoding used to represent them. The component labels are separated by a single "." character. In presentation format, a fully-qualified domain name includes the root label and the associated separator dot. For example, in presentation format, a fully-qualified domain name with two non-root labels is always shown as "example.tld." instead of "example.tld". [RFC1035] defines a numerical representation that may be used to display octets for which there is no corresponding ASCII printable character. Dick Franks ____ On 22 June 2018 at 21:01, Suzanne Woolf wrote: > Colleagues, > > This begins the working group last call for > draft-ietf-dnsop-terminology-bis-10, > "DNS Terminology”. The document has gotten significant feedback and the > editors have worked hard to document current terminology usage, both among > practitioners and for broader audiences; we’d like to advance it. > > We’re seeking consensus to advance it to the IESG with an intended status > of Best Current Practice. Note that it’s intended to obsolete RFC 7719 ( > the earlier “DNS Terminology” document). > > If you support it, please say so. If you don’t, please say why. > > The current version is at: https://datatracker.ietf.org/ > doc/draft-ietf-dnsop-terminology-bis/ > > Last Call will run for two weeks, closing on Friday July 6. This will > allow for discussion of any major outstanding issues at IETF 102. > > > thanks, > Suzanne, Tim, & Benno > ___ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop > ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Working Group Last Call on draft-ietf-dnsop-terminology-bis
Greetings! I really like the draft, and I'm sorry to be so late. I see one minor issue just below and then a few nitpicks that I don't feel strongly about. > NXDOMAIN: > "Name Error - Meaningful only for responses from an authoritative > name server, this code signifies that the domain name referenced in > the query does not exist." (Quoted from [RFC1035], Section 4.1.1.) > [RFC2308] established NXDOMAIN as a synonym for Name Error. I dislike keeping this formulation; it might confuse people. It seems to imply that NXDOMAIN from a resolver isn't "meaningful", and that's clearly not true, at least not nowadays. (I develop a resolver.) "Resolver" definition: I don't think the word really implies it runs on the same machine as the program asking it. In particular, the purpose of stub resolvers is to ask a recursive *resolver* that is typically on another machine. Perhaps I misunderstand that RFC1034 part. I found one comment on this particular point but no reactions: https://mailarchive.ietf.org/arch/msg/dnsop/tCZD120ehRkK52ikTWuZ-t5Tf2w "Authoritative-only server" definition: "ignores requests for recursion" might mislead into thinking the DNS request is not replied to, whereas the server is supposed to return either REFUSED or a referral. Maybe I'd say something like "ignores the RD bit being set to 1". "Slave server", "Master server": I'm surprised to read that current common usage has shifted to "secondary" and "primary" instead, but that is better judged by people working with authoritative servers (and not me). > Open resolver: A full-service resolver that accepts and processes > queries from any (or nearly any) stub resolver. [...] Perhaps not from any "stub resolver" but from any "client". *Who* asks really isn't the point. "Authoritative data" definition: there might be a mention of special cases added later or perhaps switch quotation to one from rfc4033#section-2 "Bailiwick" definition: I have (also) seen use like "in-bailiwick records" in the sense being in a subdomain. I can't really judge how common that usage is, but it has already been discussed wrt. this draft: https://mailarchive.ietf.org/arch/msg/dnsop/MyEdXXdUKKyTTfX3_4_7AnhE3Io My understanding of that thread is that the meaning was planned to be extended in the draft, but the current text seems still restricted to name servers. "NSEC3" definition, this is clearly a typo (missing "3"): > NSEC resource records require associated NSEC3PARAM resource records. I'm not really sure if a best-practice RFC is really allowed to "update" a standards-track RFC (2308), but I assume the authors and chairs know the process much better than me. (From my point of view it's OK.) --Vladimir ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] Working Group Last Call on draft-ietf-dnsop-terminology-bis
Colleagues, This begins the working group last call for draft-ietf-dnsop-terminology-bis-10, "DNS Terminology”. The document has gotten significant feedback and the editors have worked hard to document current terminology usage, both among practitioners and for broader audiences; we’d like to advance it. We’re seeking consensus to advance it to the IESG with an intended status of Best Current Practice. Note that it’s intended to obsolete RFC 7719 ( the earlier “DNS Terminology” document). If you support it, please say so. If you don’t, please say why. The current version is at: https://datatracker.ietf.org/doc/draft-ietf-dnsop-terminology-bis/ Last Call will run for two weeks, closing on Friday July 6. This will allow for discussion of any major outstanding issues at IETF 102. thanks, Suzanne, Tim, & Benno ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
