Re: [DNSOP] HTTPS/SVCB on Cloudflare DNS

[Mark Andrews <[e-mail]>]

> On 24 Jul 2020, at 02:43, Alessandro Ghedini <[e-mail]> wrote:
> 
> On Fri, Jul 24, 2020 at 01:20:41AM +1000, Mark Andrews wrote:
>> 
>> 
>>> On 23 Jul 2020, at 19:50, Alessandro Ghedini <[e-mail]> wrote:
>>> 
>>> On Fri, Jul 17, 2020 at 10:11:33AM +1000, Mark Andrews wrote:
>>>> 
>>>> 
>>>>> On 17 Jul 2020, at 03:26, Alessandro Ghedini <[e-mail]> 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).
>> 
>> I’m trying to determine if you are serious here.
> 
> Yes, I was serious.
> 
>> Did you honestly expect recursive servers that know about HTTPS and SVBC, had
>> hence have code to add the addition section records to the response, to have
>> been deployed in the 3 weeks since the type codes have been assigned?
> 
> No, that's not at all what I was expecting. I was just trying to figure who this
> would benefit since it wasn't completely clear to me from your email, and I
> wasn't previously aware of the resolvers behaviour regarding additional section
> (TIL I guess).
> 
> Maybe I wasn't clear either, but In my email I asked:
> 
>    Is the expectation that additional section would help resolvers reduce the
>    number of queries rather than the other DNS clients?
> 
> Reading between the lines, your reply seems to confirm that indeed what you are
> expecting is that it would help resolver.
> 
> Cheers

The benefit comes when the chains look like this with possible CNAMEs in the middle.

HTTPS (alias form) -> HTTPS (Service form) -> Addresses

It’s not the first lookup that sees the benefit at this time.  It would be nice if
we get to the stage where we are with SMTP that almost all delivery domains there is
a MX record.  That takes education to fix for HTTPS.  For new services its just a
matter of says SVCB is SHOULD.  

The alias to service form lookups is where you should see the benefit. 

Note recursive servers can prefetch on cache misses for additional data and even
stall the response to fill up the additional section.  The following is a experimental
branch for BIND 9 that does that for SRV.

https://gitlab.isc.org/isc-projects/bind9/-/merge_requests/449

There is nothing that actually prevents recursive servers vendors shipping code like this
which knows about HTTPS and SVCB.  Now that merge request and the HTTPS/SVCB merge request
handle CNAMEs slightly differently so I don’t intend to merge that as is but parts of that
are quite likely to make it into future version of BIND.

There does have to be limits on the amount of prefetching a single query can trigger however
so that is doesn’t get weaponised.  Doing A and AAAA prefetches on HTTPS alias form targets
need to not be needed.

>> Especially so when parameters like “mandatory” have only appeared
>> in the latest draft on July 13?  Add to that these records have significantly different
>> additional section processing to any other type.  It’s not just lookup the type by name
>> and add it to the additional section which.  It adding CNAMEs, which no other record
>> requires, and loop prevention code as well. It’s protecting against effectively infinite
>> chains.
>> 
>> It’s also adding code to detect and these records in responses and decide if they are
>> appropriate.  Again the rules for doing this differ in design from any other deployed
>> type.
>> 
>> You can add to all of this, a sense that the records are still not stable and really
>> should not have had type codes assigned when they where.  There was no stable reference
>> for “mandatory” when they where assigned.  IANA references draft-ietf-dnsop-svcb-https-00
>> which doesn’t contain “mandatory”.  The draft was, and potentially still is, not stable
>> enough for permanent code points.  I’m just hoping that we don’t get into serious
>> interoperability issues between implementations because of this.  A -00 server can accept
>> but not verify a record produced by a -01 server over the wire.  A -00 server can’t accept
>> all records, in presentation form, produced by -01 sources.  Do -01 sources now have to
>> emit ‘key0=“…”’ for mandatory to work around this incompatibility?  I suspect not as any
>> -00 servers will be replaced, but there is alway the possibility that someone will come
>> along and implement HTTPS and SVCB against -00 assuming that the description of the
>> records there is complete enough (which it clearly isn’t).
>> 
>>> 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 <[e-mail]> 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
>>>>>>> [e-mail]
>>>>>>> https://www.ietf.org/mailman/listinfo/dnsop
>>>>>> 
>>>>>> -- 
>>>>>> Mark Andrews, ISC
>>>>>> 1 Seymour St., Dundas Valley, NSW 2117, Australia
>>>>>> PHONE: [phone]              INTERNET: [e-mail]
>>>>>> 
>>>> 
>>>> -- 
>>>> Mark Andrews, ISC
>>>> 1 Seymour St., Dundas Valley, NSW 2117, Australia
>>>> PHONE: [phone]              INTERNET: [e-mail]
>> 
>> -- 
>> Mark Andrews, ISC
>> 1 Seymour St., Dundas Valley, NSW 2117, Australia
>> PHONE: [phone]              INTERNET: [e-mail]
>> 

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: [phone]              INTERNET: [e-mail]