https://www.ietf.org/id/draft-fujiwara-dnsop-resolver-update-00.txt
Why can't a cache store the trustworthiness [RFC 2181] as metadata for the RRset, instead of having another cache? I understand why now we don't want one set to clobber the other, that being "because of abuse." Back in the day I was taught that the parent was authoritative for the left hand side of the NS set (the owner name) and the child was authoritative for the right hand side (the RDATA holding the name server). That is why DNSSEC signs the child but not the parent NS copy set. What is gained beyond suggesting resolvers reduce the child NS TTL to that of the parent TTL (if the child TTL is longer)? Maybe this - I have seen cases where the child won't answer with its NS set but will answer the query for a name in the zone, which works if the parent NS set is used, along with the glue. (Such a setup is broken, but the URL with the name is listed in a web site ranking tool therefore it works.) I've seen these situations work when I use a fully functional, general purpose DNS recursive server but not if I try to descend the tree manually, the tool must be retaining the parent NS set. (Still I don't see the need for multiple caches.)
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
