On Tue, Nov 5, 2019 at 9:47 AM Paul Wouters <[email protected]> wrote: > 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.
Because then I need to probe them on 853 and wait N before trying on port 53, or I will only get any sort of protection for name-servers which I’ve spoken to recently enough that I have them in cache — that works for e.g: ns1.google.com, but not ns0.nohats.ca W > > Paul > -- I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf
_______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
