On Thu, Jul 23, 2020 at 10:50:40AM +0100, Alessandro Ghedini wrote: > On Fri, Jul 17, 2020 at 10:11:33AM +1000, Mark Andrews wrote: > > > > > > > On 17 Jul 2020, at 03:26, Alessandro Ghedini <alessan...@ghedini.me> > > > wrote: > > > > > > On Fri, Jul 17, 2020 at 01:37:35AM +1000, Mark Andrews wrote: > > >> Do you have a estimate on when you will enable additional section > > >> processing for these records? > > > > > > Not sure I understand the question. Do you mean authoritative servers > > > adding > > > A/AAAA records to additional section of HTTPS responses? > > > > > > Cheers > > > > Yes. At the moment there will be lots of redundant queries being made. A, > > AAAA > > and HTTPS/SVBC for every level of the chain. If HTTPS/SVBC aware servers > > actually > > return A and AAAA records for service form records, we can reduce the > > number of > > queries that need to be made. > > I did a little experiment (took me a few days to find the time) with a toy DNS > server [0].
Forgot to add the link here. The "[0]" was supposed to point to: https://gist.github.com/ghedo/cdb98af5df6a8a2bf97aac6a06ab27aa > This is obviously not a proper authoritative server, it's just to > illustrate the problem. > > When I query the auth server directly I get the HTTPS response as well as the > additional section records: > > % dig @ns1.nullroute.dev nullroute.dev. type65 > > ; <<>> DiG 9.16.4-Debian <<>> @ns1.nullroute.dev nullroute.dev. type65 > ; (1 server found) > ;; global options: +cmd > ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 18948 > ;; flags: qr rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 > ;; WARNING: recursion requested but not available > > ;; QUESTION SECTION: > ;nullroute.dev. IN TYPE65 > > ;; ANSWER SECTION: > nullroute.dev. 300 IN TYPE65 \# 21 > 00010000010006026832026833000400042D4D6042 > > ;; ADDITIONAL SECTION: > nullroute.dev. 300 IN A 198.51.100.1 > > But if I go through a resolver the additional section seems to be stripped: > > % dig @8.8.8.8 nullroute.dev. type65 > > ; <<>> DiG 9.16.4-Debian <<>> @8.8.8.8 nullroute.dev. type65 > ; (1 server found) > ;; global options: +cmd > ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 62418 > ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 > > ;; OPT PSEUDOSECTION: > ; EDNS: version: 0, flags:; udp: 512 > ;; QUESTION SECTION: > ;nullroute.dev. IN TYPE65 > > ;; ANSWER SECTION: > nullroute.dev. 299 IN TYPE65 \# 21 > 00010000010006026832026833000400042D4D6042 > > I tried a few other public resolvers and I see the same. If this is the actual > behavior of resolvers (rather than just an artifact of my experiment's setup) > then adding additional section wouldn't seem to provide much benefit for > "end-user" clients (say, a browser). > > Is the expectation that additional section would help resolvers reduce the > number of queries rather than the other DNS clients? I guess other clients > would > still need to query A/AAAA and HTTPS in parallel as they don't know whether > there is an HTTPS record at all. > > In any case we don't have plans right now to implement this on Cloudflare's > DNS > servers, but it's certainly possible. I will discuss this with our DNS people > and see what they think. > > Cheers > > > We need to get to the state where HTTPS/SVBC alias form always reaches a > > HTTPS/SVBC > > service form. When we are mostly in that state we can stop doing A and > > AAAA queries > > along side the HTTPS/SVBC query for names in the HTTPS/SVBC alias form and > > take the > > RTT hit on the occasional NODATA response. To get to that state we need > > the DNS > > servers of the content providers to be HTTPS/SVBC aware and to populate the > > additional > > section whenever possible. > > > > BIND’s HTTPS/SVBC implementation adds A, AAAA, CNAME, and HTTPS/SVBC > > records and > > looks for them in the response. I would expect all HTTPS/SVBC aware > > clients to > > look for these records in the response. At the moment we don’t look for > > DNAME in > > the additional section nor do we add it because, quite frankly, they should > > not be > > there in any sensible deployment. DNAME in the answer section is expected. > > > > Mark > > > > >>> On 17 Jul 2020, at 01:13, Alessandro Ghedini <alessan...@ghedini.me> > > >>> wrote: > > >>> > > >>> Hello, > > >>> > > >>> Just a quick note that we have started serving "HTTPS" DNS records from > > >>> Cloudflare's authoritative DNS servers. Our main use-case right now is > > >>> advertising HTTP/3 support for those customers that enabled that > > >>> feature (in > > >>> addition to using Alt-Svc HTTP headers). > > >>> > > >>> If anyone is interested in trying this out you can query pretty much > > >>> all domains > > >>> served by Cloudflare DNS for which we terminate HTTP. > > >>> > > >>> For example: > > >>> > > >>> % dig blog.cloudflare.com type65 > > >>> > > >>> ; <<>> DiG 9.16.4-Debian <<>> blog.cloudflare.com type65 > > >>> ;; global options: +cmd > > >>> ;; Got answer: > > >>> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 17291 > > >>> ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 > > >>> > > >>> ;; OPT PSEUDOSECTION: > > >>> ; EDNS: version: 0, flags:; udp: 4096 > > >>> ;; QUESTION SECTION: > > >>> ;blog.cloudflare.com. IN TYPE65 > > >>> > > >>> ;; ANSWER SECTION: > > >>> blog.cloudflare.com. 300 IN TYPE65 \# 76 > > >>> 000100000100150568332D32390568332D32380568332D3237026832 > > >>> 0004000868121A2E68121B2E00060020260647000000000000000000 > > >>> 68121A2E26064700000000000000000068121B2E > > >>> > > >>> Cheers > > >>> > > >>> _______________________________________________ > > >>> DNSOP mailing list > > >>> DNSOP@ietf.org > > >>> https://www.ietf.org/mailman/listinfo/dnsop > > >> > > >> -- > > >> Mark Andrews, ISC > > >> 1 Seymour St., Dundas Valley, NSW 2117, Australia > > >> PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org > > >> > > > > -- > > Mark Andrews, ISC > > 1 Seymour St., Dundas Valley, NSW 2117, Australia > > PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org > > > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
