Some miscellaneous thoughts vaguely related to the discussion ... ## nameserver hostnames in certificates
It's not uncommon for zones to use in-bailiwick aliases for their nameservers, which avoids transitive configuration dependencies and speeds up resolution because the resolver gets glue with the referral rather than having to chase down server addresses. (see discussion of gluelessness on https://cr.yp.to/djbdns/notes.html) This is obviously problematic for using hostname authentication. I suppose a server could provide its IP address(es) and official hostnames in its cert to allow either for authentication... ## third-party secondary servers If the ADoT status is in the delegation (special DS records, special NS records) then that implies a nasty co-ordination cost to any changes. ## glueful bootstrapping If we rely on TLSA records at the nameserver's hostname then there's a fun bootstrapping problem for in-bailiwick delegations. If a resolver queries for the TLSA records in the clear then they'll leak the zone name; if it speculatively tries TLS then it might be really slow waiting for timeouts. ## reverse dns bootstrapping If the resolver looks for TLSA records in the reverse DNS there's a fun case where it has a referral for (say) example.com with glue for ns1.example.com in 192.0.2.1, but then it finds that ns1.example.com is also a server for 2.0.192.in-addr.arpa. The resolver needs to be able to re-use the forward DNS glue to get to the reverse DNS zone. Tony. -- f.anthony.n.finch <d...@dotat.at> http://dotat.at/ Great Orme Head to the Mull of Galloway: East or southeast 4 to 6. Smooth or slight, occasionally moderate in west. Fair. Good. _______________________________________________ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
