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

[Paul Wouters <[e-mail]>]

On Tue, 5 Nov 2019, Warren Kumari wrote:

> $ dig ns a.example.com
> ;; ANSWER SECTION:
> a.example.com. 42923 IN NS ns1-dot.nameservers.example.
> a.example.com. 42923 IN NS ns2.nameservers.example.
>
> Now, if you cannot reach ns1-dot.nameservers.example, whether you fall
> back to ns2.nameservers.example is a matter of client policy /
> paranoia. As this is an *opportunistic* / better than nothing solution
> I'd think that falling back makes sense. This really really isn't a
> replacement for a more secure, downgrade resistant solution (like
> Paul's), but it *is* an incrementally deployable, opportunistic
> convention based solution. We could do it while figuring out a better,
> more secure system...

I guess you need to use ns1-dot and not a TLSA record for
_853._tcp.ns1-dot.nameservers.example.  because no sane implementation
of anything would trust unsigned TLSA records. That also says
something. Opportunistic does not have to mean soft fail.

If you are going to accept a downgrade when under attack, why even
bother with any signaling using name hacks and just try port 853 on
all nameservers, and remember the ones that failed and succeeded for a
little while? Then you truly do not need any coordination between your
nameserver operators at all, for those who depend on secondaries that
they do not control the software of.

Paul