DNSSEC and Helicopters
This is a response to https://dyn.com/blog/is-dnssec-adoption-worth-it-for-enterprises/
I did not proof-read this. I will remove this sentence, and the one before it, when I have.
The article begins by specifically using the adjective "hype" to describe DNSSEC. That is done for a reason, to bias the reader.
It then goes into telling an anectdote completely unrelated to DNS and Internet infrastructure, an anectdote that can not even be verified as having happened at all, let alone judged for whether or not it is an accurate representation of what took place.
The story basically talks about a military program that was very successful at what it did but was cut because there was not a real world need to protect the skies from Helicopters.
The story doesn't make sense as told. As a young engineering student he describes himself as at the time of the alleged story, I do not see how he would have been privy to the reasons Generals had for cutting the alleged program. I suspect the program was far more likely cut due to cost considerations.
I know there is already military technology that does what is described, if the current technology is either cheaper to keep or superior, that would likely explain why the technology in the anectdote was not used. Without actually hearing from the Generals themselves, however, all we have is a guess or hear say from a self-described student at the time.
The anectdote really has nothing to do with DNSSEC and is not comparable. Alternative technology to defend against helicopters exists but alternative technology to DNSSEC really does not exist. There are DNS security solutions that provide partial specific solutions, but nothing like DNSSEC.
What does DNSSEC do? It provides a mechanism that leverages cryptography to validate that a DNS response has not been altered between the authoritative DNS server and the party requesting the record.
What are the alternatives?
DNSCrypt levarages cryptography to prevent alteration of the DNS response between the party requesting the record and the recursive resolver it was requested from, but it provides no mechanism by which the record can be validated against what is on the authoritative DNS server for the record.
DNS over TLS (DoT) is an alternative solution to DNSCrypt and basically does the same thing. It protects the query from being modified between the party requesting the record and the recursive resolver it was requested from, but provides no mechanism for validating the record was not modified elsewhere.
DNS over HTTPS (DoH) does the same thing as both DNSCrypt and DoT but uses HTTPS to communicate with the recursive resolver. And like those solutions, it provides no mechanism by which to verify the record is the same as what is on the authoritative DNS server.
MTA-STS leverages HTTPS and PKI infrastructure to validate the MX record. It does not so much validate the MX record itself as provide an alternate secured method of delivery for the contents of the MX record. MTA clients that enforce MTA-STS will then only accept an MX hostname that is an intersection of what is in the MX record and what is delivered over the HTTPS component of MTA-STS. So while it does not validate the MX record itself, it does mean that hosts specified in a forged MX record will be rejected unless the attacker has a means of altering the HTTPS component of MTA-STS, which requires either compromising the web server or obtaining a fraudulent x.509 certificate that PKI validates.
What DNSSEC does is provide a digital signature of the record being queried. The signature itself is a record. Here is an example:
deviant.email. 3600 IN MX 10 mail.deviant.email.
deviant.email. 3600 IN RRSIG MX 7 2 3600 20190203185751 20190106185751 44237 deviant.email. CIvv[snip for brevity]5IotAA==
The first entry shows an MX record. The second is an RRSIG record that contains a cryptographic signature of the MX record.
The public zone signing key for deviant.email can be used in combination with the signature to verify that the MX record has not been altered. DNSSEC is the only technology that provides that validation capability, at least that currently exists. It is conceivable that blockchain technology could also be levaraged to do this, though I have not heard of anyone working on it (Namecoin only uses blockchain to secure the IP address of the authoritative DNS server for a zone, it does not secure the records within the zone.)
There simply is not an existing alternative to DNSSEC that does what DNSSEC does, there are plenty of existing technologies for dealing with helicopters. So the helicopter anecdote does not fit DNSSEC.
-=-=-=-=-=-=-
After giving the invalid anectdote, the author then proceeds to comment that he has never had someone actually complain of a DNS-based MITM. He is trying to suggest that like Generals allegedly did not need technology to defend against helicopters, we do not need technology to defend against attacks on DNS responses.
I do not know what rock he is hiding under. It happens with some frequency on public wifi networks, such as hotels and coffee shops. In fact both Apple and Android make it easy by not allowing the user to specify the DNS server they use, they use whatever DNS server DHCP specifies.
Just do a search for DNS spoofing and DNS cache poisoning (they are same thing). The article was authored in 2018, there is no excuse for ignorance of those type of attacks.
After his ignorance regarding DNS cache attacks, the real reason for his dislike of DNSSEC is revealed:
``Sure, there are mechanisms to offer it from most modern DNS vendors and through common code bases such as BIND. If you’re looking to do DNS like it’s 1995, you’re fine. But throw in some traffic steering and multi-vendor redundancy? That’ll complicate things significantly.''
He wants to use flawed technology that does not lend itself well to DNSSEC. Rather than accept that his solutions to problems are not the right solutions to problems, he attacks those who do not use those solutions as doing DNS "like it's 1995".
The top hit for "Traffic Steering" was dyn.com, the same domain hosting his blog saying DNSSEC is not needed.
So what is traffic steering? It looks like a solution that allows dynamic altering of DNS responses based upon pre-defined parameters. Load balancing essentially. You can do that with DNSSEC, you just need a DNS server that signs responses on the fly, such as BIND. My guess is the company he works for does not do that. Rather than serve the security needs of their customers, this blog is being used to tell their customers they should not use it.
I will never use a company that uses deception to try and convince me that I do not need security.
For intellectual honesty clarity, I must disclose that I have a dislike for dynamic DNS. I believe it is the wrong solution to the problem. However, since I can not offer alternative solutions to the problems it solves, I must concede that if it solves a problem you have then it is the right solution at the present.
In my opinion it would be better if dyn.com would innovate better solutions rather than discourage DNSSEC. However given that DNSSEC does work with dynamic responses, I do not understand why they are discouraging DNSSEC instead of implementing it. Maybe they do not care about the security of their customers? That is speculation, but I am not capable of seeing another explanation.
Why I do not like dynamic DNS? It completely takes away the ability to cache DNS responses for any reasonable length of time. For low bandwidth users, cache life of an hour or so makes a website far more usable and outside the context of a high volume website, DNS responses rarely need to by dynamic.
To me it seems idiotic to sacrifice the security of something as important as an MX record for load balancing a website. Find a better way to load balance the website than sacrificing DNS security. Set long cache on static resources, use HTTP/2, make use of server-side SQL query caching, there are many things you can do with your web application design to reduce the need for load balancing. But I digress.
His article then says "The running joke among many network operations center workers is that more websites go offline from misconfigured DNSSEC than from the attacks DNSSEC protects against. I’m inclined to believe them."
It would be nice if he actually provided some statistics for it. He does have somewhat of a point though, if you mis-configure DNSSEC then your site may go offline for many users. The same thing happens when you mis-configure your web server. Of course it should be pointed out that failure caused by a mis-configuration does not result in a security breach, so even that comparison is rather worthless. I would rather have the occasional configuration error I can correct than the occasional attack that breaches security.
But how often does the mis-configuration causing loss of service actually happen? Not very often, and when a mis-configuration of DNSSEC happens, it is really easy to detect. Simply check to see if the signatures for the records validate.
How do you know if the signatures validate? Request the records from a DNSSEC enforcing recursive resolver. This is the default mode for unbound, or if for some reason you are not running your own DNSSEC recursive resolver, the Google public DNS resolvers (8.8.8.8 and 8.8.4.4) do enforce DNSSEC. Any system administrator can verify that DNSSEC is properly configured by using the `nslookup` or `dig` command (available on any *nix system) and specifying `8.8.8.8` or `8.8.4.4` as the nameserver. Running unbound locally though is preferred.
-=-
He then goes on to talk about the effets on traffic and budget. He claims there is a 300ms delay when a recursive resolver performs the initial validation. I have not benchmarked the delay nor do I really care to. Let's assume it is correct.
A 300ms delay is a third of a second. Once for the cache life of the record. If you are using dynamic DNS responses that instruct the server not to cache the response, maybe that is a problem. If you are correctly using DNS with a cache time of, say, an hour then it really is not a problem. If you are using a really short cache time, you already have a performance problem. The client has to do frequent DNS queries. Do not use short cache time and both problems are solved. See why I do not think dynamic DNS is a good solution? Design your web applications and infrastructure so that dynamic DNS is not needed. Do things the right way, do not sacrifice security so that you can do things the wrong way.
He then goes on to argue that only 14 percent of recursive resolvers enforce DNSSEC.
Honestly, I do not care what those statistics are. The biggest value in DNSSEC to me is server to server communication and every single data center I used in the last few years has DNSSEC enforcing recursive resolvers. Furthermore, it is very common for server admins to run their own copy of unbound listening on the localhost and by default, unbound enforces DNSSEC.
I highly doubt his 14 percent statistic applies to servers where there is a lot of value is securing the DNS responses they receive.
Further down, the article reads "If you decide to sign your zone, you will limit your options for traffic steering in DNS and/or your vendor selection."
Translation - if you secure your DNS, you can not our services because we are too stone-age to implement DNSSEC.
See what I did there? The same thing he did with arguing that DNS zones that don't use "advanced" features are 1995 era zones.
DNSSEC is an "advanced" feature. Use DNS correctly, and you can use DNSSEC today with little effort.
Other advancements in DNS will hopefully be made, I would like to see solutions that make load balancing easier with a static zone file. Those advancements should not come at the expense of security.
-=-=-=-=-
If you found this informative, $5.00 to https://www.paypal.me/pipfrosch would be appreciated.
I did not proof-read this. I will remove this sentence, and the one before it, when I have.
The article begins by specifically using the adjective "hype" to describe DNSSEC. That is done for a reason, to bias the reader.
It then goes into telling an anectdote completely unrelated to DNS and Internet infrastructure, an anectdote that can not even be verified as having happened at all, let alone judged for whether or not it is an accurate representation of what took place.
The story basically talks about a military program that was very successful at what it did but was cut because there was not a real world need to protect the skies from Helicopters.
The story doesn't make sense as told. As a young engineering student he describes himself as at the time of the alleged story, I do not see how he would have been privy to the reasons Generals had for cutting the alleged program. I suspect the program was far more likely cut due to cost considerations.
I know there is already military technology that does what is described, if the current technology is either cheaper to keep or superior, that would likely explain why the technology in the anectdote was not used. Without actually hearing from the Generals themselves, however, all we have is a guess or hear say from a self-described student at the time.
The anectdote really has nothing to do with DNSSEC and is not comparable. Alternative technology to defend against helicopters exists but alternative technology to DNSSEC really does not exist. There are DNS security solutions that provide partial specific solutions, but nothing like DNSSEC.
What does DNSSEC do? It provides a mechanism that leverages cryptography to validate that a DNS response has not been altered between the authoritative DNS server and the party requesting the record.
What are the alternatives?
DNSCrypt levarages cryptography to prevent alteration of the DNS response between the party requesting the record and the recursive resolver it was requested from, but it provides no mechanism by which the record can be validated against what is on the authoritative DNS server for the record.
DNS over TLS (DoT) is an alternative solution to DNSCrypt and basically does the same thing. It protects the query from being modified between the party requesting the record and the recursive resolver it was requested from, but provides no mechanism for validating the record was not modified elsewhere.
DNS over HTTPS (DoH) does the same thing as both DNSCrypt and DoT but uses HTTPS to communicate with the recursive resolver. And like those solutions, it provides no mechanism by which to verify the record is the same as what is on the authoritative DNS server.
MTA-STS leverages HTTPS and PKI infrastructure to validate the MX record. It does not so much validate the MX record itself as provide an alternate secured method of delivery for the contents of the MX record. MTA clients that enforce MTA-STS will then only accept an MX hostname that is an intersection of what is in the MX record and what is delivered over the HTTPS component of MTA-STS. So while it does not validate the MX record itself, it does mean that hosts specified in a forged MX record will be rejected unless the attacker has a means of altering the HTTPS component of MTA-STS, which requires either compromising the web server or obtaining a fraudulent x.509 certificate that PKI validates.
What DNSSEC does is provide a digital signature of the record being queried. The signature itself is a record. Here is an example:
deviant.email. 3600 IN MX 10 mail.deviant.email.
deviant.email. 3600 IN RRSIG MX 7 2 3600 20190203185751 20190106185751 44237 deviant.email. CIvv[snip for brevity]5IotAA==
The first entry shows an MX record. The second is an RRSIG record that contains a cryptographic signature of the MX record.
The public zone signing key for deviant.email can be used in combination with the signature to verify that the MX record has not been altered. DNSSEC is the only technology that provides that validation capability, at least that currently exists. It is conceivable that blockchain technology could also be levaraged to do this, though I have not heard of anyone working on it (Namecoin only uses blockchain to secure the IP address of the authoritative DNS server for a zone, it does not secure the records within the zone.)
There simply is not an existing alternative to DNSSEC that does what DNSSEC does, there are plenty of existing technologies for dealing with helicopters. So the helicopter anecdote does not fit DNSSEC.
-=-=-=-=-=-=-
After giving the invalid anectdote, the author then proceeds to comment that he has never had someone actually complain of a DNS-based MITM. He is trying to suggest that like Generals allegedly did not need technology to defend against helicopters, we do not need technology to defend against attacks on DNS responses.
I do not know what rock he is hiding under. It happens with some frequency on public wifi networks, such as hotels and coffee shops. In fact both Apple and Android make it easy by not allowing the user to specify the DNS server they use, they use whatever DNS server DHCP specifies.
Just do a search for DNS spoofing and DNS cache poisoning (they are same thing). The article was authored in 2018, there is no excuse for ignorance of those type of attacks.
After his ignorance regarding DNS cache attacks, the real reason for his dislike of DNSSEC is revealed:
``Sure, there are mechanisms to offer it from most modern DNS vendors and through common code bases such as BIND. If you’re looking to do DNS like it’s 1995, you’re fine. But throw in some traffic steering and multi-vendor redundancy? That’ll complicate things significantly.''
He wants to use flawed technology that does not lend itself well to DNSSEC. Rather than accept that his solutions to problems are not the right solutions to problems, he attacks those who do not use those solutions as doing DNS "like it's 1995".
The top hit for "Traffic Steering" was dyn.com, the same domain hosting his blog saying DNSSEC is not needed.
So what is traffic steering? It looks like a solution that allows dynamic altering of DNS responses based upon pre-defined parameters. Load balancing essentially. You can do that with DNSSEC, you just need a DNS server that signs responses on the fly, such as BIND. My guess is the company he works for does not do that. Rather than serve the security needs of their customers, this blog is being used to tell their customers they should not use it.
I will never use a company that uses deception to try and convince me that I do not need security.
For intellectual honesty clarity, I must disclose that I have a dislike for dynamic DNS. I believe it is the wrong solution to the problem. However, since I can not offer alternative solutions to the problems it solves, I must concede that if it solves a problem you have then it is the right solution at the present.
In my opinion it would be better if dyn.com would innovate better solutions rather than discourage DNSSEC. However given that DNSSEC does work with dynamic responses, I do not understand why they are discouraging DNSSEC instead of implementing it. Maybe they do not care about the security of their customers? That is speculation, but I am not capable of seeing another explanation.
Why I do not like dynamic DNS? It completely takes away the ability to cache DNS responses for any reasonable length of time. For low bandwidth users, cache life of an hour or so makes a website far more usable and outside the context of a high volume website, DNS responses rarely need to by dynamic.
To me it seems idiotic to sacrifice the security of something as important as an MX record for load balancing a website. Find a better way to load balance the website than sacrificing DNS security. Set long cache on static resources, use HTTP/2, make use of server-side SQL query caching, there are many things you can do with your web application design to reduce the need for load balancing. But I digress.
His article then says "The running joke among many network operations center workers is that more websites go offline from misconfigured DNSSEC than from the attacks DNSSEC protects against. I’m inclined to believe them."
It would be nice if he actually provided some statistics for it. He does have somewhat of a point though, if you mis-configure DNSSEC then your site may go offline for many users. The same thing happens when you mis-configure your web server. Of course it should be pointed out that failure caused by a mis-configuration does not result in a security breach, so even that comparison is rather worthless. I would rather have the occasional configuration error I can correct than the occasional attack that breaches security.
But how often does the mis-configuration causing loss of service actually happen? Not very often, and when a mis-configuration of DNSSEC happens, it is really easy to detect. Simply check to see if the signatures for the records validate.
How do you know if the signatures validate? Request the records from a DNSSEC enforcing recursive resolver. This is the default mode for unbound, or if for some reason you are not running your own DNSSEC recursive resolver, the Google public DNS resolvers (8.8.8.8 and 8.8.4.4) do enforce DNSSEC. Any system administrator can verify that DNSSEC is properly configured by using the `nslookup` or `dig` command (available on any *nix system) and specifying `8.8.8.8` or `8.8.4.4` as the nameserver. Running unbound locally though is preferred.
-=-
He then goes on to talk about the effets on traffic and budget. He claims there is a 300ms delay when a recursive resolver performs the initial validation. I have not benchmarked the delay nor do I really care to. Let's assume it is correct.
A 300ms delay is a third of a second. Once for the cache life of the record. If you are using dynamic DNS responses that instruct the server not to cache the response, maybe that is a problem. If you are correctly using DNS with a cache time of, say, an hour then it really is not a problem. If you are using a really short cache time, you already have a performance problem. The client has to do frequent DNS queries. Do not use short cache time and both problems are solved. See why I do not think dynamic DNS is a good solution? Design your web applications and infrastructure so that dynamic DNS is not needed. Do things the right way, do not sacrifice security so that you can do things the wrong way.
He then goes on to argue that only 14 percent of recursive resolvers enforce DNSSEC.
Honestly, I do not care what those statistics are. The biggest value in DNSSEC to me is server to server communication and every single data center I used in the last few years has DNSSEC enforcing recursive resolvers. Furthermore, it is very common for server admins to run their own copy of unbound listening on the localhost and by default, unbound enforces DNSSEC.
I highly doubt his 14 percent statistic applies to servers where there is a lot of value is securing the DNS responses they receive.
Further down, the article reads "If you decide to sign your zone, you will limit your options for traffic steering in DNS and/or your vendor selection."
Translation - if you secure your DNS, you can not our services because we are too stone-age to implement DNSSEC.
See what I did there? The same thing he did with arguing that DNS zones that don't use "advanced" features are 1995 era zones.
DNSSEC is an "advanced" feature. Use DNS correctly, and you can use DNSSEC today with little effort.
Other advancements in DNS will hopefully be made, I would like to see solutions that make load balancing easier with a static zone file. Those advancements should not come at the expense of security.
-=-=-=-=-
If you found this informative, $5.00 to https://www.paypal.me/pipfrosch would be appreciated.
Comments
Post a Comment