Re: [dns-privacy] [Ext] Restarting the discussion of draft-ietf-dprive-unilateral-probing

[Daniel Kahn Gillmor <[e-mail]>]

Thanks for addressing these suggestions from Puneet, Paul.

I'm not so sure about this text:

On Mon 2022-09-26 22:32:32 +0000, Paul Hoffman wrote:
> Puneet wrote:
>
>> Generally any NS IP with working encryption should be preferred over
>> Do53.
>
>    All resolvers currently keep NS sets and, in case of encrypted
>    transport failures, the sets MAY be checked for other IPs instead
>    of falling back to Do53 on the same IP. If there is only one IP
>    address with encrypted transport, this means falling back to
>    unencrypted DNS. If a nameserver has three IP addresses,
>    two of which have encrypted transport and the first of those two
>    causes a transport failure, the second of those two will get
>    a large load due to encrypted traffic moving from the first. 

Nothing in the draft so far makes any attempt to tell the recursive
resolver how to select between different authoritative IP addresses
derived from an NS set.

Adding this text actually makes the draft more complex than it needs to
be, and there are some potentially subtle consequences that might
discourage adoption of encrypted transport if we encourage the behavior
Paul has hinted at as a MAY here.  (i grant that MAY is not a strong
prescription, but it does appear to be an endorsement)

I'm particularly concerned that wide adoption of this particular
approach by recursive resolvers would make it so that adoption of
encrypted transport by a single authoritative server within an NS set
would cause that authoritative to attract a disproportionately high
fraction of queries for that NS set, leading to problematic resource
consumption that would appear to be the fault of encrypted transport.

It seems possible that this could lead to authoritative server operators
(especially those who operate one part of a larger NS set) declining to
attempt encrypted transport out of fear of this kind of imbalance.

I'd prefer that the unilateral-probing draft not include any guidance
about how to select an IP from the NS set over hinting that a recursive
resolver might want to do it this way.

         --dkg