For DNSSEC And Why DANE Is Needed

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:
  1. 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.
  2. 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.
  3. 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.
  4. 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 an 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 an 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 a 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 an 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 a user simply navigates to a website with an "https://" scheme in its URL with an HSTS header in response, there is no such mechanism available for MTA-STS. This is because with email, there is no concept of a URL and thus no concept of a URL scheme that a user can enter while sending an email. A 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 an 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.

1. 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.
   
   - "Disadvantages of DNSSEC"

   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.

2. 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.
   
   - "Disadvantages of DNSSEC"

   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".

3. 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.
   
   - "Disadvantages of DNSSEC"

   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 an 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.

4. 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.
   
   - "Disadvantages of DNSSEC"

   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.

5. 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.
   
   - "Disadvantages of DNSSEC"

   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.

6. 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.
   
   - "Disadvantages of DNSSEC"

   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.

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 a 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.

How To Auto Renew SSL Certificates With Certbot Using DNS Challenge

If you have used certbot for automatic renewal of SSL certificates for your website using the HTTP challenge and are also running Technitium DNS Server to host your domain names then you can use certbot with DNS challenge to auto renew your SSL certificates. DNS challenge for certificate renewal has many advantages over HTTP challenge:

• DNS challenge allows renewing wildcard certificate for your domain like *.example.com. This allows hiding your subdomain names such that they are not listed in publicly available Certificate Transparency logs. If you are not familier with this then do check your domain name on crt.sh website.
• It allows renewing certificates for your internal servers i.e. servers in private LAN that are not accessible over the Internet to use the HTTP challenge. In fact, you do not even need to have a web server running to get the certificate issued.

The only constraint with using DNS challenge is to have either API access or Dynamic Updates (RFC 2136) access to your DNS provider. If you are using Technitium DNS Server to host your domain names, you have access to both. In this post we will discuss both the options you have and their pros and cons.

This post is written for Ubuntu Linux but, you can easily follow similar steps on your favorite distro.

Using HTTP API

Technitium DNS Server provides HTTP API which can be used to perform all the tasks that you can perform using the DNS web console. In fact, the DNS web console itself uses the same HTTP API. Certbot provides manual option for certificate renewal which also includes auth hook and cleanup hook options that you can utilize to create DNS records and remove them during the renewal process. We will be using these options to run a small bash script that will use the DNS server's HTTP API.

Follow the steps below to setup certbot that will use the DNS HTTP API to handle DNS challenge:

1. Generate an API Token for the DNS Server HTTP API from the web console. To do that, login to the web console, click on the top right user menu and click the Create API Token menu item. Enter the user's password, give an appropriate token name to help you identify it later, and click Create button. The API token will be generated and displayed immediately.
   
   Note! The API token is displayed only once and not available later. Thus, copy the token string somewhere temporarily to use in the later steps.
   
   Warning! It is recommended that you do not generate the API token for the DNS web console's "admin" user. Instead, create a separate user and edit the zone's permissions to give View and Modify access to it. This is necessary since in an event of the API token getting compromised the impact will be limited.
2. Login using SSH on your web server (for which you wish to setup certbot) as the root user or use sudo su to get root user access before proceeding.
3. Create a /root/certbot-auth.sh bash script using your favourite text editor with contents as shown below:

   #!/bin/bash
   
   # Generate API token from DNS web console
   API_TOKEN="your-api-token"
   
   # Create challenge TXT record
   curl "http://dns-server:5380/api/zones/records/add?token=$API_TOKEN&domain=_acme-challenge.$CERTBOT_DOMAIN&type=TXT&ttl=60&text=$CERTBOT_VALIDATION"
   
   # Sleep to make sure the change has time to propagate from primary to secondary name servers
   sleep 25

4. Similarly create a /root/certbot-cleanup.sh bash script using your favourite text editor with contents as shown below:

   #!/bin/bash
   
   # Generate API token from DNS web console
   API_TOKEN="your-api-token"
   
   # Delete challenge TXT record
   curl "http://dns-server:5380/api/zones/records/delete?token=$API_TOKEN&domain=_acme-challenge.$CERTBOT_DOMAIN&type=TXT&text=$CERTBOT_VALIDATION"

5. Make both the bash scripts executable and only accessible to the root user as shown below:

   chmod 700 /root/certbot-auth.sh
   chmod 700 /root/certbot-cleanup.sh

