In message <alpine.bsf.2.11.1406221459160.94...@joyce.lan>, "John R Levine" writes: > >> 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. > > > > There are some potentially surprising protocol implications for clients > > when recursive servers answer authoritatively for particular queries. > > Specifically, AA and AD bit processing is different. > > I don't get it. The recursive server is still using data that it got from > an authoritative server. Why wouldn't it set the bits the same way it > would as if it had fetched the records one name at a time?
Because authoritative servers don't normally validate the answers they are returning. You have to answer things like what to do when you can't establish a chain of trust to the zone you are serving or prove that there isn't a chain of trust. For a cache you SERVFAIL. An authoritative server's job is to serve the data it has regardless of whether it validates or not. That said it is possible to validate answers from a local copy of a zone and I do just that on my caching servers by having the recursive view query a seperate view which has local copies of the zones in it. > The only thing I can see that's a little funky is that it makes its own > NXDOMAIN responses, but I'd think those would be AD if they're created > from signed RRSETs. Synthesizing NXDOMAIN / NODATA responses is different to having a local copy of the zone. DLV requires caches synthesize negative responses internally so it is not like doing this is impossible. The fun part becomes limiting it to just some zones. For DLV this is easy as the entire namespace is supposed to be involved. There is no bottom of zone to detect and worry about. You also need to do things like maintain seperate NSEC / NSEC3 trees or finding the previous NSEC / NSEC3 record becomes expensive in the general case. In the NSEC3 case you also have to workout where to anchor the search for the NSEC3 record. You also have to worry about things like OPTOUT. For NSEC you can just walk the normal cache tree, provided it is in DNSSEC order, which is why DLV only uses NSEC signed zones. I didn't want to have to solve those other issues involved with NSEC3. > Regards, > John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY > Please consider the environment before reading this e-mail. > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
