Re: [dns-privacy] [Ext] Threat Model

[Brian Dickson <[e-mail]>]

On Mon, Nov 4, 2019 at 1:56 PM Paul Wouters <[e-mail]> wrote:

> On Mon, 4 Nov 2019, Brian Dickson wrote:
>
> > The names of the servers (and certificate management) would be
> orthogonal to the signaling of DoT support. I would expect the TLSA records
> would
> > be per-server and orthogonal to the per-zone signaling of DoT support.
>
> Again, that would be russian roulette. If I get an NS RRset with 3
> nameservers, and only one of these has a TLSA record, what should I
> do ?
>

IMNSHO, that is something the domain owner needs to consider, much more so
than the resolver operator.

Specifically, this is something that should probably go into a BCP about
DoT:

If you plan on doing DoT and using TLSA records, it is RECOMMENDED that the
same level of redundancy for DoT servers is deployed as would be the
general case for DNS (i.e. two minimum).

(Along with an explanation of why not having TLSA records for at least two
distinct server names would create an availability/security weakness.)

Other than the question of just one TLSA, I think the recommendation on
what to do if only a subset of NS RRSET members have TLSA records, is to
try to use all the ones that have TLSA records, repeatedly, before doing
anything else.
The "anything else" could be any of several things, from some variation of
"serve stale" to SERVFAIL to using Do53.

Brian


>
> 1) Pick the TLSA one
> 2) Pick a random one
>
> For 1) if this protocol is widely deployed, all clients will pick 1) so
> you just shot your redundancy in the foot.
>
> For 2) the clients get reduced privacy for no good reason, so why would a
> client do this?
>
> It is really a per-zone property, not a per-nameserver property.
>
> Paul
>