On Aug 4, 2018, at 10:10 AM, Stewart Bryant <stewart.bryant@xxxxxxxxx> wrote: > >>> 4. Selection of DoH Server >>> >>> SB> I am surprised that there is no discussion of the need to specify >>> SB> the raw IP address of the sever as part of the URI, and that there >>> SB> is no discussion of the server address IP address family in the document. >> >> A URI can have either host names or IP addresses in the authority part. > > I do not understand. How does a system that is using this as its DNS access mechanism find the IP address of the DNS service given only the name of the server? If a client is using DoH as its only access to the DNS, then the URI clearly needs an IP address in it. However, most of the current expected applications of DoH are for getting better DNS service, not being the exclusive or first DNS service. For example, browsers are expected to use DoH in addition to the OS's stub resolver in order to get the benefits described in the draft's Introduction. >>> SB> I would have thought that there should at least be a reference to >>> SB> "happy eyeballs" and and discussion of an optimization strategy of >>> SB> what to do if there was a response on Ipv4 and not IPv6 etc etc. >> >> Happy eyeballs is orthogonal to the document. How the client turns a host name in the URI into an IP address is completely up to the client using whatever strategies it wants to use. > > My assumption is that someone used to DNS would understand all the issues.. But you have written this document so that web applications specialists can do a DNS lookup from within their web application. It would seem reasonable to give them some hints about the issues, even if only by reference. Those hints would be for the developer of the browser or other HTTP client stack, not to DoH. DoH requires (and should not require!) any changes to those. >>> SB> It would be really useful if there was an >>> SB> example of both formats side by side. >> >> Could you explain more what you want here? The two formats will look the same: a bunch of hex. >> > How about showing the mapping of this to a 1035 message using the parameters the coder would use. So for example some of that ascii is presumably the Name of the address being looked up. I apologize for being dense, but I still don't see what you are asking for here. The DoH client marshals a DNS query just like a DNS client does by putting together all the bits from RFC 1035. The DNS name being looked up is not in ASCII: RFC 1035 says how you put together the labels of a name in a binary format. >>> >>> <64 bytes represented by the following hex encoding> >>> 00 00 81 80 00 01 00 01 00 00 00 00 03 77 77 77 >>> 07 65 78 61 6d 70 6c 65 03 63 6f 6d 00 00 01 00 >>> 01 03 77 77 77 07 65 78 61 6d 70 6c 65 03 63 6f >>> 6d 00 00 01 00 01 00 00 00 80 00 04 C0 00 02 01 >>> >>> SB> At this point in the text I am still wondering what this encoding means, I assume that >>> SB> it is a hex representation of the payload received >>> SB> back from a normal DNS query. >> >> Correct. > > It would be helpful to the new reader to explain that. Got it; will do. >> >>> >>> ========= >>> >>> 7. Definition of the application/dns-message media type >>> >>> The data payload for the application/dns-message media type is a >>> single message of the DNS on-the-wire format defined in Section 4.2.1 >>> of [RFC1035]. >>> >>> SB> That would have been useful to have known earlier >>> SB> However 4.2.1 just talks about UDP and not the message syntax. >>> SB> Also presumably we are talking about the payload of the UDP >>> SB> message excluding the UDP header. >> >> We will make the contents of the payloads clearer earlier in the document. The reason the reference is to Section 4.2.1 of RFC 1035 is that the DNS wire format changes if it is over TCP. > > Yes, but rather than have the reader work out the minor difference in please tell them. We did that in an earlier draft and was told by the WG to take it out because it was confusing. >>> SB> 4.2.2 does not seem to describe a format, unless you are implicitly >>> SB> saying that 4.2.1 does not have a length 4.2.2 does >> >> That is exactly what we are saying because that is what RFC 1035 says. > > One sentence will stop the reader having to work this out. The fact that RFC 1035 is subtle on this point is not helpful to us. RFC 1035 talks about the format throughout as if it will always be used in UDP; it's only in Section 4.2.2 that it adds (without even a diagram) the two length bytes for TCP transport. We're kind of stuck with the history of the DNS RFCs here. --Paul Hoffman