6. Install certbot if you do not have it already installed.

   apt update
   apt install certbot

7. Run the certbot command as shown below to start the initial certificate request for your domain name.

   certbot certonly \
       --manual \
       --preferred-challenges=dns \
       --manual-auth-hook /root/certbot-auth.sh \
       --manual-cleanup-hook /root/certbot-cleanup.sh \
       -d example.com \
       -d *.example.com

8. Once the certbot command completes successfully, you will find the generated certificates in /etc/letsencrypt/live/example.com folder.

The HTTP API provides powerful ways to automate tasks as shown above but it has some issues that needs to be considered:

• Using the HTTP API requires that the DNS server's web console needs to be accessible so that it can be used with automation scripts which may not be desirable in all scenarios.
• The sample certbot auth/cleanup bash scripts that use the HTTP API uses HTTP links which are not secure. Thus you need to setup SSL certificate for the DNS server's web console before deploying certbot as described above in production.
• If the API token saved in the bash scripts is compromised, an attacker will be able to perform all HTTP API calls with the priviledge of the API token's user. Thus its needed to be made sure that the user has limited access to only the zones that are required.
• The API token allows modifying all the records in the zone since there is no granular permission available for each record. So, any compromise of the token can cause issues for the entire zone.

Using Dynamic Updates (RFC 2136)

Technitium DNS Server supports Dynamic Updates (RFC 2136) for primary zones which can be used with Certbot's certbot-dns-rfc2136 plugin.

Dymamic Updates is a DNS standard which means it uses the DNS protocol itself to work and thus there is no requirement for configuring SSL certificate for your DNS server's web console like in the case of HTTP API.

Also a special thing about Dynamic Updates is that it allows authentication using TSIG standard and allows specifying a Security Policy wherein you can explicitly configure which record and record type can be created/modified/deleted using the TSIG key.

This means that Dynamic Updates option is much better compared to the HTTP API option from security perspective. Thus its recommended to be used in production over the HTTP API option described earlier.

Follow the steps below to setup certbot to use certbot-dns-rfc2136 plugin to handle DNS challenge:

1. Login using SSH on your web server (for which you wish to setup certbot) as the root user or use sudo su to get root user access before proceeding.
2. Install certbot and python3-pip if you do not have it already installed.

   apt update
   apt install certbot python3-pip -y

3. Install the certbot-dns-rfc2136 plugin as shown below.

   python3 -m pip install certbot-dns-rfc2136

4. Login to the DNS server's web console and navigate to Settings > TSIG section. Click on the Add button on the top right side to add a new entry. Enter an appropriate TSIG key name to help you identify it later, keep the Shared Secret empty, select the algorithm as HMAC-SHA256, and click Save Settings button at the bottom left corner. This will generate a TSIG key with a randomly generated Shared Secret which will be shown after you have saved the settings. Use the TSIG key name and the generated Shared Secret in the next step.
5. Create a /root/certbot-rfc2136.ini text file using your favourite text editor with contents as shown below:

   # Target DNS server (IPv4 or IPv6 address, not a hostname)
   dns_rfc2136_server = 192.168.10.2
   # Target DNS port
   dns_rfc2136_port = 53
   # TSIG key name
   dns_rfc2136_name = YOUR-TSIG-KEY-NAME.
   # TSIG key secret
   dns_rfc2136_secret = YOUR-TSIG-SHARED-SECRET
   # TSIG key algorithm
   dns_rfc2136_algorithm = HMAC-SHA256

6. Set file permissions so that the ini file is only accessible to the root user.

   chmod 600 /root/certbot-rfc2136.ini

7. Configure the zone, for which you wish to generate the SSL certificate, to enable Dynamic Updates. To do so, switch to the DNS server's web console and navigate to the Zones section. Find your zone and click on it to open the zone edit view. Find the Options button at the top and click it to open the Zone Options dialog. Navigate to the Dynamic Updates (RFC 2136) tab to configure it. In there select the "Allow" option to allow Dynamic Updates then scroll down to create a Security Policy. Click on the Add button to add a new security policy entry. Here select the TSIG key name that you had created earlier, enter "_acme-challenge.example.com" as the domain name, enter "TXT" as the Allowed Record Types, and click Save button to complete the config.
8. Run the certbot command as shown below to start the initial certificate request for your domain name.

   certbot certonly \
     --dns-rfc2136 \
     --dns-rfc2136-credentials /root/certbot-rfc2136.ini \
     --dns-rfc2136-propagation-seconds 25 \
     -d example.com \
     -d *.example.com

