jiebi/CodeConvo huggingface dataset:
Change:
Two definitions of In-bailiwick are unclear and seems the same. In-bailiwick name server names have two meanings. One is narrow and requires glue records. The other is wide and may have glue records. There are needs to distinguish two types of in-bailiwick name server names. Ondrej Sury used NS Types as in OARC 26. URL Peter Koch proposed "in domain", "sibing domain", and "unrelated". "unrelated" is out-of-bailiwick. URL I propose to add "in domain" and "sibling domain", update "in-bailiwick" and add a description for "out-of-bailiwick". If this proposal is reasonable, please improve the text and merge.
lgtm (apart from the typo)
I like the idea but still, this is sufficiently muddy area to warrant short example for each type. It will be great with examples and I will definitely support the new wording over the old one.

Discussion:
<del> (a) An adjective to describe a name server whose name is either </del> <ins> An adjective to describe a name server whose name is either </ins> subordinate to or (rarely) the same as the zone origin.  In- <del> bailiwick name servers require glue records in their parent zone </del> <ins> bailiwick name servers may have glue records in their parent zone </ins> (using the first of the definitions of "glue records" in the <del> definition above). (b) Data for which the server is either authoritative, or else authoritative for an ancestor of the owner name.  This sense of the term normally is used when discussing the relevancy of glue records in a response.  For example, the server for the parent zone "example.com" might reply with glue records for "ns.child.example.com".  Because the "child.example.com" zone is a descendant of the "example.com" zone, the glue records are in- bailiwick. The antonym of in-bailiwick. </del> <ins> definition above).  'In-bailiwick' names are divided into two type of name server names: 'in-domain' names and 'Sibling domain' names. An adjective to describe a name server whose name is either subordinate to or (rarely) the same as the ownwer name of the NS resource records.  In-domain name server name MUST have glue records or name resolution fails.  For example, a delegation for "child.example.com" may have "in-domain" name server name "ns.child.example.com". 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.  Glue records for sibling domains are allowed, but not necessary.  For example, a delegation for "child.example.com" in "example.com" zone may have "Sibling" name server name "ns.another.example.com". 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.  Glue records for out-of-bailiwick name servers are useless. </ins> "All of the RRs attached to all of the nodes from the top node of the zone down to leaf nodes or nodes above cuts around the bottom
Change:
I have been unable to find a definition of "insecure delegation", but it is a term in common use. The closest I found was some handwaving in the NSEC3 doc. Perhaps worth adding? [ Feel free to close issue if inappropriate, etc. ]
We should define it. It appears starting in RFC 4956. The definition there is: That seems fine to me
Fixed in URL

Discussion:
to prove or deny the existence of the insecure delegations. (Adapted from RFC7129, Section 5.1) <ins> "A signed name containing a delegation (NS RRset), but lacking a DS RRset, signifying a delegation to an unsigned subzone." (Quoted from RFC4956, Section 2.) </ins> "The practice of discovering the full content of a zone via successive queries."  (Quoted from RFC5155, Section 1.3.)  This is also sometimes called "zone walking".  Zone enumeration is
Change:
In June 2015, Joe Abley said: I think that "superordinate" and "subordinate" might be worth mentioning here, with reference to their definitions in EPP.
Added in URL
I think this is ok. Friendly amendment is to note that these are strictly ways of referring to the relationship standing of two domains where one is a subdomain of the other. (But I don't know that we need to do this, hence the approval.)

Discussion:
function is performed by the DNS operator plus other entities who decide about the allowed contents of the zone. <ins> These terms are introduced in RFC3731 but not defined there. Instead, they are given in examples.  "For example, domain name 'example.com' has a superordinate relationship to host name ns1.example.com'."  "For example, host ns1.example1.com is a subordinate host of domain example1.com, but it is a not a subordinate host of domain example2.com."  (Quoted from RFC3731, Section 1.1.)  These terms are strictly ways of referring to the relationship standing of two domains where one is a subdomain of the other. </ins> 8. Most DNSSEC terms are defined in RFC4033, RFC4034, RFC4035, and

Stealth server Stub resolver Subdomain <ins> Subordinate Superordinate </ins> T TLD
Change:
…erative resolution
Agree with your fix to the definition.
During the lead-up to RFC 7719, Tony Finch asked for four terms to be defined: Recursive query Non-recursive query Iterative query Iterative resolution The were not in RFC 7719 but could be in the -bis.
Updated the document in URL
I don't think iterative query is a synonym. I think an iterative query is a non-recursive query that happens to be a query in a series of recursive queries but that is itself not a recursive query. No? That seems more consistent with the iterative resolution definition that follows.

Discussion:
make it a full-service resolver), but some recursive resolvers might not cache. <ins> A query with the Recursion Desired (RD) bit set to 1 in the header.(See Section 4.1.1 of RFC1035.)  If recursive service is available and is requested by the RD bit in the query, the server uses its resolver to answer the query.  (See Section 4.3.2 of RFC1035.) A query with the Recursion Desired (RD) bit set to 0 in the header.  A server can answer non-recursive queries using only local information: the response contains either an error, the answer, or a referral to some other server "closer" to the answer. (See Section 4.3.1 of RFC1035.) Synonym for non-recursive query that happens to be a query in a series of recursive queries, but that is itself not a recursive query.  This term is used in a number of RFCs though never explicitly defined. A name server may be presented with a query that can only be answered by some other server.  The two general approaches to dealing with this problem are "recursive", in which the first server pursues the query for the client at another server, and "iterative", in which the server refers the client to another server and lets the client pursue the query there.  (See Section 2.3 of RFC1034.) In iterative resolution, the client repeatedly makes non-recursive queries and follows referrals and/or aliases.  The iterative resolution algorithm is described in Section 5.3.3 of RFC1034. </ins> "The act of finding the list of root servers from a configuration that lists some or all of the purported IP addresses of some or all of those root servers."  (Quoted from RFC8109, Section 2.)

