Re: [dns-operations] Implementation of negative trust anchors?
Just back from vacation and see an amazing 87 messages in this thread on NTAs. As the primary NTA I-D author and NTA proponent I will slowly make my way through. Regards Jason ___ 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 8/23/13 12:52 PM, Daniel Kalchev dan...@digsys.bg wrote: 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. It's fun to poke at operators I guess, and that's certainly one reason why more operators don't come to the IETF. ;-) IMHO the experiences and knowledge that operators - which implement IETF protocols and standards - bring as much value as the people writing the original standards themselves. A standard is useless if no one implements it / if it is not deployed at scale. But getting back to ISP DNS operators being clueless/careless, of course in this case the 'clueless/careless' parties are the ones who can't get their authoritative practices right - not the ISP DNS operators (or other recursive DNS operators). The obvious question is, do we want to codify this in BCP or even worse standards document? Neither. An informational document has been proposed. Jason ___ 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 8/26/13 2:16 AM, Randy Bush ra...@psg.commailto:ra...@psg.com wrote: fix the software and the ops processes. do not patch over the problems or they will increase. the problem is weak software and processes that need to be fixed, and patching and denial will not fix them. Fair enough, and I agree that software and signing ops processes *do* need work (I'm more or less screaming that from the rooftops, so to speak). But realistically this will take time and in parallel if we as a community would like to see more validation, then NTAs seem like something we'll have to learn to live with for some period of time.* So we're in a lull in DNSSEC deployment. We want to see more DNSSEC deployment but without the ability to turn off validation for a short period of time for a single domain (the other choice is for all domains, which seems less good), it is very difficult for an operator to justify implementing DNSSEC (though *not* impossible – a few of us have). If we want to see more validation we may have to acknowledge the operational realities involved in doing so. I don't see NTAs as a long-term thing but in the phase of deployment we're all in now, it sure is useful. - Jason * Phone calls to report issues / open tickets is good of course. But if we expect to find this via WHOIS, good luck, and any method unless you know the contact personally can take hours (or days) to track down someone in the know. I really do wish that there was some central critical DNS incident NOC (at ICANN, DNS-OARC, McDonalds, or wherever) where operators could open tickets and where some centralized team would do incident handling reporting. That seems more efficient than 50 or 1,000 operators all calling example.com to report a signing failure. But I digress… ___ 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?
Ondřej Surý ondrej.s...@nic.cz wrote on 09/04/2013 10:37:57 AM: On 22. 8. 2013, at 21:59, wbr...@e1b.org wrote: Our browsers give us the option to trust invalid TLS certificates, some even storing it indefinitely. Is an NTA much different? And in certain circles it's considered by one of the biggest mistakes that could have happened, and the reason why the whole PKI fails so hard now. I'll agree it's a security weakness and most users will just click through without thinking about the cause, the risks or the consequences. On the other hand we have a set of scripts that monitor the domains in .CZ zones and they rip-off the DNSSEC from the domain if a set of conditions are fullfilled: - the validation fails for a defined time - the KEYSET matches the manually defined regex for automatic registrar keys (And we have an agreement from our registrars who do by-default signing that it's ok.) We have also added a trigger that removes KEYSET when NSSET changes (and KEYSET is not updates in the same go). So our experience is that most of the errors come from badly managed transfers, and that set of workarounds fixed most of it. So our view is that it's more an operational problem on the parent side than on resolver side. It would appear that you are automatically implementing a solution for broken signatures. Is this much different than adding an NTA? In either case, a domain's signature can no longer be confirmed. Unfortunately, I don't have access to TLD zone data to remove their records. 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?
Last but not least, I observed some conflicting feedback in this thread on NTAs. So I am wondering whether there is comparatively more consensus on these two issues: 1 – Responsibility for authoritative DNSSEC mistakes rests with authoritative operators (written up quickly in http://tools.ietf.org/html/draft-livingood-auth-dnssec-mistakes-00) 2 – In case of DNSSEC validation failures, don't change resolvers (written up quickly in http://tools.ietf.org/html/draft-livingood-dont-switch-resolvers-00) Any thoughts? (Standing back – I may be throwing a can of gasoline into the fire.) :-) - Jason ___ 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?
-Original Message- From: Ondřej Surý ondrej.s...@nic.cz Date: Wednesday, September 4, 2013 10:37 AM To: wbr...@e1b.org wbr...@e1b.org Cc: dns-operati...@dns-oarc.net dns-operati...@dns-oarc.net Subject: Re: [dns-operations] Implementation of negative trust anchors? On 22. 8. 2013, at 21:59, wbr...@e1b.org wrote: Our browsers give us the option to trust invalid TLS certificates, some even storing it indefinitely. Is an NTA much different? And in certain circles it's considered by one of the biggest mistakes that could have happened, and the reason why the whole PKI fails so hard now. I just want to point out that vendors or software in general should certainly ship secure by default, BUT also give users the option to shoot their own foot (with adequate documentation and shepherding away from loading the gun). I believe in security, but also free choice. When the two seem to conflict, better education is the answer not removing one's ability to make choices. There will always be use cases the smartest can not fathom which make perfect sense to someone you have not met...no matter how well intentioned we are, I don't believe controlling someone else's destiny through force alone is the right path. In my mind, this applies to SSL/TLS, NTA, etc. ___ 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-09-04 17:55, Mike Hoskins (michoski) wrote: -Original Message- From: Ondřej Surý ondrej.s...@nic.cz Date: Wednesday, September 4, 2013 10:37 AM To: wbr...@e1b.org wbr...@e1b.org Cc: dns-operati...@dns-oarc.net dns-operati...@dns-oarc.net Subject: Re: [dns-operations] Implementation of negative trust anchors? On 22. 8. 2013, at 21:59, wbr...@e1b.org wrote: Our browsers give us the option to trust invalid TLS certificates, some even storing it indefinitely. Is an NTA much different? And in certain circles it's considered by one of the biggest mistakes that could have happened, and the reason why the whole PKI fails so hard now. I just want to point out that vendors or software in general should certainly ship secure by default, BUT also give users the option to shoot their own foot (with adequate documentation and shepherding away from loading the gun). That could work in community of geeks, but not in consumer electronics. I believe in security, but also free choice. I don't think this is about a free choice, but adhering to the protocol. When the two seem to conflict, better education is the answer not removing one's ability to make choices. There will always be use cases the smartest can not fathom which make perfect sense to someone you have not met...no matter how well intentioned we are, I don't believe controlling someone else's destiny through force alone is the right path. In my mind, this applies to SSL/TLS, NTA, etc. This is not technical, but philosophical question about where do you draw the line. Is your bank limiting your free choice by not providing the options to give free access to your money to random visitors? O. ___ 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?
-Original Message- From: ondrej.s...@nic.cz ondrej.s...@nic.cz Date: Wednesday, September 4, 2013 12:37 PM To: dns-operations@lists.dns-oarc.net dns-operations@lists.dns-oarc.net Subject: Re: [dns-operations] Implementation of negative trust anchors? When the two seem to conflict, better education is the answer not removing one's ability to make choices. There will always be use cases the smartest can not fathom which make perfect sense to someone you have not met...no matter how well intentioned we are, I don't believe controlling someone else's destiny through force alone is the right path. In my mind, this applies to SSL/TLS, NTA, etc. This is not technical, but philosophical question about where do you draw the line. Is your bank limiting your free choice by not providing the options to give free access to your money to random visitors? Drawing the line indeed...but better examples in this case would be banks allowing me to access my account on-line and even via mobile devices which are statistically far less secure vs forcing me to present my account information and hard copy ID to a teller. I can disable online/mobile access if I want (in fact I have to opt-in), but I'm not forced to. :-) ___ 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: Livingood, Jason jason_living...@cable.comcast.com 1 ? Responsibility for authoritative DNSSEC mistakes rests with authoritative operators (written up quickly in http://tools.ietf.org/html/draft-livingood- auth-dnssec-mistakes-00) The ultimate responsibility for domain issues really rests with the domain owner, not the domain admin. In section 3, you write Even in cases where some error may be introduced by a third party, whether that is due to an authoritative server software vendor, software tools vendor, domain name registrar, or other organization, these are all parties that the domain administrator has selected and is responsible for managing successfully. If the domain administration is provided by an outside party, it is the owner that selected them and the owner is the one ultimately responsible. In many such service provider arrangements, the only party that has any influence to correct problems is the owner, via SLA and the power of the checkbook. Coincidentally, I am dealing with the provider for a local college that has outsourced much of their IT. I am trying to get their SPF record corrected. The outsourcing provider admits the record could use updating but after close to 2 weeks, it is still wrong. I gave up after several phone calls to the provider and I am in contact with the local college IT staff. Time will tell if this provides any results. 2 ? In case of DNSSEC validation failures, don't change resolvers (written up quickly in http://tools.ietf.org/html/draft-livingood- dont-switch-resolvers-00) A well written sermon to the choir, I'm afraid. I suspect there is little that can be done to prevent the typical end user from doing what they perceive as fixing the problem. Unless this floats to the top of every search for Wny can't I get to $PopularDomain, people will find the advice to switch to a non-validating resolver. Fortunately, the number of publicly available non-validating resolvers is declining. 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?
I don't think this is about a free choice, but adhering to the protocol. At this point, I'm not sure who is saying what and what is inferred in the quips, but if you adhere to the protocol, you place free choice first. This is not just from my dimming memory of the 1990's when we developed the concept, we even wrote this into the latest rendition of the DNSSEC specifications (albeit in 2004). RFC 4033: ...In the final analysis, however, authenticating both DNS keys and data is a matter of local policy, which may extend or even override the protocol extensions defined in this document set. See Section 5 for further discussion. And this predicts NTA's (also in RFC 4033): Insecure: The validating resolver has a trust anchor, a chain of trust, and, at some delegation point, signed proof of the non-existence of a DS record. This indicates that subsequent branches in the tree are provably insecure. A validating resolver may have a local policy to mark parts of the domain space as insecure. I emphasize the last sentence: A validating resolver may have a local policy to mark parts of the domain space as insecure. And I'll add in a cranky manner, the overall tenor of this list insinuating that operators are incompetent and should therefor not be given free will needs to be seriously reconsidered. Perhaps I need to quite Star Wars to get the point across: Princess Leia: The more you tighten your grip, Tarkin, the more star systems will slip through your fingers. Ecologies that place heavy emphasis on security have been empirically proven to fail at scale (population and/or time). -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NeuStarYou can leave a voice message at +1-571-434-5468 There are no answers - just tradeoffs, decisions, and responses. ___ 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 26 Aug 2013, at 15:08, Randy Bush ra...@psg.com wrote: So what would your advise be to the people running resolvers/validators? in internet operations we open a ticket with the op that has the problem. we even use gasp voice phones, if that is what it takes. Sure. Been there, done that. However there are times when resolution of a problem is not fast, for various reasons: Timezones, software release cycles, registar/registry schedules to name just a few. As not validating at all or not getting to the domain needed for a prolonged time is not an option what is needed is a workaround until the problem is resolved and that is what NTAs are. Workarounds are also quite common in internet operations... So long -Ralf ___ 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?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 How about this solution: A truly DNSSEC aware authoritative server should not publish a zone, not even the unsigned records, when validation fails for that zone. That way, if a DNSSEC signed zone is DNSSEC broken, it's also broken for a non-validating resolver, there is no competition issue, and the zone publisher should fix his zone to get it working at all. Who will be the first DNS vendor implementing? :-) - -- Antoin Verschuren Technical Policy Advisor SIDN Meander 501, PO Box 5022, 6802 EA Arnhem, The Netherlands P: +31 26 3525500 M: +31 6 23368970 Mailto: antoin.verschu...@sidn.nl XMPP: antoin.verschu...@jabber.sidn.nl HTTP://www.sidn.nl/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) iQEcBAEBAgAGBQJSHKBEAAoJEDqHrM883Agno/wH/jKX6aYUFXz8sD5jia5l1rA2 R1H8+ML/rITw9M2Q/pB8hxZw6ZOOkG//NXGiL9ZpUe0TTGWECEhtyE6Pb6Nrs2cp lXB730UWycEpr/ZnvSFauKdEqtZqCT3IjGJVLSxyLUNk8vedI7JW5wzsH972Aksw mjw/n+a5LdmNpG/88RHedpoun607tP1/y8WOZd0vT4WH8it4mekVph4KebU9IUyk E+X8GkyebnE9DLOXPTBxbb+qIVLK1yg+bH3oPM/DL0EQndbtjbLPvcWx+kCiC5MA wWgfHqWfzjnTEZVdQZ1hgo8jfzcLoTS77oHG3ERbpUqhi6SgblWYXBWprxQGM+c= =Drr7 -END PGP SIGNATURE- ___ 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-27, at 08:49, Antoin Verschuren antoin.verschu...@sidn.nl wrote: How about this solution: A truly DNSSEC aware authoritative server should not publish a zone, not even the unsigned records, when validation fails for that zone. That way, if a DNSSEC signed zone is DNSSEC broken, it's also broken for a non-validating resolver, there is no competition issue, and the zone publisher should fix his zone to get it working at all. Who will be the first DNS vendor implementing? :-) That would help avoid some problems. It wouldn't help avoid all problems, though. The event horizon for end-user problems is extended based on cached records originally served from previous internally-correct zones, and bad interactions between successive, well-signed zones can still cause problems. I seem to think actually that all the prominent public failures near the root of the namespace have not been due to zones that were signed incorrectly, but rather botched rollovers, parent DS mismatch, accidental use of an old key, etc. I've long wished for a more general facility where upon successful [AI]XFR I could shell out to an arbitrary local executable and do whatever checks I wanted before signalling with exit status that this zone is ok to serve. With a bit of state held on disk about previous zones you could include some of those temporal checks and perhaps catch a few more problems. Joe 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 27, 2013, at 8:27 AM, Joe Abley jab...@hopcount.ca wrote: I seem to think actually that all the prominent public failures near the root of the namespace have not been due to zones that were signed incorrectly, but rather botched rollovers, parent DS mismatch, accidental use of an old key, etc. That is what most of the sad messages we have seen on the DNSSEC deployment list indicate. I've long wished for a more general facility where upon successful [AI]XFR I could shell out to an arbitrary local executable and do whatever checks I wanted before signalling with exit status that this zone is ok to serve. With a bit of state held on disk about previous zones you could include some of those temporal checks and perhaps catch a few more problems. ...but not all of them. --Paul Hoffman ___ 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 Tue, 27 Aug 2013, Paul Hoffman wrote: On Aug 27, 2013, at 8:27 AM, Joe Abley jab...@hopcount.ca wrote: I seem to think actually that all the prominent public failures near the root of the namespace have not been due to zones that were signed incorrectly, but rather botched rollovers, parent DS mismatch, accidental use of an old key, etc. That is what most of the sad messages we have seen on the DNSSEC deployment list indicate. Actually, I think most common has been expired RRSIGs. I've long wished for a more general facility where upon successful [AI]XFR I could shell out to an arbitrary local executable and do whatever checks I wanted before signalling with exit status that this zone is ok to serve. With a bit of state held on disk about previous zones you could include some of those temporal checks and perhaps catch a few more problems. ...but not all of them. And yes, once your dead man switch activates, and the newly botched signed zone is withheld, you _still_ need a monitor system and a human to address the issue before you end up at expired RRSIGs again for not pushing the botched zones, while your current very old zone is still being served. Paul ___ 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 Aug 27, 2013, at 12:56 PM, Paul Hoffman paul.hoff...@vpnc.org wrote: ...but not all of them. No feature / idea will ever catch all of them. This should not let us from implementing some of the good ideas that are going around. In fact, when I read 'an authoritative nameserver SHOULD NOT publish an invalid zone _ever_', well, I was struck by how obvious this is, and a bit ashamed at how I had never thought about it. This is something that should have always been in place. Same for [A|I]XFR. Slaves MUST refuse transferring invalid zones ! In that way they might keep an outdated but still validly signed zone. And, if there is a corner case where this should be allowed, well, that's what configuration options are for. We must build resiliency layer by layer. cheers! ~Carlos --Paul Hoffman ___ 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
Re: [dns-operations] Implementation of negative trust anchors?
Op 27-08-13 18:02, Paul Wouters schreef: Actually, I think most common has been expired RRSIGs. In my experience the most common error is a missing DNSKEY. That usually happens when a domain moves from a provider with DNSSEC-support to one without it. On my network these errors far outweigh al the rest. I have to add to that in my region (.NL) there are few large hosters that support DNSSEC on all their domains. That's very different from most of the rest of the world Over the past two months I have been monitoring validation failures. I've got over a hundred documented cases of a missing DNSKEY and only a handfull of expired rrsigs. -- Casper Gielen cgie...@uvt.nl | LIS UNIX PGP fingerprint = 16BD 2C9F 8156 C242 F981 63B8 2214 083C F80E 4AF7 Universiteit van Tilburg | Postbus 90153, 5000 LE Warandelaan 2 | Telefoon 013 466 4100 | G 236 | http://www.uvt.nl ___ 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?
I agree, triggering some script after certain events and condition zone acceptance to the result of the script is a nice approach. I like it. On Aug 27, 2013, at 3:54 PM, Joe Abley jab...@hopcount.ca wrote: On 2013-08-27, at 14:51, UFJORw== ufj...@gmail.com wrote: That would mean having a full-fledged DNSSEC validator in every authserv: what a software bloat! Personally, I prefer the approach of being able to shell out to a script that runs something like validns over the just-transferred zone, so I can make my own decisions as an operator as to what checks are sensible to run. And what about the validation policy? What is an invalid signature? What keys were used to verify the signatures? Local trust anchors? The root? Which version of the root keys? Should we trust the most specific key or only the root or should they be both valid? What if the domain is an island and no DS is published on purpose? What if a DLV is published because the parent does not accept DS? Which DLV database should you trust? What if the authserv does not support the signature or the hashing algorithm? What if the authserv is clock-drifting? And finally: are all of these parameters the same as those in the validators that will query the authserv? Indeed, being able to run my own script is good :-) 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?
I mostly agree, but as someone pointed out, the zone operator will be immediately (and painfully) aware of the mishap. Just as if you have a syntax error in your zone file. I fail to see how this result in 'worse' availability compared to what we have today. Regarding your What … ? questions, I agree you need to answer them, but well, they should be easy to answer if you intend to publish signed zones. And, if you cannot positively answer those questions for your zone and your three or four slaves, well, what can you expect from the Internet as a whole ? regards, ~Carlos On Aug 27, 2013, at 3:51 PM, UFJORw== ufj...@gmail.com wrote: On Tue, Aug 27, 2013 at 6:06 PM, Carlos M. Martinez carlosm3...@gmail.com wrote: when I read 'an authoritative nameserver SHOULD NOT publish an invalid zone _ever_', well, I was struck by how obvious this is, and a bit ashamed at how I had never thought about it. This is something that should have always been in place. Same for [A|I]XFR. Slaves MUST refuse transferring invalid zones ! In that way they might keep an outdated but still validly signed zone. Hi, This sounds to me like a bad/complex idea. That would mean having a full-fledged DNSSEC validator in every authserv: what a software bloat! And what about the validation policy? What is an invalid signature? What keys were used to verify the signatures? Local trust anchors? The root? Which version of the root keys? Should we trust the most specific key or only the root or should they be both valid? What if the domain is an island and no DS is published on purpose? What if a DLV is published because the parent does not accept DS? Which DLV database should you trust? What if the authserv does not support the signature or the hashing algorithm? What if the authserv is clock-drifting? And finally: are all of these parameters the same as those in the validators that will query the authserv? If you got any of these wrong, the zone will not be published. Do not expect a good availability/resiliency from that mess. Please, let's keep authservers as simple as possible. Regards, ___ 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?
Carlos M. Martinez (carlosm3011) writes: I agree, triggering some script after certain events and condition zone acceptance to the result of the script is a nice approach. I like it. This is the recommended approach for any zone production system, DNSSEC or not. Content (truncated zones, premature end of file), logical (missing NSes, broken SOA) or syntactical (5 byte IPv4 addresses. Really.), etc... That's why validns was written in the first place (that, and checking DNSSEC signatures). At every step (output from DB, pre-signature, post- signature, etc), verify. Rollback otherwise (or just don't publish). ___ 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 Tue, Aug 27, 2013 at 9:01 PM, Carlos M. Martinez carlosm3...@gmail.com wrote: I mostly agree, but as someone pointed out, the zone operator will be immediately (and painfully) aware of the mishap. Just as if you have a syntax error in your zone file. I fail to see how this result in 'worse' availability compared to what we have today. Many operators have their zone slaved by third parties, and these 3rd parties' infrastructures are not always completely flexible and/or reactive (e.g. dns hosting companies that offer slaving zones as a service; I believe this is also the case for some TLDs). I think offline signatures were first introduced in DNSSEC to allow operators to be free of such constraints relative to third parties. Regarding your What … ? questions, I agree you need to answer them, but well, they should be easy to answer if you intend to publish signed zones. And, if you cannot positively answer those questions for your zone and your three or four slaves, well, what can you expect from the Internet as a whole ? Easy only if you are a DNSSEC expert and you know these questions exist, and what to answer to each of them. DNSSEC is already not for humans. Let's not make it worse by adding new layers of complexity over this mess :) I think shelling out is sensible but will probably only be used by an elite who can already think of ways to do such validations without this feature. ___ 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 27, 2013, at 4:18 PM, UFJORw== ufj...@gmail.com wrote: On Tue, Aug 27, 2013 at 9:01 PM, Carlos M. Martinez carlosm3...@gmail.com wrote: I mostly agree, but as someone pointed out, the zone operator will be immediately (and painfully) aware of the mishap. Just as if you have a syntax error in your zone file. I fail to see how this result in 'worse' availability compared to what we have today. Many operators have their zone slaved by third parties, and these 3rd parties' infrastructures are not always completely flexible and/or reactive (e.g. dns hosting companies that offer slaving zones as a service; I believe this is also the case for some TLDs). I think offline signatures were first introduced in DNSSEC to allow operators to be free of such constraints relative to third parties. That's why every behavior should be controlled by a configuration switch. No solution is universal. Regarding your What … ? questions, I agree you need to answer them, but well, they should be easy to answer if you intend to publish signed zones. And, if you cannot positively answer those questions for your zone and your three or four slaves, well, what can you expect from the Internet as a whole ? Easy only if you are a DNSSEC expert and you know these questions exist, and what to answer to each of them. DNSSEC is already not for humans. Let's not make it worse by adding new layers of complexity over this mess :) We're talking about people who want to publish signed zones. You don't need to be an expert to answer those questions. Or, on the other hand, you probably should not publish your signed zone before you are able to answer them. I think shelling out is sensible but will probably only be used by an elite who can already think of ways to do such validations without this feature. We agree to disagree then. regards ~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?
i will try once more an american idiom is keep your eye on the doughnut not the hole. this NTA discussion focuses on the wrong thing. why is the frelling software on the farbled server not detecting that is has been farbled and screaming loudly? why is it not preventing most of these farblings in the first place? when mongolia tried to change key [alg] to one that was not in the root, their software should not have done it. fix the software and the ops processes. do not patch over the problems or they will increase. the problem is weak software and processes that need to be fixed, and patching and denial will not fix them. randy ___ 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 26 Aug 2013, at 08:16, Randy Bush ra...@psg.com wrote: an american idiom is keep your eye on the doughnut not the hole. this NTA discussion focuses on the wrong thing. why is the frelling software on the farbled server not detecting that is has been farbled and screaming loudly? why is it not preventing most of these farblings in the first place? when mongolia tried to change key [alg] to one that was not in the root, their software should not have done it. fix the software and the ops processes. do not patch over the problems or they will increase. the problem is weak software and processes that need to be fixed, and patching and denial will not fix them. I fully agree with you on better software and better processes, and better monitoring tools, etc. However keep in mind that the people deploying resolvers are not the people signing the zones. So what would your advise be to the people running resolvers/validators? So long -Ralf ___ 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 26/08/2013, at 13.18, Ralf Weber ralf.we...@nominum.com wrote: So what would your advise be to the people running resolvers/validators? Currently validating resolvers suffer from an additional and different set of configuration mistakes from those that don't validate. Arguably if everyone validated then it wouldn't matter if foo.com failed because they fumbled the DS or failed to pay for renewal. At that stage, It's Their Problem, Not Yours because everyone on the resolver side experiences the same problem (give or take $ttl just like in insecure DNS). So get everyone else to validate so we're all in the same boat :) Humor aside, I agree better automated processes would help - although today no software helps you prevent mismatched parent and child delegations, for instance. But dnssec IS more complicated, and more automation (and policy enforcement - here I'm looking at opendnssec) will certainly help. In the meantime... ... Will NTAs delay adoption of validation or speed it up thanks to the warm fuzzy feeling? P ___ 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 26, 2013, at 7:40 AM, Phil Regnauld regna...@nsrc.org wrote: On 26/08/2013, at 13.18, Ralf Weber ralf.we...@nominum.com wrote: So what would your advise be to the people running resolvers/validators? Currently validating resolvers suffer from an additional and different set of configuration mistakes from those that don't validate. Arguably if everyone validated then it wouldn't matter if foo.com failed because they fumbled the DS or failed to pay for renewal. At that stage, It's Their Problem, Not Yours because everyone on the resolver side experiences the same problem (give or take $ttl just like in insecure DNS). So get everyone else to validate so we're all in the same boat :) Humor aside, I agree better automated processes would help - although today no software helps you prevent mismatched parent and child delegations, for instance. But dnssec IS more complicated, and more automation (and policy enforcement - here I'm looking at opendnssec) will certainly help. In the meantime... ... Will NTAs delay adoption of validation or speed it up thanks to the warm fuzzy feeling? While in full agreement that signer-side tools and processes need work (and yes, I work for a DNS software vendor), I think on balance NTA speeds up adoption by compartmentalizing other people's mistakes and allowing the resolver operator to still get the benefit of DNSSEC from server operators who do properly maintain their DNSSEC. As with any tool, virtual or physical, NTA can be useful, but careless operation comes with a price. That may or may not be a reason to leave the tool on the shelf. Why would we assume that resolver operators are less able to make intelligent use of improved policy tools such as NTA than server operators are of better tools for maintaining (or breaking) their DNSSEC? Suzanne ___ 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 1:03 PM, Paul Vixie p...@redbarn.org wrote: on the other hand i would not be glad to see NTA as an IETF RFC, FYI, BCP, or other standards-like artifact. The current draft proposed status is Informational. That is, not standards-track and not BCP. See: https://datatracker.ietf.org/doc/draft-livingood-negative-trust-anchors/ It has cautionary language in it regarding the limited applicability of NTAs and IME the authors are not opposed to strengthening that. Should we document it as an RFC anyway? is a reasonable question, and I tend to think so but (like others I know here) I can live with either outcome. Suzanne ___ 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 24 Aug 2013, at 06:26, Frank Habicht ge...@geier.ne.tz wrote: 8/23/2013 11:56 PM, Joe Abley wrote: 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. That's not what is intended and if you read https://datatracker.ietf.org/doc/draft-livingood-negative-trust-anchors/ section 7 clearly states responsibilities for the problems. We live in a world where the big ones mentioned have and will have NTAs. Otherwise they wouldn't do any validation. And the draft tries to document reasonable operational practices for them which if such a draft didn't exists everybody would do on there own with maybe not so good results. We already had cases where large operators stopped validation after the first incident and haven't gone back since. The suggestion is to spread these tools to more and more resolver operators. The suggestion is to document what to do if someone decides to use NTA, the tools are already there and will be use regardless if we document their proper usage or not. 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. Not documenting something doesn't make it go away (see NAT). It just makes it harder to interoperate. 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. IMHO if we only tell zone editors to do the right thing, and resolver operators to just take the hit some zone operators will still not get it right and we will not get widespread adoption of DNSSEC in the resolver space. Frank at resource-starved isp still doing neither (signing|validating) Well think about what would make your bosses do it and what your responses to them in the case of problems would be. So long -Ralf ___ 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.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
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
Re: [dns-operations] Implementation of negative trust anchors?
On 8/21/13 11:25 AM, Warren Kumari war...@kumari.net wrote: FWIW, I remain opposed to the idea, but trying to do due diligence. I still like the idea as it is the only way for big resolver providers to deploy DNSSEC when there competitors have not. +lots. Penalizing the early adopters simply leads to no deployment. +more Our deployment at Comcast would not have happened without NTAs. I guess it is time for me to update and work on the DNSOP WG NTA I-D again (been busy on other stuff). Jason ___ 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 08/22/2013 08:29 AM, Mehmet Akcin wrote: On 8/21/13 11:25 AM, Warren Kumari war...@kumari.net mailto:war...@kumari.net wrote: FWIW, I remain opposed to the idea, but trying to do due diligence. I still like the idea as it is the only way for big resolver providers to deploy DNSSEC when there competitors have not. +lots. Penalizing the early adopters simply leads to no deployment. Agreed! 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. I continue to maintain that NTAs violate the whole principle of DNSSEC, and that if there is a high price for doing it wrong less people will do it wrong. Doug ___ 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: 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. So, for DNSSEC deployment transition work-arounds: - ISC's DLV is the white list - NTAs are the black list and both need a best-before date ? Keith ___ 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 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. You don't do crazy things like poke around to get an old copy of their zone and publish a pirate copy when they mess up something else. You say something like They messed up. In this case, you could and should say something like: Our network security defenses are telling us that there is something. wrong there. Instead of lesson plans, you might be getting child porn if you visit their pages today. Our browsers give us the option to trust invalid TLS certificates, some even storing it indefinitely. Is an NTA much different? Yes, because TLS differs because public PKI certs are merely a charade of pretend security intended to fool the rubes and harvest money from those cannot for various good and bad reasons refuse to pay the commerical PKI cert vendors. (Yes, some commercial PKI certs are free, which says all that needs to be said to anyone with 0.1% of a clue about the security of every commercial PKI cert.) A valid commercial PKI cert tells you *NOTHING* about the web data it purports to guarantee except that some was willing to pay time, effort, and perhaps some money to appear trustworthy. Perhaps in the real world, no evil nasty hackers are going to replace your staff's educational pages with nastiness with either bogus certs or corrupt DNS, but things are definitely otherwise elsewhere. 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?
Keith Mitchell 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. So, for DNSSEC deployment transition work-arounds: - ISC's DLV is the white list - NTAs are the black list and both need a best-before date ? dlv was best before the root was signed, so it's years overdue for killing. ___ 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?
(Just using this to launch into a tirade.) On Aug 22, 2013, at 15:59, wbr...@e1b.org 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! One thing that seems to need repeating from time to time is this passage in RFC 4033. ... In the final analysis, however, authenticating both DNS keys and data is a matter of local policy, which may extend or even override the protocol extensions defined in this document set. See Section 5 for further discussion. A responsibility (one of many) of a caching server operator is to protect the integrity of the cache. DNSSEC is just a tool to help accomplish that. It carries ancillary data that a local cache administrator may use to filter out undesired responses. DNSSEC is not an enforcement mechanism, it's a resource. When I see folks voice opinions that DNSSEC's recommended operation has to strictly followed, my gut reaction is that these folks have forgotten the purpose of all of our efforts. We don't secure protocols to make things work better. We don't operate the DNS because we like to run a well run machine. We don't run the Internet for the fun of it. (Some might enjoy running it, that's job satisfaction to some extent.) At the end of the day all that matters is that what is being done benefits society. We run the Internet to enrich society. We prefer a well run DNS because it saps less resources than a poorly run DNS. We prefer secure protocols so that people don't become victims (in some sense of the word). Make it work. Do what it takes to make it work. Local policy rules. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NeuStarYou can leave a voice message at +1-571-434-5468 There are no answers - just tradeoffs, decisions, and responses. ___ 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-22, at 12:06, Doug Barton do...@dougbarton.us wrote: As stated before, the problem is that after the early adopter period is over we'll be stuck with NTAs forever. I think we need to acknowledge that there will always be signing problems, and there will always be validator operators who know that certain failures are the result of those signing problems, and not some kind of attack. Further, there will always be such validator operators who have Good Reasons to accept and serve such responses. We don't need to agree that the reasons are sensible, just that some people will have them. We are not talking about code or protocol quality here, we are talking about humans. Code and protocols improve over time. Humans do not. Last thing, we have NTAs today. People use them. So, there are two plausible outcomes here: (a) DNSSEC deployment reverses, and nobody uses it any more, so there is no need for NTAs. (b) We will always NTAs. I don't feel like there is any reason to aim for outcome (a), which leaves us with (b). 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. 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?
Doug, On Aug 22, 2013, at 12:06 PM, Doug Barton do...@dougbarton.us wrote: As stated before, the problem is that after the early adopter period is over we'll be stuck with NTAs forever. 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. I would think corporate lawyers might quiver with ... righteous indignation in situations like this. As such, I have some skepticism that corporate resolver operators will be allowed to leave NTAs up for much longer than necessary. But maybe I overestimate lawyer nervousness. 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
Re: [dns-operations] Implementation of negative trust anchors?
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. Turn off validation is the only sane response this year to phone calls reporting the breakage of a major domain. Even if you have NTA, from now on you'll do as Comcast evidently is now doing and decline to pay the current and future costs of adding minor domains to your NTA list. You'll just tell your users Stuff Happens and perhaps help them use `whois` to find someone else to bother. Last year differed. I trust (wish?) we all learned the excessive costs of organization-wide white/blacklists from the last 15 years of the spam wars. madness test: would we have bothered with DNSSEC at all, back in the = day, if NTA had been known as a definite requirement? I realize this is something of a rhetorical question, but I'll bite: if = it were framed as a way of promoting incremental, fault-tolerant = deployment and mitigating the cost shifting of I screw up and your = phone rings, some of us might well have been happy to include it.=20 On the contrary, NTA is a new tool for deliberately introducing new faults in the data you give your DNS clients. It is a tool for lying to your DNS clients with data that you swear is valid and signed but that you know is at best unsigned and quite possibly invalid or worse. If I didn't know that the inevitable user response to security problems, I'd favor NTA as a way to get validation move where must be eventually, at least as close as their nearest router. After a few kerfuffles in which it is discovered that telephants have been ordered by government or corporate bosses to use NTA to obscure the hijacking of domain names on grounds of copyright violation, terrorism, publication of national defense secrets, or failure by content providers to agree to telephant tariffs, one might hope that users would stop using Central Facility's DNS validators. Of course, besides the inevitable non-response by almost users, some users would probably notice, figure it out, and care. But as always, enough of the bosses and their minions won't believe or care. 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 Aug 22, 2013, at 7:05 PM, Suzanne Woolf wo...@isc.org wrote: On Aug 22, 2013, at 6:25 PM, Paul Vixie p...@redbarn.org wrote: Paul Hoffman 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. 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. To elaborate on Paul's comment: We really do not need to create another clever attack vector. We have sufficient already.___ 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 Randy, On 2013-08-22, at 16:58, Randy Bush ra...@psg.com wrote: I think we need to acknowledge that there will always be signing problems 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. we need to think about how to make good server ops the easy path: o less breakage prone protocols o less breakage prone implementations o easing fast repair if breakage is known o detecting and reporting more aggressively o blah blah blah i.e. put that gun back in your hand I like that line of thinking. Very nicely put, and it makes me reconsider my earlier thinking that NTAs will be useful to someone for ever. However, I'm still not convinced that the right answer is not to standardise, or not to write up a BCP, for reasons of if we write about this, people will do it for ever. We can't predict how long this deployment phase will last, and it seems weird to assume that standardisation has no value over that unknown period. As a zone publisher, I would very much like to know how people are consuming my data. It seems more likely that I can have that insight if there is consistency in the way it is done. 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. 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?
I'm still not convinced that the right answer is not to standardise, or not to write up a BCP how about a wcp? nancy regan was right. i am still at the other end of the elephant. why is the frelling software on the farbled server not detecting that is has been farbled and screaming loudly? why is it not preventing most of these farblings in the first place? when mongolia tried to change key [alg] to one that was not in the root, their software should not have done it. do not be liberal in what you accept, this is the path to entropic death. randy, a naggumite ___ 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 21, 2013, at 1:33 AM, Ralf Weber ralf.we...@nominum.com wrote: Moin! On 20.08.2013, at 20:14, Doug Barton do...@dougbarton.us wrote: Rumor has it that Nominum and Fortidns have implementations for NTAs. Any truth to those rumors? It's not a rumor. Nominum Vantio had this feature for some time now. As FortiDNS uses that for DNS resolution I guess it also has it. Anyone else have an implementation? AFAIK Unbound also has that feature. Any patches for BIND? I don't know. FWIW, I remain opposed to the idea, but trying to do due diligence. I still like the idea as it is the only way for big resolver providers to deploy DNSSEC when there competitors have not. +lots. Penalizing the early adopters simply leads to no deployment. W 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 -- American Non-Sequitur Society; we don't make sense, but we do like pizza! ___ 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] Implementation of negative trust anchors?
Rumor has it that Nominum and Fortidns have implementations for NTAs. Any truth to those rumors? Anyone else have an implementation? Any patches for BIND? FWIW, I remain opposed to the idea, but trying to do due diligence. Doug ___ 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 20.08.2013, at 20:14, Doug Barton do...@dougbarton.us wrote: Rumor has it that Nominum and Fortidns have implementations for NTAs. Any truth to those rumors? It's not a rumor. Nominum Vantio had this feature for some time now. As FortiDNS uses that for DNS resolution I guess it also has it. Anyone else have an implementation? AFAIK Unbound also has that feature. Any patches for BIND? I don't know. FWIW, I remain opposed to the idea, but trying to do due diligence. I still like the idea as it is the only way for big resolver providers to deploy DNSSEC when there competitors have not. 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