9. Once the certbot command completes successfully, you will find the generated certificates in /etc/letsencrypt/live/example.com folder.

Testing Auto Renewal

Once you have the SSL certificate generated with certbot, it will be automatically renewed using the same config that you used to request the initial certificate. To test the certbot renewal process, you can try the dry run command shown below. If there are no errors reported during the dry run then it means the renewal mechanism is working as expected.

sudo certbot renew --dry-run

Configuring Your Web Server

You can now configure your web server or any other server that requires the SSL certificate to complete the setup. When the SSL certificate is renewed, your web server may need to be reloaded to allow it to load the new certificate. To do that you can create a /etc/letsencrypt/renewal-hooks/post/reload.sh bash script using your favourite text editor with the sample script below that will reload nginx web server in this example.

#!/bin/sh

systemctl reload nginx
echo "nginx reloaded!"

Make the reload script executable as shown below.

chmod +x /etc/letsencrypt/renewal-hooks/post/reload.sh

The above script will be automatically executed by certbot when the SSL certificate is renewed.

If you have any queries do let me know in the comments section below or send an email to support@technitium.com.

Configuring DNS-over-QUIC and HTTPS/3 For Technitium DNS Server

Updated: 29 Apr 2023

Technitium DNS Server is a cross-platform, free, open source software that is easy to deploy and use yet pack powerful features. Starting with the version 11.0 release, the DNS server now supports DNS-over-QUIC encrypted DNS protocol in addition to existing DNS-over-TLS and DNS-over-HTTPS encrypted DNS protocols. With this update, you will be able to use DNS-over-QUIC protocol with a forwarder or connditional forwarder, or host your own DNS-over-QUIC service.

The DNS server has also added support for HTTP/3 for both its web console and DNS-over-HTTPS service. Since HTTP/3 also uses QUIC tranport protocol, the requirements and configuration mentioned in this post also applies to it.

Let's see how to configure the DNS server to use the new QUIC transport protocol.

Requirements

The DNS-over-QUIC protocol uses a very new QUIC transport protocol which is not yet available on all platforms. Currently it is available only on Windows and Linux platforms. The .NET Runtime relies on the msquic library which is an implementation of QUIC protocol by Microsoft.

For Windows

The support for QUIC on Windows is only available on following Windows versions:

• Windows 11 (build 22000 or later)
• Windows Server 2022

The above supported Windows version have msquic already installed and thus there is no additional installation needed. There is no option yet to use the QUIC protocol on Windows 10 or older versions. However, it is possible to use it on Windows 10 by using docker container deployments.

For Linux

On Linux, you need to install libmsquic to enable QUIC protocol support. You can install it using Microsoft Software Repository for Linux. You can follow the instructions given in the link to add the software repository on your distro as shown in examples below:

• Ubuntu 22.04
  

  curl -sSL https://packages.microsoft.com/keys/microsoft.asc | sudo tee /etc/apt/trusted.gpg.d/microsoft.asc
  sudo apt-add-repository https://packages.microsoft.com/ubuntu/22.04/prod
  sudo apt-get update
  

• Raspberry Pi OS
  

  curl -sSL https://packages.microsoft.com/keys/microsoft.asc | sudo apt-key add -
  sudo apt-add-repository https://packages.microsoft.com/debian/11/prod
  sudo apt-get update
  

Once you have the Microsoft Software Repository installed on your distro, you can proceed to install libmsquic. But libmsquic library requires openssl v1.1.1 to be installed and is currently not compatible with openssl v3.x release that is by default installed on some new distros like Ubuntu 22.04. You can check which openssl version you have installed by running the following command:

$ openssl version
OpenSSL 1.1.1f  31 Mar 2020

If you see the output something like shown above then you are all set. Raspberry Pi OS has the version 1.1.1 installed so you do now have to worry about it. If you see version 3.x installed, you will need to install the version 1.1.1 for libmsquic to work.

To install openssl v1.1.1 on Ubuntu 22.04, follow the steps given below to install the pre-built binaries that are made available by Ubuntu:

