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.)
On 4/29/15, 14:13, "internet-dra...@ietf.org" <internet-dra...@ietf.org> wrote: >A New Internet-Draft is available from the on-line Internet-Drafts >directories. > This draft is a work item of the Domain Name System Operations Working >Group of the IETF. Comments in-line #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. #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. #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. #3. DNS Header and Response Codes #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. #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. 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. # 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. ;) # 5. DNS Servers #[[ 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. #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. #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. # 6. Zones #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. #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." #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. #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... # 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.) 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. #8. General DNSSEC #Most DNSSEC terms are defined in [RFC4033], [RFC4034], and [RFC4035]. (To get this response off sooner, I'll skip the DNSSEC stuff as it seems to be tied to documents. If there's a need to make DNSSEC less confusing [cough, cough]...that'll take more work.)
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
