Re: [DNSOP] feedback on draft-wkumari-dnsop-dist-root-00
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
Re: [DNSOP] feedback on draft-wkumari-dnsop-dist-root-00
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
Re: [DNSOP] feedback on draft-wkumari-dnsop-dist-root-00
On 22 Jun 2014, at 11:54, John Levine jo...@taugh.com wrote: 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. 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. If the suggestion is that a resolver with an AXFR- (or whatever-) sourced root zone should behave identically to a resolver that operates conventionally, then there are protocol changes and corresponding implementation changes needed. This draft proposes significant implementation changes for resolvers anyway, but I'm not convinced anybody has enthusiasm for revisiting the DNSSEC and DNS spec just to support this proposal (but perhaps I'm wrong, and I'm certainly biased in my mental risk/benefit analysis since I think this is a bad idea with very marginal benefit to anybody). If the suggestion is that the different behaviour is commonly observed in the wild and so therefore it's a public service to document it, then I have no problem with that. This document goes further than that, though. Joe ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] feedback on draft-wkumari-dnsop-dist-root-00
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? 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. 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
Re: [DNSOP] feedback on draft-wkumari-dnsop-dist-root-00
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
Re: [DNSOP] feedback on draft-wkumari-dnsop-dist-root-00
On 22 Jun 2014, at 18:41, Joe Abley jab...@hopcount.ca wrote: On 22 Jun 2014, at 11:54, John Levine jo...@taugh.com wrote: 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. 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 think that anybody is suggesting this. I think it is more appropriate to think of the solution as the resolver having a tiny authoritative server inside serving the root. If it has a copy of the root zone transferred it answers, if not it doesn't and the recursion goes the normal way. That is similar to what people did when there was fear of an attack on the root servers, just inside the server and not with two servers. So long -Ralf ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
