Frequently Asked Questions

The information provided here is intended to help people who want or need to know more about DNSSEC: DNS administrators, registrants of .nl domain names, network administrators and IT managers. Answers are given to FAQs about why DNSSEC matters and how it works. It's assumed that you're familiar with the DNS and the associated technical terminology.

General

DNSSEC is a cryptographic security extension to the DNS protocol. The Domain Name System (DNS) translates domain names into IP addresses (and vice versa). If, say, you want to visit example.nl, your computer (the client) has to ask a name server for the IP address of example.nl's web server, which will be something like 192.0.2.36 (IPv4) or 2001:db8::2:14 (IPv6). E-mail and other internet protocols use the same system. With DNSSEC, a digital signature is attached to the DNS information (records) that the server sends to the client, so that the client can check their authenticity.

A lot of the interaction that businesses have with their customers, partners and suppliers has already moved to the internet. Government bodies and other organisations also make increasing use of the internet to communicate with each other and with the public. Against that background, it's really important to have a secure digital entrance. On-line visitors need to know that they're dealing with a trustworthy brand or organisation. An insecure internet service -- or, even worse, a security breach -- can cause reputational, commercial and financial damage.

If a hacker interferes with a name server's DNS information before it reaches the client, the client can be directed to a fake server. It's then possible to trick visitors into giving passwords and other confidential information, and to obtain money and business by deceit.

DNSSEC secures the name server and the transmission of DNS information. So a provider of internet services can be sure that visitor traffic is not misdirected.

The internet is increasingly used as a platform for storing valuable information and performing financial transactions. People bank on line, invest on line and pay for goods and services on line. Everyone nowadays recognises that it's only safe to do things like that when connected to a secure web server (identified by the familiar lock icon in your web browser).

If a hacker interferes with a name server's DNS information while it's in transit, an internet user can be directed to a fake web server (DNS spoofing). If that happens, there may be nothing to tell the user that something has gone wrong. The fake site may be a perfect copy of the real one, and a lock icon may be visible. And, when the visitor uses the fake site, they give the scammers log-in details or sensitive personal or commercial information.

DNSSEC secures the name server and the transmission of DNS information. So an internet user can be sure that they aren't being misdirected.

When it comes to signing domain names, the Netherlands is a world leader. By spring 2018, nearly half of all .nl domains were DNSSEC-enabled. That's mainly down to the commitment of .nl registrars, who have been bulk-signing the domain names they manage since the official introduction of DNSSEC in 2012. That number of secure domain names continues to rise steadily [1, 2, 3].

However, a 2014 survey found that DNSSEC adoption differed considerably from one economic sector to the next. A follow-up survey in 2017 showed that, while adoption was up considerably across the board, the marked sectoral differences persisted. Whereas government bodies had more than made up for their slow start, banks and internet companies were still dragging their heels.

What's more, the Netherlands lags behind other countries when it comes to DNSSEC validation: clients checking the digital signatures attached to DNS information. Although some internet providers now do DNSSEC validation for their customers, most have yet to enable the service. However, a number of the biggest access providers are currently working on the implementation of DNSSEC validation on their caching DNS servers. We expect them to formally add validation to their DNS services in the near future.

In 2012, the Forum for Standardisation added DNSSEC to the so-called 'use-or-explain' list. Since then, government organisations have been more or less obliged to secure their domains and systems using DNSSEC. Since 2014, all registries and ICANN-accredited registrars have been obliged to support DNSSEC (and IPv6) on their EPP and web interfaces. It must be possible for customers to add, modify and delete key material. Consequently, DNSSEC is now an integral part of the DNS.

SIDN Labs has a web page where it publishes statistics on the .nl domain, including DNSSEC statistics[1, 2]:

DNSSECstats2018-DNSSECadoptie

The Dutch government has played an important pioneering role in getting DNSSEC accepted. In 2012 — a month after the national rollout — the Forum for Standardisation added DNSSEC to the so-called 'use-or-explain' list (along with DKIM). Since then, government organisations have been more or less obliged to secure their domains and systems using DNSSEC. In June 2016, media reports concerning the insecure nature of many municipalities' websites prompted the then Minister of the Interior to direct municipalities to secure their domain names with DNSSEC by the end of 2017 (as well as enabling TLS, DKIM and SPF).

Furthermore, the Forum for Standardisation was behind creation of the Internet.nl portal. Via the portal, users can test connections and domains to see whether they are using six modern internet standards: IPv6, DNSSEC, HTTPS, DMARC, STARTTLS and DANE. The test results are delivered in the form of a score, which serves as a quantitative indication of compliance. The site has already been used for hundreds of thousands of tests.

Whereas in 2014 government organisations were lagging well behind with DNSSEC implementation, by the time of the 2017 survey, they had more than made up their deficit.

In 2012, the Forum for Standardisation, which is an agency of the Ministry of Economic Affairs and the Ministry of the Interior, added DNSSEC (and DKIM) to the so-called 'use-or-explain' list (Dutch acronym: ptolu). That means that all (semi-)government organisations have since been more or less obliged to secure their domains and systems using DNSSEC. In practical terms, all relevant standards on the 'use-or-explain' list have to be included in tender specifications for government contracts worth more than 50,000 euros, unless there are good reasons for their non-inclusion. Consequently, the implementation of DNSSEC is normally an integral feature of public sector IT infrastructure upgrade projects.

More recently, SPF and STARTTLS in combination with DANEhave also been added to the 'use-or-explain' list. At the time of writing (spring 2018), the addition of DMARC was in the pipeline. All those standards, which serve to secure mail transmissions [1, 2], are based on the DNSSEC's cryptographic infrastructure.

The Dutch government is currently preparing the Generic Digital Infrastructure Act (Dutch initials: WGDI). One option under consideration is to make everything on the 'use-or-explain' list mandatory and include sanction provisions in the act.

In response to research by Binnenlands Bestuur (the journalistic medium for the Dutch civil service), which revealed that municipalities were hardly using modern internet standards to secure e-mail, the then Minister of the Interior decided in 2016 that DNSSEC and the other internet standards on the 'use-or-explain' list should be implemented by all municipalities before the end of 2017.

SIDN, the organisation that runs the .nl top-level domain, has played an important part both in the rollout of DNSSEC in the Netherlands, and in the development of this security technology. For example, the transfer protocol that enables signed domain names to be moved from one registrar to another without interrupting their secure status was largely devised by SIDN Labs. The procedure for a seamless transfer is similar to that for a key rollover, but involves multiple parties.

To make secure transfers possible, the EPP interface had to be extended to support a 'key relay' command, which the registrars involved can use to exchange the necessary key material via the registry. The extension has since been standardised in RFC 8063.


About DNSSEC

The DNS protocol is secure. At one time, a DNS security breach was merely a theoretical possibility. Then, in 2008, Dan Kaminsky demonstrated that false information could be injected into the caches of the most popular DNS servers in real-life situations. Clients currently represent easily the weakest point. However, as client security improves, hackers will inevitably turn their attention to name servers and the transmission of DNS information. In recent years, therefore, considerable time and effort has been invested in refining and implementing DNSSEC, a protocol extension that's been around a while, but was initially not much used. The Netherlands has played a pioneering role in that context.

DNSSEC is a forward-compatible extension to the DNS protocol. A digital signature is attached to the address information that a DNS server sends to a client that supports the extension. The authenticity of the DNS records can then be verified using the relevant domain's public key. Via the registrar, the domain's registrant deposits the public key at the next level up in the DNS hierarchy. In the case of a .nl domain name, that means that the public key is stored on the name servers of SIDN, the organisation that runs the .nl top-level domain. The key is made available to clients in the form of a hash code. A client can therefore verify that the public key received with the address information sent by a name server is indeed the same as that deposited with the registry by the domain name's registrant or administrator. Hence, a 'chain of trust' is created, running through the various levels of the DNS hierarchy.