Insecure delegation Instance Iterative mode <ins> Iterative query Iterative resolution </ins> K Key signing key (KSK)

Negative caching Negative response Next closer name <ins> Non-recursive query </ins> O OPT

RR RRset Recursive mode <ins> Recursive query </ins> Recursive resolver Referrals Registrant
Change:
I have added your text (approximately) and merged the pull request.
During the discussion that led to RFC 7719, there was a request to split out error names in their own terms to make them easier to find in the document. Now with the index in place, this seems like a good idea.
Oooh, yes, I think that this would be great. [Sorry for the non-substantive / bikeshed comment]
Entered in the doc as URL
I think this is ok, but I'd like a tiny edit before the list starts: "The names as of this writing are described below, but the official list is in the IANA registry." Or something like this. I just don't want to suggest we're arguing with the authoritative registry.

Discussion:
response. Some of response codes that are defined in RFC1035 have acquired <del> their own shorthand names.  Some common response code names that appear without reference to the numeric value are "FORMERR", "SERVFAIL", and "NXDOMAIN" (the latter of which is also referred to as "Name Error").  All of the RCODEs are listed at </del> <ins> their own shorthand names.  All of the RCODEs are listed at </ins> http://www.iana.org/assignments/dns-parameters, although that site uses mixed-case capitalization, while most documents use all-caps. <ins> Some of the names are described here, but the official list is in the IANA registry. "No error condition" (Quoted from RFC1035, Section 4.1.1.) "Format error - The name server was unable to interpret the query."  (Quoted from RFC1035, Section 4.1.1.) "Server failure - The name server was unable to process this query due to a problem with the name server."  (Quoted from RFC1035, Section 4.1.1.) "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.) "Not Implemented - The name server does not support the requested kind of query."  (Quoted from RFC1035, Section 4.1.1.) "Refused - The name server refuses to perform the specified operation for policy reasons.  For example, a name server may not wish to provide the information to the particular requester, or a name server may not wish to perform a particular operation (e.g., zone transfer) for particular data."  (Quoted from RFC1035, Section 4.1.1.) </ins> "A pseudo RCODE which indicates that the name is valid for the given class, but there are no records of the given type.  A NODATA

Empty non-terminals (ENT) F <ins> FORMERR </ins> Fast flux DNS Forward lookup Forwarder

N NODATA <ins> NOERROR NOTIMP </ins> NSEC NSEC3 <ins> NXDOMAIN </ins> Naming system Negative caching Negative response