wget http://security.ubuntu.com/ubuntu/pool/main/o/openssl/openssl_1.1.1f-1ubuntu2.18_amd64.deb
wget http://security.ubuntu.com/ubuntu/pool/main/o/openssl/libssl-dev_1.1.1f-1ubuntu2.18_amd64.deb
wget http://security.ubuntu.com/ubuntu/pool/main/o/openssl/libssl1.1_1.1.1f-1ubuntu2.18_amd64.deb
sudo dpkg -i libssl1.1_1.1.1f-1ubuntu2.18_amd64.deb
sudo dpkg -i libssl-dev_1.1.1f-1ubuntu2.18_amd64.deb
sudo dpkg -i openssl_1.1.1f-1ubuntu2.18_amd64.deb

Note! If the above specified binaries are not available, then you can just check the current version that is available from here and use the correct URL for the available version to run the above commands.

Once you have installed the above openssl binaries, run the openssl version command again to confirm that you have the correct version installed.

You can now proceed to install libmsquic library as shown below:

sudo apt-get update
sudo apt-get install libmsquic -y

Now restart the DNS server so that it loads the newly installed libmsquic library. Once the DNS server is available, you can use the DNS-over-QUIC protocol with forwarder or conditional forwarder configuration, or with the DNS Client tab in the DNS server web console. If you wish to run your own DNS-over-QUIC service, you can enable it from the Settings > Optional Protocols section similar to how you would enable the other encrypted DNS protocols.

If you have enabled HTTPS and configured a TLS certificate for the DNS web console, the web service will now automatically enable HTTP/3 support which will be available on UDP port 443.

If you have any comments or queries, do let me know in the comments section below or send an email to support@technitium.com.

Technitium DNS Server v11 Released!

I am happy to announce the release of Technitium DNS Server v11, a cross-platform, free, open source software that can be used by anyone, be it a novice or an expert user. It features an easy to use web based GUI and works with default config that allows the server to run out-of-the-box.

Download the latest update for Windows, Linux, macOS, or Raspberry Pi!

Technitium DNS Server v11

This is a major release that now runs on ASP.NET Core 7 Runtime as the DNS server now uses Kestrel web server for both its web console and also for DNS-over-HTTPS service. With this change, the DNS server now supports HTTP/2 and HTTP/3 for both DNS-over-HTTPS service and also for the DNS web console. It also now supports DNS-over-QUIC encrypted DNS protocol and many new features.

Read the change log to know full details about this latest update.

Any comment or feedback is really appreciated and helps a lot in adding new features and fixing bugs. Send your feedback or support requests to support@technitium.com. You can also post on /r/technitium on Reddit for community support. For any feature request or reporting bugs, create an issue on GitHub.

The DNS Server source code is available under GNU General Public Licence (GPL) v3 on GitHub.

Make a contribution to the project and help in developing new software, updates and adding more features possible.
Donate Now!

Technitium DNS Server v10 Released!

I am happy to announce the release of Technitium DNS Server v10, a cross-platform, free, open source software that can be used by anyone, be it a novice or an expert user. It features an easy to use web based GUI and works with default config that allows the server to run out-of-the-box.

Download the latest update for Windows, Linux, macOS, or Raspberry Pi!

Technitium DNS Server v10

This is a major release that now runs on .NET 7 Runtime and adds a lot of features like Dynamic Updates Security Policy, DANE TLSA record, SSHFP record, EDNS Client Subnet, DNS64, and more.

Read the change log to know more details about this latest update.

Any comment or feedback is really appreciated and helps a lot in adding new features and fixing bugs. Send your feedback or support requests to support@technitium.com. You can also post on /r/technitium on Reddit for community support. For any feature request or reporting bugs, create an issue on GitHub.

The DNS Server source code is available under GNU General Public Licence (GPL) v3 on GitHub.

You can make a contribution to the project by becoming a Patron and help in developing new software, updates and adding more features possible. Become a Patron now!

Technitium DNS Server v9 Released!

I am happy to announce the release of Technitium DNS Server v9, a cross-platform, free, open source software that can be used by anyone, be it a novice or an expert user. It features an easy to use web based GUI and works with default config that allows the server to run out-of-the-box.

This is a major release that adds multi-user role based access support.

Download the latest update for Windows, Linux, macOS, or Raspberry Pi!