Registrants shouldn't really notice any difference when DNSSEC is in use. DNSSEC is a fully transparent security extension to the ordinary DNS. So DNSSEC can be enabled for a domain without any inconvenience to the registrant or internet users.

If the user's system also supports DNSSEC, both parties automatically benefit from the addition of strong cryptographic security to the DNS. The client will then block any address whose digital signature can't be verified. Users whose systems don't support DNSSEC will continue accessing signed domains in the same way that they always have.

Internet users shouldn't really notice any difference when DNSSEC is in use. The difference lies primarily in the technology of the resolver, the part of the client's operating system that is responsible for translating domain names into IP addresses. However, if the authenticity of a signed DNS record can't be verified, access to the relevant address will be blocked. That's in contrast to what happens with an invalid internet certificate encountered while browsing, for example. In that situation, the user is presented with a pop-up that lets them choose whether to proceed or not. Of course, DNSSEC will make an indirect difference to the user by providing greater security in the long term.

DNSSEC secures the name server and the transmission of DNS information to the client. However, it doesn't protect the client itself. So, for example, if a PC is infected with malware, it will be possible for the malware to manipulate both the resolver (the part of the client's operating system that is responsible for translating domain names into IP addresses) and the local cache.

Clients currently represent easily the weakest link in the whole chain. However, as client security improves, hackers will inevitably turn their attention to name servers and the transmission of DNS information. Furthermore, the first cracks have started to appear in the security of the DNS protocol in recent years. Most alarmingly, in 2008 Dan Kaminsky demonstrated how hackers could inject false information into the caches of the most popular DNS servers in real-life situations. DNSSEC provides strong cryptographic protection against such attacks.

NB: DNSSEC enables only the DNS information to be authenticated. In other words, the digital signature guarantees that a DNS response received by a client is consistent with the information on the authoritative name servers. However, neither the queries nor the responses are themselves encrypted, meaning that 'anyone' can read them in transit. DNSSEC does not therefore ensure confidentiality. At the moment, no efficient confidentiality solutions are available.

Furthermore, DNSSEC is not a replacement for HTTPS, although DANE (which builds on DNSSEC) is an alternative to the CA system. Finally, DNSSEC does not prevent phishing, since there is nothing to stop a malicious registrant signing an abusive URL in the correct fashion. The DKIM/SPF/DMARC protocols (that also use DNSSEC) are, however, intended to combat phishing, spamming and the distribution of viruses and other malware.

Implementation

The infrastructure and facilities for signing .nl domain names have been fully operational since 2012. In principle, therefore, any .nl domain name can be signed. What's more, since 2013 it's been possible to transfer domain names between registrars without interrupting their secure status.

If the management of a domain name's DNS information is delegated to a registrar or another service provider, they have to sign the domain and upload the public keys to SIDN, the organisation that runs the .nl top-level domain, via the administrative interface. Many registrars have now bulk-signed the domain names that they manage.

If a registrant manages their own DNS information — i.e. operates their own DNS servers — implementation starts with the generation of a cryptographic key pair. The private key is used to sign the records. The public key has to be uploaded to SIDN via the admin dashboard of the registrar or internet service provider. The interface provided for registrars by SIDN, the organisation that runs the .nl top-level domain, now supports key uploading. Registrars and internet service providers can therefore enable customers to enter public keys when entering name server details via their admin dashboards.

You also need to use the admin dashboard if the management of DNS information is delegated to an operator such as CDN provider Cloudflare.

All popular DNS servers now support DNSSEC. They also provide tools for generating key pairs and signing records. For example, BIND, the most widely used DNS server of all, is supplied with dnssec-keygen (for generating cryptographic key pairs) and dnssec-signzone (for signing records).

Although the latest versions of BIND offer increasing scope for automating signing and key management, we recommend using it in combination with OpenDNSSEC. As well as automating signing, OpenDNSSEC handles all aspects of key management.

Major operators, including most registrars, tend to use PowerDNS. PowerDNS is DNS server software designed to maximise the automation and transparency of DNSSEC use. Many operators that previously used other packages have switched to PowerDNS because of its good DNSSEC support.

The Infoblox appliances — proprietary solutions based on Linux and BIND often used in business environments — feature out-of-the-box support for DNSSEC. Following initial configuration, enabling DNSSEC is simply a matter of ticking a box. However, the DNSSEC functionality of the Infoblox appliances is now seriously out of date, so we would not recommend its use for new implementations.

An administrator that wants to check that DNSSEC is working properly can do so by using the tools provided with their DNS server, or using the popular BIND network tool dig (with the +dnssec option).

Once you have completed your DNSSEC configuration, there are on-line tools that can be used to perform a complete check on a domain. For example, Verisign offers this:

And Sandia has this, which provides an attractive graphic overview:

dnsviz-sidn

SIDN Labs has also made a tool available on line, which lets you check a list of domain names in one go:

On the Internet.nl portal, you can test your connections and domains to see whether they are using six modern internet standards: IPv6, DNSSEC, HTTPS, DMARC, STARTTLS and DANE. The test results are delivered in the form of a score, which serves as a quantitative indication of compliance.

On the Internet.nl portal, you can test your connections and domains to see whether they are using six modern internet standards: IPv6, DNSSEC, HTTPS, DMARC, STARTTLS and DANE. The test results are delivered in the form of a score, which serves as a quantitative indication of compliance. Their Connection Test is specifically for testing DNSSEC (and IPv6) on the user side:

