Re: [DNSOP] feedback on draft-wkumari-dnsop-dist-root-00
On 25/06/2014 12:12 am, Tim Wicinski tjw.i...@gmail.com wrote: (I am merging two of Paul Hoffman's messages into one reply. I hope I am not muddling the message) Doing my own leap frog as well. Speaking as co-chair, Mr. Hoffman is absolutely correct on this point - we are more than OK with half-baked ideas being hand-waved and a solid discussion happening on the list. That's fine: it is supposed to be a consensus document and we aren't there yet. My hope is that DNSOP doesn't become too DNSEXT-like where if the -00 for a proposal isn't universally loved, it is destroyed instead of worked on. To be clear, I'm not immediately reaching for a hatchet (a pint perhaps ;). That said rumour mill preceded the draft and I felt somewhat disappointed by the -00. However I am driven by stability, robustness, and 'accuracy' of the system, thus any 'improvements' must be that with zero detractors compared to the current system. I will invest some time sooner rather than later to dive deeper into the document and highlight places that seem sketchy to me, or even just a little bit nuts. (ie For me, the second con is a rather large bump to the system - but could well be implementation specific) I don't see this so much as a question of being universally loved, but more in the realms of it being technically appropriate for the aspects of protocol function and DNS efficiencies given what we suggest here does have a strong bearing on the (big G) global internet operations. So my first, and biggest, criticism of the draft would be the lack of a clear and specific problem statement that this document addresses, or aims to address. I appreciate that this is half-baked as an answer and thats why its worth bring here, however if the problem definition itself is half baked then we really do have issues. Case in point: the second paragraph of the Intro suggests that the target is the 'somewhat inefficient' cache construction. Can we get some metrics to truly define these inefficiencies? You can also read into the Pro's that latency, DoS, centralised monitoring, junk/negative caching, and lack of DNSSEC validation are all issues. Are these the problems that _this_ draft is specifically addressing? and can we use those as metrics? Or are there other problems that the authors have in mind but haven't documented here for fear of being called a heretic? There are no porcelain angels here - if there is a problem you see (even a political one that makes technical life a pain) please call it out. My hope is that DNSOP doesn't become too DNSEXT-like where if the -00 for a proposal isn't universally loved, it is destroyed instead of worked on. We as chairs do not have that mind set. My personal feeling is to figure out what parts do seem to be useful and have some interest, and guide discussions along those lines. We may be also completely delusional, but I'd like to keep believing otherwise for a little while longer. I'm fine for the discussion and will happily participate. Cheers Terry smime.p7s Description: S/MIME cryptographic signature ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] feedback on draft-wkumari-dnsop-dist-root-00
Hi, Yes, I noted the hand waving as well as a few hand-passes of problems to $elsewhere. I personally think this needs (much) more thinking, before coming to the front of the room in DNSOP - are you considering a bar session somewhere in Toronto to chat through this? Cheers Terry On 24/06/2014 7:32 am, Paul Hoffman paul.hoff...@vpnc.org wrote: Just to be clear: Warren asked for feedback with an open mind. If you read the draft, you'll see Warren and I explicitly handwave. Also, note that at the moment, he and I disagree about some of the suggestions, just like it seems that some people here so far do. FWIW, I currently prefer the result to be a more robust cache (something that acts just like a cache but also knows how to synthesize NXDOMAIN for things not in the root), and Warren prefers the result to be a less robust slave (something that does not have as close of a relationship with the master as what we normally think, but gives authoritative answers). That's fine: it is supposed to be a consensus document and we aren't there yet. My hope is that DNSOP doesn't become too DNSEXT-like where if the -00 for a proposal isn't universally loved, it is destroyed instead of worked on. --Paul Hoffman ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop smime.p7s Description: S/MIME cryptographic signature ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] feedback on draft-wkumari-dnsop-dist-root-00
On Mon, Jun 23, 2014 at 5:32 PM, Paul Hoffman paul.hoff...@vpnc.org wrote: Just to be clear: Warren asked for feedback with an open mind. If you read the draft, you'll see Warren and I explicitly handwave. Also, note that at the moment, he and I disagree about some of the suggestions, just like it seems that some people here so far do. FWIW, I currently prefer the result to be a more robust cache (something that acts just like a cache but also knows how to synthesize NXDOMAIN for things not in the root), and Warren prefers the result to be a less robust slave (something that does not have as close of a relationship with the master as what we normally think, but gives authoritative answers). I suspect I may have worded things poorly, this isn't quite what I think. Just FYI, Paul and I had a chat last night in a really quite nice pub. I was saying that I think both of the above are merely different ways of looking at the same thing (a less strict slave, or a more knowledgeable cache). I also spent some time playing devil's advocate on returning AA vs not AA (it's entirely possible I was pontificating...) Anyway, I think that this solution shouldn't return AA bits -- this is more easily thought of as a cache pre-population system, with the added benefit of knowing the entire zone (so you already know what *doesn't* exist. That's fine: it is supposed to be a consensus document and we aren't there yet. Yup. The draft has an entire Open Questions section -- we specifically want to develop this with folk in DNSOP. We could have come along with a finished document, saying This is how you should do this - there, we fixed it for you..., and then fight over all the bits y;all thing we got wrong. Instead we'd much rather design this *with* everyone so we end up with a better solution (and with less tears too!) My hope is that DNSOP doesn't become too DNSEXT-like where if the -00 for a proposal isn't universally loved, it is destroyed instead of worked on. --Paul Hoffman ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] feedback on draft-wkumari-dnsop-dist-root-00
On Tue, Jun 24, 2014 at 3:57 AM, Paul Hoffman paul.hoff...@vpnc.org wrote: On Jun 24, 2014, at 8:08 AM, Terry Manderson terry.mander...@icann.org wrote: Yes, I noted the hand waving as well as a few hand-passes of problems to $elsewhere. The latter is unintentional. That is, the goal is to have a spec that does everything it says it will. Yup. Please point at bits where we've done this / ask what exactly we were trying to say, or, even better, provide text that answers the hand-wave. I personally think this needs (much) more thinking, before coming to the front of the room in DNSOP - are you considering a bar session somewhere in Toronto to chat through this? That's one option, but we thought that the WG chairs wanted the consensus discussions happening in the WG on the list. If that's not the case, we can certainly churn the draft in private a bit and then bring it to the WG. Yup. We did already churn this some in private -- this general idea has been around for a *long* time, but DNSSEC now makes it much more feasible. There were (unsurprisingly!) a number of emails and discussions with a number of people (many of whom are listed in the contributors section. The rough idea was also presented at DNS-OARC, RIPE and the DNS track at NANOG) before we posted this version. We specifically want to get feedback / more input, which is why we published it as a draft (listing things we know need more discussion as open questions), and then asked folk to poke at it. W --Paul Hoffman ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] feedback on draft-wkumari-dnsop-dist-root-00
From: Tim Wicinski Date: 2014-06-24 22:12 To: dnsop Subject: Re: [DNSOP] feedback on draft-wkumari-dnsop-dist-root-00 Speaking as co-chair, Mr. Hoffman is absolutely correct on this point - we are more than OK with half-baked ideas being hand-waved and a solid discussion happening on the list. That's fine: it is supposed to be a consensus document and we aren't there yet. My hope is that DNSOP doesn't become too DNSEXT-like where if the -00 for a proposal isn't universally loved, it is destroyed instead of worked on. +1 Even it looks to be not a good idea at the first stage, it may become a good idea after a detailed discussion and some adjustment. Jiankang Yao___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] feedback on draft-wkumari-dnsop-dist-root-00
Tim Wicinski wrote: ... On 6/24/14 3:57 AM, Paul Hoffman wrote: My hope is that DNSOP doesn't become too DNSEXT-like where if the -00 for a proposal isn't universally loved, it is destroyed instead of worked on. We as chairs do not have that mind set. My personal feeling is to figure out what parts do seem to be useful and have some interest, and guide discussions along those lines. We may be also completely delusional, but I'd like to keep believing otherwise for a little while longer. i don't think universal love should be the standard for surviving one's -00 or not -- so that would be a straw man argument if anyone is actually making it. however, the standard for consensus should remain good engineering in view of the overall system. i've authored any number of silly -00's over the years, which were killed before there could be a -01, because discussion in the forum pointed in that direction. e.g., dns-0x20 remains a bad idea, and will remain a bad idea, no matter how much work the group does on it. let's not learn the wrong lesson from dnsext's disgrace -- some -00 ideas do deserve to die. warren introduced dist-root to me in warsaw during dns-oarc as possibly one such stupid idea, and i agreed with him and told him why. per drc, i owe this forum a copy of those reasons. the chairs, and the co-authors, should be open to the possibility that no amount of work will yield consensus that the idea is sound and that the resulting overall system would be stronger than either the system we have now or other more easily reached alternatives. vixie ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] feedback on draft-wkumari-dnsop-dist-root-00
Paul, On Jun 23, 2014, at 5:02 AM, Paul Vixie p...@redbarn.org wrote: in this case, warren kumari is usually pretty smart and sane, but this time he's come up with a really bad idea. Your message seemed to have been oddly truncated such that the because ... part of this sentence was lost. my own related proposal can be found in the ICANN ITI report https://www.icann.org/en/system/files/files/report-21feb14-en.pdf section 9.4. Are you intending to submit that as an ID? Regards, -drc signature.asc Description: Message signed with OpenPGP using GPGMail ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] feedback on draft-wkumari-dnsop-dist-root-00
Just to be clear: Warren asked for feedback with an open mind. If you read the draft, you'll see Warren and I explicitly handwave. Also, note that at the moment, he and I disagree about some of the suggestions, just like it seems that some people here so far do. FWIW, I currently prefer the result to be a more robust cache (something that acts just like a cache but also knows how to synthesize NXDOMAIN for things not in the root), and Warren prefers the result to be a less robust slave (something that does not have as close of a relationship with the master as what we normally think, but gives authoritative answers). That's fine: it is supposed to be a consensus document and we aren't there yet. My hope is that DNSOP doesn't become too DNSEXT-like where if the -00 for a proposal isn't universally loved, it is destroyed instead of worked on. --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
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
Re: [DNSOP] feedback on draft-wkumari-dnsop-dist-root-00
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. 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.) 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 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. 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. If you could cache in-addr.arpa, that would automagically do a lot of what's in RFC 6303. 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. 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. R's, John ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
