Re: lists.isc.org rDNS failed, DNSSEC?
In message 1330508848.24108.140661042811...@webmail.messagingengine.com, nudge writes: A thought regarding the pros and cons of DNSSEC that I don't recall being mentioned. There are a whole set of things you can do once you have secure DNS. You just have to use your imagination. This one has always been blindling obvious. Was reverse-dns verification introduced in response to a lack of confidence in forward-dns? This can cause much frustration, especially in smaller environments. If the implementation of DNSSEC allowed us to avoid using reverse-dns then perhaps that could be beneficial to many. Not accepting SMTP from machines without a reverse DNS entry has nothing to do with the security of the DNS (forward or reverse). It had (past tense) to do with a strong correlation between compromised machines spewing out spam and lack of reverse DNS entries. If you actually read the RFCs they say do NOT do this check. If you are sane you only use it as one input into deciding if email is spam. The lack of a PTR record, by itself, shouldn't be enough to get a piece of email rejected though I do know lots of sites do it. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
RE: lists.isc.org rDNS failed, DNSSEC?
Please allow a, partly/mostly, non-technical feedback as security officer for a tld (.eu) First of all : I do not deny DNSSEC adds a challenge for administrators. They must understand that adding this additional SECurity aspect, will generate extra work (keygeneration/re-generation/signing and re-signing). Point taken, but let me come back on those later. The (non-technical) response : When I get in my car, I put my safety belt on. (I know some may point at undesired effects, and I do not want to have that discussion in this list), but the point is : I do hope I will never need the protection offered by the safety belt, but if, then I'll be happy I took the precaution. The similarity to DNSSEC is that we all hope we will not need the protection it offers, but if an attacker finds it interesting to attempt to exploit, I will be glad I took the precaution of activating DNSSEC. How popular are these attacks against which DNSSEC offers protection ? From what I can see, my view being limited, the most 'effective', for lack of a better word, in 2011 were not DNS related. Social engineering, making people do something (click URL, open attachment) is a far more effective way, for attackers, to get their thing done. Does this mean we don't have to put the safety belt on ? I daresay : no. Attackers constantly look for new ways, therefore if an attacker comes up with an approach that becomes popular because of ease/speed/effectiveness and that approach would have been prevented by DNSSEC, we would have been happy that we already deployed DNSSEC. To conclude (some technical) suggestions : - when offering DNSSEC on authoritative name servers, try to rely on automation (like scripts). (rather than humans to type - and re-type - the same commands over and over) - allow yourself a period of testing. Do *not* immediately have DS information put in the parent zone (thus completing the chain-of-trust but also : making validation mandatory. After all : this is a *test* period) ((look how TLDs migrate towards DNSSEC. Exactly the same : first offer DNSKEYs and RRSIGs, but no DS in the root-zone)) - and may I also plead for validation on caching/forwarding name servers ? Because it makes no sense to add signatures that can be validated to DNS replies, if the signatures are simply ignored. Kind regards, Marc Lampo Security Officer EURid (for .eu) -Original Message- From: michoski [mailto:micho...@cisco.com] Sent: 24 February 2012 06:01 AM To: vinny_abe...@dell.com; kob6...@gmail.com; ma...@isc.org Cc: bind-us...@isc.org Subject: Re: lists.isc.org rDNS failed, DNSSEC? On 2/23/12 8:48 PM, vinny_abe...@dell.com vinny_abe...@dell.com wrote: I kind of had the same thought... If ISC had a DNS outage due to expired signatures of a zone, what chance do I have in successfully deploying and maintaining DNSSEC for my zones? Sure, everyone makes mistakes, but I think it speaks volumes to the inherent complexity and the further need for simplifying the maintenance of signed zones. I know that progress is continually being made on this front and I think others agree... Just pointing it out again. I have nothing against DNSSEC, personally. I'd love to deploy it. I just don't have the time to maintain it or worry about maintaining it right now. Much agreed, though I want to point out that you should only generally deploy DNSSEC (or any new technology?) if the benefit outweighs the cost. Adopting new technology just because usually leads to trouble (or overworked admins that give up and go elsewhere). What's the potential risk to your organization if the mythical determined attacker is able to negatively or positively spoof resource records under your control? Maybe not much for you, maybe millions for financial orgs. If the potential cost to the organization is high enough... It will justify paying a team of folks to maintain DNSSEC. :-) That said, I too look forward to a day when security is easier and more automatic. Much progress has been made, and I have high hopes and faith in ISC and the DNS community at large. http://www.jnd.org/books.html -- Time is the coin of your life. It is the only coin you have, and only you can determine how it will be spent. Be careful lest you let other people spend it for you. -- Carl Sandburg ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: lists.isc.org rDNS failed, DNSSEC?
On Tue, Feb 28, 2012 at 01:16:16PM +0100, Marc Lampo wrote: Please allow a, partly/mostly, non-technical feedback as security officer for a tld (.eu) First of all : I do not deny DNSSEC adds a challenge for administrators. They must understand that adding this additional SECurity aspect, will generate extra work (keygeneration/re-generation/signing and re-signing). Point taken, but let me come back on those later. The (non-technical) response : When I get in my car, I put my safety belt on. (I know some may point at undesired effects, and I do not want to have that discussion in this list), but the point is : I do hope I will never need the protection offered by the safety belt, but if, then I'll be happy I took the precaution. The similarity to DNSSEC is that we all hope we will not need the protection it offers, but if an attacker finds it interesting to attempt to exploit, I will be glad I took the precaution of activating DNSSEC. Speaking of course from my own lowly perspective, this thread (I started it) has made me much more cautious in proceeding with deployment of DNSSEC, and I am strongly considering disabling verification on my resolvers. How popular are these attacks against which DNSSEC offers protection ? From what I can see, my view being limited, the most 'effective', for lack of a better word, in 2011 were not DNS related. Social engineering, making people do something (click URL, open attachment) is a far more effective way, for attackers, to get their thing done. Does this mean we don't have to put the safety belt on ? I daresay : no. Your analogy is weak, because while a safety belt has only minor drawbacks, DNSSEC verification has been quite intrusive for me, and AFAIK only a source of problems, not benefits. (Granted, if there was a benefit, namely to be protected from hostile data, I wouldn't know the difference easily.) In a wreck wearing a safety belt, you may get bruised along the belt line, but afterwards you get to look up at the glass in front of you and not see where your gashed, bloody forehead struck. Clear cut trade, minor annoyance for significant benefit. Doing DNSSEC verification in 2012 is lopsided the other way. You cannot resolve the names you need sometimes. You're probably not receiving any actual protection from spoofing. Last night I was unable to check the weather forecast, because the fine folks at NOAA.gov / weather.gov broke their DNSSEC. Lo and behold today I see fresh RRSIG records. They only last a week. I suppose there are different classes of failures; unfortunately on the resolver, there is only one result, SERVFAIL, to cover all. It would be better if there was a way to distinguish the oops, admin bungled DNSSEC errors from the ones which are more likely to be indicative of spoofing. The hardest part of that might be to decide which is which. IME the one that bites us most often is that of the expired RRSIG. If we could log that but go ahead and accept the data, most of the pain would stop. If the KSK does not match the parent's DS, or if there is a DS but the zone is unsigned, maybe we are looking at a real attack. Still not likely, but more likely than the case of the expired RRSIG. Attackers constantly look for new ways, therefore if an attacker comes up with an approach that becomes popular because of ease/speed/effectiveness and that approach would have been prevented by DNSSEC, we would have been happy that we already deployed DNSSEC. I suppose, but then I don't really worry much, personally, about the kind of naughty things a DNS spoofer might do. I have no money, so giving them my bank credentials won't do them any good. :) To conclude (some technical) suggestions : - when offering DNSSEC on authoritative name servers, try to rely on automation (like scripts). (rather than humans to type - and re-type - the same commands over and over) - allow yourself a period of testing. Do *not* immediately have DS information put in the parent zone (thus completing the chain-of-trust but also : making validation mandatory. After all : this is a *test* period) ((look how TLDs migrate towards DNSSEC. Exactly the same : first offer DNSKEYs and RRSIGs, but no DS in the root-zone)) Agreed. - and may I also plead for validation on caching/forwarding name servers ? Because it makes no sense to add signatures that can be validated to DNS replies, if the signatures are simply ignored. At this point, those of us who do the validation are the ones who are suffering. I think we need something like a softfail, at least for expired RRSIGs. I don't know if it is possible to make that distinction, however. -- http://rob0.nodns4.us/ -- system administration and consulting Offlist GMX mail is seen only if /dev/rob0 is in the Subject: ___ Please visit
Re: lists.isc.org rDNS failed, DNSSEC?
On 2/28/12 9:26 AM, /dev/rob0 r...@gmx.co.uk wrote: On Tue, Feb 28, 2012 at 01:16:16PM +0100, Marc Lampo wrote: First of all : I do not deny DNSSEC adds a challenge for administrators. They must understand that adding this additional SECurity aspect, will generate extra work (keygeneration/re-generation/signing and re-signing). Similar to compiling, enabling, maintaining SSH when telnet always came enabled by default in inetd.conf. ;-) That's automatic these days. Speaking of course from my own lowly perspective, this thread (I started it) has made me much more cautious in proceeding with deployment of DNSSEC, and I am strongly considering disabling verification on my resolvers. Yes, I think timing is everything. How popular are these attacks against which DNSSEC offers protection ? From what I can see, my view being limited, the most 'effective', for lack of a better word, in 2011 were not DNS related. Social engineering, making people do something (click URL, open attachment) is a far more effective way, for attackers, to get their thing done. It wasn't just 2011, social engineering has always been a trump card. There are a lot of papers on spearphishing and the like (or watch Sneakers)... but, alas, that's another thread. Does this mean we don't have to put the safety belt on ? I daresay : no. Your analogy is weak, because while a safety belt has only minor drawbacks, DNSSEC verification has been quite intrusive for me, and AFAIK only a source of problems, not benefits. Well, sometimes... One drawback of a safety belt (being EMT trained) is that if you careen off a bridge (or end up in water some other way, it happens) the device sometimes malfunctions and you can't get out of the car. Drowning has always been one of my fears -- it's why I took swimming lessons early and avoided the Navy -- it's not a minor drawback for most. That said, they make $5 belt cutters you can keep in your glove box which mitigates this concern. The right tools can make all the difference. (Granted, if there was a benefit, namely to be protected from hostile data, I wouldn't know the difference easily.) snip Doing DNSSEC verification in 2012 is lopsided the other way. You cannot resolve the names you need sometimes. You're probably not receiving any actual protection from spoofing. I feel similarly. I do see risk in the non DNSSEC world (thanks to Kaminsky and others), but not so common or devastating to justify the cost and associated risks of deployment today. I think the right tools (inline signing!) will reduce TCO and generally make more folks jump onboard. Attackers constantly look for new ways, therefore if an attacker comes up with an approach that becomes popular because of ease/speed/effectiveness and that approach would have been prevented by DNSSEC, we would have been happy that we already deployed DNSSEC. I suppose, but then I don't really worry much, personally, about the kind of naughty things a DNS spoofer might do. I have no money, so giving them my bank credentials won't do them any good. :) For small shops or personal domains, it's ultimately up to the owner/administrator to decide... You are right, the risk may not be a concern at all in some cases. However, making it easier to do when the risk is present is somewhere I'm happy to see ISC making progress. -- I have never met a man so ignorant that I couldn't learn something from him. -- Galileo Galilei ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: lists.isc.org rDNS failed, DNSSEC?
I suppose there are different classes of failures; unfortunately on the resolver, there is only one result, SERVFAIL, to cover all. It would be better if there was a way to distinguish the oops, admin bungled DNSSEC errors from the ones which are more likely to be indicative of spoofing. I'd like to see an EDNS(0) option that returns a detailed explanation of how a SERVFAIL happened. (I intend to write that IETF draft when engineering work gets out of my way enough that I have time to do it.) But it won't help until clients learn how to request that option and do something useful with the result. The hardest part of that might be to decide which is which. IME the one that bites us most often is that of the expired RRSIG. If we could log that but go ahead and accept the data, most of the pain would stop. BIND has this: dnssec-accept-expired yes; Note that it opens you to replay attacks, but misconfigured zones are more common than replay attacks, for now anyway. -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: lists.isc.org rDNS failed, DNSSEC?
In message cb725c9f.24ec1%micho...@cisco.com, michoski writes: Doing DNSSEC verification in 2012 is lopsided the other way. You cannot resolve the names you need sometimes. You're probably not receiving any actual protection from spoofing. I feel similarly. I do see risk in the non DNSSEC world (thanks to Kaminsky and others), but not so common or devastating to justify the cost and associated risks of deployment today. I think the right tools (inline signing!) will reduce TCO and generally make more folks jump onboard. DNSSEC is also a enabling technology. SSH already takes advantage of it. The DANE working group of the IETF is defining how to authenticate CERTs using the DNS associated with a DNS name which is a much more natural way of doing this than using a CA. With DNSSEC it is possible to cryptographically secure SMTP and be able to detect m-i-m attacks. DNSSEC protects the MX records (explict or implict). This lets you securely know which machine you are supposed to be connecting to, by name, and hence which CERTs are valid with STARTTLS given that name. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: lists.isc.org rDNS failed, DNSSEC?
On Tue, Feb 28, 2012 at 06:28:54PM +, Evan Hunt wrote: the one that bites us most often is that of the expired RRSIG. If we could log that but go ahead and accept the data, most of the pain would stop. BIND has this: dnssec-accept-expired yes; Note that it opens you to replay attacks, but misconfigured zones are more common than replay attacks, for now anyway. Ah! Thanks. I should have checked thr ARM before posting. I guess I'll keep my validation on with this option, see how it goes. -- http://rob0.nodns4.us/ -- system administration and consulting Offlist GMX mail is seen only if /dev/rob0 is in the Subject: ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: lists.isc.org rDNS failed, DNSSEC?
There was a issues with the delegation of some zones. NS records were not added to the parent zone when they should have been but the scripts which sign the zones added DS records which caused the parent zone not to be resigned. The signatures for the parent zone eventually expired which caused resolution failures for all the children of the parent zone rather than just the zones with a broken delegation. The scripts that sign the zones did report the error but those reports were overlooked. Operations is looking at their proceedures and what additional checking can be done to prevent a repeat. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: lists.isc.org rDNS failed, DNSSEC?
On Thu, Feb 23, 2012 at 2:47 PM, Mark Andrews ma...@isc.org wrote: There was a issues with the delegation of some zones. NS records were not added to the parent zone when they should have been but the scripts which sign the zones added DS records which caused the parent zone not to be resigned. The signatures for the parent zone eventually expired which caused resolution failures for all the children of the parent zone rather than just the zones with a broken delegation. The scripts that sign the zones did report the error but those reports were overlooked. Operations is looking at their proceedures and what additional checking can be done to prevent a repeat. I've seen several places, mostly in .gov bitten by this one and I'll admit that it almost caught me, but the fact that the ISC tripped over this says volumes about how careful people have to be about handling details when DNSSEC is added. It simply can't be the set and forget DNS of the past, at least not until and unless tools become far more bullet-proof. -- R. Kevin Oberman, Network Engineer E-mail: kob6...@gmail.com ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
RE: lists.isc.org rDNS failed, DNSSEC?
I kind of had the same thought... If ISC had a DNS outage due to expired signatures of a zone, what chance do I have in successfully deploying and maintaining DNSSEC for my zones? Sure, everyone makes mistakes, but I think it speaks volumes to the inherent complexity and the further need for simplifying the maintenance of signed zones. I know that progress is continually being made on this front and I think others agree... Just pointing it out again. I have nothing against DNSSEC, personally. I'd love to deploy it. I just don't have the time to maintain it or worry about maintaining it right now. -Vinny -Original Message- From: bind-users-bounces+vinny_abello=dell@lists.isc.org [mailto:bind-users-bounces+vinny_abello=dell@lists.isc.org] On Behalf Of Kevin Oberman Sent: Thursday, February 23, 2012 6:21 PM To: Mark Andrews Cc: bind-us...@isc.org Subject: Re: lists.isc.org rDNS failed, DNSSEC? On Thu, Feb 23, 2012 at 2:47 PM, Mark Andrews ma...@isc.org wrote: There was a issues with the delegation of some zones. NS records were not added to the parent zone when they should have been but the scripts which sign the zones added DS records which caused the parent zone not to be resigned. The signatures for the parent zone eventually expired which caused resolution failures for all the children of the parent zone rather than just the zones with a broken delegation. The scripts that sign the zones did report the error but those reports were overlooked. Operations is looking at their proceedures and what additional checking can be done to prevent a repeat. I've seen several places, mostly in .gov bitten by this one and I'll admit that it almost caught me, but the fact that the ISC tripped over this says volumes about how careful people have to be about handling details when DNSSEC is added. It simply can't be the set and forget DNS of the past, at least not until and unless tools become far more bullet-proof. -- R. Kevin Oberman, Network Engineer E-mail: kob6...@gmail.com ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: lists.isc.org rDNS failed, DNSSEC?
On 2/23/12 8:48 PM, vinny_abe...@dell.com vinny_abe...@dell.com wrote: I kind of had the same thought... If ISC had a DNS outage due to expired signatures of a zone, what chance do I have in successfully deploying and maintaining DNSSEC for my zones? Sure, everyone makes mistakes, but I think it speaks volumes to the inherent complexity and the further need for simplifying the maintenance of signed zones. I know that progress is continually being made on this front and I think others agree... Just pointing it out again. I have nothing against DNSSEC, personally. I'd love to deploy it. I just don't have the time to maintain it or worry about maintaining it right now. Much agreed, though I want to point out that you should only generally deploy DNSSEC (or any new technology?) if the benefit outweighs the cost. Adopting new technology just because usually leads to trouble (or overworked admins that give up and go elsewhere). What's the potential risk to your organization if the mythical determined attacker is able to negatively or positively spoof resource records under your control? Maybe not much for you, maybe millions for financial orgs. If the potential cost to the organization is high enough... It will justify paying a team of folks to maintain DNSSEC. :-) That said, I too look forward to a day when security is easier and more automatic. Much progress has been made, and I have high hopes and faith in ISC and the DNS community at large. http://www.jnd.org/books.html -- Time is the coin of your life. It is the only coin you have, and only you can determine how it will be spent. Be careful lest you let other people spend it for you. -- Carl Sandburg ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: lists.isc.org rDNS failed, DNSSEC?
On Thu, Feb 23, 2012 at 9:00 PM, michoski micho...@cisco.com wrote: On 2/23/12 8:48 PM, vinny_abe...@dell.com vinny_abe...@dell.com wrote: I kind of had the same thought... If ISC had a DNS outage due to expired signatures of a zone, what chance do I have in successfully deploying and maintaining DNSSEC for my zones? Sure, everyone makes mistakes, but I think it speaks volumes to the inherent complexity and the further need for simplifying the maintenance of signed zones. I know that progress is continually being made on this front and I think others agree... Just pointing it out again. I have nothing against DNSSEC, personally. I'd love to deploy it. I just don't have the time to maintain it or worry about maintaining it right now. Much agreed, though I want to point out that you should only generally deploy DNSSEC (or any new technology?) if the benefit outweighs the cost. Adopting new technology just because usually leads to trouble (or overworked admins that give up and go elsewhere). What's the potential risk to your organization if the mythical determined attacker is able to negatively or positively spoof resource records under your control? Maybe not much for you, maybe millions for financial orgs. If the potential cost to the organization is high enough... It will justify paying a team of folks to maintain DNSSEC. :-) That said, I too look forward to a day when security is easier and more automatic. Much progress has been made, and I have high hopes and faith in ISC and the DNS community at large. http://www.jnd.org/books.html FWIW, we have been signing daily and rolling ZSKs every 2 weeks for over a year with no glitches at all, though we are using a non-BIND solution (Secure64) to do the signing. Still, it tells me that it is possible and I suspect that BIND 10 will move closer to that point. -- R. Kevin Oberman, Network Engineer E-mail: kob6...@gmail.com ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