Technitium DNS Server v9

Read the change log to know more details about this latest update.

Any comment or feedback is really appreciated and helps a lot in adding new features and fixing bugs. Send your feedback or support requests to support@technitium.com. You can also post on /r/technitium on Reddit for community support. For any feature request or reporting bugs, create an issue on GitHub.

The DNS Server source code is available under GNU General Public Licence (GPL) v3 on GitHub.

You can make a contribution to the project by becoming a Patron and help in developing new software, updates and adding more features possible. Become a Patron now!

How To Secure Your Domain Name With DNSSEC

The Domain Name System Security Extension (DNSSEC) is an extension that allows you to digitally sign DNS records for your domain name. This allows a DNS client that supports DNSSEC validation to authenticate all the DNS responses for your domain name. It is important to note that DNSSEC provides authentication but does not encrypt the data in transit. Thus it is possible for an attacker on the network to log the DNSSEC requests and responses, or block them all together.

This blog post is a continuation of the previous blog post that was about self hosting your own domain name. In this blog post we will take a look at how you can sign your self hosted domain name with DNSSEC. But first lets find out why you should sign your domain name and understand how DNSSEC validation works.

Technitium DNS Server Supports Both DNSSEC Signing And Validation

Why You Should Sign You Domain Name

This is a genuine question that comes up in everyone's mind considering that SSL/TLS certificates already protect your website from Man In The Middle (MiTM) attacks and also protect the data being transferred by encrypting it. 

Even then, there are many reasons to consider to sign your domain name, some of which are:

• Most SSL/TLS certificates are issued based on domain name validation. This means an unsigned domain name that is vulnerable to spoofing, will allow an attacker to get a certificate issued for your domain name by spoofing responses to a Certificate Authority (CA) DNS requests during the certificate issue process. A signed domain name will prevent such attacks.
• The CAA records that are used to indicate which CAs are authorized to issue a certificate for your domain name are secured when the domain name is signed. This prevents an attacker to get a certificate issued from unauthorized CAs by spoofing CAA responses.
• Your HTTPS website is protected with SSL/TLS certificate since a user entering the domain name in the web browser that is matched with the certificate's subject. But your emails are not protected in that same manner. When an email is sent, the sender's mail server queries for MX records for your domain name to find out the mail servers that receive email for your domain name. If the domain name is unsigned, its possible to spoof the MX response to redirect your email to an attacker controlled mail server which then forwards the emails to your mail servers keeping a copy of all your emails.
• Even when your domain name is signed, its possible for an attacker on the network path to downgrade a SMTP session such that STARTTLS fails causing your email to be transmitted in clear text. A signed domain name that has DANE configured for your mail servers will prevent such attacks.
• DNS is also used to prove ownership of the domain name for many services that is usually done by publishing a TXT record with a given challenge string. An attacker can abuse such processes by spoofing TXT responses for unsigned domain name to prove ownership.
• A signed domain name also protects itself from cache poisoning attacks on recursive resolvers that do DNSSEC validation. 

Signing your domain name thus protects your domain name as an owner from abuse or hijacks which otherwise are possible for an attacker with enough resources and motivation. Take a look at this video that explains how an attacker was able to performed an attack to hijack IMAP service that DNSSEC would have prevented.

How Does DNSSEC Validation Work?

DNSSEC uses public key cryptography to digitally sign the DNS records. The most commonly used algorithm is RSA but new algorithms like ECDSA, Ed25519, and Ed448 are also standardized.

The primary name server that hosts a DNSSEC signed zone has access to the secret private key being used to sign the zone while the corresponding public key is available as public DNSKEY record in the zone. Each record set in the zone, which is a group of records of same type, including the DNSKEY record set, is signed using the private key and the signature is stored as a RRSIG record. So, a DNS client can validate each record set by requesting for the DNSKEY records and use the public key from them to verify the signature in the RRSIG records in the DNS response.

To make sure that the DNSKEY records received by the DNS client itself are genuine, the DNS client has to fetch another set of DS (delegation signer) records from the parent zone. The DS record contains the hash of the DNSKEY record which the DNS client can use to validate the DNSKEY record that it has received. The DNSKEY which has a corresponding DS record published in the parent zone has a flag called Secure Entry Point (SEP) set to indicate that. The DS records from the parent zone itself are signed which the DNS client has to again validate against the DNSKEY records from the parent zone. The DNS client is configured with either DS records or DNSKEY records of the ROOT zone which acts as the trust anchor allowing the DNS client to validate a domain name and its parent zones up to the ROOT zone. This is called a chain of trust where having a trusted ROOT zone's DS records is sufficient for a DNS client to validate all domain names recursively.

