You probably may have read an influential blog post Against DNSSEC and another one that follows it 14 DNS Nerds Don't Control The Internet by Thomas H. Ptacek and may have dismissed DNSSEC as unnecessary. I am calling it influential since this blog post comes up frequently at any debates that you may find online regarding DNSSEC, is listed in wiki articles, and also had an influence on me. If you haven't read both of them, I would highly recommend that you read them before reading this blog post to help to understand a lot of context. There is also a FAQ blog post for the original Against DNSSEC blog post that is also recommended to be read. There is also a recent Twitter thread by Thomas H. Ptacek which is a good read.
You may also like to read this recent Mastodon thread by Rich Felker who argues for DNSSEC and also an old For DNSSEC blog post by Zach Lym which is a rebuttal to the "Against DNSSEC" blog post.
In this blog post, based on my experience of implementing DNSSEC, I am attempting to make an argument for DNSSEC taking points from the original Against DNSSEC blog post while comparing it with Public Key Infrastructure (PKI), and make a case for DNS-based Authentication of Named Entities (DANE) adoption.
Note that DNSSEC and DANE are an alternative to PKI system and both of them use the same Transport Layer Security (TLS) for security.
But First, What Is DANE?
Before discussing DNSSEC, lets take a look at DANE to better understand the arguments being made. Many people know about DNSSEC but are unaware about DANE and even when they are aware, they do not know about its features or have misconceptions about it. Lets see what DANE is about in brief.
- DANE is an alternative for the PKI system that can co-exists with it. DANE uses TLSA resource record in the DNS which can include hash values for a PKI certificate or the hash value of its public key component. DANE TLSA records are signed by DNSSEC and are validated by clients before connecting to the TLS service. Implementing DANE support does not mean removing PKI support for any software or service. Which means, a website can implement PKI certificate, or DANE, or both together.
- The TLSA record can contain a full certificate but the common usage is to just store the hash values for either the full certificate or just the public key so as to prevent IP fragmentation of the UDP DNS response.
-
DANE provides 4 modes of operation
by publishing a TLSA record for a domain name:
- PKIX-TA: This mode allows specifying which 3rd party PKI Certificate Authorities (CA) are allowed to issue certificates for the service the client is connecting to. The client also needs to perform PKI certificate chain validation. This may look similar to the CAA record but is actually validated by the client before making the TLS connection. Whereas CAA record is checked by a CA to know if they are allowed to issue a certificate for the domain name to prevent mis-issuance.
- PKIX-EE: This mode allows specifying the end entity certificate, that is, the certificate deployed by the service. The client has to match the received certificate with DANE TLSA record and also perform usual PKI certificate chain validation.
- DANE-TA: This mode allows specifying a Trust Anchor for a CA certificate that may not be listed in the client's collection of installed certificates. Using this, an enterprise running their own internal root CA can be validated by the clients without requiring to install the root CA certificate locally. The client is required to perform PKI certificate chain validation below the specified Trust Anchor.
- DANE-EE: This is known as "domain-issued certificate" since it allows for a domain owner to issue a certificate for a service without involving a 3rd party CA. The TLS certificate on the service must match with the DANE TLSA record and PKI certificate chain validation is not required to be performed by the client.
- When using DANE-EE mode, its possible for a web server to host one or more web sites with a single TLS self-signed certificate. This is since, the domain in the URL is not matched with the subject in the certificate for DANE-EE but only the certificate or its public key is validated. This means that a web browser supporting DANE does not technically need to include a Server Name Indication (SNI) extension in the TLS handshake with DANE-EE and thus there is no need for using Encrypted Client Hello (ECH), a new extension that is being standardized, for such a deployment.
- The most useful feature of DANE that PKI cannot provide is that it protects email by ensuring that SMTP protocol uses TLS preventing downgrade attacks. Websites can be authenticated based on the CA certificate that was issued for the domain name but, such mechanism does not work with email since SMTP uses opportunistic encryption (STARTTLS) which an on-path attacker can easily downgrade to force transmission of email in plain text. When a domain owner deploys DANE for their email gateways, the sender can validate the DANE TLSA record and will attempt to send email only with TLS (STARTTLS) after ensuring that the certificate received is valid as per DANE TLSA record.
Is DNSSEC Unnecessary?
All secure crypto on the Internet assumes that the DNS lookup from names to IP addresses are insecure. Securing those DNS lookups therefore enables no meaningful security. DNSSEC does make some attacks against insecure sites harder. But it doesn’t make those attacks infeasible, so sites still need to adopt secure transports like TLS. With TLS properly configured, DNSSEC adds nothing.
- Against DNSSEC
If the secret DNSSEC keys leaked on Pastebin tomorrow, it’s unlikely that anything would break.
- 14 DNS Nerds Don't Control The Internet
This argument is kind of true at the moment since DNSSEC is not being effectively used as its is not mass adopted yet for various reasons. While all of the web today is protected by PKI despite a lot of problems with it.
There are hundreds of Root Certificate Authorities (CA) that are trusted by major web browsers and Operating Systems. Many of them are based in countries of questionable intent. A single compromised CA is capable of issuing certificates for any domain name, allowing Man In The Middle (MITM) attacks that effectively makes the entire PKI system fragile.
The most recent example being a little known Panama registered company called TrustCor Systems which was a root CA trusted by major web browsers, that has ties with U.S. intelligence and law enforcement. Not just that, they have been accused of distributing malware SDK in Google Play Store. This revelation caused it to be dropped by Mozilla and Microsoft recently. This is not a first instance of such a compromise but only a recent one.
Another popular example is that of DigiNotar discovered in 2011 which clearly indicates that this has been a known and unfixed issue since a long time.
There are several problems with how Domain Validated (DV) certificates are issued. Earlier, the most common way to issue a DV certificate was to verify email address for the domain name while the SMTP protocol used to send email, was itself known to be insecure. The current popular method uses plain text HTTP challenge or DNS challenge to prove domain name ownership where you need to prove that you either control port 80 with HTTP protocol for the domain name, or that you can add a TXT record in DNS for it. No matter what method is used, it ultimately depends upon DNS infrastructure in one way or the other for verification.
You don't have to be NSA or GCHQ to be able to acquire a DV certificate for a domain name. An attacker in position of being on-path, that is, between the CA and the domain owner's DNS or web server will be able to get himself issued a DV certificate. This is not an imaginary scenario and such kind of attacks have already occurred that used BGP attacks and could have been prevented with DNSSEC and DANE. Yes, contrary to what is believed, DNSSEC with DANE is not affected by BGP attacks. This is due to the fact that even if the attacker is able to hijack your IP addresses, they still do not have access to the DNSSEC private keys to be able to break DANE. Whereas, in the mentioned attack, the attackers were able to obtain new TLS certificates from a CA using the hijacked IP addresses.
Is DNSSEC A Government-Controlled PKI?
To understand this, you need to know who controls the private keys used to sign the zone. The Root zone is managed by ICANN and they hold the keys and organize Root Signing Ceremony to ensure transparency. The Root zone signs DS records for each signed Top-level Domain (TLD) that holds the hash value of their public keys published as DNSKEY records in the DNS.
The TLD zone's private keys are managed by the company operating it. For a Country Code Top-Level Domain (ccTLD), the government of the country will be managing the key. For popular TLDs like .COM or .NET, it will be the U.S. government through the operator Verisign. For popular ccTLD .IO, it is the government of British Indian Ocean Territory.
The private keys for an individual domain name are managed by the domain owner either directly or via the DNS provider hosting their domain name.
With DNSSEC, it is pretty clear who controls the private keys and also keeps the risks involved distributed. Which means while China holds private keys for .cn ccTLD, it can only sign domain names under it.
With PKI, any Root CA can sign a certificate for any domain name. And there are hundreds of such Root CA that you have never heard of that your web browser trusts. And to add to that, your ISP or the network operator, that you run your web server with can get a DV certificate issued for your domain name easily using HTTP challenge which you may never know of unless you manually check using Certificate Transparency logs. PKI system is open to all kinds of attackers in position to exploit it.
Its possible for a government that runs a ccTLD to get a DV certificate issued irrespective of DNSSEC status of the ccTLD. I mean, they control the parent ccTLD zone and can easily answer with name server (NS) delegation records of their choice when a CA is trying to validate domain ownership.
Had DNSSEC been deployed 5 years ago, Muammar Gaddafi would have controlled BIT.LY’s TLS keys.
- Against DNSSEC
Libya has no authority over BIT.LY’s TLS certificates.
- Questions and Answers from "Against DNSSEC"
When Muammar Gaddafi was alive, he controlled BIT.LY already and could have easily managed to get a DV certificate issued for himself if he wanted to. So, the argument that he had no authority over BIT.LY's TLS certificate is invalid since he could have had a valid DV certificate issued for any use he wished.
The Thomas H. Ptacek's FAQ blog post accepts that the PKI system is broken and needs to be replaced, but argues that DNSSEC is not better while suggesting solutions like Key Pinning that can fix issues with the CA system. The Key Pinning system however has been obsoleted in favor of Certificate Transparency due to several issues with it.
It needs to be understood clearly by everyone that DNS is a government controlled naming system by definition. Whereas, PKI is controlled by private companies all over the world and thus controlled by them, their governments, and any attacker on the network able to get a DV certificate issued. DNSSEC limits the control to only the governments who already and anyways have been controlling the DNS system. Political problems cannot be solved with technical solutions.
Is DNSSEC Cryptographically Weak?
The original DNSSEC design is two decades old; the first drafts I can find are from 1994. Real-world DNSSEC therefore relies on RSA with PKCS1v15 padding. The deployed system is littered with 1024-bit keys.
No cryptosystem created in 2015 would share DNSSEC’s design. A modern PKI would almost certainly be based on modern elliptic curve signature schemes, techniques for which have coalesced only in the last few years.
- Against DNSSEC
The original article Against DNSSEC was published in 2015 and it was true that DNSSEC was littered with 1024 bit RSA keys. Today, the Root zone and most TLDs use 2048 bit keys but you may still find some domain names using 1024 bit Key Signing Keys (KSK). The Zone Signing Keys (ZSK) for many domain names still use 1024 bit keys to reduce the size of DNS response but these keys are very frequently changed.
DNSSEC now supports RSA, ECDSA P-256, ECDSA P-384, Ed25519, and Ed448 algorithms of which ECDSA P-256 is the second most (45%) popularly deployed algorithm after RSA (51%). RSA with a sufficient key size still has no issues and experts say that quantum attacks against it are very much exaggerated.
Applications like web browsers already display warning messages for certificate issues which can be similarly used when implementing DANE where a user will see warning when the website using DANE uses weak key sizes or algorithms. This would in effect force the domain owners to increase the key size to make the warnings go away.
Is DNSSEC Expensive To Adopt?
Today, DNS lookups either succeed or fail. And there are generally two reasons a lookup fails: the name doesn’t exist, or the requestor lacks connectivity to the Internet. Network software is built around those assumptions.
DNSSEC changes all of that. It adds two new failure cases: the requestor could be (but probably isn’t) under attack, or everything is fine with the name except that its configuration has expired. Virtually no network software is equipped to handle those cases.
- Against DNSSEC
The original argument is that DNSSEC adds two new failure cases for DNS where you cannot be sure of the reason when a domain name does not resolve. It can be that there are network failures, or it can be that there is an active attack causing DNSSEC validation failure. An application like a web browser wont be able to know the exact reason to display to the user in such cases.
However, there is a solution available currently for this problem called Extended DNS Errors (RFC 8914). This standard adds a reasoning for why the response has failed and can clearly indicate the underlying issue. A DNS client implementation can thus easily find out the exact reason for failure and any software implementation can provide correct failure description to the user. This has already been deployed by DNS providers like Cloudflare and by many DNS Server software vendors. You can test it out using this online DNS Client website which will show you the exact Extended DNS Error that was received for the given test domain name.
Many web browsers have started to include a built-in DNS client to support encrypted DNS protocols like DNS-over-HTTPS. There is even a recommendation to include a DNS client with caching support to implement the new SVCB and HTTPS DNS resource records that are being deployed. For web browsers to include support for DANE, they simply need to use this already available built-in DNS client and include DNSSEC validation for it. Using DNSSEC validation combined with Extended DNS Errors, the web browser will now be in a position to show the correct failure messages to the user.
Is DNSSEC Expensive To Deploy?
DNSSEC is harder to deploy than TLS. TLS is hard to deploy (look how many guides sysadmins and devops teams write to relate their experience doing it). It’s not hard to find out what a competent devops person makes. Do the math.
- Against DNSSEC
DNSSEC used to be hard to deploy due to lack of tooling available. Today, a lot of DNS providers support DNSSEC that a domain name owner can enable just by clicking a single button. The DNS server project that I maintain can enable DNSSEC in just a few clicks.
To be clear, using managed DNS services means that the private keys are managed by the DNS provider directly and are not in the domain owner's exclusive control. Though this is no different from the current PKI scenario where a lot of managed hosting providers do the same by automatic certificate provisioning and have access to your certificate's private keys. A lot of CDN network providers already deploy certificates on behalf of their clients by default and thus hold their private keys too.
If a domain owner wants to keep the private keys in its control, be it DNSSEC keys or PKI certificate keys, they have to manage their own servers. Deploying DNSSEC is similar to deploying PKI certificate if not harder. With DNSSEC, its even possible for the domain name owner to maintain an independent, hidden primary DNS server which holds the DNSSEC private keys and then publish the pre-signed zone safely to 3rd party secondary DNS servers that actually answer the DNS queries for the domain name.
Is DNSSEC Incomplete?
You’d think, for all its deployment expense, the forklifting out of incompatible networking code, and the required adoption of a government PKI running 1990s crypto, DNSSEC would at least nail its marginally valuable core use case.
Nope.
DNSSEC doesn’t secure browser DNS lookups.
In fact, it does nothing for any of the “last mile” of DNS lookups: the link between software and DNS servers. It’s a server-to-server protocol.
- Against DNSSEC
The original argument is that DNSSEC validation is not done at the client end point is practically true base on how things are usually deployed. Any implementation of DNSSEC validation is usually done at the DNS resolver level and client end points just trust the configured resolver by their network provider.
But, DNSSEC validation is indeed end-to-end and not server-to-server like its believed. Nothing prevents a web browser to include a built-in DNS client that does DNSSEC validation and then use it to add support for DANE. Web browsers today have already added support for encrypted DNS protocols like DNS-over-HTTPS so its very much feasible to include DNSSEC validation support with it.
Is DNSSEC Unsafe?
DNSSEC builds on the original DNS database. So applications will need to distinguish between secure DNSSEC records and or insecure DNS records. To solve this problem, DNSSEC provides a cryptographically-secure “no such host” response.
But DNSSEC is designed for offline signers; it doesn’t encrypt on the fly. Meanwhile, there are infinite nonexistent hostnames. But all you can sign offline are the hostnames that do exist. So to provide authenticated denial, those signed records “chain”. You cryptographically verify that a record doesn’t exist by observing that no other record chains to it.
- Against DNSSEC
The argument that DNSSEC exposes all the sub domain names in a zone is valid. This can be an issue for some deployments while can be a non-issue for others.
DNSSEC can sign records that exists but to prove non-existence of a sub domain name or a record requires a solution like NSEC and NSEC3 that chains all sub domain names to prove that a name does not exists between given two sorted names in the chain. With NSEC, all the sub domain names are available in clear text while using NSEC3, the names are hashed but an attacker with sufficient resources can crack the hashes to find out the original names.
But, there is already a solution available to this problem that requires online DNSSEC key signing feature where the DNS server generates "white lies" or "compact lies" NSEC records on the fly to prove non-existence of a name and thus does not expose all the sub domain names in a zone.
This is also not an unique issue with DNSSEC. The Certificate Transparency system that is deployed today already exposes all your domain names that you have issued a certificate for. You can check this publicly available data using websites like crt.sh for your domain names.
Is DNSSEC Architecturally Unsound?
A casual look at the last 20 years of security history backs this up: effective security is almost invariably application-level and receives no real support from the network itself.
- Against DNSSEC
If an application like a web browser wants to add support for DANE with its own DNSSEC validation then it will be doing end-to-end validation and wont be relying on anything else.
Can’t end-systems validate DNSSEC records themselves rather than trusting servers?
Sure they can. Everyone can also just run their own caching server. They don’t, though, because the protocol was designed with the expectation that they wouldn’t (this squares with the overall design of the DNS, in which stub resolvers cooperate to reduce traffic to DNS authority servers by relying on caching servers). DNSSEC deployment guides go so far as to recommend against deployment of DNSSEC validation on end-systems. So significant is the inclination against extending DNSSEC all the way to desktops that an additional protocol extension (TSIG) was designed in part to provide that capability.
- Questions and Answers from "Against DNSSEC"
A web browser with a built-in DNS client that is capable of DNSSEC validation is very much feasible. This does not require anyone to run their own caching server either. DNS is distributed and cached at all levels which means a lot of home users with WiFi routers are hitting the DNS cache on the router itself when they query DNS. Also, as already mentioned, the new SVCB and HTTPS DNS record standard recommends clients to have support for caching to improve performance.
The claim that TSIG was designed as an alternative to DNSSEC or "to extending DNSSEC all the way to desktops" is also incorrect. TSIG was designed to allow performing authenticated Dynamic Updates, zone transfer, and queries to recursive name serves in limited scenarios. TSIG is not deployed to end-systems at scale anywhere and nobody is planning for it either. TSIG only provides transaction authentication while DNSSEC provides integrity which are completely different properties to be interchanged.
How can DNSSEC be hard to deploy? Isn’t it easier than TLS?
This site tracks DNSSEC outages. The most important DNS zones on the Internet don’t seem to be able to get it right. What makes us believe that the IT department of, say, the country’s 13th biggest insurance firm will do better?
- Questions and Answers from "Against DNSSEC"
It is true that this is one of the issues with DNSSEC where a TLD having DNSSEC outage can cause all domain names under it to fail to validate. But website outages due to invalid PKI certificate issues is like extremely common and has occurred too many times to even keep track of and thus no different.
The solution to DNSSEC outage issues is better tooling and automation that can prevent a DNS operator from making mistakes.
Can’t DNSSEC support Elliptic Curve as well as RSA?
DNSSEC has little-used support for ECDSA using the NIST P-256 curve. The roots and TLDs, upon which the security of the rest of the DNSSEC hierarchy depends, don’t use it. And according to APNIC, in a post cautioning operators not to use ECC DNSSEC, fully 1/3rd of DNSSEC-validating resolvers can’t handle ECDSA signatures.
- Questions and Answers from "Against DNSSEC"
DNSSEC today also supports Ed25519 and Ed448 in addition to RSA and ECDSA algorithms. While it is true that a lot of resolvers do not support all algorithms but if an application like a web browser wants it, it can add its own DNSSEC validation with support for all algorithms. Note that DNSSEC validation can be done end-to-end at the application level and is not limited by what algorithm the resolver on the network, or DNS stub resolver in home WiFi router supports.
Does MTA-STS Replace DNSSEC And DANE?
The other thing DNSSEC can theoretically do on an all-HTTPS Internet is help ensure that SMTP connections use TLS: downgrade attacks on SMTP are something people worry about. But the major mail providers came up with MTA-STS, which works like HSTS, to replace DNSSEC.
- Thomas H. Ptacek on Twitter
SMTP MTA Strict Transport Security (MTA-STS) is a technology similar to HTTP Strict Transport Security (HSTS) where an email gateway can discover and cache a strict transport security policy for each domain name for sending outbound emails. This is where the similarities end.
While HSTS relies on "HSTS preloaded list", which is a list of domain names that a web browser has preloaded and can also add a domain name to its list when an user simply navigates to a website with a "https://" scheme in its URL with a HSTS header in response, there is no such mechanism available for MTA-STS. This is because with email, there is no concept of an URL and thus no concept of an URL scheme that an user can enter while sending an email. An user simply enters an email address of the recipient in their email client and sends the email not knowing how the message will get routed to the destination.
The fundamental problem with MTA-STS is that it relies upon the DNS to discover the MTA-STS policy. If not for DNSSEC, an attacker who can control DNS protocol at the network level of the outbound email gateway can easily foil any protection that MTA-STS aims to provide. In fact, MTA-STS was invented so that an attacker at the network level is prevented from performing downgrade attack but the same attacker can control DNS too in many cases.
The first attack an adversary controlling DNS can perform on MTA-STS is to filter any TXT requests for "_mta-sts.example.com", where "example.com" is the domain name of the email recipient. This would prevent the outbound email gateway from being able to discover MTA-STS policy that is being published for the recipient's mail exchange (MX) servers. With this attack, the entire MTA-STS security is foiled and the attacker can perform Man in the Middle attack on the outbound SMTP connection and perform downgrade attack for STARTTLS command.
The second attack can foil protection that MTA-STS intends to provide when a security policy for a domain name is already in cache of the outbound email gateway.
If a valid TXT record is found but no policy can be fetched via HTTPS (for any reason), and there is no valid (non-expired) previously cached policy, senders MUST continue with delivery as though the domain has not implemented MTA-STS.
- RFC 8461 Section 3.3
With such an implementation that follows the RFC, all an attacker has to do is block the domain name "mta-sts.example.com" from being resolved so that the email gateway fails to download the policy from the standard "https://mta-sts.example.com/.well-known/mta-sts.txt" well known URL. The attacker now just has to wait for the previously cached policy to expire after which the email gateway will continue delivering pending emails as though the domain has not implemented MTA-STS as per the RFC's requirements.
This second attack is very much feasible considering the "max age" published by many services is inadequate. For example, the "max age" value published by Google for Gmail is just 86400 seconds (1 day). Comparing that to HSTS, the domain "mail.google.com" uses "strict-transport-security: max-age=10886400; includeSubDomains" header which has max age set to 10886400 seconds (126 days). Websites publishing max age for HSTS as large as 6 months or 1 year is quite common.
Combining both the attacks, any protection that MTA-STS provides can be effectively defeated. The only defense that is available is with logging and using SMTP TLS Reporting which is expected to be configured with MTA-STS by the recipient's email administrator. The email gateway sending the outbound email is expected to send a report of failures to the receiving email gateway's administrators using either HTTPS or email transport.
A report via email transport is useless in such cases since an attacker capable of performing downgrade attack can be expected to filter this report email too. Thus the only secure transport for the report is HTTPS which not everyone would have configured, for example, Gmail has configured email transport (v=TLSRPTv1;rua=mailto:sts-reports@google.com). A receiver of such a report is also not capable of doing anything to fix the security issues at the sender's end. The administrator of the sender's email gateway is expected to watch out for logs/alerts and try to fix them.
Clearly, MTA-STS is not in a position to be a replacement for DNSSEC and DANE.
"Disadvantages of DNSSEC"
The DNS Institute has published DNSSEC Guide which discusses "Disadvantages of DNSSEC" which I believe are no longer valid today but are still believed by many people.
-
Increased, well, everything: With DNSSEC, signed zones are larger, thus taking up more disk space; for DNSSEC-aware servers, the additional cryptographic computation usually results in increased system load; and the network packets are bigger, possibly putting more strains on the network infrastructure.
Disk space and computing power surely was an issue in 1990s or early 2000s but its 2023 and is a non-issue today. There is Extension Mechanisms for DNS (EDNS(0)) which is a required feature for implementing DNSSEC. EDNS(0) allows a DNS request over UDP protocol to be greater than the 512 bytes limit it earlier had. This makes it feasible to transport DNSSEC related records without issues for most use-cases. Even when a response does not fit into UDP and requires retransmission over TCP, its important to remember that any DNS response that was received is cached and thus is reused many times before it expires.
- "Disadvantages of DNSSEC" -
Different security considerations: DNSSEC addresses many security concerns, most notably cache poisoning. But at the same time, it may introduce a set of different security considerations, such as amplification attack and zone enumeration through NSEC. These new concerns are still being identified and addressed by the Internet community.
Amplification attack has nothing to do with DNSSEC specifically. These are already possible without DNSSEC with just plain old DNS. There are already mitigations against such attacks like query rate limiting and dropping known amplification requests. Zone enumeration through NSEC already has more than one solutions like using NSEC3 or using online signing with "white lies" or "compact lies".
- "Disadvantages of DNSSEC" -
More complexity: If you have read this far, you probably already concluded this yourself. With additional resource records, keys, signatures, rotations, DNSSEC adds a lot more moving pieces on top of the existing DNS machine. The job of the DNS administrator changes, as DNS becomes the new secure repository of everything from spam avoidance to encryption keys, and the amount of work involved to troubleshoot a DNS-related issue becomes more challenging.
Any technology adds complexity with it. Even PKI adds complexity which everyone has become accustomed with. DNSSEC is solving a complex problem and no one has yet come up with a better/easier way to solve the same problem that DNSSEC does. There are better tooling options already available that makes DNS administrator's job easier.
- "Disadvantages of DNSSEC" -
Increased fragility: The increased complexity means more opportunities for things to go wrong. In the absence of DNSSEC, DNS was essentially "add something to the zone and forget". With DNSSEC, each new component - re-signing, key rollover, interaction with parent zone, key management - adds more scope for error. It is entirely possible that the failure to validate a name is down to errors on the part of one or more zone operators rather than the result of a deliberate attack on the DNS.
The re-signing, key rollover, interaction with parent zone, key management, etc. tasks are already automated and require limited intervention. In fact, I am managing my signed zones by just adding some records to the zone and just forgetting about it.
- "Disadvantages of DNSSEC" -
New maintenance tasks: Even if your new secure DNS infrastructure runs without any hiccups or security breaches, it still requires regular attention, from re-signing to key rollovers. While most of these can be automated, some of the tasks, such as KSK rollover, remain manual for the time being.
KSK rollover is a manual task but its usually done just once a year and there is no expiry date attached to it like a TLS certificate. There are mechanisms like CDS/CDNSKEY currently being worked on to automate it too. Remember that before Let's Encrypt CA was available, everyone were used to buying TLS certificates from various CA, manually renewing them every year, and replacing the certificates on each and every web server/email gateway that was deployed. This also caused extremely common issue with expired certificates which is not a case with DNSSEC.
- "Disadvantages of DNSSEC" -
Not enough people are using it today: while it's estimated as of late 2016, that roughly 28% of the global Internet DNS traffic is validating [5] , that doesn't mean that many of the DNS zones are actually signed. What this means is, if you signed your company's zone today, only less than 30% of the Internet users are taking advantage of this extra security. It gets worse: with less than 1% of the .com domains signed, if you enabled DNSSEC validation today, it's not likely to buy you or your users a whole lot more protection until these popular domains names decide to sign their zones.
DNSSEC adoption is increasing and the reasoning that not enough people use it so you should not bother is a weak argument. If 1/3 users worldwide are validating DNSSEC then it still makes sense to sign your domain names. It does not matter how many % of .com domain names are signed, what matters is that your domain names are signed and that many of your users do DNSSEC validation.
- "Disadvantages of DNSSEC"
Conclusion
It has taken a more than a decade for DNSSEC to be designed (and redesigned) and the root zone being signed. It has been more than a decade that root zone is signed and yet not all TLDs are signed. DNSSEC adoption is low but has been steadily increasing in last few years. The low adoption rate is simply due to not many applications that implement it. Having popular applications like web browsers adopt DNSSEC and DANE will result in significantly increase the adoption rate. Many website would then start supporting PKI combined with DANE which will immediately have an impact.
DANE surely wont displace the PKI system completely but there will be an alternative option available for everyone which includes being able to deploy both PKI and DANE together. This will allow people to decide on their own if they want to use PKI, DANE, or both for their websites and services. Mass adoption of DANE for sending email will help to make sure that the email is protected from downgrade attacks and is always encrypted in transit. DANE can also be useful for enterprises to secure their intranet resources without need to deploy an enterprise wide root CA.
Modern Operating Systems already include a DNS stub resolver service (Microsoft Windows has a DNS Client service, and many Linux distros have dnsmasq or systemd-resolved daemons). These DNS stub resolvers should start supporting DNSSEC validation by default and standards like Extended DNS Errors if they do not currently. They should also be standardized to listen on loopback (127.0.0.1) address so that applications like web browsers can query the local DNS stub resolver to perform DNSSEC validation by itself and use the Extended DNS Errors signaling. This would also help with caching DNS records at the OS level such that each application individually does not have to maintain a separate cache. Such a standardized local DNS stub resolver service will help applications to support DNSSEC and DANE with ease.
DNS is the basis for Internet security which systems like PKI depend upon when issuing certificates. DNSSEC and DANE fixes the key security issues that have been ignored for too long. A lot of problems that DNSSEC have had in the past are already solved today and it is quite feasible to be implemented and deployed at scale.
So, are you for or against DNSSEC and DANE? Let me know your thoughts in the comments section below.
