Wes Hardaker <w...@hardakers.net> wrote: > > My list for putting a TLSA or similar record at the reverse zone > include: > > pros: > - the authoritative server more likely in control of its reverse zone than all > the forward zones its serving
Reverse zones plural (v4 + v6) :-) > - the number of reverse zone records to update on a key change is 1 per ip > address. The number of name server NS records to update per key > change is 1 per zone supported, which is very very large for some > servers. For forward DNS it is 1 per name server name (i.e. per alias), which might be 1 per zone for places that provision zones with in in-bailiwick name server names, or might be 1 per server if they prefer to provision zones with canonical name server names. > - it feels cleaner > cons: > - not everyone controls their reverse zone easily, especially for those > that don't hold at least a /24 allocation. Ironically, I fall into > this camp but still think this is a better solution than a name-based one. > - requires more lookups > - requires the reverse tree for that address be fully signed The "more lookups" thing is interesting. If the TLSA-like record is in the forward DNS, then you get into a bootstrapping problem. Assuming we can't add these new records as glue, a resolver ends up having to: * query a parent server for delegation; receive NS records and glue * query a child server publicly for TLSA-like record(s) * query child server privately for actual question i.e. in the DNS case we lose the opportunity for concurrent address + TLSA queries that DANE normally offers. If the TLSA-like record is in the reverse DNS, and the reverse DNS nameservers are cached, then the sequence of lookups is the same. The "more lookups" case happens when there's a cold reverse DNS cache as well as a cold forward cache. Putting TLSA-like records in the reverse DNS doesn't solve the bootstrap problem, in cases where the server you want the TLSA-like record for is authoritative for its own reverse zones. I started a thread discussing related things back in September... https://www.ietf.org/mail-archive/web/dns-privacy/current/msg02124.html Tony. -- f.anthony.n.finch <d...@dotat.at> http://dotat.at/ public services available on equal terms to all _______________________________________________ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
