Content-Type: text/plain;
	charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.5\))
From: Mark Andrews <marka@isc.org>
In-Reply-To: <20200610224455.GA44302@sokka.flat11.house>
Date: Thu, 11 Jun 2020 09:44:07 +1000
Cc: Ben Schwartz <bemasc@google.com>, dnsop <dnsop@ietf.org>,
 Eric Orth <ericorth=40google.com@dmarc.ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <5833E55F-A483-4781-BF51-DDDE95FB0677@isc.org>
References: <20200417101932.GA2035@wakko.flat11.house>
 <CAMOjQcF10Ceh=O1-s58Kw_j_hekbCnfmQ9sMZGZiwvhDdbg2bA@mail.gmail.com>
 <CAHbrMsBCeg+3wDcbAJk=KZC1y0RPtLjznst2NVSDJQVSRL84XA@mail.gmail.com>
 <CAMOjQcHTgsJo4-9O=uZF9PTOGHz0s7BFmOBuCn4nStQ+6YnW1Q@mail.gmail.com>
 <CAHbrMsDTBDuuO27mS9KbeHC042incgPbtozHZZ7tx=X2o6=RiA@mail.gmail.com>
 <20200610224455.GA44302@sokka.flat11.house>
To: Alessandro Ghedini <alessandro@ghedini.me>
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/49iVQ7V--kicNtVMs48Ky4rpEa0>
Subject: Re: [DNSOP] Comments on draft-ietf-dnsop-svcb-httpssvc-02
Precedence: list



> On 11 Jun 2020, at 08:44, Alessandro Ghedini <alessandro@ghedini.me> =
wrote:
>=20
> 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=3D
>> 40google.com@dmarc.ietf.org> wrote:
>>=20
>>>>>> 8. Maybe I'm missing something, but the following sentence in =
Section
>>>>>> 6....4 seems
>>>>>> wrong:
>>>>>>=20
>>>>>>   When SvcDomainName is ".", server operators SHOULD NOT include =
these
>>>>>> hints,
>>>>>>   because they are unlikely to convey any performance benefit.
>>>>>>=20
>>>>>> 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):
>>>>>>=20
>>>>>>    www.xample.net      3600 IN CNAME cname.cdn-a.example
>>>>>>    cname.cdn-a.example 3600 IN A 192.0.2.1
>>>>>>=20
>>>>>> and
>>>>>>=20
>>>>>>    www.xample.net      3600 IN CNAME cname.cdn-b.example
>>>>>>    cname.cdn-b.example 3600 IN HTTPSSVC 1 . alpn=3Dh3 =
esniconfig=3D"..."
>>>>>>=20
>>>>>> 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).
>>>>>>=20
>>>>>> 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.
>>>>>>=20
>>>>>=20
>>>>> 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.
>>>>>=20
>>>>> 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.
>>>>>=20
>>>>> 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.
>>>>>=20
>>>>=20
>>>> 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.
>>>>=20
>>>=20
>>> 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.
>>>=20
>>=20
>> 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.
>=20
> 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.
>=20
> Given the following records:
>=20
>    www.example.net      3600 IN A 192.0.2.1
>    www.example.net      3600 IN HTTPSSVC 1 . alpn=3Dh3 echconfig=3D"..."=

>=20
> * 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.
>=20
> * 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).
>=20
> * 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:
>=20
>    www.example.net      3600 IN A 192.0.4.1
>    www.example.net      3600 IN HTTPSSVC 1 . alpn=3Dh2
>=20
> * 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.
>=20
> 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.

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.

> 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?
>=20
> 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.
>=20
> 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.
>=20
> Cheers
>=20
> _______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop

--=20
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742              INTERNET: marka@isc.org