> I offered **two** alternatives to ns-revalidation draft: > > A. I-D.fujiwara-dnsop-resolver-update > > - attacks listed in ns-revalidation draft section 8.3 are not > applicable - zero additional cost in term of queries - easier to > operate/debug because parent-child NS mismatch suddenly does not > influence resolution algorithm - unilateral code-change in resolvers, > i.e. doable in the same time-frame as ns-revalidation
Maybe you can explain this a bit more? I-D.fujiwara-dnsop-resolver-update has the following: - Separate the cache into "authoritative data cache" and "delegation cache". This suggests to me that a serious mismatch between parent and child will also cause problems. May I missed something. - "Step 4.b." is changed as if the response contains a better delegation to other servers, cache the delegation information into delegation cache," This seems to rely on auth. servers including delegation information in answers to queries. When happens if replies are minimized? But the big one seesm to be, this does not use DNSSEC protection for name servers. The draft says: "The update does not effect to DNSSEC [RFC4033] [RFC4034] [RFC4035] because DNSSEC validates authoritative data and does not validate referrals." The whole point is that the child-side NS RRset can be validated with DNSSEC as well as any A/AAAA RRsets for the name servers. In addition I-D.fujiwara-dnsop-resolver-update seems vulnerable to ghost-domain attacks. _______________________________________________ DNSOP mailing list -- dnsop@ietf.org To unsubscribe send an email to dnsop-le...@ietf.org
