>> As I understand it, this changes DNS caches so that for the root zone >> its behavior is somewhere between a cache and a secondary master. > >The cache remains precisely a cache.
I understand that it's still a cache in the DNS hierarchy, but in operation, it's much more like a secondary master. Like a secondary, it bulk fetches the zone, answers all queries about that zone from its own copy, and uses the SOA times to decide when to fetch again. Unlike a secondary master, its answers don't have AA set, and if a refetch fails, it falls back to being an ordinary cache rather than continuing to serve what it has. It also doesn't have anything like notify or ixfr. >> The reason I ask is that I have suggested in the past >> that for DNSBLs or DNSWLs, which tend to have a lot of queries to >> names that don't exist, a DNSSEC-aware cache could synthesize the >> answers to reduce the load on the authoritative servers. The response >> from the dnsop crowd could politely be described as dismissive. > >Synthesizing positive answers in a signed zone is completely different than >sending NXDOMAIN. No, I'm talking about synthesizing NXDOMAIN. If a cache has A and C with DNSSSEC info, then gets a request for B and it sees the NSEC link A->C, it doesn't have to ask whether there is a B. Like I said, the reactions were at best dismissive. When the cache verifies the zone I presume it checks that it has the full chain of NSEC or NSEC3, so it's doing the same thing, just as a batch check up front. >> If you could cache in-addr.arpa, that would automagically do a >> lot of what's in RFC 6303. > >The number of bogus queries for in-addr.arpa has not been seen as a big issue. It must have been at some point, since we have advice for caches to locally intercept 10.in-addr.arpa and such. >> Or the servers at various parts of the Foo >> company could profitably cache foo.com, particularly if it's less >> administrative and technical hassle than setting up a local shadow >> master. > >Verisign could do this if they wanted. No, not .com, foo.com, the organization's own 2LD zone. An organization's own 2LD is likely to be small, and to be heavily used within its own organization. >> the normal place. These zones typically aren't DNSSEC signed for >> various reasons, but it occurs to me that the issues are different >> from the root, and allowing unsigned non-root zones could be OK. > >Could be OK, could also be an attack vector. For this document, which is about >the root, we want as much safety as we can muster. I understand the security issues about the root, but wouldn't the mechanism be exactly the same for any other zone? R's, John _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
