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