Re: [dns-operations] Implementation of negative trust anchors?
On 22.08.13 22:59, wbr...@e1b.org wrote: From: Doug Barton do...@dougbarton.us As stated before, the problem is that after the early adopter period is over we'll be stuck with NTAs forever. This is one of those fundamental disagreements between those who believe that DNS should always be forgiving of operator error, and those of us who do not. Running the DNS for 100+ school districts and 400,000+ devices, I really, REALLY don't want to be the one saying Sorry, you can't use the site called for in your lesson plan today because they messed up the DNSSEC records. Management's response would be Just make it work! Without a per domain NTA, the only option would be to turn off DNSSEC, returning to square one. If turning off DNSSEC is your way to Just make it work! then it is perfectly legitimate thing to do. You could do it in a limited scale for that specific lesson today and turn in on afterwards. As already mentioned, local policy always rules (as do local laws). DNSSEC is merely a technology to aid you in authenticating data and determine if it was modified in transit. Nothing more nothing less. It also provides an chain of trust, that is matching the DNS delegation chain of trust -- thus being better than traditional PKI with relation to web site certificates. DNSSEC is not some magical technology that just solves the problems. On this, I am with Doug, that if there is a high price for doing it wrong less people will do it wrong. Daniel ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] Implementation of negative trust anchors?
On 23.08.13 00:37, Joe Abley wrote: Last thing, we have NTAs today. People use them. Local policy always prevails. Even over common sense. We observe this in the real world, where local laws are always in force and in some places the local laws might not make sense to us, or even irritate our sense of 'laws'. Yet, those exist. Won't go away. Therefore, it is perfectly ok for someone to implement NTAs or other methods to ignore what DNSSEC provides. As with any other manual intervention, these are prone to error. One day, when more people are dependent on DANE and it stops working, those same oper types will start talking the opposite story... On the other hand, if we let too much ifs exist, such as but what if someone has applied NTAs to this domain, somewhare?, then application designers will be even less motivated to make use of DNSSEC. Daniel ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] Implementation of negative trust anchors?
On 23.08.13 03:07, Vernon Schryver wrote: From: Suzanne Woolf wo...@isc.org I don't like it either, but it limits the damage done by a DNSSEC = failure to status quo ante rather than something worse. That is mistaken. You get the status quo ante by simply turning off validation. It seems, discussions like this are the result of half-way implementing DNSSEC so far. Thing is, today we mostly make use of DNSSEC validation at the 'large' caching resolver sites. Those are services, that serve lots of people and if someone has any problem, they do call. It is all too easy to point at DNSSEC and demand it ignored. When/If we get to a more full DNSSEC deployment, where the validation happens on each individual end node, then each individual end user can make their own choice whether to validate or not, there won't be need for any such bypassing technologies at the service level and nobody's phone will ring for problems they did not create. But in order to arrive at this level of deployment, we need to convince application developers that DNSSEC is already stable target. Inventing more and more knobs does not signal exactly that. Of course, it will help having validating local resolvers in most major platforms :) Daniel ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] Implementation of negative trust anchors?
On Aug 22, 2013, at 3:19 PM, Paul Hoffman paul.hoff...@vpnc.org wrote: On Aug 22, 2013, at 2:47 PM, David Conrad d...@virtualized.org wrote: A resolver operator deploying an NTA is making an assertion that data behind a name is safe despite protocol indications that is may not be. Where is that stated? I ask, because it would seem that a better description would be that they are asserting that the data behind a name is unprotected by DNSSSEC. Apologies for using shorthand. The term 'safe' in my comment meant that it was what was intended by the zone editor. Regards, -drc signature.asc Description: Message signed with OpenPGP using GPGMail ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] Implementation of negative trust anchors?
On Aug 22, 2013, at 3:25 PM, Paul Vixie p...@redbarn.org wrote: A resolver operator deploying an NTA is making an assertion that data behind a name is safe despite protocol indications that is may not be. Where is that stated? I ask, because it would seem that a better description would be that they are asserting that the data behind a name is unprotected by DNSSSEC. agreed, and that's why, over and above the absurd engineering economics behind it, i don't like NTA. if my signatures don't work because i've been attacked (for example, one of my name servers has been compromised), the last thing i'd want is comcast telling their customers that the data they're getting from my compromised name server is ok to consume because it's unsigned. Exactly so. However pragmatically speaking if someone (say NASA perhaps?) screws up signing their zone, it isn't the zone-signing-screwer-upper that gets the phone calls, it is the eyeball networks that are doing the validation. Without NTA, the eyeball network operators have a choice, eat the cost of those calls or turn off validation _for ALL signed zones until the zone-signing-screwer-upper fixes their problem_. I gather you believe eating the cost is the right answer. madness test: would we have bothered with DNSSEC at all, back in the day, if NTA had been known as a definite requirement? Sure. Regards, -drc signature.asc Description: Message signed with OpenPGP using GPGMail ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] Implementation of negative trust anchors?
On Aug 22, 2013, at 5:13 PM, Paul Vixie p...@redbarn.org wrote: Randy Bush wrote: from a conversation with a friend wiser than i the problem is that we are going through a deployment phase where there is little penalty for sloppy server ops because so few are validating. patching over this to be more tolerant of sloppy server ops is going in the wrong direction. ... +1. we're currently debating placement of first mover advantage. today if you sign incorrectly you lose. with NTA at scale, if you sign incorrectly you won't lose. Sure you will. You screw up signing and you instantly lose. NTA allows other folks to not lose with you if they decide the pain of your screwing up to them is sufficiently high to justify manual intervention. Not everyone will make the same value judgement and they all won't make it at the same time. Regards, -drc signature.asc Description: Message signed with OpenPGP using GPGMail ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] Implementation of negative trust anchors?
On Aug 23, 2013, at 11:04 AM, Carlos M. Martinez carlosm3...@gmail.com wrote: I'm _very_ torn on the issue. On one hand I fully agree with Patrik in the sense that documenting such practices could lead to widespread 'holes' in validation. However, in my opinion the first knee jerk reaction of a recursive resolver operator will probably be 'if 1M clients of mine are unable to access kittenvideos.com due to a DNSSEC screewup, I will just disable it'. Maybe such operators, if presented with the possibility of having NTAs may chose to use that. Again, I'm torn. I'm not sure what will work better in the real world, or produce the best outcomes in the long term. All depends on if you actually want DNSSEC to be deployed or not. If something like NTA (or some other way to override obvious DNSSEC screwups) didn't exist, do you *really* think that Comcast and 8.8.8.8 would be doing DNSSEC validation? Do you remember the fallout from the NASA screwup? Simply telling your customers Yes, I know that it worked fine from $competitor, but we do things better here, and so you cannot see fluffy kitten chasing ball of yarn. It's for your own good, and it also teaches fkittenvideos.com to not suck so much… doesn't cut it. W regards ~Carlos On 8/23/13 11:58 AM, David Conrad wrote: On Aug 22, 2013, at 5:13 PM, Paul Vixie p...@redbarn.org wrote: Randy Bush wrote: from a conversation with a friend wiser than i the problem is that we are going through a deployment phase where there is little penalty for sloppy server ops because so few are validating. patching over this to be more tolerant of sloppy server ops is going in the wrong direction. ... +1. we're currently debating placement of first mover advantage. today if you sign incorrectly you lose. with NTA at scale, if you sign incorrectly you won't lose. Sure you will. You screw up signing and you instantly lose. NTA allows other folks to not lose with you if they decide the pain of your screwing up to them is sufficiently high to justify manual intervention. Not everyone will make the same value judgement and they all won't make it at the same time. Regards, -drc ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs -- Outside of a dog, a book is your best friend, and inside of a dog, it's too dark to read ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] Implementation of negative trust anchors?
From: David Conrad d...@virtualized.org Exactly so. However pragmatically speaking if someone (say NASA = perhaps?) screws up signing their zone, it isn't the = zone-signing-screwer-upper that gets the phone calls, it is the eyeball = networks that are doing the validation. Without NTA, the eyeball = network operators have a choice, eat the cost of those calls or turn off = validation _for ALL signed zones until the zone-signing-screwer-upper = fixes their problem_. I gather you believe eating the cost is the right answer. =20 YES! Eyeball networks are paid by their customers to act as pre-front-line support for bad DNS delegations, broken HTTP servers, and all other content provider problems. Saying otherwise for any of the services sold by eyeball networks is another step down the slope toward content providers paying eyeball networks for eyeballs and the conversion of the Internet into what it was in about 1965 when it was owned by Ma Bell and the three television networks. Of course, it wasn't called the Internet, but it was the contemporary equivalent. I was around for the Carterphone decision and the incredible freedom to connect computers that followed soon after (in about 15 years--remember DAAs?). I was also around to see the ARPANET use 56kbps leased lines that were not only incredibly slow but required incredible massaging of Ma Bell bureaucrats who required you to admit who was in really charge of your business. (I was at TIP-25 at DOCB) } From: David Conrad d...@virtualized.org } Vernon, } If the only solution to someone else screwing up signing is to turn off = } validation for all zones and the likelihood of someone screwing up = } signing scales with the number of folks signing, why bother ever turning = } validation on? Eyeball networks would be best served by turning off DNSSEC. Comcast not withstanding, DNSSEC does nothing to help their bottom lines. Let's be honest and admit that talk about NTA today and tommorow (as opposed to last year) is really a statement of regret about DNSSEC and a demand that DNSSEC just go away. If you honestly believe in DNSSEC's promise of letting me sign my zones, then you must also let me mess them up. Essentially none who will use NTA will have any inkling whether bad signatures on my zones reflect my incompetence or actions of my (and or their) enemies. Many of us here now can and are happy to make good guesses about whether a DNSSEC failure is due to zone operator error or enemy action, but that won't be true of most future NTA users, including big outfits. I read the thinness of http://dns.comcast.net/ as saying that Comcast, that major NTA supporter, has not only given up trying to diagnose other people's DNSSEC problems but quietly shelved NTA. } On the contrary, NTA is a new tool for deliberately introducing new } faults in the data you give your DNS clients. } True. This is why I suspect corporate types will have hesitancy to use = } NTAs and wish to remove them as soon as possible. On the contrary, given minimal cover such as an RFC, corporate types at eyeball networks will mandate add-only NTA lists that only grow and never lose entries. They'll say politically correct things about DNSSEC but use NTA to minimize support costs and maximize profits from activies that are incompatible with DNSSEC such as typosquatting. Vernon Schryverv...@rhyolite.com ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] Implementation of negative trust anchors?
David Conrad wrote: On Aug 22, 2013, at 3:25 PM, Paul Vixie p...@redbarn.org wrote: ... over and above the absurd engineering economics behind it, i don't like NTA. if my signatures don't work because i've been attacked (for example, one of my name servers has been compromised), the last thing i'd want is comcast telling their customers that the data they're getting from my compromised name server is ok to consume because it's unsigned. Exactly so. However pragmatically speaking if someone (say NASA perhaps?) screws up signing their zone, it isn't the zone-signing-screwer-upper that gets the phone calls, it is the eyeball networks that are doing the validation. Without NTA, the eyeball network operators have a choice, eat the cost of those calls or turn off validation _for ALL signed zones until the zone-signing-screwer-upper fixes their problem_. I gather you believe eating the cost is the right answer. ... indirectly, yes. with RPZ, we made it possible for full service resolver operators (recursive name server operators) to edit zone content as a matter of local policy. NTA is not different in principle, but it's different in an important way: in RPZ, the content being edited is malicious and/or criminal. where my mind isn't bending well at the moment is where we edit in resolvers content belonging to people who aren't malicious. since we can't know the reason why their signatures are failing, telling our full service resolver and its downstream stubs that there are no signatures is overreach. if nasa.gov had screwed up its delegation or had allowed its public secondary servers to expire the zone due to primary unreachability, i do not think the phone at comcast would have rung less, but i also don't think that comcast would have fixed nasa's error in local policy. we're only talking about this because DNSSEC is new. vixie ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
[dns-operations] Call for Participation -- ICANN DNSSEC Workshop 20 November 2013
Call for Participation -- ICANN DNSSEC Workshop 20 November 2013 The DNSSEC Deployment Initiative and the Internet Society Deploy360 Programme, in cooperation with the ICANN Security and Stability Advisory Committee (SSAC), is planning a DNSSEC Workshop at the ICANN meeting in Buenos Aires, Argentina on 20 November 2013. The DNSSEC Workshop has been a part of ICANN meetings for several years and has provided a forum for both experienced and new people to meet, present and discuss current and future DNSSEC deployments. For reference, the most recent session was held at the ICANN meeting in Durban, South Africa on 17 July 2013. The presentations and transcripts are available at: http://durban47.icann.org/node/39749. We are seeking presentations on the following topics: 1. DNSSEC Activities in Latin America: For this panel we are seeking participation from those who have been involved in DNSSEC deployment in Latin America, but also from those who have not deployed DNSSEC but who have a keen interest in the challenges and benefits of deployment. In particular, we will consider the following questions: What can DNSSEC do for you? What doesn't it do? What are the internal tradeoffs to implement DNSSEC or not? 2. The Operational Realities of Running DNSSEC Now that DNSSEC has become an operational norm for many registries, registrars, and ISPs, what have we learned about how we manage DNSSEC? What's best practice around key rollovers? How often do you review your disaster recovery procedures? Is there operational familiarity within your customer support teams? What operational statistics have we gathered about DNSSEC? Are there experiences being documented in the form of best practices, or something similar, for transfer of signed zones? 3. DNSSEC and Enterprise Activities DNSSEC has always been seen as a huge benefit to organizations looking to protect their identity and security on the Web. Large enterprises are an obvious target for DNS hackers and DNSSEC provides an ideal solution to this challenge. This session aims to look at the benefits and challenges of deploying DNSSEC for major enterprises. Topics for discussion: * What is the current status of DNSSEC deployment among enterprises? * What plans do the major enterprises have for their DNSSEC roadmaps? * What are the benefits to enterprises of rolling out DNSSEC validation? And how do they do so? * What are the challenges to deployment for these organizations? Do they foresee raising awareness of DNSSEC with their customers? 4. When Unexpected DNSSEC Events Occur What have we learned from some of the operational outages that we have seen over the past 18 months? Are there lessons that we can pass on to those just about to implement DNSSEC? How do you manage dissemination of information about the outage? What have you learned about communications planning? Do you have a route to ISPs and registrars? How do you liaise with your CERT community? 5. Preparing for Root Key Rollover For this topic we are seeking input on issues relating to root key rollover. In particular, we are seeking comments from vendors, ISPs, and the community that will be affected by distribution of new root keys. 6. DANE and Other DNSSEC Applications The DNS-based Authentication of Named Entitites (DANE) protocol is an exciting development where DNSSEC can be used to provide a strong additional trust layer for traditional SSL/TLS certificates. There is strong interest for DANE usage within web transactions as well as for securing email and Voice-over-IP (VoIP). We are seeking presentations on topics such as: * What are some of the new and innovative uses of DANE in new areas or industries? * What tools and services are now available that can support DANE usage? * How soon could DANE become a deployable reality? * How can the industry used DANE as a mechanism for creating a more secure Internet? 7. DNSSEC Automation: For DNSSEC to reach massive deployment levels it is clear that a higher level of automation is required than is currently available. Topics for which we would like to see presentations include: * What tools, systems and services are available to help automate DNSSEC key management? * Can you provide an analysis of current tools/services and identify gaps? * Where in the various pieces that make up DNSSEC signing and validation are the best opportunities for automation? * What are the costs and benefits of different approaches to automation? 8. Guidance for Registrars in Supporting DNSSEC: The 2013 Registrar Accreditation Agreement (RAA) for Registrars and Resellers requires the support of DNSSEC beginning on January 1, 2014. We are seeking presentations discussing: * What are the specific technical requirements of the RAA and how can registrars meet those requirements? * What tools and systems are available for registrars that include DNSSEC support? * What information do registrars need to provide to resellers and ultimately customers? We are
Re: [dns-operations] Implementation of negative trust anchors?
On Aug 23, 2013, at 12:19 PM, Paul Vixie p...@redbarn.org wrote: David Conrad wrote: On Aug 22, 2013, at 3:25 PM, Paul Vixie p...@redbarn.org wrote: ... over and above the absurd engineering economics behind it, i don't like NTA. if my signatures don't work because i've been attacked (for example, one of my name servers has been compromised), the last thing i'd want is comcast telling their customers that the data they're getting from my compromised name server is ok to consume because it's unsigned. Exactly so. However pragmatically speaking if someone (say NASA perhaps?) screws up signing their zone, it isn't the zone-signing-screwer-upper that gets the phone calls, it is the eyeball networks that are doing the validation. Without NTA, the eyeball network operators have a choice, eat the cost of those calls or turn off validation _for ALL signed zones until the zone-signing-screwer-upper fixes their problem_. I gather you believe eating the cost is the right answer. ... indirectly, yes. with RPZ, we made it possible for full service resolver operators (recursive name server operators) to edit zone content as a matter of local policy. NTA is not different in principle, but it's different in an important way: in RPZ, the content being edited is malicious and/or criminal. where my mind isn't bending well at the moment is where we edit in resolvers content belonging to people who aren't malicious. since we can't know the reason why their signatures are failing, telling our full service resolver and its downstream stubs that there are no signatures is overreach. if nasa.gov had screwed up its delegation or had allowed its public secondary servers to expire the zone due to primary unreachability, i do not think the phone at comcast would have rung less, but i also don't think that comcast would have fixed nasa's error in local policy. Sure, true. The untenable position for Comcast is having it not work for them, while still working for everyone else. In the scenario you described it would break for everyone, and you avoid the but it works at Verizon, I'm moving to them issue. we're only talking about this because DNSSEC is new. Yup. And those trying to do the right thing (enabling validation for clients) should get the carrot, not the stick. Explaining to bean counters that you are going to enable something that might drive customers to $competitor is hard, especially if a: the customers are not asking for it, b: your competitors don't offer it and c: handwaving is needed to explain the benefits. Much respect to Jason and the rest of the Comcast folk to being one of the first major NA ISPs to turn it on. W vixie ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs -- What our ancestors would really be thinking, if they were alive today, is: Why is it so dark in here? -- (Terry Pratchett, Pyramids) ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] Implementation of negative trust anchors?
On 23.08.13 18:12, Warren Kumari wrote: On Aug 23, 2013, at 11:04 AM, Carlos M. Martinez carlosm3...@gmail.com wrote: I'm _very_ torn on the issue. On one hand I fully agree with Patrik in the sense that documenting such practices could lead to widespread 'holes' in validation. However, in my opinion the first knee jerk reaction of a recursive resolver operator will probably be 'if 1M clients of mine are unable to access kittenvideos.com due to a DNSSEC screewup, I will just disable it'. Maybe such operators, if presented with the possibility of having NTAs may chose to use that. Again, I'm torn. I'm not sure what will work better in the real world, or produce the best outcomes in the long term. All depends on if you actually want DNSSEC to be deployed or not. If something like NTA (or some other way to override obvious DNSSEC screwups) didn't exist, do you *really* think that Comcast and 8.8.8.8 would be doing DNSSEC validation? Do you remember the fallout from the NASA screwup? Nobody has ever questioned that there is need for local policy overrides. Everyone's needs are served differently. Then, maintaining NTAs incurs high manual costs. Not everybody will agree to bear that costs. Most ISP's DNS operations are just as clueless/careless as those breaking their DNS setups. NTAs are not solutions for these, because they won't bother with it either. The obvious question is, do we want to codify this in BCP or even worse standards document? Daniel ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] Implementation of negative trust anchors?
Moin! On 23.08.2013, at 09:19, Paul Vixie p...@redbarn.org wrote: if nasa.gov had screwed up its delegation or had allowed its public secondary servers to expire the zone due to primary unreachability, i do not think the phone at comcast would have rung less, but i also don't think that comcast would have fixed nasa's error in local policy. we're only talking about this because DNSSEC is new. There is huge difference between DNS outages caused by connectivity and DNSSEC caused outages. Without DNSSEC screwing up your domain so badly that it is unreachable is very very hard. With DNSSEC you make one small error and your domain goes dark for those who validate. Given that the cost of this is not on the domain owner, but instead on the service providers that validate. I think it is absolutely needed to give them a tool to minimize these costs (NTA). So long -Ralf --- Ralf Weber Senior Infrastructure Architect Nominum Inc. o: +49 6446 4392053 m: +49 151 22659325 u: +1 650 817 5895 ralf.we...@nominum.com ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] Implementation of negative trust anchors?
On Aug 22, 2013, at 3:59 PM, wbr...@e1b.org wrote: Running the DNS for 100+ school districts and 400,000+ devices, I really, REALLY don't want to be the one saying Sorry, you can't use the site called for in your lesson plan today because they messed up the DNSSEC records. Management's response would be Just make it work! Without a per domain NTA, the only option would be to turn off DNSSEC, returning to square one. I wanted to point out this is a semi-false premise. If you were dependent on the resources, you would be pulling circuits or hosting those sites in-house. I see this argument made about availability in an absolute sense and one can't control the entire ecosystem. OpenDNS didn't just start charging enterprises because they could, they did it as a result of people realizing they were dependent on resources where they had no contractual relationship or SLA. - Jared ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] Implementation of negative trust anchors?
Ralf Weber wrote: There is huge difference between DNS outages caused by connectivity and DNSSEC caused outages. Without DNSSEC screwing up your domain so badly that it is unreachable is very very hard. With DNSSEC you make one small error and your domain goes dark for those who validate. Given that the cost of this is not on the domain owner, but instead on the service providers that validate. I think it is absolutely needed to give them a tool to minimize these costs (NTA). as i've already said, NTA as a local policy is by definition OK with everybody. that's why we call it a local policy. but it's steeped in irony. the only reason NTA can be seen as a responsible practice in the eyes of those who practice it is, the domain owner who screwed up their signatures, will still get plenty of phone calls, because NTA by definition won't have a wide spread impact. i think the fact that nominum put NTA support into CNS for comcast shows good business sense. as a nominum shareholder i applaud. any other DNS supplier who wants to compete with nominum for comcast's business will have this hill to climb first. kewl. on the other hand i would not be glad to see NTA as an IETF RFC, FYI, BCP, or other standards-like artifact. vixie ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] Implementation of negative trust anchors?
On 23.08.13 19:57, Ralf Weber wrote: Moin! On 23.08.2013, at 09:19, Paul Vixie p...@redbarn.org wrote: if nasa.gov had screwed up its delegation or had allowed its public secondary servers to expire the zone due to primary unreachability, i do not think the phone at comcast would have rung less, but i also don't think that comcast would have fixed nasa's error in local policy. we're only talking about this because DNSSEC is new. There is huge difference between DNS outages caused by connectivity and DNSSEC caused outages. Without DNSSEC screwing up your domain so badly that it is unreachable is very very hard. With DNSSEC you make one small error and your domain goes dark for those who validate. Given that the cost of this is not on the domain owner, but instead on the service providers that validate. I think it is absolutely needed to give them a tool to minimize these costs (NTA). Paul is correct. Everyone blames DNSSEC, because it is new. When you learn DNSSEC procedures and master them, you will discover it is not easy to screw up DNSSEC either. Once upon a time people were afraid to fly. Today they happily line up at airport gates. What is absolutely needed is to move the validation to the stub resolver and remove it from the caching resolver that is operated by a service provider. Any service provider will attempt to cut costs, at any price. No need to put the burden of validating DNSSEC on the resolver, as they don't have any use of this -- when stubs validate, cache corruption is not even a problem. Daniel ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] Implementation of negative trust anchors?
Moin! On 23.08.2013, at 09:02, Vernon Schryver v...@rhyolite.com wrote: YES! Eyeball networks are paid by their customers to act as pre-front-line support for bad DNS delegations, broken HTTP servers, and all other content provider problems. I have no words for this. I spend most of my professional career at ISPs/Telcos that provided access services. I never thought that our business was tech support for the rest of the Internet. Access providers are paid less and less over the last decades and yet provided faster services and are struggling with earning money on customers. On a previous job a controller said if we had one call from a subscriber in a month we would loose money. And you are suggesting these people to do DNSSEC tech support for all those who can't sign their zones? Speechless. So long -Ralf --- Ralf Weber Senior Infrastructure Architect Nominum Inc. 2000 Seaport Blvd. Suite 400 Redwood City, California 94063 ralf.we...@nominum.com ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] Implementation of negative trust anchors?
On Fri, Aug 23, 2013 at 04:02:47PM +, Vernon Schryver wrote: On the contrary, given minimal cover such as an RFC, corporate types at eyeball networks will mandate add-only NTA lists that only grow and never lose entries. Obviously that's possible, but IIRC the draft requires that NTA entries have limited (and short) lifetimes. If we decide to implement this in BIND (it's on our roadmap, but with a question mark), I expect the NTA lifetime will default to an hour and be capped at a day. NTAs would be inserted via the control channel (rndc) rather than a configuration file change, and wouldn't persist across system restarts. An operator could write a script to continually insert the same NTA's over and over again forever, but it would be easier to allow them to lapse as intended. I was against NTAs when they were first proposed; I've come around. Disabling validation because of signing failures is the wrong thing to do, but people are going to do the wrong thing whether I like it or not, and if we must choose between evils, I prefer rndc validation off nasa.gov to rndc validation off. -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] Implementation of negative trust anchors?
Moin! On 23.08.2013, at 10:05, Daniel Kalchev dan...@digsys.bg wrote: Paul is correct. Everyone blames DNSSEC, because it is new. It's not blaming. We are currently and over the past years have seen a lot of incidents where people made errors that resulted in DNSSEC validation failures. When you learn DNSSEC procedures and master them, you will discover it is not easy to screw up DNSSEC either. I think that is the wrong approach for most people and widespread deployment. We need to create better tools that hide the complexity from the average user and make it easier and less error prone for people to deploy DNSSEC. I see a lot going on in that area and have hope that this will create more widespread deployment. Once upon a time people were afraid to fly. Today they happily line up at airport gates. Yeah and here automation also helps a lot... SO long -Ralf --- Ralf Weber Senior Infrastructure Architect Nominum Inc. 2000 Seaport Blvd. Suite 400 Redwood City, California 94063 ralf.we...@nominum.com ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] Implementation of negative trust anchors?
From: Joe Abley jab...@hopcount.ca When there is sufficient validation in the world that the support costs of signing errors shift from validator operators to zone publishers, it seems reasonable to predict that any words on NTAs will become useless naturally, on their own. That seems far more likely than the outcome where validator operators continue to deploy NTAs (at their own cost) for no reason. I don't think and resolver operator will ever be adding NTA willy-nilly. But when there is good reason (see past example re: lesson plans) such a tool is helpful. As sites improve their signing procedures, they will be needed less and less. Once DNSSEC becomes nearly universal, browsers will start to warn of unsigned DNS data. And people that care will start to look for their browser to indicate DNSSEC validity, just as they look for the SSL indicators now when going to sites they expect to be secured. This is already available via plug-ins for some browsers. Confidentiality Notice: This electronic message and any attachments may contain confidential or privileged information, and is intended only for the individual or entity identified above as the addressee. If you are not the addressee (or the employee or agent responsible to deliver it to the addressee), or if this message has been addressed to you in error, you are hereby notified that you may not copy, forward, disclose or use any part of this message or any attachments. Please notify the sender immediately by return e-mail or telephone and delete this message from your system. ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] Implementation of negative trust anchors?
Hello, On 8/23/13 2:03 PM, Paul Vixie wrote: on the other hand i would not be glad to see NTA as an IETF RFC, FYI, BCP, or other standards-like artifact. A long time ago a group of people said the same about NAT and now, a few years on many of them regret it, while us who were not present there are still suffering the consequences. IMO, documenting it doesn't imply endorsement. In fact, the document gives us the opportunity to actually write down why such a practice may not in fact be a good idea, and gives guidance to do it in a predictable way for *someone who really, really wants to do it anyways*. An Informational RFC would fit this purpose nicely. Cheers! ~Carlos ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] Implementation of negative trust anchors?
From: Evan Hunt e...@isc.org On the contrary, given minimal cover such as an RFC, corporate types at eyeball networks will mandate add-only NTA lists that only grow and never lose entries. Obviously that's possible, but IIRC the draft requires that NTA entries have limited (and short) lifetimes. HAH! If RFCs were Law, then the DNSSEC RFCs would have long since answered any question about NTA as ABSOLUTE NEVER! In the real world, RFCs are no more or less than hints on what to do to minimize complaints and sanctified excuses for doing what you want to do anyway. If we decide to implement this in BIND (it's on our roadmap, but with a question mark), I expect the NTA lifetime will default to an hour and be capped at a day. NTAs would be inserted via the control channel (rndc) rather than a configuration file change, and wouldn't persist across system restarts. An operator could write a script to continually insert the same NTA's over and over again forever, but it would be easier to allow them to lapse as intended. I agree that's not nearly as evil as NTAs in a configuration file, or a cron script that runs every 30 minutes and does a few 100K `rndc nta` commands to fix that problem that someone reported year before last in the .gov signatures, and protect the advertising revenue from those typosquatted domains. I was against NTAs when they were first proposed; I've come around. Disabling validation because of signing failures is the wrong thing to do, but people are going to do the wrong thing whether I like it or not, and if we must choose between evils, I prefer rndc validation off nasa.gov to rndc validation off. On the contrary, in the real world this year, the people using `rndc nta` will decide after the 42th time in 48 hours of renewing the protection for the .gov problem (not counting the 6 renewals that should have been done between 01:00 and 03:00 when the people empowered to use `rndc nta` were asleep) to either `echo rndc nta nasa nta-cron-script` or `rndc validation off`. Next year, those empowered peole will be tired of diagnosing DNSSEC problems and arguing with their bosses about value of DNSSEC. They'll give second-line support a button to push that does `echo rndc nta $1 nta-cron-script`. Vernon Schryverv...@rhyolite.com ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] Implementation of negative trust anchors?
On Fri, Aug 23, 2013 at 01:27:32PM -0400, wbr...@e1b.org wrote: Once DNSSEC becomes nearly universal, browsers will start to warn of unsigned DNS data. And people that care will start to look for their browser to indicate DNSSEC validity, just as they look for the SSL indicators now when going to sites they expect to be secured. This is already available via plug-ins for some browsers. Once the browser vendors will have a clue/give a shit about DNSSEC, I bet they will add a shiny little button let me in which will repeat the query with the CD bit set, just like they did with TLS certificate validation exceptions. Or worse, they will set up a centralized database of pseudo-NTA like they have built the safebrowsing blacklist. NTA is a way to turn off DNSSEC for a single domain instead of having to go completely insecure, like some did a few days ago during the gov algorihm rollover screw up (BTW shutting DNSSEC validation down to have at least their own domain working was not the best thing to do: temporarily adding their own KSK to the list of trust anchors was the way to go (as the most specific key is prefered by all implementations i know of (despite the stupidity that is written here : http://tools.ietf.org/html/rfc6840#appendix-C ))) ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] Implementation of negative trust anchors?
From: Evan Hunt e...@isc.org it or not, and if we must choose between evils, I prefer rndc validation off nasa.gov to rndc validation off. ... } A document that advised limits on the use of NTAs -- for example, the } recommendation in Jason's draft that they not persist for more than } a day -- would be okay by me. On second thought, Consider the situations of resolver operators confronted with a situation where you might use `rndc nta`. Almost all of them will (and even now most) lack the expertise, time, inclination to figure out which domain to hit with `rnd nta sub.dom.example.com`. They'll only know (or hope) that the irate phone calls from principals about broken lesson plans are related to DNSSEC problems. They would be better served by `rndc validation off X hours` with a limit on the X hours of 24 than any sort of NTA hook. If you don't let them to use `rndc validation off X hours`, most will use `rndc nta gov` because their users will be shouting about governement web site problems and they won't have the time, inclination, or permission to discover that it's only the apod.nasa.gov. Vernon Schryverv...@rhyolite.com ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] Implementation of negative trust anchors?
From: Vernon Schryver v...@rhyolite.com and protect the advertising revenue from those typosquatted domains. Why would a typosquatted domain fail DNSSEC? When DNSSEC is universal and easy to do, it will be signed from the TLD on down, just like every other domain. Confidentiality Notice: This electronic message and any attachments may contain confidential or privileged information, and is intended only for the individual or entity identified above as the addressee. If you are not the addressee (or the employee or agent responsible to deliver it to the addressee), or if this message has been addressed to you in error, you are hereby notified that you may not copy, forward, disclose or use any part of this message or any attachments. Please notify the sender immediately by return e-mail or telephone and delete this message from your system. ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] Implementation of negative trust anchors?
On Aug 23, 2013, at 9:02 AM, Vernon Schryver v...@rhyolite.com wrote: Eyeball networks would be best served by turning off DNSSEC. I believe this is what they're trying to avoid. Let's be honest and admit that talk about NTA today and tommorow (as opposed to last year) is really a statement of regret about DNSSEC and a demand that DNSSEC just go away. If this were the case, it is much easier to just put dnssec-validation no; in configurations and let others get the arrows in the back. } On the contrary, NTA is a new tool for deliberately introducing new } faults in the data you give your DNS clients. } True. This is why I suspect corporate types will have hesitancy to use = } NTAs and wish to remove them as soon as possible. On the contrary, given minimal cover such as an RFC, RFCs provide no cover. If a validator operator sets an NTA and their customers are compromised by an attack that would have otherwise been prevented by DNSSEC, I strongly suspect the validator operator will have set themselves up for an interesting set of meetings with their customers' lawyers. Regards, -drc signature.asc Description: Message signed with OpenPGP using GPGMail ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] Implementation of negative trust anchors?
On Aug 23, 2013, at 9:19 AM, Paul Vixie p...@redbarn.org wrote: if nasa.gov had screwed up its delegation or had allowed its public secondary servers to expire the zone due to primary unreachability, i do not think the phone at comcast would have rung less, but i also don't think that comcast would have fixed nasa's error in local policy. That's because every resolver operator would have been affected, not just Comcast, so the screams that Comcast (alone) was censoring NASA for conspiracy theory du jour) would have been trivially dismissed. If you want a reminder of the stupidity Comcast (alone AFAIK) experienced, see http://nasawatch.com/archives/2012/01/comcast-blocks.html we're only talking about this because DNSSEC is new. Of course. NTA is a mechanism that allows folks who want to do the right thing to do so without incurring costs that folks who aren't interested in doing the right thing won't incur. As more folks start validating, the playing field levels out and the need for NTA decreases. Regards, -drc signature.asc Description: Message signed with OpenPGP using GPGMail ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] Implementation of negative trust anchors?
From: wbr...@e1b.org and protect the advertising revenue from those typosquatted domains. Why would a typosquatted domain fail DNSSEC? When DNSSEC is universal and easy to do, it will be signed from the TLD on down, just like every other domain. I wasn't talking about the typosquatters who give the registrar and registry their cuts. I meant the typosquatters who (at first) replace only NXDOMAINs (and later decide that what's good for the legitimate typosquatters is good for them). I assume we all remember the NXDOMAIN typeosquatting kerfuffles. Are any (potential) eyeball networks (in hotels for example) squatting on NXDOMAINs today? Vernon Schryverv...@rhyolite.com ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] Implementation of negative trust anchors?
Vernon, On Aug 23, 2013, at 11:10 AM, Vernon Schryver v...@rhyolite.com wrote: They would be better served by `rndc validation off X hours` with a limit on the X hours of 24 than any sort of NTA hook. So, because one zone messes up signing, instead of opening up that one zone to spoofing attack you think it is better the resolver operator opens up all zones to spoofing attack? This seems wrong to me. If you don't let them to use `rndc validation off X hours`, most will use `rndc nta gov` because their users will be shouting about governement web site problems and they won't have the time, inclination, or permission to discover that it's only the apod.nasa.gov. I'd suggest that in the BCP/RFC/whatever, in addition to recommending that NTAs be time capped and not written to permanent storage, it should also recommend NTAs be written as specifically as possible. (Should be obvious, but doesn't hurt to reiterate I suppose). Regards, -drc signature.asc Description: Message signed with OpenPGP using GPGMail ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] Implementation of negative trust anchors?
From: Vernon Schryver v...@rhyolite.com If you don't let them to use `rndc validation off X hours`, most will use `rndc nta gov` because their users will be shouting about governement web site problems and they won't have the time, inclination, or permission to discover that it's only the apod.nasa.gov. Which is worse, turning off all validation for 24 hours or turning off validation for just .gov for 24 hours? Ideally, it is best to turn off validation for as narrowly focused a zone as possible for as short a time as possible. 'rndc nta apod.nasa.gov X hours' How long does it take to go to DNSVIS or the like to find where the break is? Time and permission to discover are minimized. Inclination cannot be controlled for, but those who know about 'rndc nta ___' will hopefully be aware of the tools to test before implementing. Confidentiality Notice: This electronic message and any attachments may contain confidential or privileged information, and is intended only for the individual or entity identified above as the addressee. If you are not the addressee (or the employee or agent responsible to deliver it to the addressee), or if this message has been addressed to you in error, you are hereby notified that you may not copy, forward, disclose or use any part of this message or any attachments. Please notify the sender immediately by return e-mail or telephone and delete this message from your system. ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] Implementation of negative trust anchors?
From: David Conrad d...@virtualized.org They would be better served by `rndc validation off X hours` with=20 a limit on the X hours of 24 than any sort of NTA hook. So, because one zone messes up signing, instead of opening up that one = zone to spoofing attack you think it is better the resolver operator = opens up all zones to spoofing attack? This seems wrong to me. It's wrong only if you accept the false choice between validation off and a targeted NTA. We're talking about *resolver* server operators, not authority operators or IETF participants. Big resolver server operators not selling resolution will not bother figuring things out. They'll ignore complaints, send users chasing whois phone numbers, or turn off DNSSEC. They don't have time or permission to diagnose other people's DNSSEC problems enough to use NTA correctly. See the Comcast web page for proof of that. The resolver servers selling resolutions will use NTA correctly, but they already have NTA and don't care about opinions from peanut galleries including the IETF. The majority of resolver server operators will not use NTA more than a half a dozen times. Then they'll treat DNSSEC errors like bad delegations or use one form or another of validation off including NTA as close to the root as they can go. The best bet to keep them from a static validation off is an automatically sunsetting form. I'd suggest that in the BCP/RFC/whatever, in addition to recommending = that NTAs be time capped and not written to permanent storage, it should = also recommend NTAs be written as specifically as possible. Yes, that transient NTA a good idea I'd not heard/noticed/understood until today, but it does not redeem NTA. I can't believe you're seriously suggesting that words in any IETF document telling people to use narrow NTAs would have any effect on resolver operators. Practically no one who might use any NTA hook will understand or (be allowed to) care enough to figure out to hit cnn.co.uk instead of cnn.com. Of necessity they'll just keep hitting the NTA button with semi-random domains until the calls stop. The wise ones will go straight as high as they can, functionally to validation off. Vernon Schryverv...@rhyolite.com ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] Implementation of negative trust anchors?
The best bet to keep them from a static validation off is an automatically sunsetting form. rndc nta . (as I envision it) would be functionally equivalent to an automatically sunsetting validation off. I can't believe you're seriously suggesting that words in any IETF document telling people to use narrow NTAs would have any effect on resolver operators. Of course not, but it could affect the choices made by DNS implementors. (I expect to pay attention to Jason's draft if and when I implement this feature.) -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] Implementation of negative trust anchors?
On 2013-08-23, at 15:14, Vernon Schryver v...@rhyolite.com wrote: I can't believe you're seriously suggesting that words in any IETF document telling people to use narrow NTAs would have any effect on resolver operators. Personally, my hope is that such words would provide guidance to software vendors, to constrain resolver operators with sensible mechanisms that solve specific problems narrowly. Experience shared by Comcast and Google suggests that NTAs are necessary for validation on a large scale. However, Comcast and Google are engaged and have the resources to do the right thing; small resolver operators are generally not engaged and have fewer resources available to deal with support-loading (churn-enhancing, profit-harming) problems whose origins are elsewhere. They are far more likely to be guided by (a) the hooks available in their software and (b) the kind of rumour mill that came up with block ICMP for security reasons. Reasoned guidance from the IETF at best would improve (a) and decrease the incidence of (b). At worst, it would do no harm. Joe ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] Implementation of negative trust anchors?
On 22 Aug 2013 at 15:59, wbr...@e1b.org wrote: Running the DNS for 100+ school districts and 400,000+ devices, I really, REALLY don't want to be the one saying Sorry, you can't use the site called for in your lesson plan today because they messed up the DNSSEC records. Management's response would be Just make it work! Without a per domain NTA, the only option would be to turn off DNSSEC, returning to square one. I'm the engineer responsible for DNS in an organization with something on the order of a thousand sites, over 100K employees, and I'm not even going to estimate the number of devices. We've been DNSSEC validating all query responses from the Internet for two years now and we routinely tell employees that if a domain is DNSSEC signed and has messed up its zone, they won't be able to resolve it (no web access and no email to it) until the problem is fixed on the authoritative end. The only time I've sought and received emergency approval to disable DNSSEC validation was during the recent snafu Verisign made with .gov. Fortunately I saw it and was able to react before things started failing on our own network. I understand why it's necessary for early adopter ISPs. Their customers won't understand why they can't resolve something, but other ISPs can. We saw with Comcast and the nasa.gov failure a while back. Once a number of major ISPs have enabled validation, though, it should no longer be necessary. It should never be necessary for an enterprise or government network. If you've made the organizational decision to implement DNSSEC validation, then it's rightly an all or nothing approach. A validate some things and not others approach is largely useless. Our browsers give us the option to trust invalid TLS certificates, some even storing it indefinitely. Is an NTA much different? Yes, and we all see how well that's worked out from a security perspective... Scott ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] Implementation of negative trust anchors?
On 22 Aug 2013 at 14:37, Joe Abley wrote: If we accept that logic, then the pertinent questions is whether or not NTAs should be standardised (in a protocol or operational sense). I think the answer is yes. So do others. Some don't see value in it, but that's fine; nobody is *requiring* anybody to implement anything. If they are made a part of the standard, then the various DNS implementations will be expected (reasonably) to implement them. And they then become a standard operational tool, making DNSSEC little better than the current certificate process. If recursive, caching nameserver operators have to roll their own implementation to achieve the goal, it keeps NTAs contained. Sure, some people will go to that trouble, but unless they have a well-defined reason to do so, most won't. Scott ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] Implementation of negative trust anchors?
In message 52179660.7000...@digsys.bg, Daniel Kalchev writes: On 23.08.13 19:57, Ralf Weber wrote: Moin! On 23.08.2013, at 09:19, Paul Vixie p...@redbarn.org wrote: if nasa.gov had screwed up its delegation or had allowed its public second ary servers to expire the zone due to primary unreachability, i do not think the phone at comcast would have rung less, but i also don't think that comcas t would have fixed nasa's error in local policy. we're only talking about thi s because DNSSEC is new. There is huge difference between DNS outages caused by connectivity and DNS SEC caused outages. Without DNSSEC screwing up your domain so badly that it i s unreachable is very very hard. With DNSSEC you make one small error and you r domain goes dark for those who validate. Given that the cost of this is not on the domain owner, but instead on the service providers that validate. I t hink it is absolutely needed to give them a tool to minimize these costs (NTA ). Paul is correct. Everyone blames DNSSEC, because it is new. When you learn DNSSEC procedures and master them, you will discover it is not easy to screw up DNSSEC either. Once upon a time people were afraid to fly. Today they happily line up at airport gates. What is absolutely needed is to move the validation to the stub resolver and remove it from the caching resolver that is operated by a service provider. Any service provider will attempt to cut costs, at any price. No need to put the burden of validating DNSSEC on the resolver, as they don't have any use of this -- when stubs validate, cache corruption is not even a problem. No. Validation needs to be in *both* the resolver and the stub. Anyone who says otherwise really does not understand DNSSEC. A validating stub resolver cannot work reliably in the face of a deliberate attack unless the recursive server is also validating. Can we please stop propogating this myth that rescursive servers don't need to validate when stubs do. Mark Daniel ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] Implementation of negative trust anchors?
David Conrad (drc) writes: I'd suggest that in the BCP/RFC/whatever, in addition to recommending that NTAs be time capped and not written to permanent storage, it should also recommend NTAs be written as specifically as possible. (Should be obvious, but doesn't hurt to reiterate I suppose). What's wrong with provide unvalidated results for this zone until it validates ? I mean, we're now talking about automation, scripts to reinsert NTAs, etc. Then we might as well implement the logic to continually test validation for SOA or some other specified record for the given zone, and reenable validation. So instead of calling it NTA call it validation policy - the DNSSEC equivalent of IPSEC's required vs. use policy setting. Yes, we all know how succesful opportunistic encryption was. Yes, some are going to scream, but much better than nailing down an NTA ad vitam, or tracking TTLs, or which DS is active, or... ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] Implementation of negative trust anchors?
On 23 Aug 2013 at 19:54, UFJORw== wrote: NTA is a way to turn off DNSSEC for a single domain instead of having to go completely insecure, like some did a few days ago during the gov algorihm rollover screw up (BTW shutting DNSSEC validation down to have at least their own domain working was not the best thing to do: temporarily adding their own KSK to the list of trust anchors was the way to go (as the most specific key is prefered by all implementations i know of (despite the stupidity that is written here : http://tools.ietf.org/html/rfc6840#appendix-C ))) Ummm. No. Not all of our domains are necessarily signed or in a signed tree. The .gov screw-up broke secure and insecure delegations from .gov. I considered all this as I watched the .gov DNSKEY RRSet TTL count down in those caches which still had it before recommending we disable validation until it could be corrected. Having your TLD screw up DNSSEC validation is particularly bad... Scott ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] Implementation of negative trust anchors?
Hi, On 8/23/2013 11:56 PM, Joe Abley wrote: Experience shared by Comcast and Google suggests that NTAs are necessary for validation on a large scale. However, Comcast and Google are engaged and have the resources to do the right thing; small resolver operators are generally not engaged and have fewer resources available to deal with support-loading (churn-enhancing, profit-harming) problems whose origins are elsewhere. They are far more likely to be guided by (a) the hooks available in their software and (b) the kind of rumour mill that came up with block ICMP for security reasons. Reasoned guidance from the IETF at best would improve (a) and decrease the incidence of (b). At worst, it would do no harm. Decreasing the pain to the zone editor considered harmful. We live in a world where the big ones mentioned have and will have NTAs. Otherwise they wouldn't do any validation. The suggestion is to spread these tools to more and more resolver operators. This will directly remove pain to the zone editors doing the original mistakes. editors will continue to do mistakes. NTA will be there for ever. Dislike. Seems it's a crossroads now. do we tell the resolver operators to fix-by-workaround broken zones, or do we tell editors to be more serious and from now they MUST get it right. To do both would be sending mixed signals. Frank at resource-starved isp still doing neither (signing|validating) ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
