Sunday, May 14, 2023

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

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

Saturday, March 25, 2023

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.

Sunday, February 19, 2023

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

Updated: 14 Jul 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/12/prod
    sudo apt-get update
    

Once you have the Microsoft Software Repository installed on your distro, you can proceed to install libmsquic library as shown below:

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 HTTP/3 options, and configured a TLS certificate for the DNS web console, the web service will 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.

Saturday, February 18, 2023

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
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!