The RRSIG records allow the DNS client to validate an existing record set but how does the signed zone prove that the requested type of record set or the sub domain name itself does not exists? This problem is solved using the NSEC (next secure) records which adds a level of complexity to DNSSEC. The signed zone has NSEC records for each sub domain names including the zone's apex and contains the domain name of the next NSEC record forming a kind of linked list that is sorted in an alphabetic order (canonical order). The last NSEC record contains the domain name of the first NSEC record. The NSEC records also lists the type of record sets that exist for that particular sub domain name. A DNS client using the NSEC records received for a request can validate if the requested domain does not exists (NXDOMAIN) or if there are no records for the requested type (NODATA).

The problem with the NSEC records, used to prove non-existence of domain name or a record type, is that the zone's entire structure gets published and thus anyone can use a technique called "zone walking" to list out all the sub domain names and all the record types for the zone. This is since NSEC records form a linked list and so the first NSEC record at the zone apex tells you the sub domain name of the next NSEC record which can be similarly followed to know all the sub domain names in that zone. This can be a problem if a zone contains private or internal records that must not be publicly disclosed. To fix this issue, another record type called NSEC3 (next secure 3) was introduced that uses hashing technique to mask the domain names that are visible in NSEC records. The NSEC3 record is also a kind of linked list similar to NSEC that can be used in similar way to prove non-existence of a domain or record set but the hashing of domain names in it adds another layer of complexity. The NSEC3 record makes it difficult for an attacker to perform "zone walking" but is not impossible for someone determined with resources to spare.

Configuration

The most common way to configure a signed zone is to have two sets of key pairs called Key Signing Key (KSK) and Zone Signing Key (ZSK). The KSK is the key pair for which a DS record is added in the parent zone and is used to sign only the DNSKEY records in the zone. While ZSK is the key pair that is used to sign all other types of records in the zone. This scheme of key management allows you to replace the ZSK (rollover the key) without the need to update any DS record at the parent zone making it possible to frequently change the ZSK. This also allows the private keys corresponding to KSK to be stored securely in a Hardware Security Module (HSM) which is only used when key rollover operation is required to be performed preventing KSK from being compromised. Technitium DNS Server implements KSK and ZSK keys to sign a zone but does not yet support HSM and thus all the private keys are stored in the zone file itself.

The most common reason for a signed domain name to fail validation and thus become inaccessible to users of validating DNS resolvers is misconfiguration caused during key rollover. The DNS records are highly cached at all levels. This means a record that has been deleted from the zone can still exists in caches of recursive resolvers, DNS proxies, OS, and even applications like web browsers. This makes it error prone to perform DNSSEC operations without help of proper tooling. The DNSSEC implementation done in Technitium DNS Server ensures that its easy and error free to configure and maintain a signed zone.

There are a few minimum requirements that you must check before proceeding to sign your zone:

1. Check whether your Top Level Domain (TLD) is itself signed. You can only sign your zone if the parent zone too is signed. To check this, you can use the DNS Client tool to query for the TLD domain name with type set to DS. For example, if you domain is example.com, you should query for com as the domain name with type as DS. If you see one or more DS records in the answer section of the response then it means your TLD is signed and you can thus sign your zone.
2. Make sure your zone does not use any proprietary ANAME or APP records. This is since those records generate a dynamic response which is not supported by the DNSSEC implementation. If you have any such records for a sub domain name then create another zone for the sub domain name for these type of records which will allow you to sign your main domain name independently. This ensures that your zone is signed except for those dynamic type of records in the sub domain zone.
3. Check that all of your secondary name servers support DNSSEC. If you chose to use NSEC3 as the non-existence proof for your zone then make sure that NSEC3 too is supported by your secondary name servers.

Once you have confirmed all of the above requirements, you can proceed to sign your zone.

Signing Your Primary Zone

Proceed with the the steps below to sign your zone:

