function is performed by the DNS operator plus other entities who decide about the allowed contents of the zone.  8. Most DNSSEC terms are defined in RFC4033, RFC4034, RFC4035, and Stealth server Stub resolver Subdomain  T TLD

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.)

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


make it a full-service resolver), but some recursive resolvers might not cache.  "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  K Key signing key (KSK) Negative caching Negative response Next closer name  O OPT RR RRset Recursive mode  Recursive resolver Referrals Registrant

…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.

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


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>  http://www.iana.org/assignments/dns-parameters, although that site uses mixed-case capitalization, while most documents use all-caps.  "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  Fast flux DNS Forward lookup Forwarder N NODATA  NSEC NSEC3  Naming system Negative caching Negative response Root zone S  SOA field names Secondary server Secure Entry Point (SEP)

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.

response. Some of response codes that are defined in RFC1035 have acquired  <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)


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>  This term and its equivalent, "hostname", have been widely used but are not defined in RFC1034, RFC1035, RFC1123, or RFC2181.  The

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:

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  <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


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.

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

name actually queried or else the last name in a CNAME chain response.  5.


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>  There is also the concept of a "default TTL" for a zone, which can be a configuration parameter in the server software.  This is

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.

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  <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


due to a problem with the name server."  (Quoted from RFC1035, Section 4.1.1.) <del> "Name Error - Meaningful only for responses from an authoritative name server, this code signifies that the domain name referenced </del>  in the query does not exist."  (Quoted from RFC1035, Section 4.1.1.)  RFC2308 established NXDOMAIN as a synonym for Name Error. A program "that extract[s] information from name servers in response to client requests."  (Quoted from RFC1034, Section 2.4) <del> "The resolver is located on the same machine as the program that requests the resolver's services, but it may need to consult name servers on other hosts."  (Quoted from RFC1034, Section 5.1) A resolver performs queries for a name, type, and class, and </del>  receives answers.  The logical function is called "resolution". In practice, the term is usually referring to some specific type of resolver (some of which are defined below), and understanding requests for recursion.  It will "not normally generate any queries of its own.  Instead, it answers non-recursive queries from iterative resolvers looking for information in zones it <del> serves."  (Quoted from RFC4697, Section 2.4) </del>  The act of a client requesting a copy of a zone and an authoritative server sending the needed information.  (See zones resolver being informed. A full-service resolver that accepts and processes queries from <del> any (or nearly any) stub resolver.  This is sometimes also called a "public resolver", although the term "public resolver" is used </del>  more with open resolvers that are meant to be open, as compared to the vast majority of open resolvers that are probably misconfigured to be open.  Open resolvers are discussed in the delegation, even though they are not themselves authoritative data.  "A lame delegations exists when a nameserver is delegated responsibility for providing nameservice for a zone (via NS records) but is not performing nameservice for that zone (usually Like the NSEC record, the NSEC3 record also provides authenticated denial of existence; however, NSEC3 records mitigate against zone <del> enumeration and support Opt-Out.  NSEC resource records require </del>  associated NSEC3PARAM resource records.  NSEC3 and NSEC3PARAM resource records are defined in RFC5155.

There is one typo at "Authoritative data:". Other differences are OK. | , Section 2, defines "Authoritative RRset" which is related | to authoritative data [bu] has a more precise definition. ("bu"is "but" ?)
I missed to change branch and I commited to this branch. please review "f172affe0f5d111af23f8c48f9ed5715e7b314d0".

