Re: [DNSOP] HTTPS/SVCB on Cloudflare DNS

[Alessandro Ghedini <[e-mail]>]

On Thu, Jul 23, 2020 at 10:31:50AM -0400, Ben Schwartz wrote:
> On Thu, Jul 23, 2020 at 5:57 AM Alessandro Ghedini <[e-mail]>
> wrote:
> 
> >
> > Also btw, currently we always include ipv4hint and ipv6hint in our HTTPS
> > responses, this is to avoid breaking connections in multi-CDN scenarios,
> 
> 
> Note that this is not guaranteed to work.  A client who has the other CDN's
> AAAA record in cache will ignore your ipv6hint, leading to ECH failure.
> The proper way to support this is to make sure that TargetName is never a
> multi-CDN name.
> 
> The advice in previous drafts was arguably confusing on this point.  The
> latest draft updates the "Structuring Zones for Performance" section in an
> attempt to clarify:
> https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-svcb-https#section-5.3
> 
> so I
> > guess a resolver could in theory use this information instead? The draft
> > is, I
> > believe, a tad too strict regarding the usage of hints, so I'm not sure if
> > this
> > is forbidden or not.
> >
> 
> I'm not sure what you're proposing, but recursive resolvers are certainly
> forbidden from synthesizing address records based on the ipv*hints.

Yeah, you are right I realized this didn't make sense just after sending the
email.

Cheers

> 
> Cheers
> >
> > >
> > > 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] <+61%202%209871%204742>
> > INTERNET: [e-mail]
> > > > >>
> > > >
> > > > --
> > > > Mark Andrews, ISC
> > > > 1 Seymour St., Dundas Valley, NSW 2117, Australia
> > > > PHONE: [phone] <+61%202%209871%204742>              INTERNET:
> > [e-mail]
> > > >
> > >
> > > _______________________________________________
> > > DNSOP mailing list
> > > [e-mail]
> > > https://www.ietf.org/mailman/listinfo/dnsop
> >
> > _______________________________________________
> > DNSOP mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/dnsop
> >