1. Login to the DNS web console, go to the Zones section and click on the Edit button for your primary zone.
2. In the zone view, click on the DNSSEC button at the top right corner to get a drop down menu. Click on the Sign Zone menu item to get the Sign Zone dialog box.
   
   

   

   The Primary Zone DNSSEC Drop Down Menu

3. In the Sign Zone dialog box, select the recommended ECDSA algorithm as the DNSKEY algorithm and P256 as the ECDSA Curve.
   
   

   

   The Sign Zone Dialog Box

4. Select the recommended NSEC as the Proof Of Non-Existence option. If your zone contains private/internal sub domain name records then you may use the NSEC3 option to hide them.
5. Select a suitable DNSKEY TTL value which by default is set to 3600 sec (1 hour). A lower value allows quick addition or rollover of DNS keys but will cause frequent requests for the DNSKEY records.
6. Select a suitable ZSK Automatic Rollover value which is the frequent at which the DNS server will rollover the ZSK to a new key automatically.
7. After you have confirmed all the above values, click on the Sign Zone button to start the zone signing process.

When the zone signing process completes, you will see DNSSEC related records populated in the zone. Click on the DNSSEC button on the top right corner of the zone view and you will see a new drop down menu pop up. Click on the Properties menu item to see the DNSSEC Properties dialog box which shows you all the options that you entered while signing the zone to allow changing them later.

The DNSSEC Properties Dialog Box

Adding DS Record

Your zone is now signed but since you haven't added a DS record in the parent zone, the zone still cannot be validated by DNS clients and is still insecure. The next step is to add a DS record in the parent zone so that your zone can be validated and become secure. To do that, find the DNSKEY record with Secure Entry Point (SEP) flag set in your zone. The DNSKEY record shows additional details where you will find the Key State value as Published with a "ready by" timestamp in brackets. The timestamp tells you when the Key State will switch from Published to Ready state. Once the Key State becomes Ready, you can proceed to add the DS record for your zone.

The Primary Zone DNSKEY Records With Additional Details

WARNING! The most important thing to remember about signing the zone is that you MUST wait until the Key State of the DNSKEY with Secure Entry Point (SEP) flag becomes Ready before adding the DS record in the parent zone. If you do not wait, you risk your zone to fail validation for recursive resolvers that have old records still in their cache. The wait time to Ready state ensures that all the caches have expired.

Once the DNSKEY record's Key State becomes Ready, login to your domain registrar's web panel, find your domain name and click on the Manage option to view the domain details. Find the DNSSEC Management option in there which may be inside the Manage Nameservers option. Here you will find options to create DS records that will be automatically updated by your registrar into the parent zone.

The Create DS Record Form (For name.com Registrar)

The DNSKEY record in your zone with Secure Entry Point (SEP) flag also displays you additional values like Computed Key Tag and Computed Digests. For adding the DS record, use the Computed Key Tag as the Key Tag value, select the Algorithm number 13 i.e. ECDSAP256SHA256 that was used to sign your zone, the Digest Type as SHA-256, and Digest value as the Computed Digests SHA256 value. Ensure that you have correctly entered all the values and proceed to create the DS record. 

WARNING! If you make a mistake in adding the DS record then it will cause validation errors to resolve your domain name resulting in down time for your clients who use a DNS resolver with DNSSEC validation enabled. Thus its recommended that you cross check all the values a couple of times before proceeding to add the DS record.

NOTE! You need to add only one DS record per DNSKEY that has a Secure Entry Point (SEP) flag. You do not need to add DS record for each Digest Type hash values that you see in the zone for the DNSKEY record.

The DNS server keeps a watch on the DS record automatically every 15 minutes by querying the parent zone for it. Once it find the published DS record, the Key State of the DNSKEY will get changed from Ready to Active indicating that the zone can now be validated using the KSK DNSKEY record.

Testing Your Domain

You can now check for the DS record that was added using the DNS Client tool by querying for your domain name with type set to DS. For example, if your domain name is example.com use the same to query with the type as DS. If you get a response with DS record in the answer section then you can confirm once again the values it shows. Note that it may take a while for the DS record to be published by your Top Level Domain (TLD) so you should wait and try again after a while if you get an empty response for the DS query.

Once you see the DS record for your domain name in the DNS Client tool, you can proceed to test DNSSEC validation for your domain name. Check the Enable DNSSEC Validation option in the DNS Client tool, enter your domain name, select the record type as A, and click on the Resolve button. If everything is right then you will see response with answer section containing the A records with DnssecStatus property set to Secure.

