On Thu, Jul 23, 2020 at 10:31:50AM -0400, Ben Schwartz wrote: > On Thu, Jul 23, 2020 at 5:57 AM Alessandro Ghedini <alessan...@ghedini.me> > 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 < > > 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 <+61%202%209871%204742> > > INTERNET: ma...@isc.org > > > > >> > > > > > > > > -- > > > > Mark Andrews, ISC > > > > 1 Seymour St., Dundas Valley, NSW 2117, Australia > > > > PHONE: +61 2 9871 4742 <+61%202%209871%204742> 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 > > _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
