Re: [Add] WGLC for draft-ietf-add-dnr

[Ben Schwartz <[e-mail]>]

On Wed, Mar 9, 2022 at 12:36 PM Chris Box <[e-mail]> wrote:

> Hi everyone.
>
> I've assessed DNR against relevant parts of draft-ietf-add-requirements.
> Here's the first.
>
>     +=============+===================================================+
>     | Requirement | Description                                       |
>     +=============+===================================================+
>     | R1.1        | Discovery SHOULD provide a local network the      |
>     |             | ability to announce to clients a set of, or       |
>     |             | absence of, designated resolvers.                 |
>
> It's not clear to me how you use DNR to advertise the *absence *of local encrypted DNS. Are we saying the router should send a frame with zero option length (if that is considered a multiple of 16), and zero ADN length? If yes, we should write that. If that's a bad design, we should think about what is better.
>
> I don't think an explicit "absence" indication is needed.  Omitting the
DNR announcement seems sufficient for any use case I can think of.

>     +-------------+---------------------------------------------------+
>     | R1.3        | Discovery SHOULD support all encrypted DNS        |
>     |             | protocols standardised by the IETF.               |
>
> The requirement is approximately met, by virtue of building on SVCB. However I think the draft should normatively depend on draft-ietf-add-svcb-dns rather than the generic draft-ietf-dnsop-svcb-https.
>
> That seems right.

> There's a point to clarify. It is not stated whether it is useful or valid for the SVCB Service Priority to be zero (i.e. AliasMode). I suspect not since it would mean the mandatory SvcParams could not be populated, and may require the client to perform an additional bootstrapping query, potentially over Do53.
>
> I agree we need to make the text clearer here, and I think we should allow
AliasMode.

Consider a gateway that wants to issue a DNR result for an external
resolver, $RESOLVER.  It can do this by resolving SVCB for _dns.$RESOLVER,
and using this to populate DNR.  However, this SVCB resolution has a
limited TTL (e.g. cloudflare-dns.com has a TTL of 5 minutes).  To be able
to issue DHCP responses to new network clients without delay, the gateway
has to keep this SVCB record in its local cache at all times (constantly
refreshing), and issue DHCP responses that expire when that record expires,
which could be much shorter than an ordinary DHCP lease.  If SVCB
resolution fails (e.g. due to an upstream outage), that gateway has to do
something, but I'm not sure what.

In addition to the complexity and inefficiency of this arrangement, it also
creates a "thundering herd" problem.  In a simple implementation, all
devices on the network will have their DHCP information expire
simultaneously (at the end of the SVCB TTL), leading to a brief spike in
DHCP activity.

If AliasMode (or an equivalent) is allowed, the gateway just tells the
devices "use $RESOLVER" and lets them sort it out.  This pushes more
complexity onto the clients, but if the clients already support DDR then
implementation is trivial.