NB: If the results indicate that DNSSEC isn't supported, that doesn't necessarily mean that there is a problem with your resolver (the part of the client's operating system that is responsible for translating domain names into IP addresses). Many resolvers use the caching DNS servers operated by the user's internet access provider (via DHCP).

If you want to transfer a signed domain, the first step is to make sure that the registrar you want to switch to does support DNSSEC. If they don't, you may lose your DNSSEC protection by going ahead with the transfer. In the worst-case scenario, your domain could even become unreachable, because clients won't accept DNS information that should be signed but isn't.

Furthermore, a seamless transfer — i.e. a transfer without a security interruption — can be organisationally cumbersome, particularly if the DNS administration for the domain is in the hands of an (external) internet service provider. That is because the new operator will use a new key pair to sign the DNS information.

Fortunately, a procedure for secure domain name transfers is now available. SIDN Labs played a key role in development of the seamless transfer procedure, which is similar to the procedure for a key rollover, but involves multiple parties.

For the transfer to go through without a problem, there has to be an overlap period of a few days, during which both operators' public keys have to be available via the TLD administrator as DS records. What's more, both public keys must be available from both operators as DNSKEYs. That implies that the two operators have to exchange the relevant material prior to the transfer. SIDN has extended its registrar interfaces to make that possible. The extension to the EPP interface has since been standardised in RFC 8063.

The TLD administrator's NS records cannot be changed to point to the new name servers until the new DS and DNSKEY records are visible everywhere. Then, once all old NS records have expired, the configuration can be removed from the old name servers. Later, the old DS record (held by the TLD administrator) and the old DNSKEY (on the new name server) can be deleted as well. Although all that involves a significant amount of communication, coordination and information exchange, the protocol lends itself to automation and the necessary support is already available from SIDN. Work is currently underway to implement the transfer protocol in DNS server software.

BIND was comprehensively redeveloped between versions 9 and 10. The version 10 software was written in C++ (for the core) and Python (for the interface), and the architecture was constructed using multiple daemons (as with Postfix MTA). The development of BIND10 was sponsored by SIDN and others.

In 2014, ISCtransferred version 1.2.0 of BIND10 to the internet community under the new name Bundy. The hope was that the open-source community would take on further development, but that didn't happen. The differences from version 9 proved to be too great: the only link between the old and new versions was that version 9 zone files could be imported to version 10. Hence, it was just as easy to switch to PowerDNS, and many large operators did so. What's more, certain key elements were not initially implemented: BIND10 does support DNSSEC, but doesn't do the signing itself, and the recursive resolver is not yet usable.

The DHCP server developed as part of BIND10 was transferred to the Kea project and is now being developed further by ISC.

For the time being, ISC will continue the development of BIND version 9.

Extensive, practical information on the configuration of BIND named is available here:

Validation

You can be sure that the translation of a domain name into an IP address is completely secure only if the whole chain is secure. All the authoritative DNS servers associated with the domain name itself — the so-called 'chain of trust' — must be secure, and so must the internet access provider's caching DNS servers and the end user's client.

Most clients contain only a stub resolver and leave recursive queries — and therefore validation — to the caching DNS servers assigned to them via the provider's or network administrator's DHCP. In the Netherlands, XS4All, BIT and Edutel are currently among the few access providers whose networks support DNSSEC validation. At the time of writing (spring 2018), the country's two biggest providers, KPN and Ziggo, don't provide a validation service for their customers.

Network administrators who want to enable DNSSEC validation for their users can do so using BIND named, for example, or the PowerDNS Resolver [1, 2]. Administrators of smaller networks can use dnsmasq, a combined DNS/DHCP server that also supports DNSSEC.

An end user who wants guaranteed security from their DNS resolver should therefore install dnssec-trigger or a browser plug-in.

However, DNSSEC secures only the name server and the transmission of DNS information to the client. It doesn't secure the client itself. If your desktop is infected with malware, you can't trust any of the programs installed on it, including the resolver. For example, some malware can modify the hosts table, thus completely bypassing the DNS.

In the Netherlands, XS4All, BIT and Edutel are currently among the few access providers whose networks support DNSSEC validation. At the time of writing (spring 2018), the country's two biggest providers, KPN and Ziggo, don't provide a validation service for their customers.

Other organisations that do validation are RijksDNS, the Municipality of 's-Hertogenbosch, the University of Twente, the University of Groningen and the CWI.

A number of major access providers are currently working on the implementation of DNSSEC validation on their caching DNS servers. We expect them to formally add validation to their DNS services in the near future. Until then, end users can make use of Quad9, 1.1.1.1 or Google's Public DNS service, although the latter does involve certain privacy sacrifices.

The Authentic Data (AD) flag is used by (caching) DNS servers to indicate that they have validated the DNSSEC records. The idea is that the client doesn't then have to repeat the check. In its DNS query, the (stub) resolver asks for the DNSSEC records by setting the DO flag (DNSSEC OK) — with the dig network tool, you can achieve the same thing by using the +dnssec option. When replying with the DNS records, the DNS server may add the AD flag. The DNS server is then effectively taking responsibility for both the caching and the validation.

However, when testing a validating DNS server, it's important to bear in mind that the DNSSEC specification (RFC 4035, subsection 3.1.6) states that authoritative servers don't have to undertake validation for their own domains. They are then allowed to set the AD flag, but only if they have obtained their authoritative records in a secure manner. That has to be separately configured.

The role of the AD flag has since been extended: whereas it was originally exclusively for DNS responses, it can now be used in DNS queries. Subsection 5.7 of RFC 6840 says that it was previously recommended that the AD flag shouldn't be set in DNS queries. Now setting the AD flag in a DNS query yields information exclusively about the validation result (by means of the AD flag in the DNS response), and not about the DNSSEC records themselves. The dig network tool now supports AD flagging with its +adflag option. The DO flag is still used as before to request DNSSEC information.

Of course, the crypto-technical answer is 'never'! Because the pathway between the (stub) resolver and (caching) DNS server is generally not secure, the contents of a DNS response can always be modified by a man-in-the-middle attack undetected by the client. In principle, neither the record contents nor any of the meta-data (headers) can be trusted.

Various solutions are currently available for this so-called last-mile security problem:

  • DNS information exchange can be secured using TSIG (Transaction SIGnature). The TSIG protocol is often used for the exchange of DNS records between authoritative servers, and to secure Dynamic DNS updates from the DHCP servers to the DNS server. TSIG could also be used for communication between resolver and DNS server, but is not an obvious option in that context. The protocol is based on symmetrical cryptography, implying that a shared private key has to be exchanged between client and server.

  • By contrast, DNSCrypt uses asymmetrical cryptography, making it more suitable for last-mile security. DNSCrypt is used by the DNS service provider OpenDNS to encrypt traffic to and from its clients. The system is based on DNSCurve, developed by Daniel J. Bernstein (DJB), who has a reputation for fast and secure internet software. It was he who developed qmail and djbdns, for example. DNSCrypt is supported mainly by OpenDNS and is available for Windows, Linux, Mac OS X and iPhone.

  • DNSSIG is a rival to DNSCrypt. It is designed to maximise transparency by using TXT records.

  • In Secure Dynamic Update, Microsoft has developed a protocol for tunnelling DNS traffic. The system uses the GSS-API and a variant of Kerberos.

  • Finally, DNS-over-TLS is a much more logical option, since it is open. However, because of the overhead, it is just as inelegant for encrypting traffic between resolver and DNS server as Secure Dynamic Update.

Despite all the initiatives of the last ten years, it appears that none of the technologies outlined above will become established as the solution for last-mile security. Although combining DNSSEC validation with DNS record caching seems like an obvious (and efficient) thing to do, it truncates the cryptographically secured DNSSEC chain, which should ideally extend all the way from the root zone (.) to the client. Therefore, if validation is also performed on the caching DNS servers, a new technology is required for the last part of the chain to secure transmission of the AD flag.

The AD flag can be used on a network where the security of the last mile is assured. Examples include company networks, campus networks and the closed networks belonging to internet providers and mobile operators. On such networks, DNSSEC validation and DNS caching can be centralised on the recursive DNS servers.

Most clients contain only a stub resolver and leave recursive queries — and therefore validation — to the caching DNS servers assigned to them via DHCP by the internet access provider or network administrator. Such clients therefore rely on the AD flag that the DNS servers set on the records after validation. Hence, the pathway between stub resolver and DNS server — the 'last mile' — is not secured.

The problem of the insecure last mile is resolved by having the client do the validation. The DNS is then secured all the way to the end point. Therefore, even if the access provider or operator performs validation, users are well advised to continue validating DNSSEC signatures themselves. In due course, therefore, validation is expected to become a standard feature of all resolvers.

Network administrators who want to enable DNSSEC validation for their users can do so using BIND named, for example, or the PowerDNS Resolver [1, 2]. Administrators of smaller networks can use dnsmasq, a combined DNS/DHCP server that also supports DNSSEC.

An end user who wants guaranteed security from their DNS resolver should therefore install dnssec-trigger or a browser plug-in.

Most clients contain only a stub resolver and leave recursive queries — and therefore validation — to the caching DNS servers assigned to them via DHCP by the internet access provider or network administrator. Such clients therefore rely on the AD flag that the DNS servers set on the records after validation. Hence, the pathway between stub resolver and DNS server — the 'last mile' — is not secured.

What's more, the DNS protocol provides no scope for indicating exactly what the issue is when DNSSEC validation fails; the address whose digital signature cannot be validated is simply blocked by the resolver.

The expectation is therefore that, in due course, validation by the client will become the norm. That arrangement would resolve the problem of the 'last mile'. It would also enable web browsers and other applications on the client to do their own validation. And that in turn would mean that the user could be provided with explanatory information when validation fails.

DNSSEC plug-ins are already available for the most popular web browsers. They work in parallel with the resolver on the client and can therefore provide responses that differ significantly from those given by the local resolver. In fact, some plug-ins can even be configured to use a completely different DNS server. Consequently, whereas a validating resolver will totally block a secure domain if validation fails, the plug-ins should be seen as providing indicative information.

An end user who wants guaranteed security from their DNS resolver should therefore install dnssec-trigger or a browser plug-in.

However, DNSSEC secures only the name server and the transmission of DNS information to the client. It doesn't secure the client itself. If your desktop is infected with malware, you can't trust any of the programs installed on it, including the resolver. For example, some malware can modify the hosts table, thus completely bypassing the DNS.

The Valibox is a software image that end users can use to enable end-to-end DNSSEC validation on their wireless home/office networks.

The software has been developed by SIDN Labs, SIDN's research department, building on the open source packages LEDE (a fork of OpenWrt) and Unbound. The Valibox currently supports three hardware devices: the GL-Inet AR-150, 6416 and MT300A.

Valibox-screenshot_glinet_upload_firmware

From version 1.2.0, the Valibox incorporates a component called SPIN (Security for In-home Networks), which enables users to see exactly what data is being sent by the devices connected to their networks, including Internet of Things (IoT) devices. It also allows for potentially dangerous incoming traffic to be blocked, and therefore acts as a personal firewall.

In the period July 2015 to November 2017, SIDN ran a pilot DNSSEC-validating DNS service. The main aim was to build up a picture of the problems caused by validation errors. The pilot's second aim was to assess whether SIDN should make a validation service more widely available. Offering a service would plug the gap left by the access providers and create a non-commercial alternative to Google's Public DNS. With the added benefit of fully assuring users' privacy.

Following the pilot, SIDN decided against developing the validating DNS service into a full-scale public service. Validation errors ceased to be an issue some time ago, and the number of providers supporting DNSSEC validation is growing slowly but surely.


Technical

DNSSEC, short for DNS Security Extensions, is an extension to the basic Domain Name System (DNS). It involves attaching a cryptographic signature to DNS records, so that internet users can be sure that the IP addresses given for a domain name point to the right servers.

To enable DNSSEC, a number of new record types were added to the DNS protocol. RRSIG contains the signature sent with every DNS response (RR: Resource Record). DNSKEY contains the public key used to check the validity of the signature. And the DS (Delegation Signer) record is used to check the validity of the public key by referring to the operator of the superordinate domain. Hence, a 'chain of trust' is created, running through the various levels of the DNS hierarchy and made up of linked DNSKEY and DS records. Finally, the NSEC(3) and NSEC3PARAM records (where NSEC stands for Next Secure) are used to protect potentially sensitive information about the addresses (systems) used within a domain.

The 'chain of trust' is a sequence of security references established by means of DNSSEC between the various levels of the DNS hierarchy. When a DNS server sends address information to a client, it attaches a digital signature (in the RRSIG record). The authenticity of the record can be verified using the relevant domain's public key, which is contained in the DNSKEY record. That is done by referring to the next level up in the DNS hierarchy, where (via the registrar) the domain's registrant has deposited the public key, thus creating a trust link between the two levels.

In the case of a .nl domain name, that means that the public key is stored on the systems of SIDN, the organisation that runs the .nl top-level domain. On request, SIDN's name servers provide a signed hash code of the public key (a digital extract, in a DS record). A client can therefore verify that the public key received with the signed address information sent by a DNS server is indeed the same as that deposited with the operator of the superordinate domain by the domain name's registrant.

The public key for the .nl domain is in turn signed by the root (.). The root therefore serves as the anchor for the entire chain of trust extending down through the subordinate levels. Watch the key signing ceremony for the root servers to see how seriously the matter is taken.

DNSSEC makes use of digital signatures to authenticate the DNS responses sent by name servers. Each signed response sent to a client is accompanied by the public key for that domain. The client can then use the public key to verify that the signature attached to a DNS response is genuine. The authenticity of the public key can in turn be checked by referring to the name server for the superordinate domain. In the case of the domain sidn.nl, for example, the client would refer to the name server for the .nl domain. On request, that name server provides a signed hash code of the public key (a digital extract, in a DS record).

The public key for the .nl domain is in turn signed by the root (.). The root therefore serves as the anchor for the entire chain of trust extending down through the subordinate levels. Watch the key signing ceremony for the root servers to see how seriously the matter is taken.

In principle, a single cryptographic key pair is sufficient for signing DNS records. The private key is used to sign the DNS records (in the RRSIG records) and then stored in a secure place. The public key is provided in the DNSKEY record and therefore freely available, so that anyone can check the signatures attached to the DNS records. The same DNSKEY record is uploaded to the operator of the superordinate domain via the registrar. The operator in question signs the DNSKEY and publishes it as a DS record. The operator's signature shows that the public key in the DNSKEY record is genuine. Thus a trust link is established between the two levels, which forms part of the chain of trust.

SingleKeyPair1-1488x921

In practice, two such key pairs are usually used. The ZSK (Zone Signing Key) pair is then used to sign and validate the DNS records. Each zone usually has its own ZSK pair, so that they can easily be changed or refreshed. Such an arrangement also allows relatively light encryption to be used, meaning that the records can be kept short. When two key pairs are used, the ZSK pair's public key is not uploaded to the operator of the superordinate domain, but signed using the KSK (Key Signing Key) pair's private key. The KSK pair's public key is uploaded to the operator, who signs it and publishes it as a DS record.

DoubleKeyPair1-1984x957

In a staged KSK/ZSK configuration, replacement of the ZSK pair never necessitates re-uploading of the key material. Furthermore, stronger encryption can be used for the KSK pair. Although it is common practice to have a separate KSK pair for each zone, some operators use the same KSK pair for multiple zones.

Furthermore, at the start of 2017, the length of the ZSK pair for the root zone was changed to 2048 bits, meaning that the KSK and ZSK pairs are now equally strong. The length of the ZSK pair for the .nl zone currently remains 1024 bits.

nl-2018-03-23-11_49_19-UTC

Generally speaking, a name server provides information only to clients that ask for specific addresses. If a requested address doesn't exist, a non-secured name server will respond with an error message (NXDOMAIN). That set-up means that an outsider can never obtain information about all the addresses (systems) within a domain. Protecting such information is desirable, since it could be used to compromise security.

However, where DNSSEC is concerned, the arrangement is problematic, because a response (NXDOMAIN error message) for a non-existent address needs to be signed, just like any other response. Moreover, the signing would have to be on a dynamic basis, since it is of course impossible to generate a pre-signed error message for every non-existent address that might be queried. That in turn would make DNSSEC both extremely processor-intensive and vulnerable to denial-of-service attacks.

NSEC (Next Secure) was an initial attempt to resolve that problem. When the signed records were generated, NSEC records were also created for all intermediate ranges. The problem with that was that it allowed a client to make an inventory of all the addresses within a domain by 'name walking'.

NSEC3, short for DNSSEC Hashed Authenticated Denial of Existence, resolved that problem by sending back a hash code (a digital extract) of each queried address, rather than the address itself. Hence, a client that asks after a non-existent address is no longer told about the range between two existing addresses. The response contains only hash codes of those addresses, which cannot be traced back to the addresses themselves.

At one time, a DNS security breach was merely a theoretical possibility. Then, in 2008, Dan Kaminsky demonstrated that there really was a flaw in the design of the DNS. By exploiting the flaw, hackers could inject false information into the caches of the most popular DNS servers in real-life situations.

A traditional cache poisoning attack involves attempting to inject a caching resolver with false DNS information by bombarding it with false responses. That tactic exploits the fact that only 65,536 unique transaction IDs are available for the identification of DNS messages. The client (resolver) and the DNS server use those 65,536 sixteen-bit numbers to associate queries and responses. If a resolver is swamped with false responses with different transaction IDs, it is only a matter of time before one of them happens to have the same ID as a query that the resolver has just sent. The resolver will then accept the false response and ignore the authentic response when it arrives an instant later. That happens because DNS queries and responses use the stateless UDP protocol wherever possible.

Constantly changing the resolver's UDP port ('source port randomization') provided an interim solution to the problem. Because an attacker does not know which port a query has come from, sixty-five thousand times as many false DNS responses have to be sent in order to infect all possible ports. The workaround effectively made a traditional attack impractical.

A Kaminsky attack is like a traditional attack, but involves two stages: If you want to spoof the domain www.example.nl, you start by asking a resolver about the domain name 000001.example.nl. At the same time, you send false DNS responses to the resolver containing NS records pointing to a false authoritative DNS server. If the genuine response arrives first, you don't have to wait until the TTL of that response has expired in the cache of the resolver; you proceed to follow the same procedure with the domain name 000002.example.nl. And you continue the same way until your false response is accepted. Only then do you ask the resolver about the domain name www.example.nl. When you do that, the resolver will refer to your false authoritative name server (because of the false NS records in the cache) and will therefore obtain a false response.

The attack method described is ineffective when DNSSEC is used, because validation of the digital signatures on the incoming false records will fail.


Cryptographic algorithms

Digital signatures make use of public key cryptography: First, a hash (a digital extract) of an electronic document (in this case an RRset or DNSKEY record) is created. The hash is then encrypted using a private key. The result is a digital signature specific to that document.

Each private (i.e. secret) key is paired with a public key (i.e. a key that is available to anyone, since it is published in the DNS as a DNSKEY record). Anyone can use the public key to verify that the relevant signature does indeed belong to the particular document and therefore must have been attached by the owner of the public key (as the only party who knows the associated private key).

pubkey_cryptografie

The DNSSEC protocol is based entirely on digital signatures: Digital signatures (RRSIG records) attached to DNS responses (RRsets) confirm the authenticity of those responses. A digital signature (DS record) attached to the signer's public key (#1) (DNSKEY record) confirms the authenticity of the signer's signatures. And a digital signature attached to the public key (#2) of the signer of that public key (#1) confirms the authenticity of that public key (#2). Hence, a 'chain of trust' is created within the DNS infrastructure, anchored in the root zone. In the root, the final signature in the chain is attached using a key pair that is by definition trustworthy. That pair's public key is built into all resolver software in the form of a trust anchor.

The diagram below shows how the chain of trust leading to the root zone is built up for the domain name example.nl.

chain_of_trust-example.nl

Various algorithms are available both for creating hashes and for public key cryptography. DNSSEC supports various combinations of hashing algorithm and cryptography algorithm. So, before signing your zones, you have to choose which algorithm to use.

About fifteen cryptographic hash/pubkey combinations are defined for use in DNSSEC. A comprehensive list is available on IANA's website. Over time, some established algorithms become 'deprecated' (i.e. regarded as obsolete, on account of being outdated or insecure) and new algorithms are added.

RFC 6944 makes a number of recommendations regarding the selection and use of the various DNSSEC algorithms. Algorithm number 13 (ECDSA Curve P-256 with SHA-256) and algorithm number 14 (ECDSA Curve P-384 with SHA-384) are recommended, as are number 8 (RSA/SHA-256) and number 10 (RSA/SHA-512).

Algorithm number 1 (RSA/MD5) should definitely not be used any longer, because the MD5 hash function is known to be insecure.

SHA-1 is too weak,

The protocol has not been approved by NIST for use in digital signatures since 2011, and with good reason. It's therefore very important that a roadmap for phasing out the use of SHA-1 for DNSSEC is developed as soon as possible.

At the moment, there is no formal discouragement (in RFC 6944) to use any of the algorithms based on the SHA-1 hash. Number 3 (DSA/SHA1) and number 6 (DSA-NSEC3-SHA1) are optional, number 5 (RSA/SHA-1) is mandatory, and number 7 (RSASHA1-NSEC3-SHA1) is actually recommended. However, it is inadvisable to use any of those four algorithms. according to Marc Stevens, cryptographer at CWI and famous for cracking MD5 and SHA-1.

The authors of RFC 6944 actually recognise that SHA-1 should no longer be used, but mandatory implementation of algorithm number 5 (RSA/SHA-1) is part of the DNSSEC standard, as defined in RFC 4034. Number 5 is cryptographically the same as number 7 (RSASHA1-NSEC3-SHA1) — as are number 3 (DSA/SHA1) and number 6 (DSA-NSEC3-SHA1) — but it does not contain NSEC3 records: a signed denial of existence.

Registrants who are still using algorithm number 7 or algorithm number 5 should urgently switch to a more secure/better alternative. Algorithms numbers 3 and 6 are now barely used.

ECDSA (Elliptic Curve Digital Signature Algorithm) is an algorithm for implementation of the public key protocol, as are the more established DSA and RSA algorithms. As its name suggests, ECDSA is based on Elliptic Curve Cryptography (ECC), which has significant advantages in the context of DNSSEC.

The security of all three public key algorithmsDSA, RSA and ECDSA — is based on the mathematical difficulty of calculating discrete logarithms (in complexity terms: 'not calculable in reasonable time').

However, there is a shortcut to cracking the RSA algorithm, namely by dividing the product (multiple) of two large prime numbers back into its factors (prime factorisation). Consequently, RSA is secure to use only if quite long keys are generated, which is undesirable in the context of DNSSEC.

DSA was developed by the US government as a free alternative to the proprietary RSA algorithm. When using DSA, it is important to bear in mind that it is extremely vulnerable if a poor random generator is used.

The mathematics behind elliptic curve cryptography is much harder to explain than prime factorisation, but for enthusiasts the thinking behind ECC is revealed here by Ars Technica in an accessible way.

Of particular importance for DNSSEC is that, while the digital signatures created with ECDSA are the same length as DSA signatures, the public keys are much shorter. For example: a security level of 128 bits — implying that 2128brute force operations are needed to crack the encryption — is currently regarded as a secure minimum. To attain that security level, a public key of 256 bits is required with ECDSA (twice the desired level of security), whereas with DSA and RSA at least 2048 bits are required. With both ECDSA and DSA, the signature length is roughly four times the desired security level (i.e. 512 bits in this example), whereas with RSA it is more than 2048 bits.

ECDSADSARSA
2562048+2048+
5125122048+

Furthermore, ECDSA signatures can be generated much more quickly than RSA signatures (by one order of magnitude) and DSA (by a multiple). Only when it comes to checking ('validating') the signatures is RSA much faster than the other two algorithms; indeed it is an order of magnitude faster than ECDSA. That is the sole (albeit significant) disadvantage of using ECDSA for DNSSEC.

ECDSADSARSA
SlowFastVery fast
Very fastFastLess fast

The differences in algorithmic properties described above make ECDSA generally the best choice for DNSSEC. First, the length of both the signatures (RRSIG records) and the public keys (DNSKEY records) can be kept to less than 512 bytes. Consequently, the records can be transmitted without switching from traditional DNS packages to (longer) EDNS packages.

Second, with ECDSA, there is only a small size difference between the DNS query (lookup query) and the response. That is significant, because DNSSEC's 'inflation factor' is often exploited in DDoS/amplification attacks.

Finally, the generation of a digital signature (signing) requires much less processing power with ECDSA than with RSA. That is a major advantage for registrars and other DNS operators that bulk-sign domains for their clients. The disadvantage on the client side is that it takes longer for a resolver to validate an ECDSA signature. That is significant mainly when DNSSEC is used on a mobile device, which typically has relatively limited computation power and battery capacity.

e in het algemeen maar beperkte rekenkracht en batterijcapaciteit aan boord hebben.

Yes. From March 2016, registrars can also provide SIDN with DNSKEY records based on algorithms numbers 13 and 14 for publication in the .nl zone (as digital signatures in DS records). Consequently, registrars have since been able to sign their clients' domains using ECDSA.

The change also meant that .nl domain names hosted by Cloudflare — of which there are about twenty thousand — could be DNSSEC-enabled. Cloudflare is a CDN provider that from the start used algorithm number 13 by default to sign its clients' domain names.

Algorithms 13 and 14 are now also widely supported both on the client (resolver) side and on the server side.

Both DNSSEC algorithm number 13 and algorithm 14 are based on ECDSA. However, algorithm 14 generates longer keys (384 bits, as opposed to 256) making it suitable for use where extreme security is required. Nevertheless, for the time being algorithm 14 is unlikely to be used much in practice, because the longer keys and signatures underpinning the additional security require additional processing power and generate more traffic.

The big difference in signing speed between ECDSA and RSA means that in the future it will probably be possible to generate a digital signature for a denial-of-existence on-the-fly — in other words, as part of the DNS response composition process. One would then have a dynamic alternative to NSEC3, definitively resolving the problem of name walking.

This 'DNSSEC white lies' technology (see RFCs 4470 and 4471) is propagated mainly by CDN provider Cloudflare.


Focus points

DNSSEC significantly increases the length of the responses that name servers send in reply to DNS queries. The reason being that each RRset is accompanied by a digital signature (in an RRSIG record).

The protocol used by default for DNS communications is UDP, which is fast but stateless. Consequently, it is relatively easy to falsify the sending address (IP address spoofing). By using a botnet to send a large volume of DNS queries to one or more DNS servers, it is possible to mount a DDoS (distributed denial-of-service) attack via those servers. Because the responses are considerably larger than the queries, such an attack is known as an amplification attack.

EThere are various ways that DNS server operators can prevent their systems being abused for DNS amplification attacks:

  • Response Rate Limiting (RRL): A limit can be placed upon the number of identical responses sent to a client address. To prevent legitimate queries being ignored as well, RRL is often used in combination with SLIP. With SLIP, clients are not blocked altogether, but a proportion of their queries are referred to the TCP protocol. That eliminates the attack's amplification effect.

  • DNS dampening: This technique involves looking at the incoming queries, rather than the outgoing responses. Queries are scored by client address and query type. If a defined threshold score is exceeded, all queries from the client in question are temporarily ignored. The score then declines exponentially over time, and responses automatically resume once it is back beneath the threshold.

Whereas DNS dampening results in all responses to a given address block being withheld, RRL affects only responses to particular query types and SLIP enables clients to continue receiving requested information. Consequently, RRL is a more refined technique than DNS dampening.

RRL and DNS dampening are effective only against single-server DNS amplification attacks. If an attacker uses multiple DNS servers, the individual servers have no way of knowing that they are being used for a double-distributed attack, i.e. an attack that makes use of distributed attack clients (a botnet) and distributed DNS servers operating in relay. That is because distributed, low-frequency traffic is indistinguishable from legitimate DNS traffic.

The best way to prevent DNS amplification attacks is also (technically) the simplest. BCP 38 (Best Current Practice) states that each internet service provider (ISP) should filter its own outbound internet traffic on the basis of sender address. Packages that are not allowed to originate outside the ISP's IP network should be blocked (ingress filtering). In that way, infected clients that have been recruited into botnets are blocked at source.

However, implementation of BCP 38 is patchy, because the cost is not incurred by the beneficiary. BCP 38 serves to protect other people against spoofing attacks mounted from your network.

DNS packages limited by design to 512 bytes for transmission using the UDP protocol. For larger packages (responses), the (more resource intensive) TCP protocol is used instead. The development of DNSSEC was a primary driver for modifying the DNS to support the transmission of larger packages by means of UDP. The EDNS0 extension (Extension mechanisms for DNS) allows DNS packages of up to 4096 bytes, so that packages containing digital signatures can where possible be sent using UDP.

The ability to use larger UDP packages for DNS also means that they may be divided (in transit) across multiple IP fragments if they exceed the path MTU (maximum transmission unit). Because all DNS control information (flags, etc) is then contained in the first fragment, the contents of later fragments is much easier to predict, facilitating the injection of false DNS information by an attacker.

Again, DNSSEC validation can prevent such attacks, because the digital signature serves to authenticate the entire response (RRset).

Response Rate Limiting (RRL) is a technique for countering DNS amplification attacks. It involves an authoritative server (temporarily) limiting the number of identical responses sent to a given client address.

An attacker can abuse an authoritative server's RRL protection mechanism to increase the probability of a cache pollution attack being successful. That's done by first using IP address spoofing to deliberately get a caching resolver placed on a popular authoritative server's RRL blacklist. If the attacker then gives the IP address of the resolver as the sender in a larger number of UDP packages, the authoritative server will think that the resolver in question is the victim of a DDoS attack. That will lead the authoritative server to ignore many genuine queries from the resolver. And that in turn will make it easier for the attacker to mount a successful cache pollution attack on the resolver, because the window for false responses will be greater.

DNSSEC prevents such cache pollution attacks, because falsified DNS responses do not bear the genuine authoritative server's signature and are therefore rejected.


Organisational

a href="https://www.sidn.nl/" target="_blank">SIDN (Foundation for Internet Domain Registration in the Netherlands) is the organisation responsible for running the .nl top-level domain and the 'signposting' for all .nl domains. To that end, SIDN has developed a Domain Registration System (DRS) and established a redundant infrastructure in and around Arnhem.

Domains are registered and subsequently managed through registrars: about fifteen hundred specialist internet and hosting firms that have registration contracts with SIDN. Much of the registration work done by registrars is based on the Extensible Provisioning Protocol (EPP), an XML-based protocol for interaction between domain name administrators (registries) and their registrars.

People who want to register or maintain domain names go through internet service providers (ISPs). Many of the ISPs in question are registrars, but others are 'resellers' utilising the services of registrars. The typical arrangement is for the ISP to provide customers with a dashboard (web interface) to make and manage their registrations.

Technologically speaking, DNSSEC is very secure. The protocol is well designed and the 'chain of trust' is cryptographically watertight.

However, the system is inevitably as secure as its weakest link. At the moment, clients remain the weakest link in the chain. So, for example, if a PC is infected with malware, it will be possible for the malware to manipulate both the resolver (the part of the client's operating system that is responsible for translating domain names into IP addresses) and the local cache.

Another important dimension is the security of the registration of key material with SIDN, the organisation that runs the .nl domain. If the registration security were breached, someone could change a domain name's DS record or add an extra key/signature. To the outside world, the presence of additional key material would merely give the impression of a transfer in progress, but people visiting the domain would be vulnerable to man-in-the-middle attacks.

Registered key material could in principle be modified by a hacker, an SIDN employee, someone working in the supply chain (internet service provider - registrar), or at the request of a government agency.

The security of the key material (DNSKEY/DS records) held by SIDN satisfies strict requirements. What's more, SIDN is certified under ISO 27001, an information security standard. The systems for signing secure records were until recently used mainly by banks. They are validated in accordance with FIPS 140 and safeguarded by extensive security procedures.

Since its foundation in 1996, SIDN has always been a completely independent and impartial organisation. It operates primarily in the interests of registrants, registrars and internet service providers. A court order would be required to make SIDN interfere with the key material entrusted to it, and that has never yet happened.


DNSSEC and beyond

DNSSEC is about much more than securing DNS records. DNSSEC provides an infrastructure suitable for future use by numerous other protocols for the cryptographically secured exchange of information, and in the reinforcement of existing internet protocols.

The DKIM/SPF/DMARC protocols (which protect against phishing, spam and virus/malware distribution by securing the sender, mail host and contents of a message) are a good example. To enable those protocols, various additional DNS records are utilised. Although signing with DNSSEC is not strictly necessary for that, it represents an important addition to the mechanism.

Another example is the DANE protocol, which serves to enhance the security of encrypted internet connections. The associated TLSA record forms an additional trust chain for the X.509server certificates used when establishing a TLS/SSL connection. The use of DNSSEC is therefore a mandatory feature of the DANE standard, as defined in RFC 6698.

DANE

DANE, short for DNS-based Authentication of Named Entities, is a protocol for the secure publication of public keys and certificates. The standard utilises the cryptographically secured DNS infrastructure provided by DNSSEC.

To enable DANE, the DNS protocol has been extended by the addition of a TLSA record. That can be used to link key information — e.g. a hash code (digital extract) — to an address-protocol-port combination. It is then possible to verify the authenticity of an encrypted internet service's server certificate via the DNS. If the hash code of the server certificate doesn't match the hash code in the TLSA record, the client knows that the connection is not trustworthy, despite the encryption.

Although DANE is more widely (i.e. generally) deployable, the protocol is used mainly in the world of web certificates (HTTPS) and mail transmission security(SMTP). The latter application in particular has gathered momentum in recent years, since support for DANE authentication was added to the Postfix mail server (the second most widely used MTA after Exim). Exim support for DANE is currently still experimental. In addition, the implementation of DANE authentication in IndiMail (a reincarnation of qmail) is in the pipeline at the time of writing (spring 2018). Support for DANE by OpenSSL (from version 1.1) has made such implementations much easier.

In March 2017, the National Cyber Security Centre (NCSC) published the factsheet Securing Mail Server Connections. The factsheet recommends enabling STARTTLS and DANE to secure mail transmissions. In the same month, the government and the business community started the Secure E-mail Coalition. The coalition's members have committed to progressing the implementation of protocols such as DNSSEC, DANE and STARTTLS within their own organisations and amongst their associates. Six months earlier, the Forum for Standardisation added STARTTLS and DANE to the 'use-or-explain' list. The effect of that move was to more or less oblige government organisations to implement the two security standards in their mail infrastructures.

For their HTTPS connections, web browsers are currently completely dependent on security at the nearly one hundred Certificate Authorities (CAs). However, the DigiNotar fiasco [1, 2], which involved a hacker generating more than five hundred authenticated certificates, demonstrated that the system is only as secure as the most insecure CA. Smaller but comparable incidents have occurred at Comodo (Tweakers.net), Flame (Tweakers.net), Trustwave (Heise Online), MCS () and Turktrust.

DANE for web provides a parallel security infrastructure (chain of trust) for X.509, to give the certificate system its formal name. For many applications, the system will soon be able to fully replace X.509, rather than merely supplement it. If DANE for web had been in use, the DigiNotar affair would not have happened.

DANE for mail is what's known as an 'opportunistic protocol'. In other words, a client that already supports DNSSEC, DANE and STARTTLS has to encrypt its connections with a server that supports STARTTLS and makes TLSA records available. However, if any of the support elements is missing, client and server fall back to TLS without DANE or even to insecure transmission. In the context of e-mail, message delivery has always been prioritised over transmission security.

Nevertheless, the presence of a TLSA record implies that the mail server does support TLS, so a downgrade attack on the server's STARTTLS capability is prevented.

The Postfix mail server (the most widely used MTA after Exim) can be configured to go through a DANE authentication procedure before delivering mail to an MX gateway. Creating a TLSA record for the MX gateway on port 25 therefore yields an immediate and definite improvement to security.

In principle, a TLSA record can be created for any mail server that offers a secure connection based on TLS or STARTTLS. The Postfix mail server (the most widely used MTA after Exim) can also be configured to go through a DANE authentication procedure before delivering mail to an MX gateway. Creating a TLSA record for the MX gateway on port 25 therefore yields an immediate and definite improvement to security.

Detailed information about configuring DANE for mail is provided in this (Dutch) hands-on article:

Although DANE for web and DANE for mail appear very similar, there are also significant differences. Starting a URL with 'https' indicates that TLS must be used, but there is nothing comparable for mail. Neither the mail address used nor the associated MX records indicate anything about how the transmission is secured. Nevertheless, the presence of a TLSA record does imply that the SMTP gateway does support TLS, so a downgrade attack on the gateway's STARTTLS capability is prevented. However, the use of TLS by the client is optional, meaning that DANE for mail is a so-called 'opportunistic protocol'. In other words, a client that already supports DNSSEC, DANE and STARTTLS has to encrypt its connections with a server that supports STARTTLS and makes TLSA records available. However, if any of the support elements is missing, client and server fall back to TLS without DANE or even to insecure transmission. Message delivery without human intervention can therefore proceed wherever possible.

DANE usages 0 and 1, where the TLSA record is used to provide additional anchorage for a server certificate, cannot be used in DANE for mail. In a mail context, PKI-anchoring has no advantage over a self-signed certificate with a TLSA anchor. The reason being that, if the DNS has been compromised, the attacker can modify the TLSA records (with usage 2 or 3) so that validation of the PKI chain of trust is not required.

Although a similar argument may be made in relation to DANE for web, the authors of RFC 7672 assume the current situation, where mail clients (unlike web browsers) do not have a broadly standardised set of trust anchors. Furthermore, HTTPS and SMTP+TLS play different roles: for web transactions encryption is crucial, but with mail reliable delivery is normally more important than secure transmission. Hence, opportunistic security fallback is preferable to the message bouncing. DANE for mail is designed to add transparent security that requires no additional configuration, trust anchors or user interaction. Its designers do not therefore regard DANE as a supplement to PKI-anchoring, but as the successor to and replacement for that technology.

The DANE standard requires that, with usages 0 and 1, both chains of trust must be validated. That can be problematic if one chain can be validated but the other cannot. In the future, the internet user may be shown a pop-up warning and given the option of continuing, as currently happens if there is an issue with a TLS certificate.

Although DANE for the web is regarded as the successor to and replacement for the flawed CA system with its known security issues, the EV certificates in particular still have added value. Also, because browsers that don't support DANE and show warnings about self-signed certificates are likely to remain in use for years to come, CA certificates are not expected to fall out of use in the near future.

At the time of writing (spring 2018), the DANE protocol has not been formally adopted as an internet standard. However, RFCs 6698, 7218, 7671 and 7672 provide an almost complete technical specification of the DANE protocol.

RFC 7673 and RFC 7929 define the use of DANE for, respectively, SRV records (to support various communication protocols) and OpenPGP (anchoring public keys using OPENPGPKEY records).

In principle, a TLSA record can be created for any web server that offers a secure connection based on HTTPS.

Detailed information about configuring DANE for web is provided in this (Dutch) hands-on article:

Additional (Dutch) information is available here.

At the time of writing (spring 2018), we are not aware of any widely used web browsers that offer out-of-the-box DANE authentication of the certificates for their HTTPS connections. However, a plug-in is available that validates both DNSSEC and DANE. It has been developed by the Czech registry and is available for all popular browsers:

www.offerman.com-FFplugin

In principle, a TLSA record can be created for any mail server that offers a secure connection based on TLS or STARTTLS. The Postfix mail server (the most widely used MTA after Exim) can also be configured to go through a DANE authentication procedure before delivering mail to an MX gateway. Creating a TLSA record for the MX gateway on port 25 therefore yields an immediate and definite improvement to security.

Detailed information about configuring DANE for mail is provided in this (Dutch) hands-on article:

At the time of writing (spring 2018), we are not aware of any mail clients that validate the certificates for their POP, IMAP or SMTP connections.


DKIM, SPF and DMARC

The DKIM, SPF and DMARC protocols protect against phishing, spam and virus/malware distribution by securing the sender (the sending e-mail address), the host (the sending e-mail system) and the contents of the message. To enable those protocols, various additional DNS records are utilised. Although signing with DNSSEC is not strictly necessary for that (i.e. required by the standard), it represents an important addition to the mechanism.

The DKIM/SPF/DMARC protocols represent the first practical application of the cryptographically secured infrastructure provided by DNSSEC.

The three protocols are normally used together, but they don't have to be. You can use DKIM or SPF on its own, or DKIM and SPF together without DMARC.

With DKIM, a digital signature is attached to the body and header of each outgoing message. The public key is published via the DNS, so that a receiving MX gateway can verify the digital signature. The system prevents a fraudster sending a message as if it came from someone else (mail spoofing) or interfering with the contents of a message in transit (message integrity).

>SPF enables MX gateways to refuse e-mail messages from unauthorised servers. A list of valid sending addresses is published via the DNS. The listed addresses are typically the SMTP gateways that end users use for their outgoing messages, but may also include the addresses of external service providers that send marketing mail for the organisation. Receiving systems can check incoming messages against the published list and refuse any that come from unlisted servers.

DMARC is a supplement to the other two mail security protocols, DKIM and SPF. DMARC lays down a policy (i.e. instructions) telling receiving MX gateways what to do with any messages that cannot be validated in accordance with DKIM or SPF. That might involve discarding or quarantining all non-validated mail, for example.

The policy is published via the DNS. It may also include an e-mail address to which mail systems can report rejected messages. The mail domain's operator can then monitor the delivery of both genuine and falsified messages.

The portal dmarcian.com offers a subscription service where incoming DMARC reports can be processed to yield well-presented statistics and diagrams.

dmarcian.com-screenshot

The DKIM-SPF-DMARC combination enables much more efficient mail processing. Large-scale mail processors can divide incoming messages into two general categories: those from unauthenticated domains or previously unencountered authenticated domains and those from known benign mail domains.

Processing of the second category is straightforward: the messages can be delivered without more ado. Messages from insecure and unfamiliar domains require thorough checking. Resources can therefore be concentrated where they are needed. It also pays to delay the decision briefly, since a zero-day will not appear on any list. It is very likely that the classification of such a message will be much easier a short while later. SpamAssassin doesn't yet offer out-of-the-box support for that approach. However, the Trusted Domain Project provides all the tooling required to set it up yourself.

The rapid adoption of DKIM/SPF/DMARC has been driven mainly by the big mail processors, who had a serious problem with phishing mail. Being relatively young businesses, social media companies such as Facebook (by far the biggest mail processor in the world) generally have well-consolidated mail infrastructures. It was therefore relatively easy for them to implement DMARC.

Another group that uses e-mail on a large scale are mail marketing companies — legitimate spammers, if you like. They have a strong interest in ensuring that their messages arrive safely. And, inevitably, such companies have well-defined, modern mail infrastructures.

The more mail processors implement DKIM/SPF/DMARC, the more important it becomes for domain name registrants to publish DNS records. Because failure to follow the trend means risking the non-arrival of your mail.


Legacy

The milestones in the rollout of DNSSEC in the Netherlands were as follows (in Dutch):

DNSSEC validation errors are caused by a mismatch between the cryptographic (public) key registered with the parent domain and the (private) key actually used to sign a zone. Due to the mismatch, it is not possible to complete the chain of trust and validating resolvers will therefore block traffic to the relevant domain name. The same situation arises if a key is registered in the parent domain but the zone is not signed (any longer). Both issues result in a 'bogus domain' error.

By blocking domains under the circumstances described, DNSSEC is doing exactly what it is designed to do: treating DNS information that isn't signed correctly as untrustworthy. Nevertheless, 'false positives' cause a lot of annoyance. An internet user who can't reach a particular domain (while the users of non-validating DNS servers can) is liable to call their access provider for assistance. Only to discover that the provider can't help, because the problem is caused by a configuration error that, in most cases, someone else is responsible for. In the early stages of the DNSSEC rollout, the number of validation errors in the .nl zone was relatively high. As a result, some access providers decided against enabling DNSSEC validation on their caching DNS servers, or even reversed an earlier decision to enable validation.

Most bogus domain names are the result of a transfer from one registrar to another. The default setting in the Domain Registration System (DRS) resulted in the old registrar's key material being retained by SIDN unless the new registrar deliberately removed it.

Our own research revealed that the problem was associated mainly with registrars that had numerous resellers. In other words, the relatively high number of erroneous DNSSEC domains at that time wasn't due to any unwillingness of the registrar to do the right thing or lack of professionalism, but was a consequence of a popular business model within the industry.

The initially high number of DNSSEC configuration errors in the .nl zone was a brake on the rollout of validation by access providers. We therefore made a big effort to bring down the number of errors. The registrars responsible for the most validation errors were made aware of the configuration errors in their portfolios, in some cases by calling them individually.

Initially, we identified problems from resolver logs made available for the purpose by a few large access providers. Now, however, we our own Validation Monitor XXL, which scans all .nl domains for validation errors every night. The findings are also used in the context of our incentive scheme, the Registrar Scorecard (RSC).

The number of DNSSEC-signed domains that give rise to validation issues is now a tiny fraction of what it was some years ago. Validation errors are no longer an obstacle to access providers enabling validation. Furthermore, as the number of validating providers has increased, the impact of a configuration error is increasingly felt by the party responsible for it: the registrar and operator of the relevant domain. Their customers will complain about being unreachable for many internet users.

Before SIDN made it possible to sign any .nl domain with DNSSEC in 2012, early adopters and enthusiasts were able to submit public keys for their .nl domains. The keys were manually checked by SIDN and uploaded to the name servers for the .nl domain. Once it became possible for all registrars and internet service providers to offer DNSSEC to their customers, the Friends & Fans Programme (as the old manual system was known) was withdrawn.

The public keys for .nl domains managed by the nine registrars that had acted as DNSSEC launching partners where then transferred to the new system. Registrants of domain names managed by other registrars had to resubmit their public keys through their registrars or internet service providers (if or once the registrar or service provider supported DNSSEC).

DLV, short for Dynamic Lookaside Validation, is a method for looking up and validatingDNSSEC records in an alternative zone (dlv.isc.org). Before the root zone (.) was signed in 2010, this 'hack' was used as a roundabout way of securing the entire DNS tree to a single trust anchor.

To make the system possible, the Internet Systems Consortium (ISC) (whose credits include the development of BIND named) maintained an alternative repository for key material. DNSKEY records (the same records that SIDN uses for the .nl domain) could be submitted for addition to the repository. They then served as input for the DS records ultimately published by the registry. Subdomains of dlv.isc.org. authenticated the submitted records for their local root by adding a special TXT record to their name servers.

In that way, various DNS subtrees that could not be validated by reference to the absolute root (so-called 'islands of trust') could nevertheless be provided with a common trust anchor. However, because the chain of trust ran via an alternative route, validation always involved sending extra DNS queries relating to a completely different zone.

Although ISC originally developed DLV as part of the BIND software, the protocol (as defined in RFC 5074 and RFC 4431) was also supported by some other DNS packages, including Unbound (Men & Mice). The support for DLV was limited, however.

The signing of the root zone (.) in 2010 meant that there was a single, official trust anchor available for use by everyone. In principle, therefore, DLV should have become obsolete at that point. However, it remained relevant because many top-level domains were not signed until several years later.

In 2014, support for DNSSEC (and IPv6) became mandatory for new top-level domains. At the time of writing (spring 2018), 1400 of the 1544 top-level domains are signed. Nevertheless, out of the twenty-eight EU countries, three — Cyprus (.cy), Malta (.mt) and Slovakia (.sk) — have yet to sign their top-level domains. Other TLDs that don't yet support DNSSEC include Turkey's .tr domain.

Although the DLV root remains part of BIND's trust anchor file, DLV functionality should no longer be used. In 2016, ISC stopped registering new domain names whose top-level domains support DNSSEC, and removed previously registered domain names whose top-level domains support DNSSEC from the repository. Then, in 2017, the DLV repository was completely emptied. Nevertheless, the (now redundant) service remains live for the time being.


More information

On the Internet.nl portal, you can test your connections and domains to see whether they are using six modern internet standards: IPv6, DNSSEC, HTTPS, DMARC, STARTTLS and DANE. The test results are delivered in the form of a score, which serves as a quantitative indication of compliance.

Sorry

Your browser is too old to optimally experience this website. Upgrade your browser to improve your experience.