Root zone S <ins> SERVFAIL </ins> SOA field names Secondary server Secure Entry Point (SEP)
Change:
The current definition says: The example is ambiguous. It should instead say:
PR is at URL
FWIW I still find it confusing. proposed alternative: The need for the term "fully qualified domain name" comes from the existence of partially qualified domain names, which are names where one or more of the later labels in the desired name are omitted. For example, a user may enter "www" and rely on the application or operating system to append an appropriate domain suffix, turning it into "URL". Such partially qualified names are understood only by context.
Hi, I’m a bit confused by “earliest” and “latest” here— Paul’s wording ("earliest labels in the ordered list”) made sense to me but Duane changed it (to “later labels in the desired list”). I’d suggest making it explicitly refer to "earlier labels in the ordering of nodes from the root of the tree,” because otherwise “earlier” or “later” both make my head hurt. Suzanne
My thinking was that as I read the name (e.g. left-to-right) the "www" part is earliest and the "URL" part is later. The way we talk about ordering of labels seems sort of fundamental and it would be a shame to have it buried in this one definition of FQDN. Its not really a terminology issue, but is there some way to make it more prominent and apply to the document as a whole?
Understood, was just thinking that it’s not obvious whether we mean reading order or evaluation order or something else unless we say so. Hadn't thought of it, but yes. This is where I’m reminded there’s not really a definition of “domain name” out there to incorporate. There’s been a proposed definition kicking around for awhile, which was briefly discussed somewhere (the arcing list?) and I tried to get Ed Lewis to add to draft-lewis-domain-name. I don’t think this document is the place to propose one not previously found in an RFC, although I’d be fine with the WG considering the question if the editors disagree. Suzanne
There is in fact a definition of "domain name" to incorporate. Under "Global DNS", it says: We use "first" there, and we use it in a way that is the opposite of "earliest" in the current wording for FQDN, and thus the need for change. Duane's proposal is better than what we have now, but we can maybe even do better. How about:

Discussion:
The need for the term "fully qualified domain name" comes from the existence of partially qualified domain names, which are names where one or more of the earliest labels in the ordered list are <del> omitted (for example, "www").  Such relative names are understood only by context. </del> <ins> omitted (for example, a name of "www" derived from "www.example.net").  Such relative names are understood only by context. </ins> This term and its equivalent, "hostname", have been widely used but are not defined in RFC1034, RFC1035, RFC1123, or RFC2181.  The
Change:
In May, 2015, Tony Finch noted that the definition of "referral" in the current draft at the time was not good. He said: It would be good to review the current definition and make improvements if necessary.
Fixed with PR

Discussion:
name actually queried or else the last name in a CNAME chain response. <del> [[ This text is being modified in the WG and a changed definition will appear in a future draft. ]] Data from the authority section of a non-authoritative answer. RFC1035 Section 2.1 defines "authoritative" data.  However, referrals at zone cuts (defined in zones) are not authoritative. Referrals may be zone cut NS resource records and their glue records.  NS records on the parent side of a zone cut are an authoritative delegation, but are normally not treated as authoritative data.  In general, a referral is a way for a server to send an answer saying that the server does not know the answer, but knows where the query should be directed in order to get an answer.  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. </del> 5.
Change:
In the "TTL" section this appears: Also, if a value is flushed from the cache when its value is still positive, the value effectively becomes zero. (1) Doesn't make sense to flush a value. I think the intention was to say "if an RRSet is flushed..." (2) nitpick: "when its value is still positive" sounds like maybe it makes assumptions about the way that caches work. It sounds like the TTL is decremented and updated in the cache over time. Something like "URL the end of the TTL interval" may be better. (3) I'm not quite sure what "effectively becomes zero" means for data that has been flushed. If its flushed its gone or at least not usable again in the future.

Discussion:
The reason that the TTL is the maximum time to live is that a cache operator might decide to shorten the time to live for operational purposes, such as if there is a policy to disallow TTL <del> values over a certain number.  Also, if a value is flushed from the cache when its value is still positive, the value effectively becomes zero.  Some servers are known to ignore the TTL on some RRsets (such as when the authoritative data has a very short TTL) even though this is against the advice in RFC 1035. </del> <ins> values over a certain number.  Some servers are known to ignore the TTL on some RRsets (such as when the authoritative data has a very short TTL) even though this is against the advice in RFC 1035.  An RRset can be flushed from the cache before the end of the TTL interval, at which point the value of the TTL becomes unknown because the RRset with which it was associated no longer exists. </ins> There is also the concept of a "default TTL" for a zone, which can be a configuration parameter in the server software.  This is
Change:
There are still inconsistencies remaining. : it can be fully qualified (in which case, it begins at the common root of the graph) : partially qualified domain names, which are names where one or more of the earliest labels in the ordered list are omitted (for example, a name of "www" derived from "URL") Suggestions: Explicitly specify ordering in "Domain name": _ → Any path of a directed acyclic graph can be represented by a domain name consisting of the labels of its nodes, ordered by decreasing distance from the root(s). A domain name whose last label identifies a root of the graph is fully qualified; other domain names whose labels form a strict prefix of a fully qualified domain name are relative to its first omitted node. Note that the generality of "domain name" requires careful language here to accommodate arbitrary edge direction (parent→child vs. child→parent) and graph topology (e.g., non-tree DAGs can have multiple roots and/or multiply-referenced nodes). Update "Fully qualified domain name" accordingly: partially qualified domain names, which are names where one or more of the last labels in the ordered list are omitted (for example, a name of "www" relative to "URL" identifies "URL")_.

Discussion:
Composition of names -- A name in the global DNS has one or more labels.  The length of each label is between 0 and 63 octets <del> inclusive.  In a fully-qualified domain name, the first label in </del> <ins> inclusive.  In a fully-qualified domain name, the last label in </ins> the ordered list is 0 octets long; it is the only label whose length may be 0 octets, and it is called the "root" or "root label".  A domain name in the global DNS has a maximum total
Change:
"each other" is clearer in English. I agree that "whole labels" is better and have changed the text.
At line 139, "each other" may be "others" ? At line 358, "full labels" may be "whole labels" or "each label".

Discussion:
2. A naming system associates names with data.  Naming systems have <del> many significant facets that help differentiate them.  Some commonly-identified facets include: </del> <ins> many significant facets that help differentiate them from each other.  Some commonly-identified facets include: </ins> Composition of names

the subdomain's name ends with the containing domain's name." (Quoted from RFC1034, Section 3.1).  For example, in the host name "nnn.mmm.example.com", both "mmm.example.com" and <del> "nnn.mmm.example.com" are subdomains of "example.com". </del> <ins> "nnn.mmm.example.com" are subdomains of "example.com".  Note that the comparisons here are done on whole labels; that is, "ooo.example.com" is not a subdomain of "oo.example.com". </ins> The owner of a CNAME resource record, or a subdomain of the owner of a DNAME resource record (DNAME records are defined in RFC6672).

name server side (which is what answers the query) and a resolver side (which performs the resolution function).  Systems operating in this mode are commonly called "recursive servers".  Sometimes <del> they are called "recursive resolvers".  While strictly the difference between these is that one of them sends queries to another recursive server and the other does not, in practice it is not possible to know in advance whether the server that one is </del> <ins> they are called "recursive resolvers".  In practice it is not possible to know in advance whether the server that one is </ins> querying will also perform recursion; both terms can be observed in use interchangeably.

and controls at a high level."  (Quoted from RFC6841, Section 2) A specialized piece of hardware that is used to create keys for <del> signatures and to sign messages.  In DNSSEC, HSMs are often used to hold the private keys for KSKs and ZSKs and to create the signatures used in RRSIG records at periodic intervals. </del> <ins> signatures and to sign messages without ever disclosing the private key.  In DNSSEC, HSMs are often used to hold the private keys for KSKs and ZSKs and to create the signatures used in RRSIG records at periodic intervals. </ins> Authoritative DNS servers that support DNSSEC often contain software that facilitates the creation and maintenance of DNSSEC
Change:
I like the additional wording. I'll add it and take the question to the chairs to take to the WG.
Good catch on "DNS over TLS" -> "DNS over HTTPS". I didn't go with "DNS Queries over HTTPS" because it doesn't really describe the protocol.
Simple mistake: "DNS over TLS" should be "DNS over HTTPS" at line 1040. Or "DNS Queries over HTTPS" may be better because it is a draft name.If we're going to add class here, then I think (1) we need to go back to the WG and (2) we need to add something: "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 wrote a doc some time ago attempting to deprecate class, because of the way it keeps popping up as though it is viable.

Discussion:
record is called the "RDATA", and the authoritative answer bit is often called "the AA flag" or "the AA bit". <ins> 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. </ins> The most commonly-used rough definition is that the QNAME is a field in the Question section of a query.  "A standard query specifies a target domain name (QNAME), query type (QTYPE), and

sequence of a specific transaction.  (Definition from RFC6891, Section 6.1.1) It is used by EDNS. <del> The domain name where a RR is found (RFC1034, Section 3.6).  Often appears in the term "owner name". </del> <ins> "The domain name where a RR is found" (Quoted from RFC1034, Section 3.6).  Often appears in the term "owner name". </ins> DNS documents, including the definitions here, often refer to the fields in the RDATA of an SOA resource record by field name.

"A DNS server that implements DNS over TLS RFC7858 and may optionally implement DNS over DTLS RFC8094."  (Quoted from <del> RFC8310, Section 2) </del> <ins> RFC8310, Section 2) Other types of DNS servers might also be considerd privacy-enabling, such as those running DNS over HTTPS I-D.ietf-doh-dns-over-https. </ins> 7.

CNAME Canonical name Child <ins> Class </ins> Class independent Closest encloser Closest provable encloser