On Thu, Jun 11, 2020 at 09:44:07AM +1000, Mark Andrews wrote: > > > > On 11 Jun 2020, at 08:44, Alessandro Ghedini <alessan...@ghedini.me> 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 <ericorth= > >> 40google....@dmarc.ietf.org> wrote: > >> > >>>>>> 8. Maybe I'm missing something, but the following sentence in Section > >>>>>> 6....4 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/AAAA are the definitive address results > >>>>> for a > >>>>> given name, and clients can just optionally shortcut querying A/AAAA if > >>>>> given hints. > >>>>> > >>>>> In your example, I believe the "." HTTPSSVC entry indicates that the > >>>>> A/AAAA 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/AAAA for the HTTPSSVC. > >>>>> > >>>> > >>>> I don't think this can happen. Any CNAME that affects HTTPSSVC will also > >>>> affect the corresponding A/AAAA 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/AAAA 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 cache. > > > > So, unless I'm yet again missing something here, it seems to me that user C > > ends > > up with the A record from the new provider, while HTTPSSVC comes from the > > old > > provider. And since it has echconfig, the client is not allowed to > > fallback, so > > it will be unable to connect to www.example.net until the HTTPSSVC cache > > expires. > > Well firstly if you are going to be using providers, use their domain names in > the HTTPSSVC records. The above configuration is more for self hosting.
So, the domain name is always www.example.net for all providers, are you saying that instead of "HTTPSSVC 1 . ..." it should be "HTTPSSVC 1 www.example.net ..."? I guess the paragraph I quoted above from section 6.4 specifically mentions "." so maybe simply including the full domain instead of "." in HTTPSSVC (even if it matches the record name) is the solution here. It kind of makes the special "." value useless though IMO, and at the very least I would expect the draft to call this out more (again, happy to provide text if we agree this is the way to go). Btw, to clarify, "provider" here is to mean CDN or similar entity that terminates HTTP traffic. It _could_ mean that the "provider" manages DNS as well (so e.g. it could generate HTTPSSVC records transparently). > Secondly nothing is instantaneous in the DNS as it is a loosely coherent > system > and you take that into account when moving providers. i.e. there needs to be > overlap. The problem as far as I can see is that the A/AAAA and HTTPSSVC (without IP hints) do need to be coherent or connections will break. If there was no HTTPSSVC it would be perfectly fine for different users to get different A/AAAA responses during the migration window as long as the old provider keeps serving traffic. But with HTTPSSVC without IP hints, the only ways I can see this overlap to work would be: 1. Both providers have to offer the same set of protocols (HTTP/2, HTTP/3), and more importantly they both would need to implement ECH, which is not at all guaranteed. The new provider would then suffer from ECH fallbacks until the HTTPSSVC cache entries expire (which means slightly slower initial TLS handshakes). 2. The domain administrator disables HTTP/2 and/or HTTP/3, as well as ECH during the migration window. This kind of defeats the purpose of ECH, as it's not very useful if you need to disable it in this kind of situations, particularly if traffic to the domain is split between multiple CDNs via DNS load-balancing which would simply prevent you from enabling ECH at all. I don't particularly find these to be good solutions to the problem TBH, and it's why I think ipv4hint and ipv6hint are more important than the draft makes them to be. If the HTTPSSVC record always provides the hints then the aforementioned overlap would work in the same way as A/AAAA and it wouldn't matter which records the user gets during the migration window. I'm not calling for ipv*hint to be mandatory btw, just to clarify their use. So basically the draft already has the solution to this, but it seems to try to discourage people from using it in the (to me) obvious case where it would be useful. Cheers > > This seems like a more important failure scenario, as it would mean that > > moving > > away from any provider that supports ECH will inevitably lead to downtime > > for at > > least a portion of the zone's traffic until cache entries expire. So, what > > am I > > missing here? > > > > Also, speaking for my original CNAME scenario, I dug out the old discussion > > on > > ESNI and multi-CDN setups > > https://github.com/tlswg/draft-ietf-tls-esni/issues/35 > > which seems to indicate that this is actually a fairly common setup. IIRC > > this > > is what then prompted the addition of the "Address Set" extension in the > > ESNI > > DNS record https://github.com/tlswg/draft-ietf-tls-esni/pull/136 which was > > then > > replaced by HTTPSSVC, and at the time I had (mistakenly it seems) assumed > > that > > the HTTPSSVC IP hints were intended to solve the same problem. > > > > I'd be happy to provide text changes around this btw, though it's probably > > better if we first agree on _what_ needs to be fixed, if anything. > > > > 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 > _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