Note! Do not use the DNS Client tab that is built into the DNS web console for the above test, instead use the DNS Client website to test since the built-in tool automatically trusts your local zones and thus will always validate the DNS records in the response as Secure hiding any issues that you may have with the DS record.

You can also try the DNSViz tool that will show you the signed zone's details visually as a diagram and will also show you any errors that you may have in your overall configuration.

Backup

Once you have your zone signed and tested it to be validating correctly, you MUST take a backup of your zone files since the private key that was used to sign your zone is stored in the zone file. In case your server hosting the zone crashes causing loss of data, you will face operational issues that can cause downtime for your domain name.

Take a backup using the Backup Settings option that you will find at the bottom right side in the Settings section of the DNS web console. You must select at least the DNS Zone Files check box to create the backup zip file that contains all of the zone files.

Since the private keys are stored in the zone files, the backup zip file must be stored securely to prevent the private keys from leaking to unauthorized people. The backup zip file will help you restore your zones in a cases of hardware failure.

It is recommended to take a periodic backup of your DNS server to make it easy to restore your server quickly in case of any failures.

Key Rollover

Similar to how SSL/TLS certificates have an expiry date upon which you need to renew them, you need to perform a key rollover operation for your KSK and ZSK in your signed zones too. You have to define a policy that tells the number of days to keep the keys and make an operating procedure to rollover the keys.

The key rollover operation generates a new key pair and retires the existing key pair. The process is automatic for ZSK as per the configuration you have in the DNSSEC properties for the zone. The number of days that you have set for rollover for the ZSK will be used by the DNS server to automatically trigger the rollover process. 

For KSK, you have to manually trigger the rollover since you have to manually add the DS records in the parent zone for the new DNSKEY record. It is recommended that you do the KSK rollover once every year as a policy.

For ZSK type keys, you can start the key rollover process manually too if you wish from the DNSSEC Properties dialog by clicking on the Rollover button for the key that you wish to rollover. Once you click the Rollover button, the DNS server will automatically generate and add a new key pair with Key State as Published. Once the new Key's State becomes Active, the old key will be retired and removed automatically. Since ZSK type keys have automatic rollover feature available, you would never require to manually trigger the rollover operation.

For KSK rollover, follow the steps given below:

1. Open the DNSSEC Properties dialog and click on the Rollover button for the KSK key to start the process manually. This will cause the DNS server to generate and add a new key pair with Key State as Published.
2. Note the Key Tag number for the new KSK and close the DNSSEC Properties dialog. Click on the refresh icon that you see next to your zone's name to refresh the displayed records. Find the new DNSKEY record corresponding to the new KSK using the noted Key Tag number displayed as Computed Key Tag for the DNSKEY record.
3. Check the Key State for the DNSKEY record which will be Published with a "ready by" timestamp in the brackets, just like you had it when you first signed the zone. Similar to how you had to wait for the Key State to become Ready the first time, you have to wait again for the same. The timestamp will tell you when to come back to expect the Key State to become Ready.
4. When the Key State for the DNSKEY record becomes Ready, you can login to your domain registrar's web panel and create a new DS record for the new DNSSEC record similar to how you added the first DS record.
5. Once you have added the new DS record, find the old DS record and remove it. Make sure to confirm that you are removing the old DS record by matching its Key Tag value with the ones that you see in the zone's DNSSEC Properties dialog.

Once you have added the new DS record and removed the old DS record, the DNS server will automatically check for the updated DS record every 15 minutes by querying the parent zone. Once it finds the new DS record published, it will set the Key State for the new DNSKEY record from Ready to Active and the old DNSKEY record will be automatically retired and eventually removed.

You can again test once the new changes using DNS Client or DNSViz tools like you did earlier.

Conclusion

It is highly recommended for every domain owner to sign their domain names with DNSSEC to make them secure. Self hosting your domain name using Technitium DNS Server is easy and secure with DNSSEC. Technitium DNS Server's DNSSEC implementation makes it easy and error free to configure and manage your signed zones. With an easy to use key rollover process, there is no scope to have any misconfiguration issues that can cause downtime.

If you have any comments or queries, do let me know in the comments section below or send an email to support@technitium.com.