Ed, ----- Original Message ----- > From: "Edward Lewis" <edward.le...@icann.org> > To: "dnsop" <dnsop@ietf.org> > Sent: Sunday, 13 November, 2016 08:27:35 > Subject: [DNSOP] Why 2 caches? draft-fujiwara-dnsop-resolver-update-00
> 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 think think this is a technical detail best left to the software vendors and it should be removed from the draft. As a side note, having a (platform-sized) pointer for each RR in the RR-cache is a huge bloat... > 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. If we were to design RFC1034/1035 again I would say that NS records are more close to DS. > What is gained beyond suggesting resolvers reduce the child NS TTL to that of > the parent TTL (if the child TTL is longer)? The predictability of resolver behavior. As I said in one of my previous replies, you are not guaranteed that the child NS will ever reach the resolver when answer minimization is in effect. And what exactly happens when the NS records expire? It depends - is the resolver prefetching, so it still knows the existing nameservers - possibly pulling the child NS in this TTL round? Or did it expire completely and the resolver has to start from bottom - just pulling only the parent nameservers again? Cheers, -- Ondřej Surý -- Technical Fellow -------------------------------------------- CZ.NIC, z.s.p.o. -- Laboratoře CZ.NIC Milesovska 5, 130 00 Praha 3, Czech Republic mailto:ondrej.s...@nic.cz https://nic.cz/ -------------------------------------------- _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
