Thanks for the comments. On Apr 29, 2015, at 12:28 PM, Edward Lewis <edward.le...@icann.org> wrote: > Somewhere I saw "domaine" in the doc - can't find it now - and that > started me trying to mark this up. (I hadn't read the document in full > before, so this is a first review for me.)
<sigh> Found it. Fixed. > #ccTLD -- A TLD that is allocated to a country. Historically, these > #were two-letter TLDs, and were allocated to countries using the two- > #letter code from the ISO 3166-1 alpha-2 standard [ISO3166]. In > #recent years, there have been allocations of TLDs that conform to > #IDNA2008 ([RFC5890], [RFC5891], [RFC5892], [RFC5893], and [RFC5894]); > #these are still treated as ccTLDs for policy purposes. > > "Country" is a loaded term. I don't have a better suggestion in mind but > there are many instances where a ccTLD is a territory, etc. I don't mean > to open a rathole, just point this out. "Country" is a term of art in politics. There are definitions that most people agree to, at least when it suits them. > #gTLD -- A "generic" TLD is a TLD that is not a ccTLD, and is not one > #of the small number of historical TLDs such as .int and .arpa. There > #is no precise definition for which TLDs that are not ccTLDs are > #gTLDs. > > Might as well also list sTLD for sponsored. Technically there is no > difference, it's all in the way the registry has been instituted. I think "sTLD" is a term used in ICANN, not in the DNS, whereas gTLD has definitely slipped into DNS language. > #Public suffix -- A domain under which subdomains can be registered, > #and on which HTTP cookies ([RFC6265]) should not be set. There is no > #indication in a domaine name whether or not it is a public suffix; > #that can only be determined by outside means. The IETF DBOUND > #Working Group [DBOUND] deals with issues with public suffixes. > > I wouldn't mention DBOUND as WGs come and go but RFCs are forever. *Many* RFCs mention WGs in various ways. Note that, even though WGs come and go, even closed WGs are listed on the IETF web site. > #NODATA - This is not an actual response code, but is a particular > #type of response from a server that indicates that the queried domain > #name exists for the given class, but the resource record type being > #queried for does not exist. A NODATA response is a combination of an > #RCODE of 0 (NOERROR) and an Answer section that is empty. In > #addition, NODATA responses from authoritative servers have the > #authoritative answer (AA bit) set to 1 and include an SOA record. > #Section 1 of [RFC2308] defines NODATA as "a pseudo RCODE which > #indicates that the name is valid, for the given class, but are no > #records of the given type". The term "NXRRSET" is becoming more > #common as a synonym for NODATA. > > I never thought NODATA meant NOERROR, just simply an empty answer section. > I have never seen the term outside of "NOERROR/NODATA" either, so is > might see NODATA implies RCODE=0. Just my personal viewpoint. This confuses me, given the definition in RFC 2308. Are you saying that a NODATA response might have an RCODE that is not 0? If so, what are the allowed values for RCODE in a NODATA response? > #Negative response -- A response whose RCODE indicates that a > #particular RRset does not exist in the DNS or a failure of a > #nameserver. Sections 2 and 7 of [RFC2308] describes the types of > #negative responses in detail. > > More simply (and not the same as the above) a failure to find requested > records. I.e., not a name server failure. That definition is at odds with RFC 2308, which says: 7 - Other Negative Responses . . . 7.1 Server Failure (OPTIONAL) > Perhaps my interpretation > differs because it's never been stated what is a "final" response or an > "intermediary" response - i.e., what is sent to a stub upon its request as > opposed to a referral. I'm not seeing any use of those terms in RFCs, but I might have missed them. > > # 4. Resource Records > > #EDNS -- Also commonly called "EDNS0", this is the extension > #mechanisms for DNS. The extension mechanism, defined in [RFC6891], > #allows DNS clients and servers to specify message sizes larger than > #the original 512 octet limit, to expand the response code space, and > #to potentially carry additional options that affect the handling of a > #DNS query. > > Often misspelled as ENDS. ;) Appendix A. Common Misspellings of DNS Trems > #[[ There is a request to "first describe the iterative and recursive > #resolution processes, and mention the expected values of the RD,RA,AA > #bits. Then you can describe the distinctions between recursive and > #iterative clients, and between recursive and authoritative servers, > #in terms of the roles they play in the different resolution > #processes." This would require the section to be quite different > #than the other sections in the document. ]] > > The fact that this request has been made is an indication that needed RFCs > haven't been written. This document isn't the place to do that, IMHO. A > lot of "things" just have never been documented. That's what I feel as well, but we wanted to leave the comment in for the WG LC in case someone wants to tackle the rewrite. > #to those "outside" that network. Views are not a standardized part > #of the DNS, but they are widely implemented in server software. > > "not a standardized part...but...widely implemented" From this, we need > to do more writing. ...but not here. > > #Child-centric resolver -- A DNS resolver that, instead of serving the > #NS RRset and glue records that it obtained from the parent of a zone, > #serves data from the authoritative servers for that zone. The term > #"child-centric" is meant as the opposite of "parent-centric", which > #means a resolver that simply serves the NS RRset and glue records for > #a zone that it obtained from the zone's parent, without checking the > #authoritative servers for that zone. > > Count me as wondering why this term is included here. Perhaps the > terminology document, especially for terms outside the RFCs, should cite > where the terms are in use. I'm not disagreeing with the text above, I > just don't know why this term is even being considered. There were a few requests from the WG earlier. I'm happy to take it out, given that it doesn't appear in any RFC. > #Parent -- The domain in which the Child is registered. (Quoted from > #[RFC7344], section 1.1) Earlier, "parent name server" was defined in > #[RFC0882] as "the name server that has authority over the place in > #the domain name space that will hold the new domain". > > Speaking from personal experience, I'd use "delegated" and not registered. > In my world, there is a distinction in what is "registered" and what is > "delegated." I don't mean to derail this into a registry vs. DNS > operations discussion, just saying that the term "registered" means > something different in a field (registration of domain names and internet > numbers) very close to DNS. I agree with you about "delegated" being a better word, but if we're going to quote from RFCs, particularly recent ones that were vetted in this WG, we shouldn't be changing the words. > #Delegation -- The process by which a separate zone is created in the > #name space beneath the apex of a given domain. Delegation happens > #when an NS RRset is added in the parent zone for the child origin, > #and a corresponding zone apex is created at the child origin. > #Delegation inherently happens at a zone cut. > > I agreed up until "and a corresponding..." Once the parent creates the > zone cut, the delegation is made. The distinction is that in the world of > operations, the child's servers may be unavailable (down or cut off the > net). The delegation is still there, no one can confirm the > "corresponding" stuff mentioned here. Vice versa, once the parent removes > the NS set, the delegation is removed regardless of what the child > "thinks." That seems rational. Do others agree that we should remove "and a corresponding zone apex is created at the child origin" because that step is not necessary for a delegation to take place? > #Referrals -- ... Historically, many > #authoritative servers answered with a referral to the root zone when > #queried for a name for which they were not authoritative, but this > #practice has declined. > > Not declined - seen as a vulnerability and removed from code. The > practice was never defined as a part of the DNS protocol. When it became > the subject of abusive traffic, implementers agreed to stop issuing > "referrals to the root" to indicate lame servers. ...and thus the practice has declined. We could add text about why it has declined, but it doesn't help the definition. > #Fast flux DNS -- A mechanism where a large number of hosts rapidly > #update the address records of a zone, often to deliver malware. > #Because the addresses change so rapidly, it is difficult to > #definitively find all the hosts. > > Really would help to have references. The definition is good but if this > were wikipedia... Fully agree, but I failed to find anything. There was enough interest in the WG to add the term; I would rather not remove it just because we can't give a definitive pointer to a definition. > # 7. Registration Model > > #Registry -- The administrative operation of a zone that allows > #registration of names within that zone. > > A registry is the database (in the virtual sense) used by a DNS > administration to know what information to include in a zone. The > database may be in one's head, in a text file, in Oracle, etc. The > database schema may have contact information for each domain name. > Essential to the DNS is that there is a record of what data sets are in > the zone (A, AAAA, NS, etc.). Registries may range from the back of one's > head to full-time, high capacity operations. (This is off the top of my > head. I'd never thought to define a registry in the DNS protocol sense > before.) Do others here want to go into that level of detail? It might be useful for some readers, or it might be "too much". > Since you are "going there" - define the "Shared Registry Model". Web > searching for this includes this: > http://www.difo.dk/en/internet_governance/sole_vs_shared_registry_model/ > > But I don't know if you really want to open this document to get into > registration of data and how that impacts the DNS. To me, registration != > DNS operation, despite appearances otherwise. Also, that term seems to be barely used. --Paul Hoffman _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
