On Tue, 2019-11-05 at 09:47 -0500, Paul Wouters 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. > > Paul
If the initial goal, as suggested by Stephen, is to deploy an opportunitistic DoT to encourage deployment, then Paul's suggestion above which de-couples the recursive and authoritative seems wise. This gets "the ball further down the road" while deciding about a more rigorous solution in which recursive resolvers attempt to honour client policy (do fallback, dont fallback, etc.) and how authoritatives advertise their DoT service is developed. Regards, -- Hugo Connery, Head of IT, Dept. Environmental Engineering Technical University of Denmark, http://www.env.dtu.dk _______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
