Re: [DNSOP] Comments on draft-ietf-dnsop-svcb-httpssvc-02
On Mon, Apr 20, 2020 at 11:02:00PM -0400, Ben Schwartz wrote: > On Mon, Apr 20, 2020 at 9:25 PM Eric Orth 40google@dmarc.ietf.org> wrote: > > 8. Maybe I'm missing something, but the following sentence in Section > 64 seems > wrong: > > When SvcDomainName is ".", server operators SHOULD NOT include these > hints, > because they are unlikely to convey any performance benefit. > > My understanding is that ipv4hint and ipv6hint are the way to solve the > ESNI > multi-CDN problem, so let's say I have "www.example.net" that CNAMEs > to both > "cname.cdn-a.example" and "cname.cdn-b.example". A client queries both > A and > HTTPSVC concurrently for "www.example.net", and receives two answers > (the answer > to the A query points to CDN A, while the answer to HTTPSSVC points to > CDN B): > > www.xample.net 3600 IN CNAME cname.cdn-a.example > cname.cdn-a.example 3600 IN A 192.0.2.1 > > and > > www.xample.net 3600 IN CNAME cname.cdn-b.example > cname.cdn-b.example 3600 IN HTTPSSVC 1 . alpn=h3 esniconfig="..." > > My understanding is that in this case the client could end up > connecting to > 192.0.2.1 (CDN A) with CDN B's ESNI config (or e.g. with the wrong > ALPN). So if > the server doesn't provide IP hints there would indeed be impact on > performance > because the client would just straight up fail to connect initially > (e.g. maybe > CDN A doesn't support HTTP/3, but CDN B's HTTPSSVC says the client can > use it, > or just because of the wrong ESNI config). > > Long story short, I don't think the text should discourage setting > ipv4hint and > ipv6hint here. I get that it's SHOULD NOT and not MUST NOT, but it's > pretty > confusing nevertheless. > > >>> > >>> I don't think the hints are intended for this problem. I think the > >>> general design idea is that A/ are the definitive address results for > >>> a > >>> given name, and clients can just optionally shortcut querying A/ if > >>> given hints. > >>> > >>> In your example, I believe the "." HTTPSSVC entry indicates that the > >>> A/ addresses for "cname.cdn-b.example" should be used, so it doesn't > >>> seem like there is a multi-CDN problem. The correct addresses for the > >>> correct CDN are used. > >>> > >>> But I think this might point out a potential problem with skipping hints > >>> for "." results. If the HTTPSSVC result passes through a CNAME, a > >>> non-HTTPSSVC-supporting recurssive will handle the CNAME, but not lookup > >>> A/ for the HTTPSSVC. > >>> > >> > >> I don't think this can happen. Any CNAME that affects HTTPSSVC will also > >> affect the corresponding A/ queries, which are always issued > >> simultaneously and to the same QNAME. > >> > > > > alessandro@'s case was for multiple CNAME's and a recursive with behavior > > that could follow those in different directions for the different > > requests. Not technically legal, but the more important question here is > > whether or not significant instances behave in this non-standard way. If > > they do, this will lead to a situation where hints would be beneficial even > > for "." records. > > > > Thanks for the explanation. I would prefer to warn against this, rather > than encourage more use of hints. When SvcDomainName is ".", I think not > including hints is going to perform better on average, even in the case of > multiple CNAMEs, because the split-CNAME cases should be very rare (due to > caching), but the hints add overhead to every response. They can also > impair load balancing if managed poorly. I had to step away from HTTPSSVC for a bit due to other priorities (hence the delay in responding), but I've been thinking about this some more and I see another potential case where the A/ and HTTPSSVC records might diverge. Given the following records: www.example.net 3600 IN A 192.0.2.1 www.example.net 3600 IN HTTPSSVC 1 . alpn=h3 echconfig="..." * At time T, user A queries a resolver for the www.example.net A record, so the resolver fetches it from the auth server and caches it. * At time T+5m, user B queries the same resolver for both A and HTTPSSVC records. The resolver serves the A record from cache, and fetches HTTPSSVC from the auth server (and caches it). * The administrator of www.example.net now decides to move the zone to a different provider (either manually or with some automatic DNS load-balancer), with the following records: www.example.net 3600 IN A 192.0.4.1 www.example.net 3600 IN HTTPSSVC 1 . alpn=h2 * At time T+1h+1s, user C queries the same resolver for both A and HTTPSSVC, the cache entry for A expired so the resolver fetches it again (this time pointing to the new provider), while HTTPSSVC is still served from cac
[DNSOP] Are SVCB/HTTPSSVC going to be renamed after all?
Hello, At the risk of re-opening a can of worms, there was a discussion a while ago on this list on renaming the SVCB and HTTPSSVC records to something else https://mailarchive.ietf.org/arch/msg/dnsop/dh_H24_Dq-nr4TkO0FCqySjsnC8/ So I was wondering where that discussion landed (if anywhere) as I can't seem to be able to find any resolution to that on the list. To be clear, I don't particularly care either way, but if a rename is going to happen I'd rather it happens sooner as it will affect implementers, and it might unduly cause people to hold back from merging/deploying code in case a rename actually happens, e.g. https://github.com/miekg/dns/pull/1067#issuecomment-627807069 Cheers ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Comments on draft-ietf-dnsop-svcb-httpssvc-02
> On 11 Jun 2020, at 08:44, Alessandro Ghedini wrote: > > On Mon, Apr 20, 2020 at 11:02:00PM -0400, Ben Schwartz wrote: >> On Mon, Apr 20, 2020 at 9:25 PM Eric Orth > 40google@dmarc.ietf.org> wrote: >> >> 8. Maybe I'm missing something, but the following sentence in Section >> 64 seems >> wrong: >> >> When SvcDomainName is ".", server operators SHOULD NOT include these >> hints, >> because they are unlikely to convey any performance benefit. >> >> My understanding is that ipv4hint and ipv6hint are the way to solve the >> ESNI >> multi-CDN problem, so let's say I have "www.example.net" that CNAMEs >> to both >> "cname.cdn-a.example" and "cname.cdn-b.example". A client queries both >> A and >> HTTPSVC concurrently for "www.example.net", and receives two answers >> (the answer >> to the A query points to CDN A, while the answer to HTTPSSVC points to >> CDN B): >> >>www.xample.net 3600 IN CNAME cname.cdn-a.example >>cname.cdn-a.example 3600 IN A 192.0.2.1 >> >> and >> >>www.xample.net 3600 IN CNAME cname.cdn-b.example >>cname.cdn-b.example 3600 IN HTTPSSVC 1 . alpn=h3 esniconfig="..." >> >> My understanding is that in this case the client could end up >> connecting to >> 192.0.2.1 (CDN A) with CDN B's ESNI config (or e.g. with the wrong >> ALPN). So if >> the server doesn't provide IP hints there would indeed be impact on >> performance >> because the client would just straight up fail to connect initially >> (e.g. maybe >> CDN A doesn't support HTTP/3, but CDN B's HTTPSSVC says the client can >> use it, >> or just because of the wrong ESNI config). >> >> Long story short, I don't think the text should discourage setting >> ipv4hint and >> ipv6hint here. I get that it's SHOULD NOT and not MUST NOT, but it's >> pretty >> confusing nevertheless. >> > > I don't think the hints are intended for this problem. I think the > general design idea is that A/ are the definitive address results for > a > given name, and clients can just optionally shortcut querying A/ if > given hints. > > In your example, I believe the "." HTTPSSVC entry indicates that the > A/ addresses for "cname.cdn-b.example" should be used, so it doesn't > seem like there is a multi-CDN problem. The correct addresses for the > correct CDN are used. > > But I think this might point out a potential problem with skipping hints > for "." results. If the HTTPSSVC result passes through a CNAME, a > non-HTTPSSVC-supporting recurssive will handle the CNAME, but not lookup > A/ for the HTTPSSVC. > I don't think this can happen. Any CNAME that affects HTTPSSVC will also affect the corresponding A/ queries, which are always issued simultaneously and to the same QNAME. >>> >>> alessandro@'s case was for multiple CNAME's and a recursive with behavior >>> that could follow those in different directions for the different >>> requests. Not technically legal, but the more important question here is >>> whether or not significant instances behave in this non-standard way. If >>> they do, this will lead to a situation where hints would be beneficial even >>> for "." records. >>> >> >> Thanks for the explanation. I would prefer to warn against this, rather >> than encourage more use of hints. When SvcDomainName is ".", I think not >> including hints is going to perform better on average, even in the case of >> multiple CNAMEs, because the split-CNAME cases should be very rare (due to >> caching), but the hints add overhead to every response. They can also >> impair load balancing if managed poorly. > > I had to step away from HTTPSSVC for a bit due to other priorities (hence the > delay in responding), but I've been thinking about this some more and I see > another potential case where the A/ and HTTPSSVC records might diverge. > > Given the following records: > >www.example.net 3600 IN A 192.0.2.1 >www.example.net 3600 IN HTTPSSVC 1 . alpn=h3 echconfig="..." > > * At time T, user A queries a resolver for the www.example.net A record, so > the > resolver fetches it from the auth server and caches it. > > * At time T+5m, user B queries the same resolver for both A and HTTPSSVC > records. The resolver serves the A record from cache, and fetches HTTPSSVC > from the auth server (and caches it). > > * The administrator of www.example.net now decides to move the zone to a > different provider (either manually or with some automatic DNS > load-balancer), > with the following records: > >www.example.net 3600 IN A 192.0.4.1 >www.example.net 3600 IN HTTPSSVC 1 . alpn=h2 > > * At time T+1h+1s, user C queries the same resolver for both A and HTTPSSVC, > the cache entry