due to a problem with the name server."  (Quoted from RFC1035, Section 4.1.1.)  <ins> "Name Error - This code signifies that the domain name referenced </ins> in the query does not exist."  (Quoted from RFC1035, Section 4.1.1.)  RFC2308 established NXDOMAIN as a synonym for Name Error. A program "that extract[s] information from name servers in response to client requests."  (Quoted from RFC1034, Section 2.4)  <ins> A resolver performs queries for a name, type, and class, and </ins> receives answers.  The logical function is called "resolution". In practice, the term is usually referring to some specific type of resolver (some of which are defined below), and understanding requests for recursion.  It will "not normally generate any queries of its own.  Instead, it answers non-recursive queries from iterative resolvers looking for information in zones it  <ins> serves."  (Quoted from RFC4697, Section 2.4) In this case, "ignores requests for recursion" means "responds to requests for recursion with responses indicating that recursion was not performed". </ins> The act of a client requesting a copy of a zone and an authoritative server sending the needed information.  (See zones resolver being informed. A full-service resolver that accepts and processes queries from  <ins> any (or nearly any) client.  This is sometimes also called a "public resolver", although the term "public resolver" is used </ins> more with open resolvers that are meant to be open, as compared to the vast majority of open resolvers that are probably misconfigured to be open.  Open resolvers are discussed in the delegation, even though they are not themselves authoritative data. <ins> RFC4033, Section 2, defines "Authoritative RRset" which is related to authoritative data but has a more precise definition. </ins> "A lame delegations exists when a nameserver is delegated responsibility for providing nameservice for a zone (via NS records) but is not performing nameservice for that zone (usually Like the NSEC record, the NSEC3 record also provides authenticated denial of existence; however, NSEC3 records mitigate against zone  <ins> enumeration and support Opt-Out.  NSEC3 resource records require </ins> associated NSEC3PARAM resource records.  NSEC3 and NSEC3PARAM resource records are defined in RFC5155.


"and are, or will be, resolvable in the global DNS" or "but only using the presentation format". <del> 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. </del>  Using the short set of facets listed in "Naming system", the global DNS can be defined as follows.  Most of the rules here come (ICANN).  The names operational community selects the IANA Functions Operator for the global DNS root zone.  At the time this document is published, that operator is Public Technical <del> Identifiers (PTI).  The name servers that serve the root zone are provided by independent root operators.  Other zones in the global DNS have their own policies for administration. </del>  Types of data that can be associated with names -- A name can have zero or more resource records associated with it.  There are DNS documents, including the definitions here, often refer to the fields in the RDATA of an SOA resource record by field name. <del> Those fields are defined in Section 3.3.13 of RFC1035.  The names (in the order they appear in the SOA RDATA) are MNAME, RNAME, SERIAL, REFRESH, RETRY, EXPIRE, and MINIMUM.  Note that the meaning of MINIMUM field is updated in Section 4 of RFC2308; the new definition is that the MINIMUM field is only "the TTL to be used for negative responses".  This document tends to use field names instead of terms that describe the fields. </del>  The maximum "time to live" of a resource record.  "A TTL value is an unsigned number, with a minimum value of 0, and a maximum value "A server that knows the content of a DNS zone from local knowledge, and thus can answer queries about that zone without needing to query other servers."  (Quoted from RFC2182, <del> Section 2.)  It is a system that responds to DNS queries with information about zones for which it has been configured to answer with the AA flag in the response header set to 1.  It is a server that has authority over one or more DNS zones.  Note that it is possible for an authoritative server to respond to a query without the parent zone delegating authority to that server. Authoritative servers also provide "referrals", usually to child zones delegated from them; these referrals have the AA bit set to 0 and come with referral data in the Authority and (if needed) the Additional sections. </del>  A name server that only serves authoritative data and ignores requests for recursion.  It will "not normally generate any zone that have changed (described in RFC1995).  Many systems use non-standard methods for zone transfer outside the DNS protocol.  "An authoritative server which uses zone transfer to retrieve the zone" (Quoted from RFC1996, Section 2.1).  Secondary servers are also discussed in RFC1034.  RFC2182 describes secondary servers in this as a "slave", the current common usage has shifted to calling it a "secondary". <del> See secondary server. </del>  "Any authoritative server configured to be the source of zone transfer for one or more [secondary] servers" (Quoted from RFC1996 referred to this as a "master", the current common usage has shifted to "primary". <del> See primary server. </del> "The primary master is named in the zone's SOA MNAME field and optionally by an NS RR".  (Quoted from RFC1996, Section 2.1). RFC2136 defines "primary master" as "Master server at the root of NODATA NOERROR NOTIMP  NSEC NSEC3 NXDOMAIN S SERVFAIL  SOA field names Secondary server Secure Entry Point (SEP)

Agree with the first one, although I don't care which way it comes out from the RFC Editor. For the second one, I have changed the wording to 'An authoritative server is named in the NS ("name server") record in a zone.' We don't need to stray into which zone has authoritative data; the double use of "authoritative" will confuse the reader without helping with the terminology.
l 179, s/octets which/octets that. This has been changed to violate the that/which conventions of the RFC Editor. l844 (new) the authoritative name server is named in the parent zone but is not authoritative data there (NS is authoritative in the child). This is discussed elsewhere in the document, and I find this addition confusing. I won't hold up pver either of these. The rest looks ok.

"and are, or will be, resolvable in the global DNS" or "but only using the presentation format".  <ins> An ordered list of zero or more octets that 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. </ins> Using the short set of facets listed in "Naming system", the global DNS can be defined as follows.  Most of the rules here come (ICANN).  The names operational community selects the IANA Functions Operator for the global DNS root zone.  At the time this document is published, that operator is Public Technical  <ins> Identifiers (PTI).  (See <https://pti.icann.org/> for more information about PTI operating the IANA Functions.)  The name servers that serve the root zone are provided by independent root operators.  Other zones in the global DNS have their own policies for administration. </ins> Types of data that can be associated with names -- A name can have zero or more resource records associated with it.  There are DNS documents, including the definitions here, often refer to the fields in the RDATA of an SOA resource record by field name.  <ins> "SOA" stands for "start of a zone of authority".  Those fields are defined in Section 3.3.13 of RFC1035.  The names (in the order they appear in the SOA RDATA) are MNAME, RNAME, SERIAL, REFRESH, RETRY, EXPIRE, and MINIMUM.  Note that the meaning of MINIMUM field is updated in Section 4 of RFC2308; the new definition is that the MINIMUM field is only "the TTL to be used for negative responses".  This document tends to use field names instead of terms that describe the fields. </ins> The maximum "time to live" of a resource record.  "A TTL value is an unsigned number, with a minimum value of 0, and a maximum value "A server that knows the content of a DNS zone from local knowledge, and thus can answer queries about that zone without needing to query other servers."  (Quoted from RFC2182,  <ins> Section 2.)  An authoritative server is named in the NS ("name server") record in a zone.  It is a system that responds to DNS queries with information about zones for which it has been configured to answer with the AA flag in the response header set to 1.  It is a server that has authority over one or more DNS zones.  Note that it is possible for an authoritative server to respond to a query without the parent zone delegating authority to that server.  Authoritative servers also provide "referrals", usually to child zones delegated from them; these referrals have the AA bit set to 0 and come with referral data in the Authority and (if needed) the Additional sections. </ins> A name server that only serves authoritative data and ignores requests for recursion.  It will "not normally generate any zone that have changed (described in RFC1995).  Many systems use non-standard methods for zone transfer outside the DNS protocol. <ins> See "Secondary server". </ins> "An authoritative server which uses zone transfer to retrieve the zone" (Quoted from RFC1996, Section 2.1).  Secondary servers are also discussed in RFC1034.  RFC2182 describes secondary servers in this as a "slave", the current common usage has shifted to calling it a "secondary".  <ins> See "Primary server". </ins> "Any authoritative server configured to be the source of zone transfer for one or more [secondary] servers" (Quoted from RFC1996 referred to this as a "master", the current common usage has shifted to "primary".  "The primary master is named in the zone's SOA MNAME field and optionally by an NS RR".  (Quoted from RFC1996, Section 2.1). RFC2136 defines "primary master" as "Master server at the root of NODATA NOERROR NOTIMP <ins> NS </ins> NSEC NSEC3 NXDOMAIN S SERVFAIL <ins> SOA </ins> SOA field names Secondary server Secure Entry Point (SEP)


name (i.e. the name that was in the RDATA of the CNAME RR) as also being the QNAME. <del> This creates a kind of confusion, however, because the answer to a query that results in CNAME processing contains in the echoed </del>  Question Section one QNAME (the name in the original query), and a second QNAME that is in the data field of the last CNAME.  The confusion comes from the iterative/recursive mode of resolution, A program "that extract[s] information from name servers in response to client requests."  (Quoted from RFC1034, Section 2.4) A resolver performs queries for a name, type, and class, and <del> receives answers.  The logical function is called "resolution". </del>  In practice, the term is usually referring to some specific type of resolver (some of which are defined below), and understanding the use of the term depends on understanding the context. A related term is "resolve", which is not formally defined in RFC1034 or RFC1035.  An imputed definition might be "asking a question that consists of a domain name, class, and type, and <del> receiving some sort of answer".  Similarly, an imputed definition of "resolution" might be "the answer received from resolving". </del>  A resolver that cannot perform all resolution itself.  Stub resolvers generally depend on a recursive resolver to undertake specific to be generally useful. A configuration for a DNS server that allows it to provide <del> different answers depending on attributes of the query, such as </del>  for "split DNS".  Typically, views differ by the source IP address of a query, but can also be based on the destination IP address, the type of query (such as AXFR), whether it is recursive, and so

Thanks the authors for their work in making this draft. I'm going through and I noticed that the term "answer" (45 occurrences) and "response" (47 occurrences) are used interchangeably in the text. I am OK with that, but they should be explicitly defined IMHO, to avoid confusion. E.g.: if I: ` Is the response the entire DNS-layer packet(s), with all the RRs in it? (including flags,etc) Is an answer each line in both ANSWER and AUTHORITY section? Maybe this is clear to many ppl, but it would be nice to write it down. thanks
I do not believe that we have used these terms "interchangeably", since they're not. Some responses are answers and all answers are responses. Some answers contain an Answer Section and some (negative answers, for instance) do not. If that isn't clear, we perhaps ought to add text similar to that, though I thought we had some discussion of this. I didn't see it while looking on my phone just now, however. A
I have opened PR to fix the places where I think we are really talking about responses, not answers.
I think given how late this is in the draft, I'd like to suggest just adding a new bit of text rather than changing the terms, because the WG has been over this ground some. I think it'll be easier to get WG agreement on some text describing the differences without trying to pick each case. Dunno where to put it -- probably intro or something like that -- but here's a suggestion: This document is sometimes unclear on the terms "response" and "answer". The lack of clarity is partly because the DNS specifications themselves use the terms ambiguously. In general, a response is any DNS message with the QR bit set (see [forward reference here]). An answer is any response that attempts actually to answer the question posed in the corresponding query message. Not all answers are authoritative (see [forward reference here]). Some answers contain an Answer Section (see [xref?]), but not all do (such as a negative answer, [forward reference]). Some other responses are not an answer at all, such as an error response. Sorry not to submit this in the usual and proper githubby way, but I'm on vacation and jamming this in.
Closed with , but might be reopened during IESG review if needed.

name (i.e. the name that was in the RDATA of the CNAME RR) as also being the QNAME.  <ins> This creates a kind of confusion, however, because the response to a query that results in CNAME processing contains in the echoed </ins> Question Section one QNAME (the name in the original query), and a second QNAME that is in the data field of the last CNAME.  The confusion comes from the iterative/recursive mode of resolution, A program "that extract[s] information from name servers in response to client requests."  (Quoted from RFC1034, Section 2.4) A resolver performs queries for a name, type, and class, and  <ins> receives responses.  The logical function is called "resolution". </ins> In practice, the term is usually referring to some specific type of resolver (some of which are defined below), and understanding the use of the term depends on understanding the context. A related term is "resolve", which is not formally defined in RFC1034 or RFC1035.  An imputed definition might be "asking a question that consists of a domain name, class, and type, and  <ins> receiving some sort of response".  Similarly, an imputed definition of "resolution" might be "the response received from resolving". </ins> A resolver that cannot perform all resolution itself.  Stub resolvers generally depend on a recursive resolver to undertake specific to be generally useful. A configuration for a DNS server that allows it to provide  <ins> different responses depending on attributes of the query, such as </ins> for "split DNS".  Typically, views differ by the source IP address of a query, but can also be based on the destination IP address, the type of query (such as AXFR), whether it is recursive, and so


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>  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

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")_.

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  <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


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>  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>  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>  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>  Authoritative DNS servers that support DNSSEC often contain software that facilitates the creation and maintenance of DNSSEC

"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".

2. A naming system associates names with data.  Naming systems have  <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  <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  <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  <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


record is called the "RDATA", and the authoritative answer bit is often called "the AA flag" or "the AA bit".  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>  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>  7. CNAME Canonical name Child  Class independent Closest encloser Closest provable encloser

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.

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.  <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  <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


the definition here also applies to systems other than the DNS. RFC1034 defines the "domain name space" using mathematical trees and their nodes in graph theory, and this definition has the same <del> practical result as the definition here.  Using graph theory, a domain name is a list of labels identifying a portion along one edge of a directed acyclic graph.  A domain name can be relative to parts of the tree, or it can be fully qualified (in which case, it begins at the common root of the graph). </del>  Also note that different IETF and non-IETF documents have used the term "domain name" in many different ways.  It is common for The need for the term "fully qualified domain name" comes from the existence of partially qualified domain names, which are names <del> where one or more of the earliest labels in the ordered list are omitted (for example, a name of "www" derived from "www.example.net").  Such relative names are understood only by context. </del>  This term and its equivalent, "hostname", have been widely used but are not defined in RFC1034, RFC1035, RFC1123, or RFC2181.  The

cc NAME NAME Ref 92efaf05a13690953c3123bef664fcd96d2b07c7 Ref URL :
This is an improvement over the existing text and is formally more correct, I think. That means, however, that it is technically a substantive change. I think it is not a substantive change that would make any difference to any DNSOP participant so I think this is ok without going back to the WG.

the definition here also applies to systems other than the DNS. RFC1034 defines the "domain name space" using mathematical trees and their nodes in graph theory, and this definition has the same  <ins> practical result as the definition here.  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) (which is the normal convention within the DNS, including this document).  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. </ins> Also note that different IETF and non-IETF documents have used the term "domain name" in many different ways.  It is common for The need for the term "fully qualified domain name" comes from the existence of partially qualified domain names, which are names  <ins> where one or more of the last labels in the ordered list are omitted (for example, a domain name of "www" relative to "example.net" identifies "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


In order to be fully functional, the owner of the 'arpa.' zone must add a delegation of 'service.arpa.' in the '.arpa.' zone RFC3172. This delegation should be set up as was done for 'home.arpa', as a <del> result of the specification in RFC8375. </del>  8.

Add a reference to the IAB statement on the registration of special use names in the ARPA domain.

In order to be fully functional, the owner of the 'arpa.' zone must add a delegation of 'service.arpa.' in the '.arpa.' zone RFC3172. This delegation should be set up as was done for 'home.arpa', as a  <ins> result of the specification in RFC8375.  This is currently the responsibility of the IAB </ins> 8.


This document only makes use of the 'default.service.arpa' subdomain of 'service.arpa.'  Other subdomains are reserved for future use by DNS-SD or related work.  The IANA is requested to create a registry, <del> the "service.arpa Subdomain Registry".  This registry shall begin as the following table: </del>  9.3.

David Schinazi pointed out: This PR implements David's suggestion.
I noticed this during my shepherd review. Section creates a new registry but is lacking sufficient information for IANA to create the registry. In particular, the registration procedure is missing. Please refer to RFC 8126 for guidance.
Fixed by

This document only makes use of the 'default.service.arpa' subdomain of 'service.arpa.'  Other subdomains are reserved for future use by DNS-SD or related work.  The IANA is requested to create a registry,  <ins> the "service.arpa Subdomain Registry".  The IETF shall have change control for this registry.  New entries may be added either as a result of Standards Action RFC8126 or with IESG approval RFC 8126, provided that a specification exists RFC8126. The IANA shall group the "service.arpa Subdomain Registry" with the "Locally-Served DNS Zones" registry.  The registry shall be a table with three columns: the subdomain name (expressed as a fully- qualified domain name), a brief description of how it is used, and a reference to the document that describes its use in detail. This registry shall begin as the following table: </ins> 9.3.


2.1.1. Full-featured hosts are either configured manually with a <del> registration domain, or use the "dr._dns-sd._udp.<domain>" query (RFC6763) to learn the default registration domain from the network. RFC6763 says to discover the registration domain using either ".local" or a network-supplied domain name for <domain>.  Services using SRP MUST use the domain name received through the DHCPv4 Domain Name option (RFC2132), if available, or the Neighbor Discovery DNS Search List option RFC8106.  If the DNS Search List option contains more than one domain name, it MUST NOT be used.  If neither option is available, the Service Registration protocol is not available on the local network. </del>  Manual configuration of the registration domain can be done either by <del> querying the list of available registration zones ("r._dns-sd._udp") and allowing the user to select one from the UI, or by any other means appropriate to the particular use case being addressed.  Full- featured devices construct the names of the SRV, TXT, and PTR records describing their service(s) as subdomains of the chosen service registration domain.  For these names they then discover the zone apex of the closest enclosing DNS zone using SOA queries RFC8765. Having discovered the enclosing DNS zone, they query for the "_dnssd-srp._tcp.<zone>" SRV record to discover the server to which they should send DNS updates.  Hosts that support SRP Updates using TLS use the "_dnssd-srp-tls._tcp.<zone>" SRV record instead. </del>  2.1.2.

The text describing the behavior of full-featured hosts specified behavior that conflicted with the behavior specified in RFC6763 not because a change was needed, but because I just misunderstood how it worked. This change updates that text to simply refer to the relevant section in RFC6763. In addition, the term "zone" was used where "domain" should have been used, and the term "DNS Update" was used to refer to something that should only ever be an SRP update, so these errors are also corrected.

2.1.1. Full-featured hosts are either configured manually with a  <ins> registration domain, or discover the default registration domain as described in RFC6763.  If this process does not produce a default registration zone, the Service Registration protocol is not discoverable on the local network using this mechanism.  Other discovery mechanisms are possible, but are out of scope for this document. </ins> Manual configuration of the registration domain can be done either by  <ins> querying the list of available registration domains ("r._dns-sd._udp") and allowing the user to select one from the UI, or by any other means appropriate to the particular use case being addressed.  Full-featured devices construct the names of the SRV, TXT, and PTR records describing their service(s) as subdomains of the chosen service registration domain.  For these names they then discover the zone apex of the closest enclosing DNS zone using SOA queries RFC8765.  Having discovered the enclosing DNS zone, they query for the "_dnssd-srp._tcp.<zone>" SRV record to discover the server to which they should send SRP updates.  Hosts that support SRP Updates using TLS use the "_dnssd-srp-tls._tcp.<zone>" SRV record instead. </ins> 2.1.2.


2.1.1. <del> Full-featured hosts are either configured manually with a </del>  registration domain, or discover the default registration domain as described in RFC6763.  If this process does not produce a default registration zone, the Service Registration protocol is not 2.2.1. <del> We refer to the DNS Update message sent by servers using SRP as an SRP Update.  Three types of updates appear in an SRP update: Service Discovery records, Service Description records, and Host Description records. </del>  RFC6763 describes the details of what each of these types of updates contains, with the exception of the KEY RR, which is defined in

I had a brief chat with Qiaoyu and the change here is the result of that discussion, including a minor editorial fix that makes a compound sentence a little more comprehensible (I hope).

2.1.1.  <ins> Full-featured hosts either are configured manually with a </ins> registration domain, or discover the default registration domain as described in RFC6763.  If this process does not produce a default registration zone, the Service Registration protocol is not 2.2.1.  <ins> We refer to a DNS Update message that is constructed so as to conform to the constraints described in server_behavior as an SRP update. SRP Updates are sent by SRP requestors to SRP registrars.  Three types of updates appear in an SRP update: Service Discovery records, Service Description records, and Host Description records. </ins> RFC6763 describes the details of what each of these types of updates contains, with the exception of the KEY RR, which is defined in


Note that there can be more than one Service Discovery Instruction for the same name if the SRP requestor is advertising more than one <del> service of the same type, or is changing the target of a PTR RR.  For each such PTR RR add or remove, the above constraints must be met. </del>  2.3.1.2. 2.3.2. <del> An SRP Update MUST include zero or more Service Discovery Instructions.  For each Service Discovery Instruction, there MUST be at least one Service Description Instruction.  Note that in the case of SRP subtypes (RFC6763), it's quite possible that two Service Discovery Instructions might reference the same Service Description Instruction.  For each Service Description Instruction there MUST be at least one Service Discovery Instruction with its service instance name as the target of its PTR record.  There MUST be exactly one Host Description Instruction.  Every Service Description Instruction must have that Host Description Instruction as the target of its SRV record.  A DNS Update that does not meet these constraints is not an SRP Update. A DNS Update that contains any additional adds or deletes that cannot be identified as Service Discovery, Service Description or Host Description Instructions is not an SRP Update.  A DNS update that contains any prerequisites is not an SRP Update.  Such messages should either be processed as regular RFC2136 updates, including access control checks and constraint checks, if supported, or else rejected with RCODE=REFUSED. In addition, in order for an update to be a valid SRP Update, the target of every Service Discovery Instruction MUST be a Service Description Instruction that is present in the SRP Update.  There MUST NOT be any Service Description Instruction to which no Service Discovery Instruction points.  The target of the SRV record in every Service Description Instruction MUST be the single Host Description Instruction. </del>  If the definitions of each of these instructions are followed carefully and the update requirements are validated correctly, many

This update removes the constraint in the section titled "Host Description Instruction" that the Host Description instruction must be pointed to by at least one Service Description instruction. It also removes some duplicate constraints from the section titled "Valid SRP Update requirements" and moves the mention of subtypes to the "Service Discovery Instruction" section.

Note that there can be more than one Service Discovery Instruction for the same name if the SRP requestor is advertising more than one  <ins> service of the same type, or is changing the target of a PTR RR. This is also true for SRP subtypes (RFC6763).  For each such PTR RR add or remove, the above constraints must be met. </ins> 2.3.1.2. 2.3.2.  <ins> An SRP Update MUST contain exactly one Host Description Instruction. In addition, there MUST NOT be any Service Description Instruction to which no Service Discovery Instruction points.  A DNS Update that contains any additional adds or deletes that cannot be identified as Service Discovery, Service Description or Host Description Instructions is not an SRP Update.  A DNS update that contains any prerequisites is not an SRP Update.  An SRP registrar MAY either process such messages are either processed as regular RFC2136 updates, including access control checks and constraint checks, if supported, or MAY reject them with RCODE=REFUSED. </ins> If the definitions of each of these instructions are followed carefully and the update requirements are validated correctly, many


In order to maximize cache friendliness, DNS API clients using media formats that include DNS ID, such as application/dns-udpwireformat, <del> should use a DNS ID of 0 in every DNS request.  HTTP semantics correlate the request and response, thus eliminating the need for the ID in a media type such as application/dns-udpwireformat. </del>  DNS API clients can use HTTP/2 padding and compression in the same way that other HTTP/2 clients use (or don't use) them.

And explain why more clearly.
this is editorial - should me merged imo NAME
I fully disagree that making something a RFC 2119 requirement is "editorial". In this case, it could have surprising effects on the DNS server side of a DOH server. It's worth discussing, but not just sweeping it in with "editorial".
when I wrote that text I meant it to be SHOULD - its a typo; that's why its editorial :) If its not normative then it really has no meaning in that paragraph.

In order to maximize cache friendliness, DNS API clients using media formats that include DNS ID, such as application/dns-udpwireformat,  <ins> SHOULD use a DNS ID of 0 in every DNS request.  HTTP correlates request and response, thus eliminating the need for the ID in a media type such as application/dns-udpwireformat and the use of a varying DNS ID can cause semantically equivalent DNS queries to be cached separately. </ins> DNS API clients can use HTTP/2 padding and compression in the same way that other HTTP/2 clients use (or don't use) them.


order using HTTP's multi-streaming functionality (RFC7540 Section 5}). <del> The Answer section of a DNS response contains one or more RRsets. </del>  (RRsets are defined in RFC7719.)  According to RFC2181, each resource <del> record in an RRset is supposed to have the Time To Live (TTL) freshness information.  Different RRsets in the Answer section can have different TTLs, though it is only possible for the HTTP response to have a single freshness lifetime.  The HTTP response freshness lifetime (RFC7234 Section 4.2) should be coordinated with the Resource Record bearing the smallest TTL in the Answer section of the response.  Specifically, the HTTP freshness lifetime SHOULD be set to expire at the same time any of the DNS Records reach a 0 TTL.  The </del>  response freshness lifetime MUST NOT be greater than that indicated <del> by the DNS Record with the smallest TTL in the response. </del>  A DNS API client that receives a response without an explicit freshness lifetime MUST NOT assign that response a heuristic A DOH API client may utilize a hierarchy of caches that include both HTTP and DNS specific caches.  HTTP cache entries may be bypassed <del> with HTTP mechanisms such as the Cache-Control no-cache directive </del>  however DNS caches do not have a similar mechanism. A DOH response that was previously stored in an HTTP cache will

feel free to merge if my language works for you
I just now see you gave me the go ahead to merge. I'll fix the conflict and do so.

order using HTTP's multi-streaming functionality (RFC7540 Section 5}).  <ins> The Answer section of a DNS response can contain zero or more RRsets. </ins> (RRsets are defined in RFC7719.)  According to RFC2181, each resource  <ins> record in an RRset has Time To Live (TTL) freshness information. Different RRsets in the Answer section can have different TTLs, although it is only possible for the HTTP response to have a single freshness lifetime.  The HTTP response freshness lifetime (RFC7234 Section 4.2) should be coordinated with the RRset with the smallest TTL in the Answer section of the response.  Specifically, the HTTP freshness lifetime SHOULD be set to expire at the same time any of the DNS resource records in the Answer section reach a 0 TTL.  The </ins> response freshness lifetime MUST NOT be greater than that indicated  <ins> by the DNS resoruce record with the smallest TTL in the response. If the DNS response has no records in the Answer section, and the DNS response has an SOA record in the Authority section, the response freshness lifetime MUST NOT be greater than the MINIMUM field from that SOA record.  Otherwise, the HTTP response MUST set a freshness lifetime (RFC7234 Section 4.2) of 0 by using a mechanism such as "Cache-Control: no-cache" (RFC7234 Section 5.2.1.4). </ins> A DNS API client that receives a response without an explicit freshness lifetime MUST NOT assign that response a heuristic A DOH API client may utilize a hierarchy of caches that include both HTTP and DNS specific caches.  HTTP cache entries may be bypassed  <ins> with HTTP mechanisms such as the "Cache-Control no-cache" directive; </ins> however DNS caches do not have a similar mechanism. A DOH response that was previously stored in an HTTP cache will


The queries and responses must be able to be flexible enough to express every normal DNS query. <del> The protocol must allow implementations to use HTTP's content negotiation mechanism. </del>  The protocol must ensure interoperable media formats through a mandatory to implement format wherein a query must be able to

Conneg is a means, not an end.
this is a good change. I'm good if paul is good.

The queries and responses must be able to be flexible enough to express every normal DNS query.  <ins> The protocol must permit the addition of new formats for DNS queries and responses. </ins> The protocol must ensure interoperable media formats through a mandatory to implement format wherein a query must be able to


6.1. <del> A DOH API client may utilize a hierarchy of caches that include both </del>  HTTP and DNS specific caches.  HTTP cache entries may be bypassed with HTTP mechanisms such as the "Cache-Control no-cache" directive; however DNS caches do not have a similar mechanism. A DNS API client may face a similar bootstrapping problem when the HTTP request needs to resolve the hostname portion of the DNS URI. Just as the address of a traditional DNS nameserver cannot be <del> originally determined from that same server, a DOH client cannot use its DOH server to initially resolve the server's host name into an address.  Alternative strategies a client might employ include making the initial resolution part of the configuration, IP based URIs and corresponding IP based certificates for HTTPS, or resolving the DNS API server's hostname via traditional DNS or another DOH server while still authenticating the resulting connection via HTTPS. </del>  HTTP RFC7230 is a stateless application level protocol and therefore DOH implementations do not provide stateful ordering guarantees

Yipes, I thought I had found these in the last round. Thanks!
Even though the Terminology section contains "DNS API client" and "DNS API server" respectively, the -04 version of the draft still contains a few instances of "DOH client" and "DOH server". Not sure that's intended.
As well as one instance of "DOH API client" in Section 6.1

6.1.  <ins> A DNS API client may utilize a hierarchy of caches that include both </ins> HTTP and DNS specific caches.  HTTP cache entries may be bypassed with HTTP mechanisms such as the "Cache-Control no-cache" directive; however DNS caches do not have a similar mechanism. A DNS API client may face a similar bootstrapping problem when the HTTP request needs to resolve the hostname portion of the DNS URI. Just as the address of a traditional DNS nameserver cannot be  <ins> originally determined from that same server, a DNS API client cannot use its DNS API server to initially resolve the server's host name into an address.  Alternative strategies a client might employ include making the initial resolution part of the configuration, IP based URIs and corresponding IP based certificates for HTTPS, or resolving the DNS API server's hostname via traditional DNS or another DNS API server while still authenticating the resulting connection via HTTPS. </ins> HTTP RFC7230 is a stateless application level protocol and therefore DOH implementations do not provide stateful ordering guarantees


server.  Filtering or inspection systems that rely on unsecured transport of DNS will not function in a DNS over HTTPS environment. <del> Many HTTPS implementations perform real time third party checks of the revocation status of the certificates being used by TLS.  If this check is done as part of the DNS API server connection procedure and the check itself requires DNS resolution to connect to the third party a deadlock can occur.  The use of an OCSP RFC6960 server is one example of how this can happen.  DNS API servers SHOULD utilize OCSP Stapling RFC6961 to provide the client with certificate revocation information that does not require contacting a third party. </del>  A DNS API client may face a similar bootstrapping problem when the HTTP request needs to resolve the hostname portion of the DNS URI.

hmm. we do need to fix this - but the proposed fix removes a normative should and introduces tls 1.3 which creates a publishing dependency. The dep is rather minor, but the benefit to DoH even more minor. let me see if I can come up with a fix that is just a SHOULD inline/staple
We cannot say SHOULD use 6961 because that is not allowed in TLS 1.3. I purposely didn't make a publishing dependency to TLS 1.3 by naming it but not giving a link; every reader of this document will know what we are talking about.
I understand the problem. We can probably say something like SHOULD generically staple or inline (such as 6961 where it applies). tls 1.3 does do stapling, it just doesn't do it via 6961.
wdyt of that NAME ?
Reworded again, and back to you NAME
"DNS API servers SHOULD utilize OCSP Stapling [RFC6961] to provide the client with certificate revocation information that does not require contacting a third party." TLS 1.3 will probably be published before DOH and TLS 1.3 deprecates/obsoletes RFC 6961. TLS 1.3 uses only RFC 6066. Maybe you should refer to both RFC 6066 and RFC 6961.
Good catch! Open as PR .

server.  Filtering or inspection systems that rely on unsecured transport of DNS will not function in a DNS over HTTPS environment.  <ins> Some HTTPS client implementations perform real time third party checks of the revocation status of the certificates being used by TLS.  If this check is done as part of the DNS API server connection procedure and the check itself requires DNS resolution to connect to the third party a deadlock can occur.  The use of an OCSP RFC6960 server is one example of how this deadlock can happen.  To avoid the possibility of deadlock, DNS API servers SHOULD bundle the certificate status as part of the handshake using a mechanism appropriate to the version of TLS, such as using RFC6961 for TLS version 1.2. </ins> A DNS API client may face a similar bootstrapping problem when the HTTP request needs to resolve the hostname portion of the DNS URI.


4.1. The data payload is the DNS on-the-wire format defined in RFC1035. <del> The format is for DNS over UDP.  (Note that this is different than the wire format used in RFC7858. </del>  When using the GET method, the data payload MUST be encoded with base64url RFC4648 and then placed as a name value pair in the query between different requests.  DOH cannot be used as a transport for other protocols that require strict ordering.  10. Joe Hildebrand contributed lots of material for a different iteration

Related to
this is a strict improvement. let's merge and we can adjust further if there is feedback
No limit? Not even the UDP 64 k limit?
I would delete the "over TCP" in "DNS API server was not able to retrieve a full answer for the query over TCP" The DoH server is supposed to do its best to get the fuil answer, it does not mean we force TCP.
Good catches. Will update with URL
I don't see a compelling technical reason to set a limit.
Whether or not RFC 1035 has this limit, DOH should not.
The relevant text in RFC 1035 is: or UDP headers). Longer messages are truncated and the TC bit is set in the header. If the DOH protocol is referred to as "per RFC 1035" then readers of the spec would be entitled to believe that the 512 byte limit applies unless explicitly documented otherwise.
Hello NAME ! as quite a bunch of records are indeed > 512.... some companies set 1024~4096 as operational limit on forwarders and routers. Maybe it could be set in draft to 1024, to avoid jumboframes at all in the picture ? Maybe RFC1035 not have foreseen the increasing size of messaging we then experienced lately (along with Add and Auth getting bigger for redundancy) ? no doubts on it, people are creative about what they can put inside DNS: geo-informations in LOC type, or surf web within TXT records, PGP keys ... I can personally get along most of times with 50-100 bytes average packet size in a simple browsing session, but carrying DNSSEC or even just an SPF will make the use of TCP on DNS backend more and more and more exclusive... I am not saying is any bad/good. We risk limiting the "native DNS" initial use of UDP (which has probably grown after 1035 initial needs) by reverting back to quite an "old" setting. I am not sure everyone today does truncate on exact 512, I might be very wrong. Little higher limit can still be beneficial to transport, compression, stateless/stateful costs etc. By the way, one of today's standing argument by Sir P. Mockapretis, is indeed the present limit on the size of datagrams, just to make things funnier ! Making a parallel with the transport layer, we do not want to drive trough TCP-only world as we had also mentioned QUIC and others. Another parallel on semantics, we almost mention HTTP3 just because comes after HTTP2 but nothing lower than 2. So why shall we not leave that choice OPEN to implementors, to set the desired truncating threshold starting at 512 an up ? Are there references to present RFC on the topic to help reasoning or delegate the choice on this ? The truncate decision for an ANSWER having size > threshold is taken only by server, client will accept and parse so no impact ? Can we try to elaborate on this ? Just brainstorming...
Goodness no, not the least of which being because https transport issues are clearly out of scope for this work.

The truncate decision for an ANSWER having size > threshold is taken only by server, client will accept and parse so no impact ? Can we try to elaborate on this ? The server may have gotten a truncated response from an an authoritative name server, so the client always need to expect an truncated response (except in some local uses of DNS). YES, Seems like something that should be elaborated on.
Proposed fix at
.. we can reopen this issue if necessary
reopen to consider

4.1. The data payload is the DNS on-the-wire format defined in RFC1035.  <ins> The format is for DNS over UDP.  Note that this is different than the wire format used in RFC7858.  Also note that while RFC1035 says "Messages carried by UDP are restricted to 512 bytes", that was later updated by RFC6891, and this protocol does not put any limit on the size of DNS on-the-wire format payloads. </ins> When using the GET method, the data payload MUST be encoded with base64url RFC4648 and then placed as a name value pair in the query between different requests.  DOH cannot be used as a transport for other protocols that require strict ordering. <ins> If a DNS API server responds to a DNS API client with a DNS message that has the TC (truncation) bit set in the header, that indicates that the DNS API server was not able to retrieve a full answer for the query over TCP and is providing the best answer it could get. This protocol does not require that a DNS API server that cannot get an untruncated answer send back such an answer; it can instead send back an HTTP error to indicate that it cannot give a useful answer. </ins> 10. Joe Hildebrand contributed lots of material for a different iteration


The protocol must use normal HTTP semantics. The queries and responses must be able to be flexible enough to <del> express every normal DNS query. </del>  The protocol must permit the addition of new formats for DNS queries and responses. The protocol must ensure interoperability by specifying a single format for requests and responses that is mandatory to implement. That format must be able to support future modifications to the <del> DNS protocol including the inclusion of one or more EDNS extensions (including those not yet defined). </del>  The protocol must use a secure transport that meets the requirements for HTTPS. Supporting insecure HTTP <del> Supporting legacy HTTP versions </del> 4. To make a DNS API query a DNS API client encodes a single DNS query is used directly as the HTTP message body. DNS API clients using the DNS wire format MAY have one or more EDNS <del> extensions RFC6891 in the request. </del>  The media type is "application/dns-udpwireformat". response formats will be defined in the future. The DNS response for "application/dns-udpwireformat" in dnswire MAY <del> have one or more EDNS extensions, depending on the extension definition of the extensions given in the DNS request. </del>  Each DNS request-response pair is matched to one HTTP request- response pair.  The responses may be processed and transported in any

NAME my previous (deleted now) comment was in error in case you get a copy of that in email. sorry - git skillz failure on my part.

The protocol must use normal HTTP semantics. The queries and responses must be able to be flexible enough to  <ins> express every DNS query that would normally be sent in DNS over UDP (including queries and responses that use DNS extensions, but not those that require multiple responses). </ins> The protocol must permit the addition of new formats for DNS queries and responses. The protocol must ensure interoperability by specifying a single format for requests and responses that is mandatory to implement. That format must be able to support future modifications to the  <ins> DNS protocol including the inclusion of one or more EDNS options (including those not yet defined). </ins> The protocol must use a secure transport that meets the requirements for HTTPS. Supporting insecure HTTP  4. To make a DNS API query a DNS API client encodes a single DNS query is used directly as the HTTP message body. DNS API clients using the DNS wire format MAY have one or more EDNS  <ins> options RFC6891 in the request. </ins> The media type is "application/dns-udpwireformat". response formats will be defined in the future. The DNS response for "application/dns-udpwireformat" in dnswire MAY  <ins> have one or more EDNS options, depending on the extension definition of the extensions given in the DNS request. </ins> Each DNS request-response pair is matched to one HTTP request- response pair.  The responses may be processed and transported in any


The format is for DNS over UDP.  Note that this is different than the wire format used in RFC7858.  Also note that while RFC1035 says "Messages carried by UDP are restricted to 512 bytes", that was later <del> updated by RFC6891, and this protocol does not put any limit on the size of DNS on-the-wire format payloads. </del>  When using the GET method, the data payload MUST be encoded with base64url RFC4648 and then placed as a name value pair in the query If a DNS API server responds to a DNS API client with a DNS message that has the TC (truncation) bit set in the header, that indicates that the DNS API server was not able to retrieve a full answer for <del> the query over TCP and is providing the best answer it could get. This protocol does not require that a DNS API server that cannot get an untruncated answer send back such an answer; it can instead send back an HTTP error to indicate that it cannot give a useful answer. </del>  10.

Fixes to PR
It doesn't feel to me like "beyond what is already in {{RFC1035}}" really clarifies anything, and might just cause additional confusion, as it makes me as a reader wonder, "oh well what's in 1035? Guess I have to go searching..."
If you want to put the specific limit from RFC 1035 in, that's fine.
Well no, because I don't think there should be a limit. While DNS messages implicitly have a maximum size of 64k in DNS, there's no reason dns-udpwireformat in HTTPS can't surpass that.
NAME It would be an interoperability problem if a DNS API server handed a DNS API client a message that it could not handle. It is reasonable to assume that DNS API clients expect to parse messages as if they were DNS messages.
NAME This was sloppy on my part: I meant the addition to point to RFC 6891; now changed.
Right NAME but my point is that something like multiple AXFR messages re-assembled into one unit is still a DNS message even if it exceeds 64k. From a wire-format point of view, it parses exactly the same way.
NAME Really? Ugh. Gotta love this protocol. So, you would prefer that the text says "URL this protocol allows DNS-on-the-wire format payloads of any size"?
Yes, I would. Realistically almost everything is still going to be sub-10k, but I don't see an intrinsic need to limit it, especially with https channels routinely handling far larger responses.
I think David and I are now in agreement; NAME should consider accepting.

The format is for DNS over UDP.  Note that this is different than the wire format used in RFC7858.  Also note that while RFC1035 says "Messages carried by UDP are restricted to 512 bytes", that was later  <ins> updated by RFC6891, and this protocol allows DNS on-the-wire format payloads of any size. </ins> When using the GET method, the data payload MUST be encoded with base64url RFC4648 and then placed as a name value pair in the query If a DNS API server responds to a DNS API client with a DNS message that has the TC (truncation) bit set in the header, that indicates that the DNS API server was not able to retrieve a full answer for  <ins> the query and is providing the best answer it could get.  This protocol does not require that a DNS API server that cannot get an untruncated answer send back such an answer; it can instead send back an HTTP error to indicate that it cannot give a useful answer. </ins> 10.


untruncated answer send back such an answer; it can instead send back an HTTP error to indicate that it cannot give a useful answer.  10. Joe Hildebrand contributed lots of material for a different iteration

This is to address the issue of draft-ietf-dnsop-dns-wireformat-http needing to say what the original transport was. Covered on the mailing list March 25 and March 30.
What's the benefit of "original_" over just plain "transport"?

untruncated answer send back such an answer; it can instead send back an HTTP error to indicate that it cannot give a useful answer. <ins> This protocol does not define any use for the "original_transport" optional parameter of the application/dns-udpwireformat media type. </ins> 10. Joe Hildebrand contributed lots of material for a different iteration


URI used by the request.  Configuration and discovery of the URI is done out of band from this protocol.  When using the POST method the DNS query is included as the message body of the HTTP request and the Content-Type request header indicates the media type of the message.  POST-ed requests are DNS resolution privileges to URIs that are not recognized by the client as trusted DNS API servers.  7. 7.1.

By my unofficial informal tally, there was a strong agreement on application/dns-udpwireformat being mandatory, and both GET and POST mandatory for servers.
I made some very minor edits NAME merge if you're ok with them
The fact that an HTTP server can provide a response in the format of its choice was not well understood by DNS people. This motivates the MTI format for servers.
On 2018-03-25, NAME sent the following to the list: At the meeting in London last week, we asked the room for opinions on two topics: Should we have a content-type that is Mandatory to Implement? Several participants spoke in favor of making the default format (currently called "application/dns-udpwireformat") mandatory, at least for servers. Among the GET and POST modes of operation, which, if any, should be mandatory to implement? Among the participants, there was consensus in favor of making both GET and POST mandatory to implement for servers. If you would like to voice a dissenting opinion on either point, please reply on this list. Otherwise, the chairs will regard these decisions as the group's consensus.
See PR
I think most of this can be handled by the MTI PR. But I will just make a tiny clarification indicating that the server is really able to return whatever it needs to.
as discussed on list.. 1) Make one mandatory-to-implement 2) Make both mandatory-to-implement 3) Talk about why there is no mandatory-to-implemen
At the face-to-face meeting, I thought the sense of the room was servers MUST implement both GET and POST, clients can implement either or both. This needs to be confirmed on the list.
See PR
My personal take of consensus is that, having heard no opposition to the position of NAME summary above, to go with that.

URI used by the request.  Configuration and discovery of the URI is done out of band from this protocol. <ins> DNS API servers MUST implement both POST and GET methods. </ins> When using the POST method the DNS query is included as the message body of the HTTP request and the Content-Type request header indicates the media type of the message.  POST-ed requests are DNS resolution privileges to URIs that are not recognized by the client as trusted DNS API servers. <ins> 6.4. In order to maximize interoperability, DNS API clients and DNS API servers MUST support the "application/dns-udpwireformat" media type. Other media types MAY be used as defined by HTTP Content Negotiation (RFC7231 Section 3.4). </ins> 7. 7.1.


checks of the revocation status of the certificates being used by TLS.  If this check is done as part of the DNS API server connection procedure and the check itself requires DNS resolution to connect to <del> the third party a deadlock can occur.  The use of an OCSP RFC6960 server is one example of how this deadlock can happen.  To avoid the </del>  possibility of deadlock, DNS API servers SHOULD bundle the certificate status as part of the handshake using a mechanism <del> appropriate to the version of TLS, such as using RFC6961 for TLS version 1.2. </del>  A DNS API client may face a similar bootstrapping problem when the HTTP request needs to resolve the hostname portion of the DNS URI.

Please don't include advice about TLS extensions that aren't deployed. RFC 6961 is not widely implemented or used. I'm sad to say, but RFC 6066 is the best reference for OCSP stapling right now. Also, if you are including this sort of advice, advice against using AIA should go there as well. Some browsers chase AIA URLs in certificates, which will fail for similar reasons. (You can cite Section 4.2.2.1 of RFC 5280 for that bit).
NAME Given that this has wandered around a bit, could you create a PR with exactly the changes to the Operational Considerations that you think are needed here?

checks of the revocation status of the certificates being used by TLS.  If this check is done as part of the DNS API server connection procedure and the check itself requires DNS resolution to connect to  <ins> the third party a deadlock can occur.  The use of OCSP RFC6960 servers or AIA for CRL fetching (RFC5280 Section 4.2.2.1) are examples of how this deadlock can happen.  To mitigate the </ins> possibility of deadlock, DNS API servers SHOULD bundle the certificate status as part of the handshake using a mechanism  <ins> appropriate to the version of TLS, such as using RFC6066 Section 8 for TLS version 1.2. </ins> A DNS API client may face a similar bootstrapping problem when the HTTP request needs to resolve the hostname portion of the DNS URI.


Using the GET method is friendlier to many HTTP cache implementations. <del> The DNS API client SHOULD include an HTTP "Accept:" request header to say what type of content can be understood in response.  The client </del>  MUST be prepared to process "application/dns-udpwireformat" dnswire <del> responses but MAY process any other type it receives. </del>  In order to maximize cache friendliness, DNS API clients using media formats that include DNS ID, such as application/dns-udpwireformat,

The fact that an HTTP server can provide a response in the format of its choice was not well understood by DNS people. This motivates the MTI format for servers.
On 2018-03-25, NAME sent the following to the list: At the meeting in London last week, we asked the room for opinions on two topics: Should we have a content-type that is Mandatory to Implement? Several participants spoke in favor of making the default format (currently called "application/dns-udpwireformat") mandatory, at least for servers. Among the GET and POST modes of operation, which, if any, should be mandatory to implement? Among the participants, there was consensus in favor of making both GET and POST mandatory to implement for servers. If you would like to voice a dissenting opinion on either point, please reply on this list. Otherwise, the chairs will regard these decisions as the group's consensus.
See PR
I think most of this can be handled by the MTI PR. But I will just make a tiny clarification indicating that the server is really able to return whatever it needs to.

Using the GET method is friendlier to many HTTP cache implementations.  <ins> The DNS API client SHOULD include an HTTP "Accept" request header to indicate what type of content can be understood in response. Irrespective of the value of the Accept request header, the client </ins> MUST be prepared to process "application/dns-udpwireformat" dnswire  <ins> responses but MAY also process any other type it receives. </ins> In order to maximize cache friendliness, DNS API clients using media formats that include DNS ID, such as application/dns-udpwireformat,


4. <del> To make a DNS API query a DNS API client encodes a single DNS query into an HTTP request using either the HTTP GET or POST method and the other requirements of this section.  The DNS API server defines the URI used by the request.  Configuration and discovery of the URI is done out of band from this protocol. </del>  <del> DNS API servers MUST implement both POST and GET methods. </del>  When using the POST method the DNS query is included as the message body of the HTTP request and the Content-Type request header indicates the media type of the message.  POST-ed requests are smaller than their GET equivalents. <del> When using the GET method the URI path MUST contain a query parameter name-value pair QUERYPARAMETER with the name of "ct" and a value indicating the media-format used for the dns parameter.  The value may either be an explicit media type (e.g., "ct=application/dns- udpwireformat&dns=...") or it may be empty.  An empty value indicates the default application/dns-udpwireformat type (e.g., "ct&dns=..."). When using the GET method the URI path MUST contain a query parameter with the name of "dns".  The value of the parameter is the content of the request potentially encoded with base64url RFC4648. Specifications that define media types for use with DOH, such as DNS Wire Format dnswire of this document, MUST indicate if the dns parameter uses base64url encoding. </del> Using the GET method is friendlier to many HTTP cache implementations. payloads of any size. When using the GET method, the data payload MUST be encoded with <del> base64url RFC4648 and then placed as a name value pair in the query portion of the URI with name "dns".  Padding characters for base64url MUST NOT be included. </del>  When using the POST method, the data payload MUST NOT be encoded and is used directly as the HTTP message body. These examples use HTTP/2 style formatting from RFC7540. <del> These examples use a DNS API service located at https://dnsserver.example.net/dns-query to resolve the IN A records. </del>  The requests are represented as application/dns-udpwirefomat typed bodies.

NAME ?
This probably fell through the cracks when was closed. The current design of the GET-based request uses two fields that work in tandem. carries a content type, carries the query. This is suboptimal from a performance perspective when a new request format is developed, which would effectively discourage adoption of new formats (though most likely it will just prolong the lifetime of the baseline format). A query in the form with an implicit content type would be ideal. New formats for requests could do this: . POST requests can't benefit from this sort of approach. Not sure what I think about that.
My question is: does this also extend to multi-parameter query types in the future, e.g. ?
Yes, I am for having query types yes ! My pre-doh thing was accounting for name+type to allow for that granularity, for example MX resolution (looking outside web-only context) Other bits are welcome, recursion for example.
NAME yes.
I am warming up to this.
This still seems silly to me for wireformat because if you can decode the answer, you can encode the query. If someone comes up with a JSON response encoding, the query type will be trivial to describe. NAME what other use cases are you thinking of?
The notion would be to create performance incentives for deploying new media types.. you're right that for it to work you also need to support the old wireformat type so the new type needs to have an advantage other than "easier". Is that not a possibility - will wireformat always be the most expressive?
How could the wire format not be the most expressive? DNS doesn't have an analog of HTTP headers: it's always just a message body.
tl;dr: reopen please. If you subscribe to the notion that wire format is all you ever need, then we're done already. Just close the door on that possibility and remove . That would be fine for web+JS cases, because all the ugliness of the wire format can be wrapped with an ergonomic API. On the other hand, you might believe there to be value in formats that can express queries in a less-obtuse format. After all, you can't slap every problem with a JSL until it goes away. For instance, replacing a '.' with a count is pretty onerous in some clients. After considering this some more, I don't think that you want to manage this by overloading a request with multiple query types. That might sound like a good idea, but it has complications in implementation (what if the two queries disagree, how do you ensure cachability, etc....). I really want to consider the interaction with discovery, without actually defining a discovery method. Say that you invent a new scheme that includes the combination of multiple QNAMEs and QTYPEs in the following fashion: . Rather than put that query syntax on the same base URL, you would instead configure clients with a discovery document that lists different query modes: Yes, risks straying into territory, but I don't think that you need to actually specify discovery. Instead, you can instead structure configuration/discovery differently. That would enable that sort of discovery if someone wanted to go there, but it wouldn't force it on anyone. specify that this document has precisely one query syntax for GET specify that syntax with a single variable input (drop ) and use a URI template to define the placement of that parameter observe that an alternative query syntax might be supported, but that the syntax would use a different endpoint and URI template and so would require separate configuration That doesn't invalidate the current query format, it only changes the configuration. Servers can provide a URI template for their current syntax (e.g., would describe the endpoint that is also usable by clients that use configuration from earlier draft versions).
I'm a bit torn here. The proposed architecture is fine. My gut also says that its a layer of indirection that won't be used in anyway that is more meaningful than what is defined.. and adds it complexity to understanding what is going on which is definitely an anti-goal. your 3 point definition is actually on the side of "simple enough" for me, though I'm not positive we can write it down in a way that doesn't create a lot of questions. I've made a PR with what works for me but I'm hesitant to go much further. let me know what you think.
I have mixed feelings about changing the wireformat so late, but think this is probably the best way to go.

4.  <ins> A DNS API client encodes a single DNS query into an HTTP request using either the HTTP GET or POST method and the other requirements of this section.  The DNS API server defines the URI used by the request through the use of a URI Template RFC6570.  Configuration and discovery of the URI Template is done out of band from this protocol. </ins>  <ins> The URI template defined in this document is processed without any variables for requests using POST, and with the single variable "dns" for requests using GET.  The value of the dns parameter is the content of the request (as described in dnswire), encoded with base64url RFC4648. Future specifications for new media types MUST define the variables used for URI Template processing with this protocol. DNS API servers MUST implement both the POST and GET methods. </ins> When using the POST method the DNS query is included as the message body of the HTTP request and the Content-Type request header indicates the media type of the message.  POST-ed requests are smaller than their GET equivalents.  Using the GET method is friendlier to many HTTP cache implementations. payloads of any size. When using the GET method, the data payload MUST be encoded with  <ins> base64url RFC4648 and then provided as a variable named "dns" to the URI Template expansion.  Padding characters for base64url MUST NOT be included. </ins> When using the POST method, the data payload MUST NOT be encoded and is used directly as the HTTP message body. These examples use HTTP/2 style formatting from RFC7540.  <ins> These examples use a DNS API service with a URI Template of "https://dnsserver.example.net/dns-query{?dns}" to resolve IN A records. </ins> The requests are represented as application/dns-udpwirefomat typed bodies.


request through the use of a URI Template RFC6570.  Configuration and discovery of the URI Template is done out of band from this protocol. <del> The URI template defined in this document is processed without any variables for requests using POST, and with the single variable "dns" for requests using GET.  The value of the dns parameter is the content of the request (as described in dnswire), encoded with base64url RFC4648. </del>  Future specifications for new media types MUST define the variables used for URI Template processing with this protocol.

dns request clarified in b2a7c6c43f3003e8b56aad62822592c5acf04cdb
From Star Brilliant on the DOH WG mailing list: Issue 1: I found the phrase "URI template" is spelled with a lower "t", where all other occurrences of this phrase is spelled with an upper "T". Is this a typo? Issue 2: I suggest we change the word "and" in Line 2 to "or", for the reason that an HTTP request could not be both GET and POST.

request through the use of a URI Template RFC6570.  Configuration and discovery of the URI Template is done out of band from this protocol.  <ins> The URI Template defined in this document is processed without any variables when the HTTP method is POST.  When the HTTP method is GET the single variable "dns" is defined as the content of the request (as described in dnswire), encoded with base64url RFC4648. </ins> Future specifications for new media types MUST define the variables used for URI Template processing with this protocol.


2. <del> A server that supports this protocol is called a "DNS API server" to differentiate it from a "DNS server" (one that uses the regular DNS protocol).  Similarly, a client that supports this protocol is called a "DNS API client". </del>  The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and

this is meant as simpler alternative to . Its much less of a rewrite. consolidates caching rules by moving text adds a new section header "HTTP Exchange" for request and response to fall under moves the wireformat definition out of the http sections by moving text.
NAME NAME wdyt?
I'm not terribly happy with pushing the definition of wireformat to so much later because it will cause HTTP people to maybe miss the salient points. This makes the document feel much more like "HTTPS around DNS" instead of "DNS in HTTPS", but I can live with it. Given that there are more knobs and fiddly bits in the HTTP part than in the DNS part, it's reasonable to put those first. NAME if you're OK with it, say so here and I'll accept. I'll then make some very small editorial changes that I am seeing.
I'm OK with it. Would putting the wire format first help? FWIW I don't think HTTP folks are going to miss bits just because of the position in the doc.
Thanks all. I think this is on balance a useful change. I'll fix the bitrot and merge.

2.  <ins> A server that supports this protocol on one or more URIs is called a "DNS API server" to differentiate it from a "DNS server" (one that uses the regular DNS protocol).  Similarly, a client that supports this protocol is called a "DNS API client". </ins> The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and