Re: [DNSOP] draft-wkumari-dnsop-dist-root-01.txt
Declan Ma wrote: Zhiwei, Your proposal seems reasonable. But we can not separate the recursive-level and authorative-level, as you call it by the way, since the DNS is an integrated one. If both of the two solutions are feasible, we need to figure out how and to what extent, both solutions could collaborate on root zone file distribution, not in the “respective scenarios” . Declan Ma ZDNS in my opinion, the applicability statement of a recursive solution would be: if you want these benefits and can manage these risks, then you can configure your rdns as follows. whereas the applicability statement for an authoritative solution would be: if you want to serve root dns content to a loopback, lan, campus, or global network, then configure your adns and your routing as follows. separate from applicability, there is vision. the vision statement for an rdns solution would be: to allow self selected recursive dns operators to become less dependent on the root name server system, the following proposal is offered. whereas the vision statement for the adns solution would be: to better server root dns content to the internet, the following proposal is offered. vixie ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft-wkumari-dnsop-dist-root-01.txt
I would suggest there is also a third angle here: On Jul 8, 2014, at 11:30 PM, yzw_iplab yzw_ip...@163.commailto:yzw_ip...@163.com wrote: Hi, all, There are currently two solutions proposed to distrbute the DNS root service more widely.In my opinion, we should work on this issue following the two steps: 1) we should discuss their feasibility from technological aspects. the technological requirements of them should be gathered and listed ,and then analyzed one by one. 2) these two solutions consider the similar issue from different levels: one is the recursive-level and another one is the authorative-level. (if both of them are feasible) we should figure out respective scenarios and requirements suitable for each of them. 3) we should discuss how easily the solutions can actually be *deployed* and used. I realize this is perhaps a subset of #1, but I want to call it out specifically because this step seems to be sometimes overlooked. If, for instance, a solution requires changes to the way stub resolvers work and requires updates to the zillions of devices out there that now provide embedded DNS resolvers, the chances of that solution being *widely* deployed are significantly less than a solution that requires changes at only, say, authoritative name servers. Not to say the first solution *couldn't* be deployed, but we just need to be realistic up front about what it might take to get the solution out there. My 2 cents, Dan (who spends his days looking at how to get DNSSEC more widely deployed) -- Dan York Senior Content Strategist, Internet Society y...@isoc.orgmailto:y...@isoc.org +1-802-735-1624 Jabber: y...@jabber.isoc.orgmailto:y...@jabber.isoc.org Skype: danyork http://twitter.com/danyork http://www.internetsociety.org/deploy360/ ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft-wkumari-dnsop-dist-root-01.txt
Patrik, On Jul 7, 2014, at 10:02 PM, Patrik Fältström p...@frobbit.se wrote: The main argument against slaving the root I've seen appears to me to be FUD: people running resolvers are too stupid to configure slaving the root correctly so root data will go stale! (paraphrased). I am a bit disappointed that you David do summarize the arguments against this proposal in this way. Sorry to disappoint you by stating how the main arguments against the draft appear to me. What I have recommended Warren to do is to properly list the arguments, make a proper analysis (an attack tree would be one good start) because my largest fear is that the various issues that might look like weaknesses of the proposal must be analyzed, and that they are not. I'm sure Warren will do an outstanding job if he chooses to obey your recommendation. Perhaps one of the undoubtedly many reasons for your disappointment is that I am taking the system as it currently exists (as least as I understand it). As far as I am aware, that system does not have any solution to: - Lack of DNSSEC validation - The fact not all data in the root zone is signed - Lack of legal protection of the root zone itself Do you believe the current system addresses these concerns? If so, how? With respect to the others: - Recovery process when bad data end up in the resolver (cache v.s. auth) As I've pointed out, if bad data is being served to clients of a resolver, those affected can call up their resolver operator and demand they fix it. Since the users of the resolver may actually be paying customers, there might even be a chance that the resolver operator will listen. What would be the recovery process if the existing root server system distributed bad data? If I root started serving bad data, how would anyone non-technical know even who to call? Assume they know how to call their ISP's help desk and that help desk is able to figure out it is the I root server that is serving the bad data. How will that help desk implement a fix on the I root server? What is the likely timeframe from detection of problem to fix compared to the slaving the root scenario? More generally, what recourse does _anyone_ have if a root server operator (say) chooses not to upgrade bandwidth to their root when it drops the majority of queries? Or goes off the air for a few days? Or doesn't deploy IPv6? - Routing issues (which is what I see the largest burden of a root server operator) Must have missed this one and am unsure what it means in this context. What routing issues were asserted that resolver operators that slave the root are going to have? It would seem to me that the slaving the root approach can vastly simplify the routing (no need for inter-AS anycast) so I must be missing something. - Political/regulative implications (to ensure a different TA is used than ICANN) I'm confused. Did you mean to stop someone from using a different TA? What's to stop someone from doing that now? ...and possibly more. Yes, perhaps there are more and perhaps if Warren obeys your recommendation, they'll be discovered. However, as many people have pointed out, _people are already slaving the root_ and oddly disaster has not befallen the Internet (or the customers of the folks that are slaving the root) as yet. Quoting Ralf Weber: The draft doesn't require every resolver to slave the zone, but merly is an information that this is a possible way to do it and I assume that large resolver operators would benefit from it [...] It in the end of course comes down to do we want to document what is out there anyway or do we want to hide our heads in the sand. Especially for an operational group I would prefer the former. Once again, this is such a large issue that I would prefer a bit better arguments than what is demonstrated here. Actually, since it is opt-in, it doesn't seem to be that large of an issue to me, but perhaps that's because I'm not a root server operator and have no particular interest in maintaining the status quo. Yes, I know you wrote in affection, but let this remind all of us that we can do better. Undoubtedly we can. 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] draft-wkumari-dnsop-dist-root-01.txt
On 8 jul 2014, at 08:22, David Conrad d...@virtualized.org wrote: On Jul 7, 2014, at 10:02 PM, Patrik Fältström p...@frobbit.se wrote: The main argument against slaving the root I've seen appears to me to be FUD: people running resolvers are too stupid to configure slaving the root correctly so root data will go stale! (paraphrased). I am a bit disappointed that you David do summarize the arguments against this proposal in this way. Sorry to disappoint you by stating how the main arguments against the draft appear to me. That I understand, and I myself react like that regarding arguments both in favor and against the proposal. One could say the discussion is a typical non-constructive IETF discussion which too many are. What I have recommended Warren to do is to properly list the arguments, make a proper analysis (an attack tree would be one good start) because my largest fear is that the various issues that might look like weaknesses of the proposal must be analyzed, and that they are not. I'm sure Warren will do an outstanding job if he chooses to obey your recommendation. Perhaps one of the undoubtedly many reasons for your disappointment is that I am taking the system as it currently exists (as least as I understand it). As far as I am aware, that system does not have any solution to: - Lack of DNSSEC validation - The fact not all data in the root zone is signed - Lack of legal protection of the root zone itself Do you believe the current system addresses these concerns? If so, how? The discussion about these things, and the differences between a cache and authoritative server I would like to have in a room where people are not shouting at each other. There are differences, and you know that as well as I. With respect to the others: - Recovery process when bad data end up in the resolver (cache v.s. auth) As I've pointed out, if bad data is being served to clients of a resolver, those affected can call up their resolver operator and demand they fix it. Since the users of the resolver may actually be paying customers, there might even be a chance that the resolver operator will listen. The market economy forces fixing things is correct. What I was thinking of is for example the difference between restarting a caching resolver and re-priming an auth server. Sure, everyone can learn both recovery mechanisms, but restart your server is quite simple task. Once again, I want the arguments listed. What would be the recovery process if the existing root server system distributed bad data? If I root started serving bad data, how would anyone non-technical know even who to call? Assume they know how to call their ISP's help desk and that help desk is able to figure out it is the I root server that is serving the bad data. How will that help desk implement a fix on the I root server? What is the likely timeframe from detection of problem to fix compared to the slaving the root scenario? You here list a few to me different problems. If people get wrong data from the IP address of I they call Netnod. More generally, what recourse does _anyone_ have if a root server operator (say) chooses not to upgrade bandwidth to their root when it drops the majority of queries? Or goes off the air for a few days? Or doesn't deploy IPv6? That is, as you know, also an interesting discussion. - Routing issues (which is what I see the largest burden of a root server operator) Must have missed this one and am unsure what it means in this context. What routing issues were asserted that resolver operators that slave the root are going to have? It would seem to me that the slaving the root approach can vastly simplify the routing (no need for inter-AS anycast) so I must be missing something. What I want to have examined is how to ensure the right data is coming to whoever wants it, and who is responsible to clean up when there are issues. Today, as you say yourself, the responsibility is on the root server operators. - Political/regulative implications (to ensure a different TA is used than ICANN) I'm confused. Did you mean to stop someone from using a different TA? What's to stop someone from doing that now? I see it as a big difference between having auth data (explicitly changed) within a difficult democracy and having caches of the data. Sure, some of them have already implemented what you talk about but having IETF explicitly saying auth data is coming from recursive resolvers will from my point of view drastically increase the amount of blocked DNS traffic across the global Internet and that will indeed impact network neutrality. ...and possibly more. Yes, perhaps there are more and perhaps if Warren obeys your recommendation, they'll be discovered. However, as many people have pointed out, _people are already slaving the root_ and oddly disaster has not befallen the Internet (or the
Re: [DNSOP] draft-wkumari-dnsop-dist-root-01.txt
Hiya, I really like this idea. Many ISPs already do this, (including some high profile public recursives, like Google and OpenDNS), because it simply makes sense: It reduces latency for the end user, reduces outbound traffic overhead, eliminates an attack vector. This specific document shouldn’t be a discussion point at all. Folks are doing this right now. What we need is a BCP that describes: IFF you are going to do it, here is how. I would also like to see some facilitation around this as well: a notify service of new versions, a zone distribution service (xfer service), possibly out of ICANN or VeriSign. Personally, I’m interested in what operators of large recursives have to say about this. Hope this helps. Roy On 04 Jul 2014, at 21:50, Paul Hoffman paul.hoff...@vpnc.org wrote: Greetings. Warren and I have done a major revision on this draft, narrowing the design goals, and presenting more concrete proposals for how the mechanism would work. We welcome more feedback, and hope to discuss it in the WG in Toronto. --Paul Hoffman Begin forwarded message: From: internet-dra...@ietf.org Subject: I-D Action: draft-wkumari-dnsop-dist-root-01.txt Date: July 3, 2014 at 2:17:46 PM PDT To: i-d-annou...@ietf.org Reply-To: internet-dra...@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Securely Distributing the DNS Root Authors : Warren Kumari Paul Hoffman Filename: draft-wkumari-dnsop-dist-root-01.txt Pages : 9 Date: 2014-07-03 Abstract: This document recommends that recursive DNS resolvers get copies of the root zone, validate it using DNSSEC, populate their caches with the information, and also give negative responses from the validated zone. [[ Note: This document is largely a discussion starting point. ]] The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-wkumari-dnsop-dist-root/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-wkumari-dnsop-dist-root-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-wkumari-dnsop-dist-root-01 ___ 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] draft-wkumari-dnsop-dist-root-01.txt
On Jul 8, 2014, at 7:40 AM, Roy Arends r...@dnss.ec wrote: Hiya, I really like this idea. Many ISPs already do this, (including some high profile public recursives, like Google and OpenDNS), because it simply makes sense: It reduces latency for the end user, reduces outbound traffic overhead, eliminates an attack vector. This specific document shouldn’t be a discussion point at all. Folks are doing this right now. What we need is a BCP that describes: IFF you are going to do it, here is how. I would also like to see some facilitation around this as well: a notify service of new versions, a zone distribution service (xfer service), possibly out of ICANN or VeriSign. Personally, I’m interested in what operators of large recursives have to say about this. Hope this helps. Roy Roy you hit the nail on the head, this is a no brainer as a BCP. The contents of this draft may or may not be right at this point but we need a BCP that explains how to do this and the pitfalls to be aware off. For an DNS resolution provider that elects to there are two ways to do it, forward zone local authoritative zone. both should be allowed, this document seems “bind” specific that it assumes that the recursive resolver can be both authoritative and recursive which is not a requirement. There is no need that every recursive resolver at a Resolution Provider have a copy of the root zone only that the resolvers know the “local root servers”. In my mind this is not that far off from Anycast root servers i.e. additional server placed closer to the query generators. The big difference is in management and control. The root server operators believe (correctly) that they provide valuable service and are critical to the operation of the internet, They also believe that having close control over all root servers is essential. A number of people over the years have said that the current model is not the only possible way to provide the same service just as well, further diversification of root server services is enabled by DNSSEC. The open question is does the promotion of this type of service create any NEW attacks agains the CONTENT of the root zone, i.e. would this have made the it possible/easier for Turkey to restrict access to Google and Twitter? The technical question that needs to be answered what is the safest way to distribute the root zone and locally validate it before making it available on the “local root servers”. In my mind the answer Notify and incremental XFR with stronger protections. I think the answer is NO thus I support the promotion of a BCP on “locally provided root servers”. Olafur On 04 Jul 2014, at 21:50, Paul Hoffman paul.hoff...@vpnc.org wrote: Greetings. Warren and I have done a major revision on this draft, narrowing the design goals, and presenting more concrete proposals for how the mechanism would work. We welcome more feedback, and hope to discuss it in the WG in Toronto. --Paul Hoffman Begin forwarded message: From: internet-dra...@ietf.org Subject: I-D Action: draft-wkumari-dnsop-dist-root-01.txt Date: July 3, 2014 at 2:17:46 PM PDT To: i-d-annou...@ietf.org Reply-To: internet-dra...@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Securely Distributing the DNS Root Authors : Warren Kumari Paul Hoffman Filename: draft-wkumari-dnsop-dist-root-01.txt Pages : 9 Date: 2014-07-03 Abstract: This document recommends that recursive DNS resolvers get copies of the root zone, validate it using DNSSEC, populate their caches with the information, and also give negative responses from the validated zone. [[ Note: This document is largely a discussion starting point. ]] The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-wkumari-dnsop-dist-root/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-wkumari-dnsop-dist-root-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-wkumari-dnsop-dist-root-01 ___ 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 ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft-wkumari-dnsop-dist-root-01.txt (and draft-lee-dnsop-scalingroot-00.txt)
Colleagues, We have two drafts on the general topic of wider distribution for the root zone, and the draft agenda says we'll devote some time to both of them. The drafts discuss different methods, which may or may not be complementary, each having strengths and weaknesses to consider. It's no surprise that people have strong feelings about them. To me at least, one important question is what problem we're seeking to solve, or document existing solutions for? I'm not suggesting a full requirements analysis, and I think there is a fairly simple underlying problem statement to be had (at least one!), but I'd like to take a step back from the specifics for a moment: we have now one document that some people seem to want to call a BCP and others want labeled strictly cautionary, and another document that we still haven't really looked at. I'd like to see as much agreement as possible, or at least as much clarity as possible, on how we'll judge what work we want to commit to as the WG: do we want a BCP out of this? a document describing methods, without judgment? a suggestion for IANA or others, which of course they can take or not? All of those things? The kernel of a problem statement to me looks like: A few hundred root name servers behind a handful of IP addresses for a network of millions of servers used by billions of people constitutes a weakness; reliable access to the contents of the root zone should be more widely available. What people seem to want to discuss is how to scale the existing capacity within the constraints provided by the protocol, resource availability, and prevalent operational models. If that's a reasonable question, pros and cons of a given solution spin out from there. Please review both drafts, discussion welcome here and at IETF 90. best, Suzanne On Jul 8, 2014, at 8:03 AM, Olafur Gudmundsson o...@ogud.com wrote: On Jul 8, 2014, at 7:40 AM, Roy Arends r...@dnss.ec wrote: Hiya, I really like this idea. Many ISPs already do this, (including some high profile public recursives, like Google and OpenDNS), because it simply makes sense: It reduces latency for the end user, reduces outbound traffic overhead, eliminates an attack vector. This specific document shouldn’t be a discussion point at all. Folks are doing this right now. What we need is a BCP that describes: IFF you are going to do it, here is how. I would also like to see some facilitation around this as well: a notify service of new versions, a zone distribution service (xfer service), possibly out of ICANN or VeriSign. Personally, I’m interested in what operators of large recursives have to say about this. Hope this helps. Roy Roy you hit the nail on the head, this is a no brainer as a BCP. The contents of this draft may or may not be right at this point but we need a BCP that explains how to do this and the pitfalls to be aware off. For an DNS resolution provider that elects to there are two ways to do it, forward zone local authoritative zone. both should be allowed, this document seems “bind” specific that it assumes that the recursive resolver can be both authoritative and recursive which is not a requirement. There is no need that every recursive resolver at a Resolution Provider have a copy of the root zone only that the resolvers know the “local root servers”. In my mind this is not that far off from Anycast root servers i.e. additional server placed closer to the query generators. The big difference is in management and control. The root server operators believe (correctly) that they provide valuable service and are critical to the operation of the internet, They also believe that having close control over all root servers is essential. A number of people over the years have said that the current model is not the only possible way to provide the same service just as well, further diversification of root server services is enabled by DNSSEC. The open question is does the promotion of this type of service create any NEW attacks agains the CONTENT of the root zone, i.e. would this have made the it possible/easier for Turkey to restrict access to Google and Twitter? The technical question that needs to be answered what is the safest way to distribute the root zone and locally validate it before making it available on the “local root servers”. In my mind the answer Notify and incremental XFR with stronger protections. I think the answer is NO thus I support the promotion of a BCP on “locally provided root servers”. Olafur On 04 Jul 2014, at 21:50, Paul Hoffman paul.hoff...@vpnc.org wrote: Greetings. Warren and I have done a major revision on this draft, narrowing the design goals, and presenting more concrete proposals for how the mechanism would work. We welcome more feedback, and hope to discuss it in the WG in Toronto.
Re: [DNSOP] draft-wkumari-dnsop-dist-root-01.txt
On Jul 7, 2014, at 10:02 PM, Patrik Fältström p...@frobbit.se wrote: - Recovery process when bad data end up in the resolver (cache v.s. auth) That's the cache has gone stale issue that David raised. It is dealt with in the current draft. There is no other way for bad data to be in the cache other than by having it come from a signed root zone that has changed. - Routing issues (which is what I see the largest burden of a root server operator) The draft does not impose any routing issue on the root. In fact, it says that the signed root might be gotten from entities that are not root zone operators. - Lack of DNSSEC validation The draft says repeatedly that the information is only entered if it is DNSSEC validated. If you can find any sentence in the draft that says differently, I'll fix it immediately. - The fact not all data in the root zone is signed That is a statement with no effect. If the data is not signed when it is retrieved from the signed root zone, it will be unsigned when retrieved using normal queries to the root zone. - Political/regulative implications (to ensure a different TA is used than ICANN) That is a statement with no effect. Nothing in the draft changes the TA used to validate the root zone, so a validating recursive resolver acts identically whether it uses the mechanism or not. - Lack of legal protection of the root zone itself Please try to explain this. The root zone operators current serve the root zone signed with DNSSEC. This draft doesn't change that, so there are no new legal implications. ...and possibly more. That is not helpful. ...and of course a combination of these. Umm, that is not helpful either. Once again, this is such a large issue that I would prefer a bit better arguments than what is demonstrated here. The reason that there are not arguments in the -01 draft to deal with your issues above is that they seem unrelated to the draft. It is hard to have a section that says Someone objected that this does X, but they are wrong that has a finite length. Yes, I know you wrote in affection, but let this remind all of us that we can do better. Sure, but bringing up issues that are just as true whether or not the draft is implemented is not doing better. Having a list of issues that come from what the draft changes would be great: we can deal with those. --Paul Hoffman P.S. None of the above relates to Joe's big issue, which is that implementing the draft doesn't help anyone much. To me, that's a much more valid (and measurable) criticism than anything on the list above. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft-wkumari-dnsop-dist-root-01.txt
On Tue, 8 Jul 2014, Olafur Gudmundsson wrote: On Jul 8, 2014, at 7:40 AM, ? Roy Arends r...@dnss.ec wrote: Hiya, I really like this idea. Many ISPs already do this, (including some high profile public recursives, like Google and OpenDNS), because it simply makes sense: It reduces latency for the end user, reduces outbound traffic overhead, eliminates an attack vector. (possibly some more questions or variations for the draft to consider) How can I as a user ensure that what Google does in the name of moi, can be verified to be an untampered copy of the root zone? How do I as a user know if there's a stale copy of the root zone being slaved^H^H^H^H^H^H^H supplied by my ISP? (is not being able to reach wyle.e.coyote.acme enough to give me that hint?) How do I know if my ISP, etc. are running a local copy of the zone? Can I call RSACC to complain about an outage? (In other words, what are the mechanisms for someone to figure this out before calling the helpdesk, or, should the draft say to call if you suspect something is wrong? They'd probably do it anyways...maybe. Yes, I'm rhetorical here, DNSSEC etc for mitigation, etc.) Roy Roy you hit the nail on the head, this is a no brainer as a BCP. The contents of this draft may or may not be right at this point but we need a BCP that explains how to do this and the pitfalls to be aware off. BCP or informational (cautionary tales)? For an DNS resolution provider that elects to there are two ways to do it, forward zone local authoritative zone. both should be allowed, this document seems ?bind? specific that it assumes that the recursive resolver can be both authoritative and recursive which is not a requirement. There is no need that every recursive resolver at a Resolution Provider have a copy of the root zone only that the resolvers know the ?local root servers?. I see mentions of 'Resolution Provider'. Is this a BCP for only them, or can anyone join the local auth zone party at their own risk/pleasure, at which point it's informational or still BCP? What is the litmus test? In my mind this is not that far off from Anycast root servers i.e. additional server placed closer to the query generators. The big difference is in management and control. There were good intentions behind the Cymru bogon list. Every once in a while, we start to see complaints of former bogons being unreachable because they're no longer bogons. Is there a similar risk for that here and should it be identified? The root server operators believe (correctly) that they provide valuable service and are critical to the operation of the internet, They also believe that having close control over all root servers is essential. A number of people over the years have said that the current model is not the only possible way to provide the same service just as well, further diversification of root server services is enabled by DNSSEC. The open question is does the promotion of this type of service create any NEW attacks agains the CONTENT of the root zone, i.e. would this have made the it possible/easier for Turkey to restrict access to Google and Twitter? The technical question that needs to be answered what is the safest way to distribute the root zone and locally validate it before making it available on the ?local root servers?. In my mind the answer Notify and incremental XFR with stronger protections. I think the answer is NO thus I support the promotion of a BCP on ?locally provided root servers?. Olafur On 04 Jul 2014, at 21:50, Paul Hoffman paul.hoff...@vpnc.org wrote: Greetings. Warren and I have done a major revision on this draft, narrowing the design goals, and presenting more concrete proposals for how the mechanism would work. We welcome more feedback, and hope to discuss it in the WG in Toronto. --Paul Hoffman Begin forwarded message: From: internet-dra...@ietf.org Subject: I-D Action: draft-wkumari-dnsop-dist-root-01.txt Date: July 3, 2014 at 2:17:46 PM PDT To: i-d-annou...@ietf.org Reply-To: internet-dra...@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Securely Distributing the DNS Root Authors : Warren Kumari Paul Hoffman Filename: draft-wkumari-dnsop-dist-root-01.txt Pages : 9 Date: 2014-07-03 Abstract: This document recommends that recursive DNS resolvers get copies of the root zone, validate it using DNSSEC, populate their caches with the information, and also give negative responses from the validated zone. [[ Note: This document is largely a discussion starting point. ]] The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-wkumari-dnsop-dist-root/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-wkumari-dnsop-dist-root-01 A diff from
Re: [DNSOP] draft-wkumari-dnsop-dist-root-01.txt
Ralf Weber d...@fl1ger.de wrote: I think if we think of the resolver having another auth root server at localhost the logic is easier to understand makes much more sense as DNSSEC protections would kick in even if someone managed to inject a bad zone. I think that is too simplistic: simply slaving the root zone doesn't give you any good way to detect or recover from a corrupted zone transfer. By the time normal DNSSEC validation has detected any problems it is too late. Tony. -- f.anthony.n.finch d...@dotat.at http://dotat.at/ FitzRoy: Northerly 4 or 5, increasing 6 or 7 in south, perhaps gale 8 later in southeast. Moderate, becoming moderate or rough in south. Fair. Good. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft-wkumari-dnsop-dist-root-01.txt
On 8 Jul 2014, at 16:14, Tony Finch d...@dotat.at wrote: simply slaving the root zone doesn't give you any good way to detect or recover from a corrupted zone transfer. If that's a credible threat/risk, there are ways to mitigate it. Perhaps v2 of this draft could discuss these. FWIW in playing with DNS for 20-odd years, I've never come across an actual example of zone transfer corruption, either in the protocol or the underlying TCP transport. That doesn't mean it can't happen of course. The risks are close to zero IMO. Which doesn't necessarily mean they should be ignored. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft-wkumari-dnsop-dist-root-01.txt
Paul Hoffman paul.hoff...@vpnc.org wrote: On Jul 8, 2014, at 8:14 AM, Tony Finch d...@dotat.at wrote: I think that is too simplistic: simply slaving the root zone doesn't give you any good way to detect or recover from a corrupted zone transfer. By the time normal DNSSEC validation has detected any problems it is too late. Can you give a scenario where that second sentence is true? That is, if a validating recursive resolver retrieves the entire signed zone, validates the contents, and then puts all of the contents in the cache, how can some problem happen too late? If you do that (i.e. if you do what your draft specifies rather than what Ralf suggested) then you aren't simply slaving the zone (you are validating it too) and you aren't doing normal per-query on-demand DNSSEC validation. Tony. -- f.anthony.n.finch d...@dotat.at http://dotat.at/ Viking: Variable 4 becoming north 5 to 7. Slight becoming moderate. Fog patches then rain. Moderate or good, occasionally very poor at first. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft-wkumari-dnsop-dist-root-01.txt
are you saying that to pre-validate signed materials along a trust chain outside some immediate context (x) is inherently invalid? whats the limit on x? seconds? microseconds? don't all cacheing resolves cache common path trust checks under the TTL of the elements along the path anyway? On Wed, Jul 9, 2014 at 3:45 AM, Tony Finch d...@dotat.at wrote: Paul Hoffman paul.hoff...@vpnc.org wrote: On Jul 8, 2014, at 8:14 AM, Tony Finch d...@dotat.at wrote: I think that is too simplistic: simply slaving the root zone doesn't give you any good way to detect or recover from a corrupted zone transfer. By the time normal DNSSEC validation has detected any problems it is too late. Can you give a scenario where that second sentence is true? That is, if a validating recursive resolver retrieves the entire signed zone, validates the contents, and then puts all of the contents in the cache, how can some problem happen too late? If you do that (i.e. if you do what your draft specifies rather than what Ralf suggested) then you aren't simply slaving the zone (you are validating it too) and you aren't doing normal per-query on-demand DNSSEC validation. Tony. -- f.anthony.n.finch d...@dotat.at http://dotat.at/ Viking: Variable 4 becoming north 5 to 7. Slight becoming moderate. Fog patches then rain. Moderate or good, occasionally very poor at first. ___ 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] draft-wkumari-dnsop-dist-root-01.txt
On Jul 8, 2014, at 8:45 AM, Tony Finch d...@dotat.at wrote: Paul Hoffman paul.hoff...@vpnc.org wrote: On Jul 8, 2014, at 8:14 AM, Tony Finch d...@dotat.at wrote: I think that is too simplistic: simply slaving the root zone doesn't give you any good way to detect or recover from a corrupted zone transfer. By the time normal DNSSEC validation has detected any problems it is too late. Can you give a scenario where that second sentence is true? That is, if a validating recursive resolver retrieves the entire signed zone, validates the contents, and then puts all of the contents in the cache, how can some problem happen too late? If you do that (i.e. if you do what your draft specifies rather than what Ralf suggested) then you aren't simply slaving the zone (you are validating it too) and you aren't doing normal per-query on-demand DNSSEC validation. Just to be clear: you are saying that what we actually say to in the draft doesn't have the too late issue you refer to above, correct? --Paul Hoffman ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft-wkumari-dnsop-dist-root-01.txt
Note that I only listed a hand full of issues I immediately think of that I think needs to be compared and evaluated. Like Suzanne wrote. In some cases there is no difference between an auth server and cache, in other cases there might be. On 8 jul 2014, at 16:18, Paul Hoffman paul.hoff...@vpnc.org wrote: On Jul 7, 2014, at 10:02 PM, Patrik Fältström p...@frobbit.se wrote: - Recovery process when bad data end up in the resolver (cache v.s. auth) That's the cache has gone stale issue that David raised. It is dealt with in the current draft. There is no other way for bad data to be in the cache other than by having it come from a signed root zone that has changed. Not all data in a signed zone is signed. But I appreciate you say you feel you have been thinking about it. My point is that I really really really want to know that the unsigned info in a signed zone is NOT treated differently in an auth server than a cache. Once again, I list questions. - Routing issues (which is what I see the largest burden of a root server operator) The draft does not impose any routing issue on the root. In fact, it says that the signed root might be gotten from entities that are not root zone operators. I understand my statement was weird. Today when clients get weird responses they look where they get the response from, identify one of the 13 ip addresses and contact the root server that quite often do various monitoring and protection of the routing of that very IP address. I.e. responding to DNS queries is one thing, managing one of the key ip addresses is another. Yes, I understand that is not really an issue if the resolver is auth for the root zone. - Lack of DNSSEC validation The draft says repeatedly that the information is only entered if it is DNSSEC validated. If you can find any sentence in the draft that says differently, I'll fix it immediately. How is that policed? Yes, people can say that that already happens which of course is true. But I see a difference between recommending this and just making it possible, from the IETF. - The fact not all data in the root zone is signed That is a statement with no effect. If the data is not signed when it is retrieved from the signed root zone, it will be unsigned when retrieved using normal queries to the root zone. See above. - Political/regulative implications (to ensure a different TA is used than ICANN) That is a statement with no effect. Nothing in the draft changes the TA used to validate the root zone, so a validating recursive resolver acts identically whether it uses the mechanism or not. Not really. If you are auth, then queries by definition do not leak to a place where a different TA is needed. - Lack of legal protection of the root zone itself Please try to explain this. The root zone operators current serve the root zone signed with DNSSEC. This draft doesn't change that, so there are no new legal implications. The root server operators (at least for example the three outside of the US) have an MOU with ICANN that say we will serve the zone ICANN serves. Where is the same protection between end users in $state using $isp under $regulative_policy that the same zone is served? In this case I want $state to have for example have signed a treaty saying the root zone is not to be modified. ...and possibly more. That is not helpful. Well, I was responding to drc that wrote something in affect, and my intention was to show a subset of issues to address and look at, as a longer list that what drc listed. ...and of course a combination of these. Umm, that is not helpful either. That was to protect myself. For example, the fact not everything in the root zone is signed, ability to sign and produce a new root server with new TA with not a complete root zone in $state under some interesting $regulation. Possibly using the same (or different ip addresses) than what is used today. I hope proponents of this proposal can explain why this is different than an alternate root. Once again, this is such a large issue that I would prefer a bit better arguments than what is demonstrated here. The reason that there are not arguments in the -01 draft to deal with your issues above is that they seem unrelated to the draft. It is hard to have a section that says Someone objected that this does X, but they are wrong that has a finite length. Yes, I know you wrote in affection, but let this remind all of us that we can do better. Sure, but bringing up issues that are just as true whether or not the draft is implemented is not doing better. Having a list of issues that come from what the draft changes would be great: we can deal with those. Understood. Once again, I responded more to the mail from drc than address the draft per se. Patrik --Paul Hoffman P.S. None of the above relates to Joe's big issue, which is that implementing
Re: [DNSOP] draft-wkumari-dnsop-dist-root-01.txt
Paul Hoffman paul.hoff...@vpnc.org wrote: Just to be clear: you are saying that what we actually say to in the draft doesn't have the too late issue you refer to above, correct? Right. Tony. -- f.anthony.n.finch d...@dotat.at http://dotat.at/ Dover, Wight: Variable 4 becoming northwest 4 or 5, occasionally 6 later. Slight, becoming slight or moderate. Showers. Good. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft-wkumari-dnsop-dist-root-01.txt
George Michaelson g...@algebras.org wrote: are you saying that to pre-validate signed materials along a trust chain outside some immediate context (x) is inherently invalid? whats the limit on x? seconds? microseconds? I'm sorry I can't parse that. Tony. -- f.anthony.n.finch d...@dotat.at http://dotat.at/ Viking: Variable 4 becoming north 5 to 7. Slight becoming moderate. Fog patches then rain. Moderate or good, occasionally very poor at first. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft-wkumari-dnsop-dist-root-01.txt
Roy Arends r...@dnss.ec wrote: I would also like to see some facilitation around this as well: a notify service of new versions, a zone distribution service (xfer service), possibly out of ICANN or VeriSign. Does it need a notification service when the zone update period (every 12 hours ish) is much longer than the refresh period (30 minutes)? Tony. -- f.anthony.n.finch d...@dotat.at http://dotat.at/ Hebrides, Bailey: Variable 4, becoming southeasterly 4 or 5 later in west Bailey. Slight or moderate, becoming slight in Hebrides. Mainly fair. Good, occasionally poor. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft-wkumari-dnsop-dist-root-01.txt
On 8 Jul 2014, at 16:40, Tony Finch d...@dotat.at wrote: Jim Reid j...@rfc1035.com wrote: On 8 Jul 2014, at 16:14, Tony Finch d...@dotat.at wrote: simply slaving the root zone doesn't give you any good way to detect or recover from a corrupted zone transfer. If that's a credible threat/risk, there are ways to mitigate it. Perhaps v2 of this draft could discuss these. -01 already does: it requires the slave to validate the entire zone before putting it into service, and it requires fallback to legacy non-slave resolution. Indeed. But you seemed to be implying that those provisions were insufficient or defective. Oh well. FWIW I wonder if MUST validate is good enough when there's no mention of the One True Trust Anchor which presumably should be used for that. Would out-of-band validation (handwave!) such as rsync over SSH be OK? ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft-wkumari-dnsop-dist-root-01.txt
Hi Roy! On 8 July 2014 at 7:40:22, Roy Arends (r...@dnss.ec) wrote: I really like this idea. Many ISPs already do this, (including some high profile public recursives, like Google and OpenDNS), because it simply makes sense: It reduces latency for the end user, reduces outbound traffic overhead, eliminates an attack vector. This specific document shouldn’t be a discussion point at all. Folks are doing this right now. What we need is a BCP that describes: IFF you are going to do it, here is how. As I discussed with Warren back when he was still at the pre-typing, thinking stage on this draft, I agree with you. I think documenting the trade-offs and giving advice to people who have decided to slave the root themselves is valuable. (I proposed something like slaving-root-considered-harmful in my review last week, which with hindsight was a bit hysterical. I like the idea of writing a document that describes how, with current code and in the current operational landscape people could do this. The document under discussion specifies protocol-level changes for resolvers, however, and goes further than simply providing analysis and recommendations about how people could make sure they don't shoot themselves in the foot. Perhaps a way forward here is to reign in the current effort and constrain it to the best way of using a local copy of the root zone on a resolver today, with no protocol or specification changes to resolvers. Once we've identified the best such configuration and have identified any operational concerns with it, we will be in a much better position to consider changes to the resolver spec and/or new root zone distribution mechanisms to make it better. Joe ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft-wkumari-dnsop-dist-root-01.txt
whats the issue with the cycle time to validate whats in a blob you fetch, against fetching the elements inside that blob on demand and processing them? what do you think DNS implementors do with the DS/DNSKEY validations they perform along the FQDN each time? do you think they always throw away all acquired knowledge to the root? ps I tried google translate. it worked fine. zeg je dat te pre-valideren ondertekend materialen langs een trust chain buiten aantal onmiddellijke context (x) is inherent ongeldig? Wat is de limiet op x? seconden? microseconden? On Wed, Jul 9, 2014 at 4:03 AM, Tony Finch d...@dotat.at wrote: George Michaelson g...@algebras.org wrote: are you saying that to pre-validate signed materials along a trust chain outside some immediate context (x) is inherently invalid? whats the limit on x? seconds? microseconds? I'm sorry I can't parse that. Tony. -- f.anthony.n.finch d...@dotat.at http://dotat.at/ Viking: Variable 4 becoming north 5 to 7. Slight becoming moderate. Fog patches then rain. Moderate or good, occasionally very poor at first. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft-wkumari-dnsop-dist-root-01.txt
On Jul 8, 2014, at 9:00 AM, Patrik Fältström p...@frobbit.se wrote: Note that I only listed a hand full of issues I immediately think of that I think needs to be compared and evaluated. Like Suzanne wrote. In some cases there is no difference between an auth server and cache, in other cases there might be. Section 4 of our draft lists two very distinct possibilities for how the validating recursive resolver responds to cached information about the root: continue to act like a cache (do not set the AA bit), or as an authoritative slave (turn on the AA bit for answers for root zone info). It sounds like you are only considering the second possibility, and that you consider that risky. If so, instead of attacking the entire draft, maybe just attack that one possible choice. If others agree with you, then that second option can be removed. I simply do not see how a validating recursive resolver that pulls in the entire root zone and validates it before putting it in the cache, and then responds exactly as if it had queried each record in the root, has any of the issues you are hammering on, particularly the political ones. --Paul Hoffman ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft-wkumari-dnsop-dist-root-01.txt
Olafur Gudmundsson o...@ogud.com wrote: this document seems “bind” specific that it assumes that the recursive resolver can be both authoritative and recursive which is not a requirement. You can't implement this draft's validation and fallback requirements just by configuring BIND, so I think all name server software will need significant improvements. Tony. -- f.anthony.n.finch d...@dotat.at http://dotat.at/ FitzRoy: Northerly 4 or 5, increasing 6 or 7 in south, perhaps gale 8 later in southeast. Moderate, becoming moderate or rough in south. Fair. Good.___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft-wkumari-dnsop-dist-root-01.txt
On Jul 8, 2014, at 9:15 AM, Jim Reid j...@rfc1035.com wrote: FWIW I wonder if MUST validate is good enough when there's no mention of the One True Trust Anchor which presumably should be used for that. If a message (in this case, an RRset) is signed with a public key, the validator needs to use that exact public key to validate. There is no other option. Would out-of-band validation (handwave!) such as rsync over SSH be OK? No. That would only validate the integrity of the data, not the origin. --Paul Hoffman ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft-wkumari-dnsop-dist-root-01.txt
George Michaelson g...@algebras.org wrote: whats the issue with the cycle time to validate whats in a blob you fetch, against fetching the elements inside that blob on demand and processing them? Time is not the issue. Ralf seemed to be suggesting that lazy validation is OK, where you simply slave the root zone locally and point a normal validating resolver at it. If you do that then you don't have a sensible way to recover from a corrupt transfer, because you will only discover it is bust when you are processing a query and that's a bad time to try re-doing the transfer. Maybe it would be OK if the resolver was configured to use the real root servers as a fallback in case the local copy gets corrupted. Tony. -- f.anthony.n.finch d...@dotat.at http://dotat.at/ Cromarty, Forth: Variable 3 becoming northwest 4 or 5, occasionally 6 later. Slight, becoming slight or moderate. Thundery showers and fog patches at first. Moderate or good, occasionally very poor at first. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft-wkumari-dnsop-dist-root-01.txt
On Jul 8, 2014, at 12:33 PM, Tony Finch d...@dotat.at wrote: Olafur Gudmundsson o...@ogud.com wrote: this document seems “bind” specific that it assumes that the recursive resolver can be both authoritative and recursive which is not a requirement. You can't implement this draft's validation and fallback requirements just by configuring BIND, so I think all name server software will need significant improvements. Tony. -- f.anthony.n.finch d...@dotat.at http://dotat.at/ FitzRoy: Northerly 4 or 5, increasing 6 or 7 in south, perhaps gale 8 later in southeast. Moderate, becoming moderate or rough in south. Fair. Good. I agree with you that just configuring “Some off the shelf name server” is not enough but wether that should be built into Authoritative server or is a stand-alone tool should be left each implementation. Olafur ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft-wkumari-dnsop-dist-root-01.txt
On Jul 8, 2014, at 10:28 AM, William F. Maton Sotomayor wma...@ottix.net wrote: On Tue, 8 Jul 2014, Olafur Gudmundsson wrote: On Jul 8, 2014, at 7:40 AM, ? Roy Arends r...@dnss.ec wrote: Hiya, I really like this idea. Many ISPs already do this, (including some high profile public recursives, like Google and OpenDNS), because it simply makes sense: It reduces latency for the end user, reduces outbound traffic overhead, eliminates an attack vector. (possibly some more questions or variations for the draft to consider) How can I as a user ensure that what Google does in the name of moi, can be verified to be an untampered copy of the root zone? How do I as a user know if there's a stale copy of the root zone being slaved^H^H^H^H^H^H^H supplied by my ISP? (is not being able to reach wyle.e.coyote.acme enough to give me that hint?) How do I know if my ISP, etc. are running a local copy of the zone? Can I call RSACC to complain about an outage? (In other words, what are the mechanisms for someone to figure this out before calling the helpdesk, or, should the draft say to call if you suspect something is wrong? They'd probably do it anyways...maybe. Yes, I'm rhetorical here, DNSSEC etc for mitigation, etc.) Roy Roy you hit the nail on the head, this is a no brainer as a BCP. The contents of this draft may or may not be right at this point but we need a BCP that explains how to do this and the pitfalls to be aware off. BCP or informational (cautionary tales)? too early to tell. The former if possible, but that may need protocol work a better zone transfer mechanism, a zone consistency check built into the system (something like SIG(AXFR) from RFC2065 but better) For an DNS resolution provider that elects to there are two ways to do it, forward zone local authoritative zone. both should be allowed, this document seems ?bind? specific that it assumes that the recursive resolver can be both authoritative and recursive which is not a requirement. There is no need that every recursive resolver at a Resolution Provider have a copy of the root zone only that the resolvers know the ?local root servers?. I see mentions of 'Resolution Provider'. Is this a BCP for only them, or can anyone join the local auth zone party at their own risk/pleasure, at which point it's informational or still BCP? What is the litmus test? Litmus test, why? Root zone is not special from a serving point of view, only from fetching it and maintaining it. If I’m a Resolution Provider who can I hurt by messing up? Only my customers. In my mind this is not that far off from Anycast root servers i.e. additional server placed closer to the query generators. The big difference is in management and control. There were good intentions behind the Cymru bogon list. Every once in a while, we start to see complaints of former bogons being unreachable because they're no longer bogons. Is there a similar risk for that here and should it be identified? All risks and benefits we can think of should be documented. A guide to monitoring the service should be provided The root server operators believe (correctly) that they provide valuable service and are critical to the operation of the internet, They also believe that having close control over all root servers is essential. A number of people over the years have said that the current model is not the only possible way to provide the same service just as well, further diversification of root server services is enabled by DNSSEC. The open question is does the promotion of this type of service create any NEW attacks agains the CONTENT of the root zone, i.e. would this have made the it possible/easier for Turkey to restrict access to Google and Twitter? The technical question that needs to be answered what is the safest way to distribute the root zone and locally validate it before making it available on the ?local root servers?. In my mind the answer Notify and incremental XFR with stronger protections. I think the answer is NO thus I support the promotion of a BCP on ?locally provided root servers?. Olafur On 04 Jul 2014, at 21:50, Paul Hoffman paul.hoff...@vpnc.org wrote: Greetings. Warren and I have done a major revision on this draft, narrowing the design goals, and presenting more concrete proposals for how the mechanism would work. We welcome more feedback, and hope to discuss it in the WG in Toronto. --Paul Hoffman Begin forwarded message: From: internet-dra...@ietf.org Subject: I-D Action: draft-wkumari-dnsop-dist-root-01.txt Date: July 3, 2014 at 2:17:46 PM PDT To: i-d-annou...@ietf.org Reply-To: internet-dra...@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Securely Distributing the DNS Root Authors : Warren
Re: [DNSOP] draft-wkumari-dnsop-dist-root-01.txt
Patrik, On Jul 7, 2014, at 11:39 PM, Patrik Fältström p...@frobbit.se wrote: One could say the discussion is a typical non-constructive IETF discussion which too many are. Seems like it has been (mostly) a constructive discussion to me. Once again, this is such a large issue that I would prefer a bit better arguments than what is demonstrated here. Actually, since it is opt-in, it doesn't seem to be that large of an issue to me, but perhaps that's because I'm not a root server operator and have no particular interest in maintaining the status quo. I do not see it as opt-in. Definitely not. I see this draft be a tool that is used to force opt in to a different root zone than what ICANN is managing. A very effective tool regarding fragmenting the Internet. And having an incoming CTO of ICANN requesting fragmentation of the Internet actually worries me a bit. Because of this, I think it must proven that increased deployment of this technology will not increase fragmentation of the Internet. I'll admit I'm quite surprised and disappointed in your response here. I hope you'll forgive me if I choose not to respond to you further on this thread. 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] draft-wkumari-dnsop-dist-root-01.txt
Paul, On Jul 8, 2014, at 7:18 AM, Paul Hoffman paul.hoff...@vpnc.org wrote: None of the above relates to Joe's big issue, which is that implementing the draft doesn't help anyone much. To me, that's a much more valid (and measurable) criticism than anything on the list above. I believe section 5.1 discusses the benefits in a reasonable way, although perhaps more could be explained about the reduced latency aspects. Perhaps unsurprisingly, I might add a bit on responsiveness, i.e., having incentive to improve infrastructure or respond to problems based on the fact that direct/paying customers will scream at you if you don't. However, I suspect whether or not you believe those benefits provide sufficient help depends largely on your belief about the existing infrastructure and how that infrastructure will scale in the future. Fortunately, the draft is not demanding the existing infrastructure be dismantled so people with differing opinions can choose to implement what they believe is best. 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] draft-wkumari-dnsop-dist-root-01.txt
William, On Jul 8, 2014, at 7:28 AM, William F. Maton Sotomayor wma...@ottix.net wrote: How can I as a user ensure that what Google does in the name of moi, can be verified to be an untampered copy of the root zone? The same way you can do so now: you validate the response yourself. How do I know if my ISP, etc. are running a local copy of the zone? Assuming they don't tell you, perhaps reduced latency, particularly in non-existent TLD cases. Can I call RSACC to complain about an outage? Heh. BCP or informational (cautionary tales)? Personally, I'd prefer informational until there is more publicly discussed deployment experience. There are undoubtedly quirks, tricks, and gotchas that will come out as people discuss what they've been doing more publicly. Perhaps a second iteration would fit into BCP. I see mentions of 'Resolution Provider'. Is this a BCP for only them, or can anyone join the local auth zone party at their own risk/pleasure, at which point it's informational or still BCP? What is the litmus test? I'm not sure there can be a litmus test. What's being discussed is a technique anyone running a resolver can implement. It's not like an informational RFC or BCP on the topic would be creating a new capability. It would, as Ralf points out, be documenting an existing practice. There were good intentions behind the Cymru bogon list. Every once in a while, we start to see complaints of former bogons being unreachable because they're no longer bogons. Is there a similar risk for that here and should it be identified? Isn't this a variation of the stale data problem? In the worst case (where a resolution provider does not refresh), you can always point to a different resolution provider (or do it yourself). 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] draft-wkumari-dnsop-dist-root-01.txt
On Jul 8, 2014, at 9:17 AM, Joe Abley jab...@hopcount.ca wrote: Perhaps a way forward here is to reign in the current effort and constrain it to the best way of using a local copy of the root zone on a resolver today, with no protocol or specification changes to resolvers. Once we've identified the best such configuration and have identified any operational concerns with it, we will be in a much better position to consider changes to the resolver spec and/or new root zone distribution mechanisms to make it better. +1 Perhaps two drafts, one as Joe describes above. The second, perhaps being Experimental, discussing thoughts on resolver modifications or novel zone distribution mechanisms? 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] draft-wkumari-dnsop-dist-root-01.txt
On Jul 8, 2014, at 3:17 PM, David Conrad d...@virtualized.org wrote: On Jul 8, 2014, at 9:17 AM, Joe Abley jab...@hopcount.ca wrote: Perhaps a way forward here is to reign in the current effort and constrain it to the best way of using a local copy of the root zone on a resolver today, with no protocol or specification changes to resolvers. Once we've identified the best such configuration and have identified any operational concerns with it, we will be in a much better position to consider changes to the resolver spec and/or new root zone distribution mechanisms to make it better. +1 Perhaps two drafts, one as Joe describes above. The second, perhaps being Experimental, discussing thoughts on resolver modifications or novel zone distribution mechanisms? The AS112-like paradigm proposed in draft-lee-dnsop-scalingroot-00.txt also deserves review and comment. (I've got no opinion on this, yet, as co-chair or root server operator or anything else, beyond it should be discussed openly, with an eye on technical/operational means of making DNS resolution for internet users work/scale better.) thx, Suzanne ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft-wkumari-dnsop-dist-root-01.txt
On 8 jul 2014, at 20:30, David Conrad d...@virtualized.org wrote: On Jul 7, 2014, at 11:39 PM, Patrik Fältström p...@frobbit.se wrote: One could say the discussion is a typical non-constructive IETF discussion which too many are. Seems like it has been (mostly) a constructive discussion to me. Now yes, I completely agree! Once again, this is such a large issue that I would prefer a bit better arguments than what is demonstrated here. Actually, since it is opt-in, it doesn't seem to be that large of an issue to me, but perhaps that's because I'm not a root server operator and have no particular interest in maintaining the status quo. I do not see it as opt-in. Definitely not. I see this draft be a tool that is used to force opt in to a different root zone than what ICANN is managing. A very effective tool regarding fragmenting the Internet. And having an incoming CTO of ICANN requesting fragmentation of the Internet actually worries me a bit. Because of this, I think it must proven that increased deployment of this technology will not increase fragmentation of the Internet. I'll admit I'm quite surprised and disappointed in your response here. I hope you'll forgive me if I choose not to respond to you further on this thread. That is completely understood, and excuses are not needed, if you forgive me ;-) I was, as you saw, surprised myself over your words in the mail I responded to. Patrik signature.asc Description: Message signed with OpenPGP using GPGMail ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft-wkumari-dnsop-dist-root-01.txt
On 9/07/2014 5:17 am, David Conrad d...@virtualized.org wrote: On Jul 8, 2014, at 9:17 AM, Joe Abley jab...@hopcount.ca wrote: Perhaps a way forward here is to reign in the current effort and constrain it to the best way of using a local copy of the root zone on a resolver today, with no protocol or specification changes to resolvers. Once we've identified the best such configuration and have identified any operational concerns with it, we will be in a much better position to consider changes to the resolver spec and/or new root zone distribution mechanisms to make it better. +1 Perhaps two drafts, one as Joe describes above. The second, perhaps being Experimental, discussing thoughts on resolver modifications or novel zone distribution mechanisms? That works for me, I think there is a natural inheritance there that will certainly help scope the problem statement and the requirements of the second document, so please do A and then work on B as Joe suggests. Cheers, Terry smime.p7s Description: S/MIME cryptographic signature ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft-wkumari-dnsop-dist-root-01.txt
Hi, all, There are currently two solutions proposed to distrbute the DNS root service more widely.In my opinion, we should work on this issue following the two steps: 1) we should discuss their feasibility from technological aspects. the technological requirements of them should be gathered and listed ,and then analyzed one by one. 2) these two solutions consider the similar issue from different levels: one is the recursive-level and another one is the authorative-level. (if both of them are feasible) we should figure out respective scenarios and requirements suitable for each of them. BR, Zhiwei Yan ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft-wkumari-dnsop-dist-root-01.txt
Zhiwei, Your proposal seems reasonable. But we can not separate the recursive-level and authorative-level, as you call it by the way, since the DNS is an integrated one. If both of the two solutions are feasible, we need to figure out how and to what extent, both solutions could collaborate on root zone file distribution, not in the “respective scenarios” . Declan Ma ZDNS 在 2014年7月9日，上午11:30，yzw_iplab yzw_ip...@163.com 写道： Hi, all, There are currently two solutions proposed to distrbute the DNS root service more widely.In my opinion, we should work on this issue following the two steps: 1) we should discuss their feasibility from technological aspects. the technological requirements of them should be gathered and listed ,and then analyzed one by one. 2) these two solutions consider the similar issue from different levels: one is the recursive-level and another one is the authorative-level. (if both of them are feasible) we should figure out respective scenarios and requirements suitable for each of them. BR, Zhiwei Yan ___ 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] draft-wkumari-dnsop-dist-root-01.txt
Joe, I was in the middle of a long, extremely eloquent point-by-point rebuttal when I realized it was pointless: we're approaching the draft from completely different directions and I strongly doubt anything I might say might change your mind. However, I did want to focus on one point. To quote a bit of your message: There's no obvious operational benefit to root server operators [...] I do not believe the draft is about improving life for the root server operators. That might be a side benefit in that it would reduce the noise root server operators have to wade through, but it isn't the primary goal. I see the primary benefit being a way of addressing what I consider a fundamental flaw in the historical DNS operational architecture. Specifically, the DNS operational infrastructure is a bit like 6to4: it relies on the kindness of strangers who may or may not have any incentive to ensure the service is provided in the best possible way. This draft attempts to document a way in which organizations can choose to be the masters of their own fate when it comes to root name service instead of relying on a set of 12 (or 11, depending on your point of view) volunteers who upgrade or not, buy capacity or not, deploy IPv6 or not, deploy anycast or not, etc., based on their own internal rationales and justifications. Further, it is opt-in: if you're perfectly happy with the existing system, no one is forcing you, as a resolver operator, to slave the root zone. In my mind, this is a much more scalable, resilient, robust, and even rational (from the perspective of the operation of critical infrastructure) system that the current root service architecture. 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] draft-wkumari-dnsop-dist-root-01.txt
Hi, On Mon, Jul 07, 2014 at 12:27:36PM -0700, David Conrad wrote: This draft attempts to document a way in which organizations can choose to be the masters of their own fate when it comes to root name service instead of relying on a set of 12 (or 11, depending on your point of view) volunteers who upgrade or not, buy capacity or not, deploy IPv6 or not, deploy anycast or not, etc., based on their own internal rationales and justifications. Further, it is opt-in: if you're perfectly happy with the existing system, no one is forcing you, as a resolver operator, to slave the root zone. In my mind, this is a much more scalable, resilient, robust, and even rational (from the perspective of the operation of critical infrastructure) system that the current root service architecture. Perhaps. I haven't myself made up my mind about this draft, partly because I think the situation is somewhat more complicated than you suggest above. It's true that the draft sort of allows an operator to be master of its own fate. But it does require -- and indeed, the coherence (however loose) of the DNS requires -- that one fall back to asking a real root server in the event one isn't up to date. Now, the problem is that the root server operations are organized according to the work needed. That is, many of the server operators seem to do a pretty good job of ensuring capacity for their actual loads. If the proposals in this draft are widely adopted, that will by definition change the profile of the traffic the root servers see, and that will mean that such potential traffic will not be considered in the planning by root server operators. This may not be a fatal flaw (probably it isn't), but it does worry me a little. Best regards, A -- Andrew Sullivan a...@anvilwalrusden.com ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft-wkumari-dnsop-dist-root-01.txt
Paul, On Jul 6, 2014, at 9:14 PM, Paul Vixie p...@redbarn.org wrote: there are far more errors encountered below .com or .de than by their siblings in the root. any argument in favour of wide scale slaving of the root zone begs the question, why not every tld and every pseudo-tld (such as no-ip.org)? the root isn't special in regards to a goal of preventing junk queries. The operators of the authorities for .com and .de and others have a natural incentive to augment their systems to deal with issues such as errors or DDoS or whatever. As we have seen multiple times in the past, most individual root operators simply do not have this incentive. that's why query minimization is the preferred solution to this problem. This isn't either/or. right now, root name servers are part of an explicit, hand-maintained NOTIFY tree. thus, all internet actions depending on root zone content have up-to-the-minute data if not up-to-the-second data in many cases. we should treat this as an invariant, I'm a bit (ok, a lot) skeptical of this claim, particularly given arguments made by some root server operators during the ICANN root scaling discussions about having instances at the end of long, thin, and fragile pipes and thus the size of the root zone must be limited. However, ignoring that, one key point of slaving the root is that folks who do slave the root are accepting the responsibility to keep it up to date. Failure to do so only impacts their own customer base. This is a self-correcting problem -- get too stale and your (presumably paying) customer scream at you (cue Vijay Gill's talk on the cost of customer calls in relation to the profit that customer will bring over their lifetime of being a customer). As a customer, you can also always choose to run your own resolver (which is, of course, the right answer for other reasons). 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] draft-wkumari-dnsop-dist-root-01.txt
Andrew, On Jul 7, 2014, at 12:44 PM, Andrew Sullivan a...@anvilwalrusden.com wrote: It's true that the draft sort of allows an operator to be master of its own fate. But it does require -- and indeed, the coherence (however loose) of the DNS requires -- that one fall back to asking a real root server in the event one isn't up to date. If you're defining a real root server to include the zone delivery servers, I'd agree, however I feel the zone delivery servers have sufficiently different performance requirements as to put them in a different class than the name servers that respond to non-XFR queries. Now, the problem is that the root server operations are organized according to the work needed.[...] If the proposals in this draft are widely adopted, that will by definition change the profile of the traffic the root servers see, and that will mean that such potential traffic will not be considered in the planning by root server operators. This may not be a fatal flaw (probably it isn't), but it does worry me a little. Joe has already indicated that the normal query flow is essentially inconsequential in relation to capacity planning for the root server operators since they have to build based on DDoS/flash crowd loads, not on steady state. 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] draft-wkumari-dnsop-dist-root-01.txt
David Conrad wrote: Paul, ... that's why query minimization is the preferred solution to this problem. This isn't either/or. are you proposing to solve problem A (junk queries at the root) and problem B (junk queries at tld's and pseudo-tld's) using different mechanisms? why is the cost of a second mechanism worth paying, if a single mechanism would solve both problems? granted, we can solve any given problem in any number of ways including one, or more than one. but what's our incentive to pay more than we have to? ... one key point of slaving the root is that folks who do slave the root are accepting the responsibility to keep it up to date. Failure to do so only impacts their own customer base. This is a self-correcting problem -- get too stale and your (presumably paying) customer scream at you ... my experience has been that when dns doesn't work the call reporting this can go just about anywhere. if i could be sure that the first call from most users would go to the actual person who had the power to fix whatever caused the call, i'd certainly make that a primary design assumption. put it the other way. as a domain holder, i'd like the system recommended by IETF whereby my delegation data is distributed to be as error-unlikely as possible. if you give me a vote, wearing my domain holder hat, i will pick please tell the small number of people who want to run root anycast nodes to do so rather than please tell the large number of RDNS operators to slave the root. this is me wanting, selfishly, uptime and a low number of dependencies and state-permutations. but i consider myself to be representative of other domain holders in this regard, so it could be worth paying attention to my selfish desires this time. vixie ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft-wkumari-dnsop-dist-root-01.txt
On Jul 7, 2014, at 4:36 PM, Paul Vixie p...@redbarn.org wrote: that's why query minimization is the preferred solution to this problem. This isn't either/or. are you proposing to solve problem A (junk queries at the root) and problem B (junk queries at tld's and pseudo-tld's) using different mechanisms? why is the cost of a second mechanism worth paying, if a single mechanism would solve both problems? Query minimization and slaving the root focus on solving different problems. For example, query minimization does nothing to reduce systemic vulnerability to DoS. Both should probably be done. put it the other way. as a domain holder, i'd like the system recommended by IETF whereby my delegation data is distributed to be as error-unlikely as possible. As a user of the Internet, I'd like the system recommended by the IETF to scale in the face of ISPs being unable to address DoS in any effective way. The root of the DNS, concentrated in the hands of 24 (still not 26, sigh) IP addresses, is and always has been non-scalable -- we just didn't have a zillion botnet zombies rubbing our noses in it. Worse the existing system relies on the goodwill and potentially unbounded donation of resources from folks who aren't paid to provide the service. When you, I, and the Internet were younger, this (arguably) made sense but the Internet has changed (not to mention you and I). Slaving the root means the folks who are getting paid to provide domain resolution service to their customers are no longer dependent on the kindness of strangers, the single point of failure represented by the real-time query response requirement of root servers can be avoided, latency is reduced for queries for non-existant names, and information leakage can be minimized. The main argument against slaving the root I've seen appears to me to be FUD: people running resolvers are too stupid to configure slaving the root correctly so root data will go stale! (paraphrased). I've no doubt some folks will get it wrong, however again, this is a self-correcting problem that impacts a fraction of the Internet at large. If nothing else, repeated failure of a resolver operator to fix their slave configuration will result either in migration to folks who can get it right or people running their own resolvers. Seems like a win to me. 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] draft-wkumari-dnsop-dist-root-01.txt
On 8 jul 2014, at 02:55, David Conrad d...@virtualized.org wrote: The main argument against slaving the root I've seen appears to me to be FUD: people running resolvers are too stupid to configure slaving the root correctly so root data will go stale! (paraphrased). I am a bit disappointed that you David do summarize the arguments against this proposal in this way. Several various weaknesses of the proposal have been explained at several occasions (although of course also them with a bit of hand waving), and they are definitely not fud and definitely not limited to people making mistakes. What I have recommended Warren to do is to properly list the arguments, make a proper analysis (an attack tree would be one good start) because my largest fear is that the various issues that might look like weaknesses of the proposal must be analyzed, and that they are not. I have at least heard: - Recovery process when bad data end up in the resolver (cache v.s. auth) - Routing issues (which is what I see the largest burden of a root server operator) - Lack of DNSSEC validation - The fact not all data in the root zone is signed - Political/regulative implications (to ensure a different TA is used than ICANN) - Lack of legal protection of the root zone itself ...and possibly more. ...and of course a combination of these. Once again, this is such a large issue that I would prefer a bit better arguments than what is demonstrated here. Yes, I know you wrote in affection, but let this remind all of us that we can do better. Ok? Patrik signature.asc Description: Message signed with OpenPGP using GPGMail ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft-wkumari-dnsop-dist-root-01.txt
Moin! On 05 Jul 2014, at 18:11, Joe Abley jab...@hopcount.ca wrote: TL;DR: there are way more cons than pros to this proposal. The pros listed are weak; the cons listed are serious. I don't see a net advantage to the DNS (or to perceived performance of the DNS for any client) here. This proposal, if implemented, would represent non-trivial additional complexity with minimal or no benefit. I am not in favour of it, if that's not obvious. As noted previously, I am not against documenting and discussing the merits of slaving the root zone on resolvers (in some fashion). My preference would be for a draft called something like draft-ietf-dnsop-slaving-root-on-resolvers-harmful, which could borrow much of your section 5.1 and 5.2 to make its argument. Oh like draft-ietf-dnsop-reflectors-are-evil that became RFC5358, but still hasn't stopped Google and others offering open resolving service to the internet. Granted there are a lot of open DNS proxies out there that should be taken down, but I assume there are some companies offering resolving services that are valuable to Internet users. I remain very much *not* in favour of making changes to the DNS specification that don't have a clear benefit to balance their costs. I think there is a difference between the precise specification and what you can do with your DNS software. While it may not be within the spec you can setup an auth server today that slaves the root zone and use a stub on your resolver to point to that root zone. That's how I run my setup at home because I don't want to my queries to be part of the DITL collection and I know that others do that because they have very bad connectivity to the root servers and in general. I think if we think of the resolver having another auth root server at localhost the logic is easier to understand makes much more sense as DNSSEC protections would kick in even if someone managed to inject a bad zone. The draft doesn't require every resolver to slave the zone, but merly is an information that this is a possible way to do it and I assume that large resolver operators would benefit from it and the CPEs you mention that even haven't implemented EDNS0 wouldn't matter anyway. It in the end of course comes down to do we want to document what is out there anyway or do we want to hide our heads in the sand. Especially for an operational group I would prefer the former. So long -Ralf ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft-wkumari-dnsop-dist-root-01.txt
In message etpan.53b82396.4353d0cd.3...@walrus.hopcount.ca, Joe Abley writes : Hi Paul, Warren, On 4 July 2014 at 16:50:08, Paul Hoffman (paul.hoff...@vpnc.org) wrote: Greetings. Warren and I have done a major revision on this draft, narrowing the design goals, and presenting more concrete proposals for how the mechanism would work. We welcome more feedback, and hope to discuss it in the WG in Toronto. I think there is much in the language of this draft that could be tightened up, but this is an idea for discussion so I'll avoid a pedantic line-by-line dissection. But I can give you the full pedantry if you like :-) On the pros and cons, however (crudely pasted below), see below. TL;DR: there are way more cons than pros to this proposal. The pros listed are weak; the cons listed are serious. I don't see a net advantage to the DNS (or to perceived performance of the DNS for any client) here. This proposal, if implemented, would represent non-trivial additional complexity with minimal or no benefit. I am not in favour of it, if that's not obvious. As noted previously, I am not against documenting and discussing the merits of slaving the root zone on resolvers (in some fashion). My preference would be for a draft called something like draft-ietf-dnsop-slaving-root-on-resolvers-harmful, which could borrow much of your section 5.1 and 5.2 to make its argument. I remain very much *not* in favour of making changes to the DNS specification that don't have a clear benefit to balance their costs. --- 5.1. Pros o Junk queries / negative caching - Currently, a significant number of queries to the root servers are junk queries. Many of these queries are TLDs that do not (and may never) exist in the root Another significant source of junk is queries where the negative TLD answer did not get cached because the queries are for second- level domains (a negative cache entry for foo.example will not cover a subsequent query for bar.example). I think a better way to accommodate the second point is to implement qname minimisation in recursive server logic. When you can get rid of all the servers in the world which followed RFC 2535 which return NXDOMAIN for empty non terminal qname minimisation and this sort of logic will be viable though it won't do anywhere as near as good a job as having a local copy of the root zone. I don't know that the first point is much of a pro. Root server operators need to provision significant spare capacity in order to accommodate flash crowds and attack traffic, and compared to that spare capacity the volume of junk queries is extremely small. There's no obvious operational benefit to root server operators in reducing their steady-state query load (in fact, it would make it harder in some cases to obtain the exchange point capacity you need to accommodate flash crowds, on exchanges where higher-capacity ports are reserved for those that have demonstrable need based on steady-state traffic.) But there is big benefit to cache operators. The bigger the client base the bigger the benefit. I'm also a little concerned about the word junk. It's a pejorative term that implies assumptions about the intent of the original query. If my intent is to confirm that a top-level label doesn't exist, then BLAH/IN/SOA is a perfectly reasonable query for me to send to a root server. We might assume that a query Joe's iPhone/IN/SOA sent to a root server is not reasonable, but we're only assuming; we don't actually have a way of gauging the actual intent with any accuracy. o DoS against the root service - By distributing the contents of the root to many recursive resolvers, the DoS protection for customers of the root servers is significantly increased. A DDoS may still be able to take down some recursive servers, but there is much more root service infrastructure to attack in order to be effective. Of course, there is still a zone distribution system that could be attacked (but it would need to be kept down for a much longer time to cause significant damage, and so far the root has stood up just fine to DDoS. If I was to paraphrase this advantage with malicious intent :-), you mean that we don't have to rely upon the root server system to continue to perform under attack, because we don't need the root server system any more, although we do need the new bits of the root server system we are specifying, and if those bits are not available we do need the conventional root server system after all, but that's probably ok because the root server system is pretty resilient. That sounds a bit circular. o Small increase to privacy of requests - This also removes a place where attackers could collect information. Although query name minimization also achieves some of this, it does still leak the TLDs that people behind a
Re: [DNSOP] draft-wkumari-dnsop-dist-root-01.txt
In message 53ba1e98.9030...@redbarn.org, Paul Vixie writes: i am not joe, but i strongly +1'd his response on this thread, so i'm putting my oar back into the water now. Mark Andrews wrote: In message etpan.53b82396.4353d0cd.3...@walrus.hopcount.ca, Joe Abley wri tes: 5.1. Pros o Junk queries / negative caching - Currently, a significant number of queries to the root servers are junk queries. Many of these queries are TLDs that do not (and may never) exist in the root Another significant source of junk is queries where the negative TLD answer did not get cached because the queries are for second- level domains (a negative cache entry for foo.example will not cover a subsequent query for bar.example). I think a better way to accommodate the second point is to implement qname minimisation in recursive server logic. When you can get rid of all the servers in the world which followed RFC 2535 which return NXDOMAIN for empty non terminal qname minimisation and this sort of logic will be viable query minimization is very much worth having for its own sake. RFC 2535 style authorities were never numerous. we can cope. Even with query minimization you will still gets lots of junk queries to the roots. though it won't do anywhere as near as good a job as having a local copy of the root zone. there are far more errors encountered below .com or .de than by their siblings in the root. any argument in favour of wide scale slaving of the root zone begs the question, why not every tld and every pseudo-tld (such as no-ip.org)? the root isn't special in regards to a goal of preventing junk queries. that's why query minimization is the preferred solution to this problem. The root scales at present. ... There's an implication here that a recursive resolver sending a query to a root server is potentially impinging upon the privacy of its anonymous clients. I find that a bit difficult to swallow. Given the intelligence that root server operators have glenned in the past there is a degree of credability here. if it were possible to put in place agreements between the root name server operators and the internet community, one of the things i'd ask for is a no data mining rule. that is, i would want to be sure that verisign's security business was in no way commercially advantaged by its exclusive access to the a/j root query stream (or the .com query stream). alas, that's the third rail of internet politics, and i have no wish to place a moist body part up against it. to your actual point, query minimization is the solution to data leaks into root, and tld, and pseudo-tld authorities. slaving the root zone only solves this problem for the root name server operators, who are nowhere near our full problem statement with regard to long-qname surveillance. query minimization only addresses part of the issue, usually that of having .corp in a search list (or similar) when not talking to a recursive server with a .corp configured. It does not address the issue of stub resolvers appending . to single labels when searching. A new root zone is published usually two (but sometimes more) times per day. The semantics specified in the draft for refreshing a local copy of the root zone say keep re-using the copy you have until it expires. If I assume that expire means survives beyond SOA.EXPIRE seconds of when we originally fetched it, then there's the potential for stale data to be published for a week plus however old the originally-retrieved file was (which is difficult to determine, in contrast to the traditional root zone distribution scheme). I think this disadvantage is more serious than is presented. Slaves perform refresh queries every 30 minutes (refresh = 1800). Oops actually clear up faster with slaves than without as many of the responses are now direct to stub rather than cached responses which have much higher TTLs. If one was really worried one could keep a log of the last 24 hours of zone tranfers and issue a NOTIFY to all of the sources that transfered the zone. Normal refresh logic would then kick in for a large percentage of slaves. This is permitted by the RFC's. Machines are actually good at doing this sort of thing. This is actually a pro not a con. right now, root name servers are part of an explicit, hand-maintained NOTIFY tree. thus, all internet actions depending on root zone content have up-to-the-minute data if not up-to-the-second data in many cases. we should treat this as an invariant, which means any IETF recommendation for root zone slave service should include an explicit NOTIFY tree, though i doubt it can be either hand maintained as the current one is nor remember everybody who has fetched it and NOTIFY all of them as you suggest. (since many RDNS servers are behind firewalls or NAT or both, it's fair to say that most
Re: [DNSOP] draft-wkumari-dnsop-dist-root-01.txt
Hi Paul, No oars - just a bit of a broken paddle. On 7/07/2014 2:14 pm, Paul Vixie p...@redbarn.org wrote: right now, root name servers are part of an explicit, hand-maintained NOTIFY tree. thus, all internet actions depending on root zone content have up-to-the-minute data if not up-to-the-second data in many cases. we should treat this as an invariant, which means any IETF recommendation for root zone slave service should include an explicit NOTIFY tree, though i doubt it can be either hand maintained as the current one is nor remember everybody who has fetched it and NOTIFY all of them as you suggest. (since many RDNS servers are behind firewalls or NAT or both, it's fair to say that most could never hear a NOTIFY.) Terry thinking aloud: it might be palatable to have a automated registration process where a 'root zone enabled resolver' registers with a 'zone distribution service' and issue a keep-alive, such that the ZDS might be able to issue a notify (of sorts) to the resolver.. But getting ahead of myself, the underlying issue of zone freshness (as I've mentioned before) is my break-point. And the environment we have now simply doesn't help that, inclusive of NAT effects. thus my preference for the root server anycast proposal first described in 2005 at https://ss.vix.su/~vixie/alternate-rootism.pdf https://ss.vix.su/~vixie/alternate-rootism.pdf (btw this needs to be http, https asks for auth!) and then described again this year for the ICANN ITI panel report (see section 9.4) at https://www.icann.org/en/system/files/files/report-21feb14-en.pdf https://www.icann.org/en/system/files/files/report-21feb14-en.pdf and then described again this week for the IETF DNSOP wg at https://tools.ietf.org/id/draft-lee-dnsop-scalingroot-00.txt https://tools.ietf.org/id/draft-lee-dnsop-scalingroot-00.txt I'm not going to make statements of the above on technical feasibility, but I am more than concerned about: (sec 3.) The proposed architecture is strongly based on the widely deployed DNSSEC. .. not that is based on DNSSEC, the premise of 'widely', and that serves as a unilateral go signal. I would suggest that timing might well be the impeding factor here. I still see some 6-10K queries/per sec (diurnal pattern) on L-root without the DO bit set. That isn't insignificant as L is only 1 of the 13. So while 'widely deployed' could be argued (23K-31K qps with DO bit) I think 'near pervasive' is the buy-in point. I might well be with you if the omission of the DO bit was at similar or lower levels as the v6 query rate - 2k qps, non-dirurnal. ;) Or maybe the new service addressees in scalingroot-00 MUST only answer to DNSSEC queries..but that is a stretch IMHO. Cheers Terry smime.p7s Description: S/MIME cryptographic signature ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft-wkumari-dnsop-dist-root-01.txt
Hi Paul, Warren, On 4 July 2014 at 16:50:08, Paul Hoffman (paul.hoff...@vpnc.org) wrote: Greetings. Warren and I have done a major revision on this draft, narrowing the design goals, and presenting more concrete proposals for how the mechanism would work. We welcome more feedback, and hope to discuss it in the WG in Toronto. I think there is much in the language of this draft that could be tightened up, but this is an idea for discussion so I'll avoid a pedantic line-by-line dissection. But I can give you the full pedantry if you like :-) On the pros and cons, however (crudely pasted below), see below. TL;DR: there are way more cons than pros to this proposal. The pros listed are weak; the cons listed are serious. I don't see a net advantage to the DNS (or to perceived performance of the DNS for any client) here. This proposal, if implemented, would represent non-trivial additional complexity with minimal or no benefit. I am not in favour of it, if that's not obvious. As noted previously, I am not against documenting and discussing the merits of slaving the root zone on resolvers (in some fashion). My preference would be for a draft called something like draft-ietf-dnsop-slaving-root-on-resolvers-harmful, which could borrow much of your section 5.1 and 5.2 to make its argument. I remain very much *not* in favour of making changes to the DNS specification that don't have a clear benefit to balance their costs. --- 5.1. Pros o Junk queries / negative caching - Currently, a significant number of queries to the root servers are junk queries. Many of these queries are TLDs that do not (and may never) exist in the root Another significant source of junk is queries where the negative TLD answer did not get cached because the queries are for second- level domains (a negative cache entry for foo.example will not cover a subsequent query for bar.example). I think a better way to accommodate the second point is to implement qname minimisation in recursive server logic. I don't know that the first point is much of a pro. Root server operators need to provision significant spare capacity in order to accommodate flash crowds and attack traffic, and compared to that spare capacity the volume of junk queries is extremely small. There's no obvious operational benefit to root server operators in reducing their steady-state query load (in fact, it would make it harder in some cases to obtain the exchange point capacity you need to accommodate flash crowds, on exchanges where higher-capacity ports are reserved for those that have demonstrable need based on steady-state traffic.) I'm also a little concerned about the word junk. It's a pejorative term that implies assumptions about the intent of the original query. If my intent is to confirm that a top-level label doesn't exist, then BLAH/IN/SOA is a perfectly reasonable query for me to send to a root server. We might assume that a query Joe's iPhone/IN/SOA sent to a root server is not reasonable, but we're only assuming; we don't actually have a way of gauging the actual intent with any accuracy. o DoS against the root service - By distributing the contents of the root to many recursive resolvers, the DoS protection for customers of the root servers is significantly increased. A DDoS may still be able to take down some recursive servers, but there is much more root service infrastructure to attack in order to be effective. Of course, there is still a zone distribution system that could be attacked (but it would need to be kept down for a much longer time to cause significant damage, and so far the root has stood up just fine to DDoS. If I was to paraphrase this advantage with malicious intent :-), you mean that we don't have to rely upon the root server system to continue to perform under attack, because we don't need the root server system any more, although we do need the new bits of the root server system we are specifying, and if those bits are not available we do need the conventional root server system after all, but that's probably ok because the root server system is pretty resilient. That sounds a bit circular. o Small increase to privacy of requests - This also removes a place where attackers could collect information. Although query name minimization also achieves some of this, it does still leak the TLDs that people behind a resolver are querying for, which may in itself be a concern (for example someone in a homophobic country who is querying for a name in .gay). There's an implication here that a recursive resolver sending a query to a root server is potentially impinging upon the privacy of its anonymous clients. I find that a bit difficult to swallow. I'm surprised not to see improves performance for clients in this list, on the general principle that every cache miss
Re: [DNSOP] draft-wkumari-dnsop-dist-root-01.txt
Joe Abley wrote: Hi Paul, Warren, On 4 July 2014 at 16:50:08, Paul Hoffman (paul.hoff...@vpnc.org) wrote: Greetings. Warren and I have done a major revision on this draft, narrowing the design goals, and presenting more concrete proposals for how the mechanism would work. We welcome more feedback, and hope to discuss it in the WG in Toronto. I think there is much in the language of this draft that could be tightened up, but this is an idea for discussion so I'll avoid a pedantic line-by-line dissection. But I can give you the full pedantry if you like :-) On the pros and cons, however (crudely pasted below), see below. TL;DR: there are way more cons than pros to this proposal. The pros listed are weak; the cons listed are serious. I don't see a net advantage to the DNS (or to perceived performance of the DNS for any client) here. This proposal, if implemented, would represent non-trivial additional complexity with minimal or no benefit. I am not in favour of it, if that's not obvious. ... i am +1 to joe's comments above and analysis elided. i consider joe's response to be at least as good as the because i owe DRC after my first short answer to the -00 version of this draft. however, i want to add two other countervailing points. first, this approach was tried in freebsd, when doug barton (then freebsd's BIND9 maintainer) made it the default. all hell broke loose due to changes in firewall config. debugging cost was maximized, and the debugging skills were minimized. this config was removed with prejudice. this experience, where freebsd users are actually among the smartest of all dns users, should serve as a warning sign to others: abandon hope all ye who enter here. so, joe's recommendation that this draft be retitled and rekerned to be draft-ietf-dnsop-slaving-root-on-resolvers-harmful resonates very strongly with me. second, this approach asks millions or tens of millions of rdns servers to change their config in order to actually scale the capacity of the root. (so, high cost and low benefit, as joe said.) the reason i proposed a radically different solution in my ICANN ITI contribution (now described at http://tools.ietf.org/html/draft-lee-dnsop-scalingroot-00) is to allow a few dozen to a few hundred self selected highly skilled and motivated network-level admins to scale the capacity of the root for everyone. it's a plain hierarchical solution allowing the operators of any loopback network on any host, or any LAN segment, or any campus, corporate, or ISP network to add root name service as a local capability; it also allows unlimited scale at the global BGP layer. it is patterned after the success of AS112. it is apolitical since existing rootops are also expected to participate. vixie ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] draft-wkumari-dnsop-dist-root-01.txt
Greetings. Warren and I have done a major revision on this draft, narrowing the design goals, and presenting more concrete proposals for how the mechanism would work. We welcome more feedback, and hope to discuss it in the WG in Toronto. --Paul Hoffman Begin forwarded message: From: internet-dra...@ietf.org Subject: I-D Action: draft-wkumari-dnsop-dist-root-01.txt Date: July 3, 2014 at 2:17:46 PM PDT To: i-d-annou...@ietf.org Reply-To: internet-dra...@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Securely Distributing the DNS Root Authors : Warren Kumari Paul Hoffman Filename: draft-wkumari-dnsop-dist-root-01.txt Pages : 9 Date: 2014-07-03 Abstract: This document recommends that recursive DNS resolvers get copies of the root zone, validate it using DNSSEC, populate their caches with the information, and also give negative responses from the validated zone. [[ Note: This document is largely a discussion starting point. ]] The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-wkumari-dnsop-dist-root/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-wkumari-dnsop-dist-root-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-wkumari-dnsop-dist-root-01 ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
