On Jun 22, 2014, at 2:14 AM, John Levine <jo...@taugh.com> wrote: >> Reactions have been, um, mixed. Some folk say it;s a no-brainer, >> others seriously dislike the idea. > > 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. The proposal is simply a way to (a) fill the cache with TLDs immediately on starting, (b) keep it filled when the TTL kicks in, and (c) let the cache know which TLDs do not exist so that the cache can send back NXDOMAIN without asking the root. > It > slurps up a copy of the root zone by AXFR or rsync or something, > checks that all the DNSSEC is valid, and then directly answers queries > about that zone. All the info about the zone comes from the real master > with TTL or other limits to avoid staleness, but once it has the info, > it is in practice authoritative for the zone. (Although I realize that > its answers to queries still say it's a cache, no AA bits on the > answers.) Yes. > Since it has the whole zone, it can immediately return NXDOMAIN for > names in the zone that don't exist, which is not something that caches > currently do. Is the plan that it will infer by looking at the NSEC > or NSEC3 records that nonexistent names don't exist, or is it just > part of the design, it validated the zone, so it knows it has the > whole thing? The latter. That's a benefit of DNSSEC. > 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. > Personally, I think it's fine to do it either way, if you don't want > stale answers, you know how to set TTLs. > > Another question is why one would limit this to the root, since it is > hardly the only zone that has a lot of traffic, much of which is > bogus. One step at a time. > 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. > 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. There is no reason to have this document, which is about the root, suggest what Verisign, Nominet, or any other TLD operator should do. > I also observe that it is very common to do basically this trick at > busy mail sites for DNSBLs. The site copies the DNSBL zones using > rsync or the like, serves it from a server on the LAN, and the caches > are configured to find those zones from the local server rather than > 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. --Paul Hoffman _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
