DNSSEC

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.

DNS is one of the oldest internet protocols still in use. It was developed in the 1980s, nearly 40 years ago (the oldest RFCs, 882/883, date from 1983, and the oldest currently in use, 1034/1035, from 1987.

Back then, the internet was largely the preserve of the academic community, and its users often collaborated on the basis of mutual trust. Consequently, security was not a priority when those protocols were developed, let alone an integral feature of them, as it is of modern protocols.

Despite its age, DNS remains one of the internet's most important protocols: if the DNS were to cease working, the internet would effectively cease working.

And any criminal who was able to 'crack' the DNS, would have the world in the palm of their hand.

Because the DNS is such an old and fundamental feature of the internet, security was developed for it relatively late. The basis for DNSSEC as it is used to day is defined in RFC 4033, 4034 and 4035, all of which date from 2005. By way of comparison: SSL (the predecessor of TLS, the protocol that secures web traffic) dates from 1995.

Although the Netherlands has pioneered the use of DNSSEC, its global adoption (particularly by registrants) remains very low.

Furthermore, DNSSEC protects only the authenticity (integrity) of DNS information, not its confidentiality. Extensions to the DNS that protect the transport of DNS information were developed only in recent years:

• DNS over TLS (DoT): RFC 7858 and 8310 from 2016/2018

• DNS over HTTPS (DoH): RFC 8484 from 2018

• DNS over QUIC (DoQ): RFC 9250 from 2022

The primary purpose of DNSSEC was to assure the authenticity of DNS information, thus preventing DNS spoofing.

Given the hugely increased need to secure digital points of entry, that is important for registrants:

• It important for businesses, because a lot of interaction with customers, partners and suppliers has already moved to the internet.

• It important for government bodies and other organisations that make increasing use of the internet to communicate with each other and with the public.

• It important for individual internet users, who 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.

That has implications not only for the service provider, but also for internet users, due to their growing reliance on the internet as a platform for storing valuable information and performing financial transactions. It is nowadays normal to bank online, invest online and pay for goods and services online, for example. DNSSEC serves to assure internet users that they aren't being misdirected.

Furthermore, the addition of cryptographic security to DNS information means that the DNS infrastructure is now also suitable for the distribution of other types of information whose authenticity needs to be guaranteed. DNSSEC therefore opens the way for a wide range of new internet applications, such as:

• SPF, DKIM and DMARC

• DANE

• SSHFP

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 point of entry. Online 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 DNS information, while it's on the DNS server, while it's in transit, or after it reaches the client, the client can be directed to a fake server (DNS spoofing). 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 authoritative name server and the transport 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 online, invest online and pay for goods and services online. 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 DNS information, while it's on the DNS server, while it's in transit, or after it reaches the client, the internet user can be directed to a lookalike 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. The visitor is therefore likely to go ahead and use the fake site, giving the scammers log-in details or sensitive personal or commercial information.

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

Absolutely.

• DNSSEC has been around in its current, modern form for more than 15 years. The basis for DNSSEC as it is used to day is defined in RFC 4033, 4034 and 4035, all of which date from 2005. The .nl zone has supported DNSSEC since 2012.

• DNSSEC support (signing) was made mandatory by ICANN on 1 January 2014, meaning that at least all new gTLDs have since been required to support this security technology. As of December 2022, DNSSEC (signing) is supported by more than 90 per cent of all ccTLDs. Usage of DNSSEC within the TLDs varies enormously, however. When it comes to signing domain names, the Netherlands is a world leader: by December 2022, nearly 60 per cent of all .nl domains were DNSSEC-enabled.

• Globally, roughly 30 per cent of internet users were using validating resolvers in December 2022. In Europe, use of DNSSEC validation is now above 40 per cent. With an adoption level of roughly 60 per cent, the Netherlands is now finally on a par with neighbouring countries where DNSSEC validation is concerned.

• DNSSEC is supported by all actively maintained DNS server and resolver software, with the exception of dnsmasq (forwarding only) and djbdns (outdated). Moreover, the various servers and resolvers are fully interoperable. Popular software consequently no longer requires interoperability testing prior to business deployment.

• DNSSEC is supported by all main network management software and tools as well. That includes provider platforms such as Plesk, cPanel and DirectAdmin.

• DNSSEC is supported by all the main operating systems, including both open-source and proprietary systems.

• DNSSEC is supported by most registrars and resellers active on the Dutch market. Customers who manage their own zones can therefore add key material (DS records) to the parent zone (typically in the control environment for NS amendments), while those who delegate zone management to their registrar can easily have them signed.

• DNSSEC-related knowledge, experience and support are widespread amongst vendors and service providers.

In other words, DNSSEC is a proven, robust technology. Consequently, investment in and migration to DNSSEC involve no technological risk.

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, DNSSEC (and DKIM) were added to the so-called 'use-or-explain' list (Dutch acronym: ptolu) by the Forum for Standardisation, which is an agency of the Ministry of Economic Affairs and the Ministry of the Interior. 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 DANE were also added to the 'use-or-explain' list. DMARC then followed in 2018. All those standards, which serve to secure mail transmissions [1, 2], are based on DNSSEC's cryptographic infrastructure.

The Dutch government is currently finalising the Generic Digital Infrastructure Act (Dutch initials: WGDI). One option under consideration is to make all the standards 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.

A Joint Ambition Statement that includes implementation deadlines for modern (security) standards has additionally been agreed with the Pan-governmental Digital Government Policy Liaison Forum (OBDO). Given that the newest Ambition Statement, regarding IPv6 , expired at the end of 2021, all government domains should now support modern internet standards. In recent years, however, adoption of all the standards has faltered [1, 2].

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 operator/registrar to another without interrupting their secure status was devised largely by SIDN Labs before being formalised in RFC 6781. To make secure transfers possible, an extension to the EPP protocol was also developed, so that key material can be transferred from the old operator to the new operator via the registry. That methodology has since been standardised in RFC 8063).

In addition, SIDN has promoted the adoption of DNSSEC by offering financial incentives. By giving registrars a rebate on the cost of DNSSEC-enabled domains, we sought to help tip the balance in favour of investment in DNSSEC.

The DNSSEC incentive was subsequently scaled back, then superseded by a broader scheme. Starting in 2023, at least a certain percentage of a registrar's .nl domain names have to be DNSSEC-enabled for the registrar to qualify for the other RSC incentives (for e-mail security, IPv6 support and active use).

The original DNS protocol is vulnerable, but not insecure. Despite its age, the protocol has proven to be surprisingly resistant to the falsification of DNS information (DNS spoofing). Over the decades, various attack methods have been devised, but they were not easy to execute and/or relatively easy to counter. In practice, therefore, attacks have been rare.

Malicious manipulation of the protocol was regarded as merely a theoretical possibility until 2008, when Dan Kaminsky demonstrated a serious flaw in the system's design. By exploiting the flaw, hackers could inject false information into the caches of the most popular DNS servers in real-life situations.

After the Kaminsky attack was published, things were relatively quiet on the DNS front for a long time. Then, in November 2020, DNS security hit the headlines again with publication of the 'SAD DNS' attack. The discoverers used a new side-channel to inject false DNS information into a caching resolver.

Exactly a year later, the same research team revealed another way of mounting a cache poisoning attack. Being conceptually the same as the previous attack strategy, the method was dubbed SAD DNS 2.0.

The two recently revealed attack methods involve identifying the resolver's ephemeral outbound UDP port. That enables an attacker to negate the original strategy for preventing classic DNS cache poisoning attacks and Kaminsky attacks, namely source port randomisation.

Clients currently represent easily the weakest point. However, as client security improves, hackers will inevitably turn their attention to DNS servers and the transport 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. DNSSEC is a security technology that provides a structural solution to such attacks. The reason being that a validating resolver will never accept the false

DNSSEC is a cryptographic mechanism for securing DNS information. Digital signatures are attached to a domain's DNS records, guaranteeing their authenticity.

DNSSEC is a forward-compatible extension to the original DNS protocol. In other words, DNSSEC can be implemented without needing to scrap your existing DNS infrastructure. Despite being a large and complex extension, DNSSEC is very precisely integrated with the existing DNS protocol.

The DNSSEC security mechanism depends on two things:

• Digital signatures must be applied to the records on a domain's authoritative name servers.

• Resolvers that request DNS information about the domain have to check the signatures on the records sent back to them.

If either of those things isn't done – if the zone isn't signed or the resolver doesn't validate the signatures – DNS records are requested, exchanged and processed in the traditional way. Therefore, for outdated name servers and resolvers that are not configured to use DNSSEC, it is a completely transparent extension to the DNS.

DNS name servers that support DNSSEC offer the possibility of signing the zones they serve. Signing implies attaching digital signatures to all the DNS information in the zone (in the form of RRSIG records).

Because all DNS information is requested, transported and processed in discrete bundles called RRsets, an RRSIG record is generated for each complete RRset. An RRSIG record is exactly like any other record type, implying that it is included in the zone and made available on request.

When looking up domain names, a DNSSEC-validating resolver requests not only the ordinary DNS records, but also the associated DNSSEC records (by setting a DO flag, part of EDNS0). If the zone a resolver enquires after is signed, each RRset returned by the name server has an RRSIG record. The resolver then uses the digital signature in the RRSIG record to check authenticity of the RRset's contents. The information received by the resolver is passed on to the requesting application (and saved in the resolver's cache) only if the digital signature matches the contents of the RRset (or if the zone contains no DNSSEC security information).

As well as the digital signatures (in the RRSIG records), the public key (in the form of a DNSKEY record) is added to the zone. The hash value (a digital extract) of the public key is published in the parent zone (in the form of a DS record). Because the DS record in the parent zone also bears a digital signature, its authenticity is guaranteed. Thus, a cryptographic chain of trust is established, consisting of RRSIG-DNSKEY-DS links leading all the way back to the root. The public key for the root zone is a 'well-known value' that is installed as a trust anchor on every validating resolver.

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

If both the registrant and the internet user support DNSSEC, both automatically benefit from the strong cryptographic security that DNSSEC adds to the DNS. With DNSSEC enabled on both sides, a client will block any address whose digital signature can't be verified. Meanwhile, users whose systems don't support DNSSEC will continue accessing signed domains in the same way as 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 (stub) 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 when an invalid server certificate is 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 ultimately providing greater security.

If both the registrant and the internet user support DNSSEC, both automatically benefit from the strong cryptographic security that DNSSEC adds to the DNS. With DNSSEC enabled on both sides, a client will block any address whose digital signature can't be verified. Meanwhile, users whose systems don't support DNSSEC will continue accessing signed domains in the same way as they always have.

DNSSEC is an important extension to the DNS. Its primary purpose is to assure the authenticity of DNS information, thus preventing DNS spoofing. Consequently, there are some issues that this security protocol doesn't address:

• Client is not secured: DNSSEC protects only the substance of DNS information, such as the signed data published on name servers and transported to the client. However, it doesn't secure the client (endpoint) itself. Consequently, if for example a PC is infected with malware, it is possible for the malware to manipulate both the (stub) resolver (the part of the client's operating system that is responsible for translating domain names into IP addresses) and the local cache. For instance, some malware can modify the hosts table, thus completely bypassing the DNS.

• Authenticity is assured, but not confidentiality: DNSSEC assures only the authenticity of DNS information. In other words, the digital signature guarantees that a DNS response received by a (validating) 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. That limitation is addressed by DoT, DoH and DoQ: extensions to the DNS that do protect the transport of DNS information. However, all are relatively new and are currently used largely at the application level (in web browsers).

• Cryptographically complete, not cryptographically watertight: Although the DNSSEC chain of trust is cryptographically complete, it is not cryptographically watertight. Every transition to a parent zone (or, strictly speaking, each delegation) represents an administrative pinch point: if the operator of the parent zone were to delete the DS record, DNSSEC protection in the child zone would be disabled, since the presence of a parent DS record is required for DNSSEC to function in the child zone. Other (more obvious) possibilities include the modification of a key and the addition of an extra DS record. Registered key material in the .nl zone could in principle be modified by a hacker, an SIDN employee, someone working in the supply chain (internet service provider/registrar/reseller), or at the request of a government agency. However, SIDN 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.

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

That limitation is addressed by DoT, DoH and DoQ: extensions to the DNS that do protect the transport of DNS information. However, all are relatively new and are currently used largely at the application level (in web browsers).

DNSSEC assures only the authenticity of DNS information. In other words, the digital signature guarantees that a DNS response received by a (validating) 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.

What's more, most clients contain only a stub resolver and leave recursive queries – and therefore validation – to the caching DNS servers assigned to them via DHCP or NDP by their internet access provider or network administrator. Hence, the pathway between stub resolver and DNS server – the 'last mile' – is not secured.

That limitation is addressed by DoT, DoH and DoQ: extensions to the DNS that do protect the (end-to-end) transport of DNS information. However, all are relatively new and are currently used largely at the application level (in web browsers).

When it comes to signing domain names, the Netherlands is a world leader: by December 2022, nearly 60 per cent of all .nl domains were DNSSEC-enabled. That's mainly down to the commitment of .nl registrars, many of whom have bulk-signed the domain names they manage since the official introduction of DNSSEC in 2012.

SIDN promoted the adoption of DNSSEC by offering financial incentives to registrars as part of the Registrar Scorecard scheme (RSC). By giving registrars a rebate on the cost of DNSSEC-enabled domains, we are trying to help tip the balance in favour of investment in DNSSEC. The DNSSEC incentive is now being scaled back in anticipation of its ultimate replacement by a broader scheme.

Although the proportion of domain names that are DNSSEC-enabled continues to rise, it is now rising very slowly: 1 or 2 percentage points a year for the last four years.

https://images.ctfassets.net/yj8364fopk6s/2b8zHsZDyQkjXEhfhjbCgS/7d6fd097a11867e0c50bca7edf463450/stats.sidnlabs.nl-DNSSECbeveiligd-20221206.png

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

As of December 2022, roughly 60 per cent of all queries received by the authoritative servers for .nl were from validating resolvers. Query traffic to the servers comes from resolvers not only in the Netherlands, but all over the world. The main sources were resolvers operated by the big cloud service providers: Google, Microsoft, Amazon and Cloudflare. Consequently, the biggest share of the query traffic (more than 25 per cent) was attributable to resolvers in the US, with only 10 per cent coming from resolvers in the Netherlands.

https://images.ctfassets.net/yj8364fopk6s/3sPTKJLK6Eu2uNL59EChQU/cf91cc308ce9c83f082eeb407c23a77b/stats.sidnlabs.nl-DNSSECqueries-20221206-EN.png

https://images.ctfassets.net/yj8364fopk6s/7D2KXaDwJMSCyPrjTLuNkk/582a9a77f05e4b32c3bbca0c44b32d70/stats.sidnlabs.nl-DNSSECresolverNetwerken-20220807-EN.png

https://images.ctfassets.net/yj8364fopk6s/1pT8G7bgFkpMaxxakRcKK4/96ec5fd8a711b1092eaa92802ec454ac/stats.sidnlabs.nl-DNSSECresolverLocations-20221206-EN.png

When it comes to DNSSEC validation, the Netherlands lagged behind other countries for a long time. For Dutch internet users, the problem was that the two biggest access providers in the Netherlands, KPN and Ziggo, didn't support validation on their DNS servers. Although KPN finally enabled validation for KPN/Telfort customers in 2020, VodafoneZiggo still doesn't support validation. Consequently, roughly 60 per cent of Dutch internet users now utilise validating resolvers.

https://images.ctfassets.net/yj8364fopk6s/5DVqp8ensDxctdx4bK9CSB/dd2388357fc820d971ea0800d0927809/stats.sidnlabs.nl-DNSSECresolverNLnetwerken-20221206-compleet-EN.png

https://images.ctfassets.net/yj8364fopk6s/3Zty47erq7Fr75yrBpmPhU/098c1814f57bb52aabe481c939fc8392/APNIC-DNSSECvalidationNL-20221206.png

https://images.ctfassets.net/yj8364fopk6s/7AfiaBOmZRqGKBMoCbJRB2/eaeb6e41e2d390a342b16353190bd606/APNIC-DNSSECvalidationKPN-20221206.png

https://images.ctfassets.net/yj8364fopk6s/3cXgSNqzOct00oJoI9A51Q/e9319212a6f4579333af5c2d043fdfee/APNIC-DNSSECvalidationVodafoneZiggo-20221206.png

The Dutch government has played an important pioneering role in the adoption of DNSSEC. In 2012 – a month after DNSSEC's formal introduction – the Forum for Standardisation added DNSSEC (and DKIM) to the so-called 'use-or-explain' list, known by the Dutch abbreviation 'ptolu'. 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 Platform for Internet Standards [1, 2] and the Internet.nl portal. Via the portal, users can test connections and domains to see whether they are using 6 modern internet standards: IPv6, DNSSEC, HTTPS, DMARC, StartTLS and DANE. The test results are delivered in the form of an overall 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.

While the adoption of DNSSEC is now proceeding relatively well in the Netherlands, the global picture is much less rosy. Usage of DNSSEC within top-level domains (i.e. the signing of domain names) is particularly disappointing.

ICANN made DNSSEC support mandatory on 1 January 2014, meaning that at least all new gTLDs have since been required to support this security technology.

As of May 2024, DNSSEC (signing) is supported by more than 90 per cent of all ccTLDs. As the following map shows, it is mainly ccTLDs in the Africa and the Middle East that don't yet support DNSSEC.

https://images.ctfassets.net/yj8364fopk6s/3ovMRCMnTRRwPFkutj40uv/6d09badf8d716ef0ec6771505ec05211/ISOC-Pulse-DNSSEC-20221208.png

Usage of DNSSEC within the TLDs varies enormously and is highly dependent on:

• Financial incentivisation by the registry

• Where ccTLDs are concerned: the number of major access providers active in the region and their policies

• Government policy on modern internet security standards in general and DNSSEC in particular

The graph below shows the development of DNSSEC in the European ccTLDs with the best adoption rates, as of August 2022. Like the Dutch .nl zone, the Czech (.cz), Norwegian (.no) and Swedish (.se) zones all have adoption rates exceeding 50 per cent, as does the .nu domain, which is popular in the region. Notable climbers include Switzerland (.ch) and Denmark (.dk).

For some years, SIDN has been a major contributor to development of the DNSSEC standard, as have the Swedish registry Internetstiftelsen and the Czech registry CZ.NIC. SIDN has also supported the development and deployment of DNS(SEC) software by various direct and indirect means: the widely used packages PowerDNS [1, 2], Unbound, NSD and OpenDNSSEC were all developed in the Netherlands, for example.

CZ.NIC has pursued similar policies with the development of Knot DNS, Knot Resolver and the DNSSEC/TLSA Validator (the last of which is no longer being updated).

Most importantly, however, the Swedish, Czech and Norwegian registries, like SIDN, operate financial incentive schemes; a similar scheme now also applies to the .nu zone, which is operated by the Swedish registry.

The influence that active registry involvement and incentivisation have on the adoption of DNSSEC is underscored by the extension's use – or lack of it – in the international gTLDs .com, .net, .org and .info: in all those zones and many others, DNSSEC is barely used at all.

https://images.ctfassets.net/yj8364fopk6s/12JnSQ8oVt3pfd5bxgZgKq/7cca57394e51aeb5fdb79c98c942f4f5/diagram_grouped-screenshot2.png

Globally, roughly 30 per cent of internet users were using validating resolvers in December 2022. However, after being stalled by COVID, adoption has increased by 5 percentage points over the last year.

https://images.ctfassets.net/yj8364fopk6s/6pJMKoN5oXoU6JuqDY9Kqi/2d16910af69972d80a6c1d01896f4859/APNIC-DNSSECvalidationWorldXA-20221206.png

In Europe, use of DNSSEC validation is now above 40 per cent, and adoption has accelerated over the last year.

https://images.ctfassets.net/yj8364fopk6s/KVa1WLeRi0R8zO7RiKgCB/3d47544e004cf16837a9bf5a4a7cea42/APNIC-DNSSECvalidationEuropeXE-20221206.png

With an adoption level of roughly 60 per cent, the Netherlands is now finally on a par with neighbouring countries where DNSSEC validation is concerned. The Scandinavian countries are doing considerably better, while the South European nations and GB/IE are a good way behind us.

https://images.ctfassets.net/yj8364fopk6s/33G7mG2tflUs9PDasYcZmS/58f5f3bb7ee50100df41d82a411d6413/APNIC-DNSSECvalidationEuropeXEmapNL-20221206.png

The infrastructure and facilities for signing .nl domain names have been fully operational since 2012. In principle, therefore, DNSSEC security can be enabled for any .nl domain name. 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 operator, they have to sign the domain name 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 you manage your own DNS information – operate your own DNS servers, in other words – implementation starts with the generation of a cryptographic key pair. The private key is used to sign the resource record sets (RRsets) in your domain name's zone file. The public key then has to be uploaded to SIDN using you registrar's or internet service provider's admin dashboard. The interface that we make available to registrars in our role as operators of the .nl top-level domain supports key uploading. Registrars and internet service providers can therefore enable customers to provide 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 things such as generating key pairs and signing records. For example, BIND (named), the world's most popular DNS server with operators other than major registrars, is supplied with dnssec-keygen (for generating cryptographic key pairs) and dnssec-signzone (for signing records) as standard.

Although the latest versions of BIND offer increasing scope for the comprehensive automation of signing and key management, we would advise anyone with a large installation to use BIND 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 became outdated some time ago, prompting us to recommend that it should no longer be used for new implementations.

Over the years, SIDN has published quite a number of 'hands-on' guides to DNSSEC signing in the most popular auhoritative name server software. An overview of the various software packages, and the key features of each, is provided below. If you are still considering which DNS(SEC) solution to use, you will hopefully find the summary useful.

• Infoblox appliance These ready-to-use systems are popular mainly with large commercial organisations. Signing a zone involves merely clicking a button. However, both times that we looked at this appliance (most recently in summer 2018), we were obliged to conclude that the software was seriously behind the times, at least where DNSSEC was concerned.

• BIND named BIND named is the de facto (open-source) standard on Linux and other Unix-type systems, and therefore the most widely used DNS server software (except amongst major registrars). From version 9.11, key management can also be fully automated. As a result, it's no longer necessary to use custom scripts and cron jobs, or to go over to OpenDNSSEC. Following initial configuration, key pair generation, zone file signing, key rollover and key management can all be handled automatically by the software.

• PowerDNS Authoritative Server PowerDNS is a Dutch (open-source) product whose popularity owes much to its support for DNSSEC. When support was introduced, the signing of domains on other authoritative servers was quite cumbersome. By contrast, PowerDNS adopted a turnkey approach from the start. Other distinctive features include scalability and speed. Almost all major service providers that wanted to bulk-sign their domains did so using the Authoritative Server. Although the software's architecture is elegant, the extensive nature of the package can mean that it takes a while to become familiar with it.

Over the years, SIDN has published quite a number of 'hands-on' guides to DNSSEC signing on authoritative name servers:

• DNSSEC signing in BIND named

• DNSSEC signing on the PowerDNS Authoritative Server

• DNSSEC signing on an Infoblox appliance

An overview of the various software packages, and the key features of each, is available here.

SIDN also publishes a steady stream of DNSSEC-related news bulletins, technical articles, reports and case studies on sidn.nl.

Operators who want to check that DNSSEC is working properly can do so by using the tools provided with their DNS servers, or using the popular BIND network tool dig (with the '+dnssec' option).

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

• https://dnssec-debugger.verisignlabs.com/

https://images.ctfassets.net/yj8364fopk6s/5JHGRLGjWF04p12XVv4Vay/336e53671245d235764b8817474da49e/dnssec-debugger.verisignlabs.com-sidn.nl-screenshot20230202.png

And Sandia's DNSViz provides an attractive graphic overview:

• https://dnsviz.net/

https://images.ctfassets.net/yj8364fopk6s/R5iirPB9q16YszMK9qwgO/dc4528a156aae414ed2259ee95648610/DNSViz-sidn.nl-2023-01-23-08_47_03-UTC.svg

SIDN Labs has also made a tool available online, which lets you check a list of domain names in one go. The tool is due to be phased out in the course of 2023, but in the meantime you can find it here:

• DNSSEC Portfolio Checker

On the Internet.nl portal, you can test your connections and domains, to see whether they're using 6 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 6 modern internet standards: IPv6, DNSSEC, HTTPS, DMARC, StartTLS and DANE. The test results are delivered in the form of an overall score, which serves as a quantitative indication of 'compliance'. Their Connection Test is specifically for testing user-side support for DNSSEC (and IPv6):

• https://conn.internet.nl/connection/

NB: If the results indicate that DNSSEC isn't supported, that doesn't necessarily mean that there is a problem with your (stub) 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 access provider (via DHCP).

Authoritative name server operators have to change the cryptographic key pairs for their signed zones on a regular basis.

The keys are often changed as part of periodic updates. An update is sometimes desirable for security reasons. That can be the case if the key length no longer meets modern requirements, or the algorithm is no longer secure, for example. Periodic updating can also be used to minimise the risk of a successful 'brute force' attack. Another reason for performing an update is so that the rollover procedure is sufficiently well-practised to ensure that it goes smoothly in an emergency situation, as with a fire drill. Keys are also changed when a domain is transferred to another operator/registrar. A situation may also arise where new keys are urgently required because private key material has been leaked or otherwise compromised.

A smooth change to a new key pair ensures that the DNS service remains available to everyone, and the domain's DNSSEC security is not interrupted.

However, you can't simply take down cryptographic material published in the DNS, and replace it with new material. Like all other DNS records, DNSSEC records are cached by resolvers, meaning that old information remains in use around the internet for a while – in the case of a DNSSEC record, for the time specified in the record's TTL value.

Keys are therefore changed by following a procedure called a rollover. A rollover involves first introducing and propagating a new key, and subsequently withdrawing the old key. During a rollover, therefore, 2 (partial) sets of DNSSEC records are temporarily in use alongside each other.

It's important to understand how rollovers work and why they matter, because rollovers are also required in the context of other DNSSEC-based security standards.

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, ISC transferred 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. Against that backdrop, further development of Bundy currently remains stalled.

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:

• Hands-on: DNSSEC signing in BIND named

• Hands-on: DNSSEC validation in BIND named

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. That implies that all the authoritative name servers associated with the domain name itself must be secure, and so must the 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 DNSSEC validation – to the caching DNS servers assigned to them via DHCP or NDP by their access provider or network administrator. Such clients rely on the AD flag that the DNS servers set in their DNS responses following positive validation. Consequently, the pathway between stub resolver and DNS server – the 'last mile' – usually remains unsecured.

A few of the Netherlands' smaller access providers, including Freedom, BIT and Edutel, have supported DNSSEC validation since the early days. The country's 2 biggest access providers have dragged their heels, though. KPN finally enabled validation for KPN/Telfort customers in 2020. However, as of February 2023, Ziggo's DNS servers still didn't support validation.

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

An end user who wants a DNS resolver that's guaranteed to be secure should therefore install the de Unbound resolver or other validating resolver software. The installation and configuration of Unbound with DNSSEC-Trigger is described in this guide. Other options are also available to end users.

Finally, be aware that DNSSEC protects only substantive DNS information, such as the signed data published on authoritative name servers and transported to the client. It doesn't secure the client (endpoint) itself. Consequently, if for example a PC is infected with malware, it is possible for the malware to manipulate both the (stub) resolver (the part of the client's operating system that is responsible for translating domain names into IP addresses) and the local cache. For instance, some malware can modify the hosts table, thus completely bypassing the DNS.

Over the years, SIDN has published quite a number of 'hands-on' guides to DNSSEC validation in the most popular (caching) resolver software packages. An overview of the various software packages, and the key features of each, is provided below. If you are still considering which DNS(SEC) solution to use, you will hopefully find the summary useful.

• Unbound en DNSSEC-Trigger The Unbound validating resolver is a Dutch (open-source) package. If all you need is a validating resolver, Unbound is probably a better option than BIND named, and certainly much better than the stub resolvers supplied with Linux or Windows. The software is compact and fast, and Unbound is now the standard resolver on various Linux distributions, and on FreeBSD and OpenBSD. In combination with DNSSEC-Trigger, Unbound also serves as a very straightforward solution for end-to-end validation for mobile users.

• Infoblox appliance If you have a recent version of NIOS running, configuring DNSSEC validation on an Infoblox appliance should be very straightforward. All you need to do is check the default settings. However, we regard this option as useful only to organisations that are already using Infoblox. The reason being that both times that we looked at this appliance (most recently summer 2018), we were obliged to conclude that the software was seriously behind the times, at least where DNSSEC was concerned.

• PowerDNS Recursor PowerDNS is a Dutch (open-source) product whose popularity owes much to its support for DNSSEC. The Recursor supports DNSSEC validation from version 4.0. Its main difference from the Unbound resolver is that the settings in the configuration file are restricted to familiar server-related matters, whereas the configuration of Unbound involves a long list of options regarding both server-related and DNSSEC/protocol-specific matters. If you want to do more with PowerDNS Recursor, you can load separate start-up/run-time scripts for the built-in Lua engine.

• BIND named BIND named can function as an (authoritative) name server and/or as a (caching) resolver. Because the software has developed in step with DNSSEC, the validation functionality it provides depends very much on which version you have, just as the signing functionality does. If all you need is a validating resolver, Unbound is probably a better option.

This news bulletin refers to an evaluation of 6 widely used validating resolvers by network/infrastructure architect Tore Anderson. Unbound and the Knot Resolver emerged as highly recommended. Anderson reported that the latest versions of PowerDNS Recursor and Bind named worked well too, but had no advantages over Unbound or the Knot Resolver.

Over the years, SIDN has published quite a number of 'hands-on' guides to DNSSEC validation on (caching) resolvers:

• DNSSEC validation using Unbound and DNSSEC-Trigger

• DNSSEC validation on BIND named

• DNSSEC validation with the PowerDNS Recursor

• DNSSEC validation on an Infoblox appliance

An overview of the various software packages, and the key features of each, is available here.

SIDN also publishes a steady stream of DNSSEC-related news bulletins, technical articles, reports and case studies on sidn.nl.

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 validation (and the RRSIG records) by setting the DO flag (DNSSEC OK) – with the dig network tool, you can do that by using the '+dnssec' option. When responding with the DNS records, the DNS server can then send the AD flag as well. 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, section 3.1.6) states that authoritative name 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. According to RFC 6840, section 5.7, 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 RRSIG records themselves. The dig network tool now supports AD flagging with its '+adflag' option. The DO flag is still used as before to request RRSIG records.

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 (MITM)attack undetected by the client. In principle, neither the record contents nor any of the metadata (headers) can be trusted.

Although combining DNSSEC validation with DNS record caching seems like an obvious (and efficient) thing to do, it truncates the cryptographically secured DNSSEC chain. Ideally, the chain should extend all the way from the root zone (.) to the associated trust anchor on 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.

Various solutions to that 'last mile' problem were already available:

• DNS information exchange can be secured using TSIG (Transaction SIGnature). The TSIG protocol is often used for the exchange of DNS records between authoritative name 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 symmetric cryptography, implying that a shared private key has to be exchanged between client and server.

• By contrast, DNSCrypt is based on an asymmetric protocol, making it more suitable for securing the 'last mile'. 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, djbdns and EdDSA, for example. DNSCrypt is mainly supported 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.

Despite all the earlier initiatives and ideas, none of the technologies outlined above ultimately became established as the solution for last-mile security. Instead, the open standards DoT, DoH and DoQ have become the normal way of protecting the transport of DNS traffic. However, those standards are relatively new and are currently used mainly at the application level (in web browsers).

The AD flag can, however, be used without any other security measures on a network where the security of the last mile is assured. Examples include company networks, campus networks and the closed access networks belonging to internet access 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 or NDP by their internet access provider or network administrator. Such clients therefore rely on the AD flag that the DNS servers set in their DNS responses following positive 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 validation by the client will increasingly 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.

We are now seeing a prominent trend towards the use of DoT, DoH and DoQ in resolvers and applications. However, those technologies secure only transport between the resolver and application on the one side, and the configured DNS service on the other. They do not assure the authenticity of the DNS information; that still requires DNSSEC validation.

The expectation is that validation by the client will increasingly 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.

We are now seeing a prominent trend towards the use of DoT, DoH and DoQ in resolvers and applications. However, those technologies secure only transport between the resolver and application on the one side, and the configured DNS service on the other. They do not assure the authenticity of the DNS information; that still requires DNSSEC validation.

Network administrators who want to enable DNSSEC validation for their users can do so using BIND named, for example, or the PowerDNS Recursor [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 the Unbound resolvers or other validating resolver software. The installation and configuration of Unbound with DNSSEC-Trigger is described in this guide.

Other options available to end users are:

• DNSSEC validation in systemd-resolved (a stub resolver included in the systemd suite for Linux)

• Unwind: a validating forwarding DNS resolver (a drop-in replacement for Unbound, created by the developers of OpenBSD)

• Stubby: a validating forwarding DNS resolver with DoT support

In any case, we believe that DNS resolving and DNSSEC validation should be implemented at the operating system level, not the application level, because DNS is used by numerous applications besides web browsers.

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 was developed by SIDN Labs, SIDN's research department, building on the open-source packages OpenWrt and Unbound. The Valibox currently supports 4 hardware devices: the GL-Inet AR-150 and MT300A, the VirtualBox and the Raspberry Pi 4B.

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. One of the main reasons for the decision was that validation errors ceased to be an issue a long time ago. Also, there are now several major providers of public DNS services, and the number of providers supporting DNSSEC validation is growing slowly but surely.

To enable DNSSEC, a number of new record types were added to the original DNS protocol.

The first 4 record types are defined in RFC 4034. They are used to construct a cryptographic 'chain of trust'.

The NSEC3 and NSEC3PARAM record types are defined in RFC 5155. They are used for NSEC3 security.

Various other record types have subsequently been defined, further extending the DNSSEC protocol.

In addition to the definition of new record types, DNSSEC required a number of extensions to the original DNS protocol itself. The Extension Mechanisms for DNS (EDNS(0), defined in RFC 6891) added the pseudo-RR OPT to the 'additional data' section, creating additional space for extra flags and parameters.

To begin with, a DNS client can now state the maximum number of bytes it is able to process in its UDP buffer. Hence, the size of DNS (response) packets sent using UDP is no longer limited to 512 bytes. That limit was a feature of the DNS specification, based on the minimum size that IPv4 specifies for the UDP buffer. It was imposed so that DNS clients did not need to implement their own UDP buffers. If a client is unable to proceed on the basis of a truncated DNS response, it can re-send the query to the resolver, this time using the less efficient TCP transport protocol. That extension was needed to enable digital signatures (in RRSIG records) to be sent with the RRsets using UDP.

In addition, the following 3 flags were defined for DNSSEC (the first in the OPT pseudo-record):

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 1232

Note that RRSIG records can be requested in the same way as traditional DNS records, but mustn't be used to validate previously requested RRsets. Use of RRSIG records for that purpose could lead to problems with dynamic records whose digital signatures are generated on-the-fly (and whose records have a TTL of 1).

The basics of DNSSEC are defined in 3 RFCs:

• RFC 4033: DNS Security Introduction and Requirements

• RFC 4034: Resource Records for the DNS Security Extensions

• RFC 4035: Protocol Modifications for the DNS Security Extensions

Important supplements, extensions and clarifications are contained in the following RFCs:

• RFC 5155: DNS Security (DNSSEC) Hashed Authenticated Denial of Existence [NSEC3]

• RFC 7583: DNSSEC Key Rollover Timing Considerations

• RFC 6781: DNSSEC Operational Practices, Version 2

• RFC 6840: Clarifications and Implementation Notes for DNS Security (DNSSEC)

• RFC 8499: DNS Terminology

The 'chain of trust' is a cryptographic sequence of security links between the various levels of the DNS hierarchy, which is established by means of DNSSEC. When a DNS server sends a response to a client (resolver), 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 anchored the public key (by means of the DS record), thus creating a link between the two levels in the chain of trust.

In the case of a .nl domain name, that means that the public key is stored on the systems of SIDN, the operator of the .nl top-level domain. On request, SIDN's name servers provide a signed hashcode (a digital extract, in a DS record) of the relevant domain name's public key. A resolver can therefore verify that the public key associated with the signed response from a DNS server is indeed the same as the key previously deposited with the operator of the parent domain by the domain name's registrant.

The public key for the .nl top-level 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 key pair to see how seriously the matter is taken.

The cryptographic chain of trust leading back to the root that is followed to validate the name www.example.nl is set out below:

• The name www.example.nl itself is validated by checking the associated digital signature (in the RRSIG record) against the public key in the form of a DNSKEY record that is also published in the example.nl zone.

• The authenticity of the public key (in the DNSKEY record) in the example.nl zone is assured by the derived DS record published in the .nl zone.

• The authenticity of the DS record for example.nl in the .nl zone is assured by the digital signature in the associated RRSIG record in the .nl zone.

• The digital signature in the RRSIG record in the .nl-zone is checked against the public key, which is also published in the .nl zone in the form of a DNSKEY record.

• The authenticity of the public key (in the DNSKEY record) in the .nl zone is assured by the derived DS record published in the root zone.

• The authenticity of the DS record for the .nl zone in the root zone is assured by the digital signature in the associated RRSIG record in the root zone.

• Finally, the digital signature in the RRSIG record in the root zone is checked against the public key installed as a well-known value on every validating resolver in the form of a trust anchor.

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 a zone. 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 also sent to the operator of the parent 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 creating a link in the chain of trust.

The advantage of such a configuration is its relative simplicity. The disadvantage is that every rollover requires a change to the parent zone, and therefore interaction with that zone's operator.

In practice, it is normal to have a cascade (i.e. a hierarchical series) of 2 key pairs:

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 it 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 sent to the operator of the parent domain, but signed using the KSK pair's private key.

The KSK pair (the Key Signing Keys) is used only to sign the DNSKEY records (including its own public key), not to sign the other DNS records. A DNSKEY record, complete with public KSK, can be recognised from the set SEP flag (Secure Entry Point; see RFC 3757). Only the public key of that KSK pair is sent to the operator of the parent zone for publication as a DS record.

With a cascaded KSK/ZSK configuration of that kind, no new key material has to be sent to the operator of the parent zone when the ZSK pair is changed. 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.

Because a KSK/ZSK configuration is the norm, that type of configuration is often mentioned in RFCs, and a single key pair is referred to as the Combined Signing Keys (CSK).

As the following diagram shows, both the root zone and the .nl zone use DNSSEC algorithm number 8 (RSA/SHA-256).

Both key pairs for the root zone use an (RSA) key length of 2048 bits (the length of the ZSK pair was increased from 1024 bits to 2048 in 2017, so both pairs are the same length).

The length of the ZSK pair for the .nl zone currently remains 1024 bits. SIDN plans to upgrade from algorithm 8 to algorithm 13 (ECDSA-P256/SHA-256) before too long. The advantages of ECDSA cryptography are considered here.

https://images.ctfassets.net/yj8364fopk6s/1FCUMEZCWcKemYt4JXjLHY/604a9eca71b5740188ebf1ddf7dbc635/DNSViz-nl-2023-01-07-07_00_43-UTC.png

Cryptographic material published in the DNS can't simply be taken down and replaced with new material. Like all other DNS records, DNSSEC records are cached by resolvers, meaning that old information remains in use around the internet for a while – in the case of a DNSSEC record, for the time specified in the record's TTL value.

Keys are therefore changed by following a procedure called a rollover. A rollover involves first introducing and propagating a new key, and subsequently withdrawing the old key. During a rollover, therefore, 2 (partial) sets of DNSSEC records are temporarily in use alongside each other.

Key rollovers are typically performed when replacing a cryptographic key pair, changing cryptographic parameters or transferring a domain name. There are in principle 2 algorithms that can be used, although the first is suitable only for switching a key pair:

• The Pre-Publish Rollover, where first the new key pair is deployed (alongside the old key pair), and then the digital signatures are changed. Once the signatures have been adopted everywhere (implying that the old signatures are gone from all caches), the old key pair can be deleted.

• The Double-Signature Rollover, where first the new signatures are published (alongside the old signatures), and then a new chain of trust is established from the bottom up, parallel to the old one. The old chain of trust cannot be deleted until the whole of the new one is known everywhere.

It's important to be aware of the difference between KSK rollovers and ZSK rollovers: You can perform a ZSK rollover yourself, implying that it can be fully automated, whereas a KSK rollover requires the registration of new key material with the parent zone.

Also, a Pre-Publish Rollover is suitable only for key pair replacement. The transfer of a DNSSEC-enabled domain name involves following a specific protocol based on the Double-Signature Rollover. And, when switching to another algorithm, you have to use a Double-Signature Rollover, because a new algorithm always has to be introduced to the DNSSEC chain of trust from the bottom up (RRSIG – DNSKEY – DS), as explained below.

A Pre-Publish Rollover involves the following steps:

• A new key pair is generated.

• The new public key is published in the form of a DNSKEY record (alongside the existing DNSKEY record), together with the derived DS record in the parent zone (alongside the existing DS record).

• As long as the old chain of trust remains fully available for

  validation, it doesn't matter that no RRSIG records are present for the new key pair.

• Once the greater of two time periods – the TTL of the old DNSKEY record and a period equal to the TTL of the old DS record plus the refresh time of the parent zone – has expired, you know that both the new DNSKEY record and the new DS record are available everywhere.

• The new private key is then used to generate new digital signatures in the form of RRSIG records (to replace the existing RRSIG records based on the old private key), thus completing the new chain of trust.

• Once the TTL of the old RRSIG records has expired, you can be sure that there are no old RRSIG records anywhere.

• At that point, the old DNSKEY record can be deleted from the zone, and the old DS record from the parent zone,

thus completing the rollover.

Note that the procedure described above takes no account of:

• The time required for new records to propagate from a hidden (administrative) master to the public name servers

• The time that the registry requires to refresh the TLD zone (complete with the DS records)

Rollovers and the associated timing considerations are explored in detail in, respectively, RFC 6781 and RFC 7583 (secties 3.2 en 3.3).

The general timing aspects of DNSSEC are considered more closely in this article.

A Double-Signature Rollover involves the following steps:

• A new key pair is generated.

• The new private key is then used to generate new digital signatures in the form of

  RRSIG records (alongside the existing RRSIG records), which are published in the zone together with the new DNSKEY record (also alongside the existing DNSKEY record), and the corresponding new DS record is published in the parent zone (again alongside the existing DS record). (Although technically speaking, the steps of this protocol can be executed at the same time, in practice they are executed sequentially.)

• Although a complete chain of trust will now have been created parallel to the existing one, the old chain of trust must remain in place until all new RRSIG, DNSKEY and DS records are available everywhere, since successful validation depends on at least 1 of the chains of trust being complete at all times.

• Once the greater of 3 time periods – the TTL of the old RRSIG records, the TTL of the old DNSKEY record and a period equal to the TTL of the old DS record plus the refresh time of the parent zone – has expired, you know that both the new RRSIG records and the new DNSKEY and DS records are available everywhere, and that therefore the new, parallel chain of trust is complete. (The time period in question is the minimum required before the next step; a longer delay is no problem, of course.)

• At that point, the old RRSIG records and the old DNSKEY record can be deleted from the zone, and the old DS record from the parent zone, thus completing the rollover.

Note that the procedure described above takes no account of:

• The time required for new records to propagate from a hidden (administrative) master to the public name servers

• The time that the registry requires to refresh the TLD zone (complete with the DS records)

Rollovers and the associated timing considerations are explored in detail in, respectively, RFC 6781 and RFC 7583 (sections 3.2 and 3.3). The general timing aspects of DNSSEC are considered more closely in this article.

The respective pros and cons of a Pre-Publish Rollover and a Double-Signature Rollover are summarised in the following table:

DNSSEC supports multiple cryptographic algorithms. A rollover from one algorithm to another is performed in exactly the same way as a Double-Signature Rollover to a new key pair [BIND named].

Both the key pair and the algorithm can be changed in a single rollover if you wish. However, the interest of continuity, we recommend switching to a new algorithm in the context of a separate rollover, rather than your regular (automated) rollover.

Also, be aware that you can't use multiple algorithms at the same time. RFC 6840 (section 5.11) applies a number of constraints:

1. The DS and DNSKEY records determine the algorithms that are used for zone signing.

2. A (signed) zone must have a DNSKEY record for each algorithm (not each key) named in the DS records. Note, however, that the reverse does not apply: not every algorithm named in the DNSKEY records has to be mentioned in the DS records as well.

3. A zone must be signed using each algorithm (not each key) named in the DNSKEY records. In combination with Rule 2, above, that implies that there may be RRSIG records (and, therefore, DNSKEY records) in the zone for an algorithm that isn't mentioned in the DS records, enabling an algorithm to be changed by means of a Double-Signature Rollover. Conversely, you can't change an algorithm by means of a Pre-Publish Rollover, because a new algorithm mustn't be added to the DNSKEY records before the corresponding RRSIG records are available.

4. To sum up: a complete set of signatures (RRSIG records) must be present for every

   algorithm (not every key) used in the DS and DNSKEY records (signature completeness).

Although the RFC doesn't present the supporting rationale, the rules assume compartmentalisation of the chain of trust on the basis of algorithms. The chain of trust is built from the top down (i.e. from the root/parent to the delegations), and only the presence of a DS record determines whether the zone is signed. Hence, zone signing can be done from the bottom up – starting with the RRSIG records, then the DNSKEY record, and finally the DS record – and you can change the algorithm between the DNSKEY and DS records (which actually involves building a new, parallel signature from the bottom up).

Note that the rules were all formulated with algorithms in mind; key pairs are not subject to any constraints. Key pair rollovers therefore take place within the various algorithmic compartments, and can be performed in various ways.

A signed domain can be transferred to another operator/registrar without interrupting its DNSSEC security by means of a special procedure largely developed by SIDN Labs [1, 2, 3, 4, 5] and standardised in RFC 6781. The procedure is designed to avoid the need for private key material to be exchanged.

The procedure is effectively a Double-Signature Rollover, part of which is performed by each of the two operators:

• The new operator completes the new chain of trust (consisting of RRSIG records and the DNSKEY record based on that operator's own key pair), but the new DS record is not immediately published in the TLD zone.

• Before the domain is actually transferred by the registry (by switching the name servers (NS records) and publishing the new DS record):

  • The new operator ensures that the old signatures (in the RRSIG records managed by the old operator) remain valid by including the old DNSKEY record in the new zone file and signing it, while the old DNSKEY record remains available via the DNS.

  • The old operator ensures that the new signatures (in the RRSIG records managed by the new operator) work with the existing DNSKEY records by adding the new DNSKEY record to the old zone file and re-signing it. Because the NS records still point to the old operator, that cannot be done via DNS. SIDN Labs has therefore developed an extension to the EPP protocol (standardised in RFC 8063), so that a registry can transfer key material from the old operator to the new operator [1, 2, 3] .

• Once the greatest of all the relevant TTLs has expired, the actual transfer can be actioned by the registry:

  • Administrative control over the domain is transferred to the new registrar.

  • At the same time, the name servers (NS records) are switched from the old operator to the new one.

  • Also at the same time, the new DS record is published in the TLD zone (alongside the old operator's DS record, which is now retained by default during a domain transfer).

• Once the greater of the TTL of the old NS records and the TTL of the old DS record has expired, the old DS record can be deleted from the TLD zone by the new operator.

• Once the TTL of the old DS record has expired, the old DNSKEY record can be deleted from the new zone file, thus completing the rollover.

Where relevant, the time required for propagation from hidden to public name servers and the refresh times of the TLD zone must be added.

The process is clearly defined and can be fully automated (being now implemented in many DNS software packages.

When presenting the new DNSKEY record, the new operator is authenticated by means of the existing transfer token.

One drawback of the method is that it depends on the old operator retaining control of the TTL value of the old DNSKEY record.

Note that, if a double key pair is used during the transfer of a signed domain, the new operator must use the same cryptographic algorithm as the old operator. The reason being that RFC 6840, section 5.11 requires that, for each algorithm used in the DNSKEY and DS records, there must also be a signature (RRSIG record) based on the same algorithm. To avoid a situation where, over time, it gradually becomes necessary for an operator/registrar to have a number of algorithms in use, the new operator can roll over the domain's algorithm to their preferred algorithm once the transfer is complete.

The typical intervals for refreshing digital signatures and rolling overKSK/ZSK key pairs are as follows:

Generally speaking, a name server provides information only to a client that asks after a specific domain name. If a requested name doesn't exist, a non-secured name server will respond with an error message: NXDOMAIN for non-existent names, and NODATA for non-existent record types relating to names that do exist. That set-up means that an outsider can never obtain information about all the names (systems) within a domain. Protecting such information is desirable, since it could be used to compromise security.

However, things are not as simple where DNSSEC-nabled domains are concerned, because a response (NXDOMAIN/NODATA error message) for a non-existent address needs a digital signature, 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 attack.

NSEC -- short for Next Secure, part of DNSSEC (defined in RFC 4034, section 4) -- is part of DNSSEC, developed in an initial attempt to resolve that problem. NSEC makes it possible to provide DNS responses regarding non-existent records with digital signatures ('authenticated denial of existence')

Instead of specifying a particular non-existent name, an NSEC record specifies the range between two existent domain names. If, for example, you ask for the A record for the non-existent name charlie.example.nl, the response is an NSEC record stating that there are no names between two names that do exist: bravo.example.nl and delta.example.nl. NSEC records are created and signed when you sign your zone (usually roughly doubling the size of the zone file). So, when a validating resolver requests a non-existent name, it gets back a signed NSEC record for the interval within which the requested name falls. The resolver can therefore be sure that the name doesn't exist.

It should be stressed that the mechanism described above is the basic model. As you can read in this article, operators such as Cloudflare have come up with all sorts of clever tricks for generating NSEC(3) records for dynamic zones (with DNS responses generated on-the-fly using a database).

The problem with NSEC is that it makes it easy to discover all the names in a zone. By firing off a smart series of non-existent name lookups, you can compile a full set (linked list) of a zone's NSEC records, defining all the interval boundaries (i.e. the names that do exist). Such 'zone walking' or 'zone enumeration' is often undesirable from a security viewpoint.

Defined in RFC 5155, NSEC3 was developed partly to address the 'zone walking' security issue associated with NSEC. The basic principle is that, instead of stating actual names in your signed responses, you state their hashes (digitally scrambled versions of the names). A client that asks for a non-existent name therefore gets back a signed NSEC3 record for the interval between two hashes, within which the hash of the requested name falls.

That involves the zone operator first hashing the zone's NSEC interval boundaries and then sequencing them for signing. A client that validates an NSEC3 record doesn't therefore check the name itself, but first generates the name's hash and then checks that the hash falls within the NSEC3 record's boundaries. The use of hashes prevents the straightforward compilation of a list of existing names.

Even with hashes, however, it's possible to discover all the names in a zone by using a dictionary table (a table of pre-generated hashes of all common labels). To prevent that as well, a salt is added to each name and a number of extra steps (iterations) are added to the hash function. The relevant settings are the same for the whole zone and are published in the NSEC3PARAM record. By regularly changing the salt (simply a random string), you can prevent the compilation of a reusable dictionary table for your zone.

For background information about how NSEC and NSEC3 work, and about their history, see RFC 7129.

NSEC3 (the successor to NSEC) was added to DNSSEC to protect signed zones against malicious cataloguing by means of 'zone walking'. However, it seems that, in its present form, the extension has been overtaken by developments: NSEC3 is complex and no longer provides effective protection against the problem it was developed to prevent. It also has cryptographic design flaws.

For one thing, many host names are not secret, such as www, mx1, api, etc. As long ago as 2014, for example, a group of researchers succeeded in mapping two thirds of the NSEC3-secured domains in the .com zone. Using a single graphics processing unit (GPU), it took the researchers just 4.5 days to complete the task.

What's more, adding extra iterations to the hash doesn't make the mechanism fundamentally more secure. It simply means that both hackers and legitimate actors, such as the operators of validating resolvers serving numerous users and the administrators of large signed zones, have to deploy proportionally greater computational power. In most cases, the use of salts also seems unnecessary: hashes are generated from full domain names (FQDN), implying that dictionary tables need to be zone-specific in any case. Moreover, frequent salt rollovers represent a very minor additional challenge for a would-be hacker; in a relatively stable zone, most previously discovered labels will remain valid.

Those issues led to the development of RFC 9276. In that RFC, authoritative name server operators are advised to use NSEC3 only where the additional protection it affords is genuinely needed, and otherwise to use basic NSEC. Furthermore, if NSEC3 is used, the advice is to set the extra iterations to zero ('0') and to leave the salt blank ('-'):

example.nl.    IN    NSEC3PARAM    1 0 0 -

DNSSEC-algorithms number 6 (DSA-NSEC3-SHA1) and above are suitable for NSEC3.

It's worth noting that, although algorithm number 5 (RSA/SHA-1) is cryptographically the same as number 7 (RSASHA1-NSEC3-SHA1), it doesn't support the inclusion of NSEC3 records. A similar situation exists with algorithms 3 (DSA/SHA1) and 6 (DSA-NSEC3-SHA1). When NSEC3 was introduced, the cryptographic algorithms then in use (numbers 3 and 5) were assigned new numbers/names. However, the aliases (numbers 6 and 7) tell resolvers that the cryptographic algorithms in question can be combined with NSEC3.

That ensured backward compatibility with existing resolvers that did validate (on the basis of algorithms up to and including number 5, i.e. the highest until then) but didn't support NSEC3 (as defined in RFC 5155, section 2). Because the DNSSEC protocol requires validating resolvers to ignore (but not block) unrecognised algorithms, the approach ensured NSEC3's smooth introduction to the existing DNSSEC landscape.

With algorithm number 8 (RSASHA256) and above, resolver support for NSEC3 is mandatory (see RFC 5702, section 5.2) and the distinction between algorithms that do support NSEC3 and those that don't has therefore ceased to exist.

With NSEC(3), a digital signature is attached to any reply sent in response to a query about a non-existent DNS record. The signed reply -- known as an 'authenticated denial of existence' -- serves as cryptographic evidence to a validating resolver that the requested record really doesn't exist.

Like other DNS responses, an NSEC(3) response has a specified (remaining) 'time to live': the number of seconds that the response remains valid and can therefore be cached by the resolver. The starting point for the reply's time to live (TTL) is specified in the MINIMUM field of the relevant zone's SOA record (as per RFCs 4034 and 5155).

However, the TTLs aren't determined in the same way as the TTLs of traditional, unsigned DNS responses. Both the SOA record's MINIMUM value and the TTL of the SOA record itself are checked, and the lowest of the two values is used.

As a result, a (signed) NSEC(3) record can have a longer TTL than an unsigned NXDOMAIN/NODATA error message (if the MINIMUM field value is higher than the TTL of the SOA record). And that's an undesirable situation.

Attempts have therefore been made to ensure that divergent TTLs for NSEC(3) responses are brought into line with the unsigned denial-of-existence responses. The first such attempt was RFC 8198, which sought to optimise validating resolver cache implementation. However, the community was divided on the merit of that RFC, which was in any case narrowly defined for a particular application.

The recently published RFC 9077 offers a structural solution to the TTL discrepancy issue. The new RFC proposes harmonising the TTLs by defining NSEC(3) response TTLs in exactly the same way as traditional, unsigned denial-of-existence TTLs.

Special procedures and protocols have been developed for downloading, verifying and updating DNSSEC trust anchors. The procedures and protocols in question are relevant mainly to the developers and operators of resolver software. They are particularly significant in the context of migration to a new trust anchor (part of the root KSK rollover).

The trust anchor is well-known. A special procedure and tooling are available for its manual (out-of-band) authentication. However, there is also a protocol for automatic updating of the trust anchor in accordance with RFC 5011 (considered below).

In practice, however, a new trust anchor is supplied to most systems in the context of operating system updates. That is why the security of IoT devices and other small internet-connected appliances that typically don't receive software updates presents so many challenges.

RFC 5011 defines a protocol, on the basis of which validating resolvers can implement new trust anchors and phase out the old ones, without any operator involvement. Such a resolver can therefore perform a fully automated complete rootKSK pair rollover. Since the (first) root KSK rollover in 2017/2018, RFC 5011 has been adopted by almost all validating resolvers.

An automated trust anchor update begins with collection of the new public key (in the form of a DNSKEY record) from an authoritative server for the root zone (or another trust point). The record has a digital signature based on the old, trusted trust anchor, so the resolver is able to validate the record's authenticity (in band) using the usual DNSSEC functionality. The resolver recognises a valid KSK from the SEP flag (Secure Entry Point; see RFC 3757) in the DNSKEY record. The resolver consequently has to regularly check the root zone for the availability of new (KSK) DNSKEY records.

For security reasons, RFC 5011 states that a new public KSK must not be added to the trust anchors for at least 30 days (the hold-down period). During that period, a resolver has to check at intervals not exceeding two weeks whether the new key is still present. The procedure therefore has a built-in safety margin and a mechanism for aborting a root KSK rollover if problems arise.

Once the actual rollover is complete, the old public key can be removed from the list of trust anchors held by the resolvers by setting the relevant DNSKEY record's REVOKE flag. In other words, as well as being used to declare insecure key pairs invalid, this legacy functionality now serves to clear out expired key pairs.

Because the method depends entirely on a trusted public key being present on the resolver side, it will work only with systems on which a trust anchor is already installed. Most resolver software developers therefore provide the current trust anchors hard-coded into their products as a matter of course.

In order to complete the chain of trust for a signed zone, the (new) public key must be published in the parent zone, in the form of a DS record (containing a hash value). At the moment, new public keys usually have to be submitted to parent zone operators manually (out of band), e.g. using a DNSKEY/DS record dialogue in a web interface, typically in the same place that the authoritative name servers (NS records) are managed. However, there is now also a mechanism for the automatic updating of DS records in the parent zone.

RFC 8078 defines a protocol, on the basis of which an authoritative name server can add a new DS record to the parent zone, without the involvement of the parent zone's operator. However, RFC 8078 is a relatively new protocol that isn't yet widely supported or used.

In order to use the protocol, you have to publish your new public keys in your own zone, as a CDNSKEY and/or CDS record (Child DNSKEY/DS). Parent zone operators (or registrars) periodically scan child zones (delegated zones) to check whether new keys are available.

However, that method works only for delegated zones that have already been DNSSEC-enabled (in band), because trust in new key material depends on the digital signature attached to the CDNSKEY/CDS records. Therefore, the initial submission of key material (before a chain of trust has been completed) is always a manual process (although RFC 8078 does outline a couple of semi-automated alternatives).

Some or all of the DS records in the parent zone can be deleted by publishing a CDNSKEY/CDS record containing zero values.

Therefore, RFC 8078 provides a mechanism for the exchange of key material between parent and child zones, similar to that provided for in RFC 5011, but operating in the opposite direction (complementary).

DNS spoofing, also known as DNS cache poisoning, involves the malicious injection of false DNS information into a resolver, displacing the authoritative DNS information.

Attackers use the tactic with the aim of misdirecting users (or systems) to, for example, fake websites, with a view to fraudulently obtaining valuable or confidential information. That might involve the interception of passwords (and other credentials) and personal data (for identity theft), or an automated man-in-the-middle (MITM) attack via a falsified front end.

Alternatively, the attackers might seek to mislead visitors into acting in a particular way by giving them fake news or false stock market information.

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 16-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', as described in RFC 5452) provided an interim solution to the problem. Because an attacker does not know which port an outbound query has come from, 65,000 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.

The diagrams below show that only 1 per cent of the resolvers around the world that query the authoritative servers for .nl employ inadequate source port randomization. Half of the Dutch resolvers that score badly belong to Microsoft.

https://images.ctfassets.net/yj8364fopk6s/5aIexdEhPoKrhp2ox46efC/bd8d37f9800b52b80062cfa2f89c2150/stats.sidnlabs.nl-SourcePortRandomization-20220809.png

https://images.ctfassets.net/yj8364fopk6s/6cL3wHHh3P1b3w5pD5wY9b/63575373321354e64c612d37413fbf0d/stats.sidnlabs.nl-SourcePortRandomizationNL-20220809.png

In practice, however, a 'cache poisoning' attack of the kind described was difficult to carry out. The probability of managing to generate a correct DNS response within such a short time frame was small. What's more, no further attempt could be made until the relevant record's cache TTL (time to live) had expired, which could be hours or even days. The reason being that the attacker couldn't poison the resolver with false DNS data until a fresh DNS query about the domain in question was sent to the authoritative DNS server. Then, in 2008, Dan Kaminsky showed that it was possible to get around that particular obstacle, meaning that any resolver that didn't use source port randomization was vulnerable.

After the Kaminsky attack was published in 2008, things were relatively quiet on the DNS front for a long time. Then, in November 2020, DNS security again hit the headlines with publication of the 'SAD DNS' attack, which was followed a year later by the 'SAD DNS 2.0' attack. All 3 of those attacks are forms of 'cache poisoning' attack.

In March 2024, a serious vulnerability in the DNSSEC specification itself was published. Known as KeyTrap, the vulnerability meant that it was possible to mount a denial-of-service (DoS) attack on a validating resolver from a DNS server. Because the cause was a flaw in the specification itself, all popular DNS resolvers and services were affected. What's more, the issue was so serious that it couldn't be published until it had been fixed.

The KeyTrap vulnerability [technical report] was discovered in late 2023 by researchers at Germany's National Research Center for Applied Cybersecurity (ATHENE). However, its cause goes back more than 20 years, to RFC 2535, the first version of the modern DNSSEC security methodology, published in 1999. Via the successors to that RFC, the vulnerability found its way into various implementations, including BIND9, Unbound, PowerDNS and other resolver software.

The KeyTrap vulnerability originates from what the researchers describe as "eager validation of signatures and of keys". The DNSSEC protocol requires a validating resolver to go on evaluating all the signatures provided (in an RRSIG record) and all the associated public keys (in a DNSKEY record) until a valid signature for the relevant DNS record is found. The idea is, of course, to ensure that the DNSSEC mechanism is as robust as possible. Moreover, the simultaneous publication/overlap of multiple signatures and multiple public keys is a common phenomenon, occurring in the context of every re-signing and rollover.

However, there was a problem with the key tag, a 16-bit identifier that serves to distinguish key pairs from one another, enabling the resolver to immediately find the right public key when evaluating a signature. Although the key tag is generated on a (pseudo-)random basis – RFC 4034, appendix B recommends using a simple checksum – it is not necessarily unique. Consequently, 'key tag collisions' are technically permissible.

A malicious actor could take advantage of that situation by publishing a DNS record with a string of signatures all of the same cryptographic type, in combination with a string of keys all with the same key tag. If all the signatures were invalid, the resolver would not conclude that that was the case until it had evaluated all the available signatures for all the keys provided.

Because cryptographic operations – especially the validation of ECDSA-based signatures – require considerable processing power, a record with the combination of signatures and keys described would require the resolver to do a lot of work trying all the possible combinations. Until it had finished performing all the calculations, the resolver would be able to do little or nothing else, resulting in denial of service. The researchers found that a validating resolver running on low-power hardware could be kept occupied for 16 hours by a record of the type described.

Because the KeyTrap issue made it easy to disable large parts of the internet, the researchers described it as the biggest DNS vulnerability ever discovered. However, the developers' contention that this security flaw had gone unnoticed for 25 years is debatable. Dex Bleeker published an essay detailing precisely this issue back in 2019. However, Dex didn't configure his keys for maximum impact, with the consequence that, although he observed an increased load, he didn't take down the resolver. [1]

Malicious manipulation of the original DNS protocol was regarded as merely a theoretical possibility until 2008, when Dan Kaminsky demonstrated a serious flaw in the system's design. By exploiting the flaw, hackers could inject false information into the caches of the most popular DNS servers in real-life situations.

A Kaminksy attack has two stages: If you want to attack the domain www.example.nl, you start by asking the resolver about the domain name 000001.example.nl. At the same time, you send false ('spoofed') DNS responses to the resolver containing NS records pointing to a false authoritative name server. If the genuine response arrives first, you don't have to wait until the TTL (Time To Live) 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. 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.

A more structural answer to this kind of attack is of course to use DNSSEC validation. A validating resolver will never accept the false information (at application level) if it doesn't bear a valid digital signature.

After the Kaminsky attack was published in 2008, things were relatively quiet on the DNS front for a long time. Then, in November 2020, DNS security hit the headlines again with publication of the 'SAD DNS' attack. The discoverers used a new side-channel to inject fake DNS information into a caching resolver. Hence the name – Side-channel AttackeD DNS. According to the discoverers, a third of all caching resolvers were initially vulnerable to this kind of DNS cache poisoning attack, as were the majority of major public DNS services.

With SAD DNS, an attacker establishes what a DNS resolver's (ephemeral) outbound UDP port is by taking advantage of the protective rate limiting functionality for ICMP messages built into all network stacks. If, for example, the limit is set at 1,000 messages per second (as with Linux), the attacker can test all 65,000 UDP ports in blocks of a thousand to find out which block includes the outbound port. That involves first sending 1,000 fake DNS responses from spoofed IP addresses, one to each port in the block. The resulting ICMP error messages are lost because the sender's address is spoofed. However, if the attacker sends a 1,001st message from their real IP address within the same second and gets one final ICMP response, they know that the correct port is in that series of 1,000 ports. Otherwise the limit of 1,000 ICMP error messages would have been exceeded for the second in question.

By establishing what the resolver's (ephemeral) outbound UDP port is, the attacker negates the original strategy for preventing classic DNS cache poisoning attacks and Kaminsky attacks, namely source port randomisation. Once the port is known, the attacker merely has to try each of the 65,000 different transaction IDs in order to inject fake DNS information (by means of a Kaminsky-style attack). In their publication, the researchers explain how they were additionally able to extend the window for performing a complete attack from a few tens of milliseconds to many tens of seconds.

The best way to address the particular threat posed by SAD DNS was to introduce a considerable degree of randomness to the hard-coded limit of 1,000 ICMP messages per second.

A more structural answer to this kind of attack is of course to use DNSSEC validation. The reason being that a validating resolver will never accept the false information if it doesn't bear a valid digital signature.

At the end of 2021, just a year after publishing the first SAD DNS attack method, the same research team revealed another way of mounting a cache poisoning attack on the DNS. Being conceptually the same as the previous attack strategy, the method was dubbed SAD DNS 2.0. According to the researchers, it's mainly Linux systems that are vulnerable to the attack, along with popular DNS software such as BIND, Unbound and dnsmasq (all of which are Linux-based). Of the major public DNS services, half proved to be vulnerable, including Cisco's OpenDNS and Quad9 (9.9.9.9).

Like the first SAD DNS attack, SAD DNS 2.0 builds on the Kaminsky attack method that was published in 2008. In a Kaminsky attack, a caching resolver is injected with false DNS information by targeting it with DNS queries and spoofed false DNS responses. A DNS cache poisoning attack of that kind can be prevented by source port randomisation (as defined in RFC 5452). That involves configuring the resolver to change the outbound UDP port for every query, which makes the spoofing of false DNS responses practically impossible.

The first SAD DNS attack negated the protection afforded by source port randomisation by identifying the momentary (ephemeral) outbound UDP port. That was done by (indirectly) counting the ICMP messages sent in response to spoofed DNS responses. The attack method is described in more detail in this article.

Like the first method, the new SAD DNS attack method involves identifying the resolver's ephemeral outbound UDP port. However, the side channels used to do that are different. For the latest variant, the researchers developed various side channel attacks on the basis of the 'ICMP frag needed' and 'ICMP redirect' messages. This 'ephemeral port scanning' method involves sending a series of spoofed ICMP messages to the resolver, and then checking whether the ephemeral port has been hit. On Linux, a valid ICMP message leads to modification of the 'next hop exception cache' (part of the network stack). And it's possible to ascertain whether a modification has been made by, for example, sending a simple ping message to the resolver in question.

Once the ephemeral outbound UDP port has been identified, a Kaminsky-style attack is again mounted to obtain the DNS transaction IDs by brute force.

Additional techniques can be used to frustrate the transmission and safe receipt of the correct response from the true authoritative name server, thus increasing the window for landing false DNS responses. Those techniques were previously described in the publication about the first SAD DNS attack.

When the researchers tested the new ICMP/UDP-based side channel attacks, they were able to inject vulnerable resolvers with false DNS information within a few minutes.

While pointing out that the new SAD DNS variant could be countered in various ways, the researchers stressed that DNSSEC was the best defence against cache poisoning. The reason being that a validating resolver will never accept the false information if it doesn't bear a valid digital signature.

Malicious manipulation of the original DNS protocol was regarded as merely a è until 2008, when Dan Kaminsky demonstrated a serious flaw in the system's design. By exploiting the flaw, hackers could inject false information into the caches of the most popular DNS servers in real-life situations.

After the Kaminsky attack was published, things were relatively quiet on the DNS front for a long time. Then, in November 2020, DNS security hit the headlines again with publication of the 'SAD DNS' attack. The discoverers used a new side-channel to inject false DNS information into a caching resolver.

Exactly a year later, the same research team revealed another way of mounting a cache poisoning attack. Being conceptually the same as the previous attack strategy, the method was dubbed SAD DNS 2.0.

The 2 recently revealed attack methods involve identifying the resolver's ephemeral outbound UDP port. That enables an attacker to negate the original strategy for preventing classic DNS cache poisoning attacks and Kaminsky attacks, namely source port randomisation.

DNSSEC provides a structural solution to such attacks. The reason being that a validating resolver will never accept the false information if it doesn't bear a valid digital signature.

DNSSEC assures only the authenticity of DNS information. In other words, the digital signature guarantees that a DNS response received by a (validating) 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.

What's more, most clients contain only a stub resolver and leave recursive queries – and therefore validation – to the caching DNS servers assigned to them via DHCP or NDP by their internet access provider or network administrator. Hence, the pathway between stub resolver and DNS server – the 'last mile' – is not secured.

That limitation is addressed by DoT, DoH and DoQ: extensions to the DNS that do protect the (end-to-end) transport of DNS information. However, all are relatively new and are currently used largely at the application level (in web browsers).

Like DoH and DoQ, DoT (DNS over TLS) is an extension to the DNS that secures the transport of DNS information. It is a relatively new security standard and currently used mainly at the application level (in web browsers).

As its name suggests, DoT involves the client first establishing a cryptographically secured TLS connection, over which the DNS queries and responses are then transported. Thus, the confidentiality and the 'last mile' of the DNS transport are secured. That is not the case with 'basic' DNSSEC, which assures only the authenticity of the DNS information. DoT is not therefore an alternative to DNSSEC, but a complementary technology.

Like DoT and DoQ, DoH (DNS over HTTPS) is an extension to the DNS that secures the transport of DNS information. It is a relatively new security standard and currently used mainly at the application level (in web browsers).

As its name suggests, DoH involves the client first establishing a cryptographically secured HTTPS connection, over which the DNS queries and responses are then transported. Thus, the confidentiality and the 'last mile' of the DNS transport are secured. That is not the case with 'basic' DNSSEC, which assures only the authenticity of the DNS information.

DoH is not therefore an alternative to DNSSEC, but a complementary technology. The DoH standard (defined in RFC 8484) is concerned exclusively with use cases where DoH is deployed for communication between an end user and a caching resolver, either at the operating system level (by the stub resolver) or at the application level (by the web browser).

For a detailed description of DoH, see this article.

Like DoT and DoH, DoQ (DNS over QUIC) is an extension to the DNS that secures the transport of DNS information. It is a relatively new security standard and currently used mainly at the application level (in web browsers).

As its name suggests, DoQ involves the client first establishing a cryptographically secured QUIC connection, over which the DNS queries and responses are then transported. Thus, the confidentiality and the 'last mile' of the DNS transport are secured. That is not the case with 'basic' DNSSEC, which assures only the authenticity of the DNS information. DoQ is not therefore an alternative to DNSSEC, but a complementary technology.

For a detailed description of DoQ (and QUIC), see this article.

Digital signatures make use of public-key cryptography and hash functions: First, a hash (a digital extract) of an electronic document (in this case an RRset) 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; in this case a DNSKEY record 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).

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 (via a 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 existing 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.

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 what combination of pubkey algorithm and hash function to use.

Separately, you have to choose which hash function to use for the DS/CDS records.

About 15 cryptographic pubkey/hash combinations are defined for use in DNSSEC . A comprehensive list is available on IANA's website:

https://www.iana.org/assignments/dns-sec-alg-numbers/dns-sec-alg-numbers.xhtml

Over time, some established algorithms become 'deprecated' (i.e. regarded as obsolete, on account of being outdated or insecure) and new algorithms are added. Where DNSSEC is concerned, the latest developments in (applied) cryptography are reflected in RFC 6824, the successor to RFC 6944.

RFC 6824 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) is recommended

• Alongside number 8 (RSA/SHA-256), which was the standard for a long time but it is now being phased out in favour of the ECDSA-based algorithms

• Number 10 (RSA/SHA-512), a variant of number 8, has never gained popularity, and its use is now discouraged.

• Number 14 (ECDSA Curve P-384 with SHA-384) is a stronger version of number 13, but isn't needed yet (and rarely used).

• However, the expectation is that, in due course, number 13 will be succeeded not by number 14 but by an EdDSA-based algorithm (number 15, Ed25519).

Therefore, if you are implementing DNSSEC now, use algorithm number 13. However, if you're already using DNSSEC on the basis of algorithm number 8 (or an older algorithm), you are advised to switch to number 13 before too long.

Algorithms based on the SHA-1 hash function (algorithms 3, 5, 6 and 7) are now considered seriously outdated and weakened . The expectation is that the last of the SHA-1-based algorithms will soon be removed from the DNSSEC protocol. As of September 2024, there were nevertheless still 3,200 domain names within the .nl zone signed using the algorithms in question. The registrants of those domain names really should switch as soon as possible to a stronger algorithm – preferably algorithm 13, of course.

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

However, the SHA-1 hash function was also deprecated by NIST for use in digital signatures as far back as 2011. "SHA-1 is no longer secure," said Marc Stevens at the time. Marc is a cryptographer at CWI, known for breaking MD5 and SHA-1.

Use of the SHA-1 hash function has been officially discouraged in DNSSEC since the publication of RFC 8624 in June 2019. The algorithms to be avoided are therefore numbers 3 (DSA/SHA1), 5 (RSA/SHA-1), 6 (DSA-NSEC3-SHA1) and 7 (RSASHA1-NSEC3-SHA1). The expectation is that the last of the SHA-1-based algorithms will soon be removed from the DNSSEC protocol. As of September 2024, there were nevertheless still 3,200 domain names within the .nl zone signed using the algorithms in question. The registrants of those domain names really should switch as soon as possible to a secure algorithm – preferably algorithm 13, of course.

Algorithms 8 and 10 are both based on the SHA-2 family of hash functions. SHA-2 is the successor to SHA-1, and is secure for use in digital signatures, at least for now. For a long time, number 8 (RSA/SHA-256) was the standard, but it is now being phased out in favour of the ECDSA-based algorithms. Number 10 (RSA/SHA-512), a variant of number 8, has never gained popularity, and its use is now discouraged (in RFC 8624).

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 3 public key algorithms – DSA, 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 2 large prime numbers back into its factors (prime factorisation). Consequently, RSA is secure to use only if quite long keys are generated, which makes this algorithm less suitable for use 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 roughly the same length as DSA signatures, the public keys are much shorter. For example: a security level of 128 bits – implying that 2^128 'brute 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 2,048 bits are required. With both ECDSA and DSA, the signature length is roughly 4 times the desired security level (i.e. 512 bits in this example), whereas with RSA it is more than 2048 bits.

For 128-bit security:

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 2 algorithms; indeed it is an order of magnitude faster than ECDSA. That is the sole (albeit significant) disadvantage of using ECDSA for DNSSEC.

The differences in algorithmic properties described above make ECDSA generally the best choice for DNSSEC. First, the length of both the digital 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.

Yes. Since March 2016, registrars have been able to provide SIDN with DNSKEY records based on algorithms numbers 13 and 14 for publication in the .nl zone (in the form of hash values in DS records). Consequently, registrars are able to sign their clients' domains using ECDSA.

Since support for those algorithms was added, it's been possible to enable DNSSEC protection for .nl domain names hosted by Cloudflare, of which there are about 20,000. Cloudflare is a CDN provider that has used algorithm number 13 by default from the outset 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. As the following graph shows, algorithm 7 has now almost entirely disappeared from the .nl zone, while algorithm 8 is being displaced by algorithm 13. By September 2024, 59 per cent of DNSSEC-enabled .nl domain names were using algorithm 13, and 41 per cent were using algorithm 8.

https://images.ctfassets.net/yj8364fopk6s/UfHHqBQoapqMtaaGmzGvq/fb08db89265df917e7bca30c2ecdb36b/stats.sidnlabs.nl-DNSSECalgorithms-20240826.png

In summer 2023, we also migrated the .nl top-level domain itself from algorithm 8 to algorithm 13.

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, algorithm 14 isn't used much, because the longer keys and signatures underpinning the additional security require additional processing power and generate more traffic. In September 2024, a mere 0.03 per cent of DNSSEC-enabled .nl domain names were using algorithm 14. Furthermore, we expect that, in due course, algorithm 13 will be succeeded not by algorithm 14, but by an EdDSA-based algorithm (number 15, Ed25519).

https://images.ctfassets.net/yj8364fopk6s/UfHHqBQoapqMtaaGmzGvq/fb08db89265df917e7bca30c2ecdb36b/stats.sidnlabs.nl-DNSSECalgorithms-20240826.png

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. That will provide a dynamic alternative to NSEC(3), definitively resolving the security problem of 'zone walking'.

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

EdDSA (Edwards-curve Digital Signature Algorithm) is an algorithm for implementation of the public-key protocol, as are the more established DSA and RSA algorithms. Technically speaking, EdDSA is very similar to ECDSA – another modern public-key algorithm. However, as the name suggests, EdDSA uses 'twisted Edwards curves', a particular variant of the mathematics underpinning Elliptic-Curve Cryptography (ECC).

DNSSEC algorithms 15 and 16 (defined in RFC 8080) use the Ed25519 and Ed448 cryptographic constructions (defined in RFCs 8032 and 7748). The first of those constructions combines elliptic curve Curve25519 with the SHA-512 hash function, resulting in a very fast public-key algorithm. Ed448 does the same using Curve448 and SHA-3 (in this case, the SHAKE256 variant).

Like algorithm 13 (ECDSA Curve P-256 with SHA-256), Ed25519 (algorithm 15) provides 128-bit security (the current norm) on the basis of a 256-bit private key, plus a 512-bit public key and 512-bit signatures. With a key length of 448 bits and 224-bit security, Ed448 (algorithm 16) is the EdDSA-based equivalent of algorithm 14 (ECDSA Curve P-384 with SHA-384).

For DNSSEC, EdDSA-based cryptograph has the same benefits over DSA and RSA that ECDSA has, while also being simpler, slightly faster and less vulnerable to (side-channel) attacks than ECDSA.

Although it's certainly possible, the large-scale operational use of algorithms 15 (Ed25519) and 16 (Ed448) is regarded as premature at the present time (February 2023).

Registrars can definitely provide SIDN with DNSKEY records based on algorithms 15 and 16 for publication in the nl zone (in the form of hash values in DS records). In principle, therefore, registrars can also sign their clients' domains using EdDSA.

RFC 8624 (published in June 2019) describes the implementation of algorithms 15 and 16 in resolvers, and the implementation of algorithm 15 in name servers, as 'recommended'. As a result, support for EdDSA-based algorithms will be incorporated into DNS software in the years ahead. However, until that support is realised, it would be premature to make large-scale operational use of the algorithms. According to DNSThought statistics, 85 per cent of validating resolvers currently support algorithm 15. However, where the .nl zone is concerned, a negligible 0.01 per cent of domain names are using algorithm 15.

RFC 8624 (also) makes recommendations regarding the hash function to use for DS/CDS records:

• Only a handful of algorithms are currently defined. The full list is available on IANA's website: https://www.iana.org/assignments/ds-rr-types/ds-rr-types.xhtml

• Hash algorithm 2 (SHA-256) is recommended.

• Hash algorithm 1 (SHA-1) is still in widespread use, but should be replaced by number 2 in short time.

• Hash algorithm 4 (SHA-384) is a stronger version of number 2, but isn't needed yet.

Therefore, if you are implementing DNSSEC now, use hash algorithm 2. If, on the other hand, you're already using DNSSEC on the basis of hash algorithm 1, you are advised to switch to number 2 in short time.

However, where domain names in the .nl zone are concerned, registrants don't need to do anything, because we don't ask registrants to provide DS records. Instead, we ask for DNSKEY records, from which we generate DS records ourselves, and have always done so using SHA-256.

A DS record must be present in the parent zone for DNSSEC to function in the child zone. Before going live with DNSSEC security for a signed domain (i.e. before uploading key material to the parent for publication as a DS record), it's important to satisfy yourself that the domain is working and will continue working. The main things you need to do are:

• Check the signed zone: In addition to standard DNS tools and DNSSEC-specific tools, we recommend using DNSViz.

• Back up the key material: All DNS software and hardware devices (HSMs) that support DNSSEC feature key pair export functionality. Make a backup of the key pairs before enabling DNSSEC.

• It is advisable to reduce the TTL values before doing work on an active domain's DNS infrastructure. That will enable changes to be made more quickly, potentially reducing the duration and thus mitigating the impact of any errors. Be aware, however, that shorter TTLs mean higher loads on your name servers.

DNSSEC is a lot less tolerant of errors than the traditional DNS. Furthermore, errors have more serious consequences: in the worst-case scenario, an entire domain could be blocked by all validating resolvers. It's therefore vital that any errors in the zone are corrected before the zone is signed.

Fortunately, a number of good tools are available to help you get the configuration right:

• The named-checkzone command (part of BIND)

• The kzonecheck command (part of Knot DNS)

• The DNSChecker.org online tool

Various other tools are available for checking and debugging your zone once it's signed:

• The DNSViz graphical online tool (recommended!)

• The DNSSEC Analyzer online tool

• The Internet.nl online tool (also for other tests)

• DNSSEC-Tools (outdated?)

DNSSEC itself is also considerably more sensitive than the traditional DNS:

• Public-key cryptography makes DNSSEC complex.

• Misconfigurations have immediate adverse effects.

• Re-signing and key management/rollovers are particularly problem-prone.

• In the worst-case scenario, an entire domain can be blocked by all validating resolvers (in the early days of DNSSEC, that even happened to several TLDs; fortunately, few validating resolvers were in use back then).

Problems with re-signing and key management/rollovers can easily be avoided by automating the relevant processes as far as possible:

• DNS software developers have done their best to make the complexities of DNSSEC manageable, to move as much as possible 'under the hood' and to automate as much as possible.

• Support for automated re-signing and key management/rollovers is now a standard feature of all software for authoritative name servers.

• Individual zone files can now be signed using the OpenDNSSEC tool (used for the .nl zone).

DNSSEC has changed the DNS in a number of significant ways:

• It has transformed the DNS from a primarily administrative system into a much more complex cryptographic platform that can be used for a wide variety of new applications.

• It has introduced absolute time to an environment that previously relied entirely on relative times (TTLs). Furthermore, with DNSSEC, the two timing methods need to interact.

The modern DNS now uses three distinct forms of time:

Relative time

TTL values are relative timestamps that are used to state the (remaining) lifetime of a record.

example.nl.    3600    IN    A    94.198.159.35

Caching name servers use TTL values to count down the validity periods of cached records, which are measured in seconds. As time elapses and a record moves further away from the authoritative name server in the cache hierarchy, the TTL value decreases, until the record is deleted from the cache. TTL values were a feature of the DNS protocol prior to DNSSEC, and most operators are therefore familiar with them.

Absolute time

As well as a digital signature, RRSIG and NSEC(3) records each contain two absolute timestamps specifying the start and end of the validity period.

example.nl.    3600    IN    RRSIG    A 13 2 3600 20220901125646 20220818112455
    7104 example.nl. 3TMKhc7EuQL08gYuNKPBZAFAyNCEogkr+5fasVTerD9...

The RRsets need to be re-signed well before the associated signature expires. Both the validity period and the re-signing period are determined by the name server's relative timing settings. This timing method is specific to DNSSEC and therefore a new feature of the DNS.

Administrative time

The cryptographic key pairs for signing the RRsets have an administrative validity period only. They are used by the DNSSEC system for a specific period, after which they need to be rolled over. However, the usage period isn't strictly enforced; until a new key pair becomes available, the old pair remains in use.

The DNSKEY and DS records do not include any timing information; their relative (remaining) validity period is determined entirely by the associated TTL values.

example.nl.    3600    IN    DNSKEY    257 3 13 5LLZ7NLIMEYHcU2D...
example.nl.    3600    IN    DNSKEY    256 3 13 jyFF8wHMIIuGLORliN...
example.nl.    3600    IN    DS        31925 13 2 E992722DF695728385A...

The key pair settings are specific to DNSSEC and therefore a new feature of the DNS.

A number of points are worth highlighting with regard to DNSSEC records, signing and rollovers:

• Both traditional DNS records and modern DNSSEC records have relative (remaining) lifetimes determined by their TTL values. An RRSIG record must have a TTL value equal to that of the corresponding resource record. In addition, a digital signature has an absolute validity period specified in the RRSIG record.

• DNSKEY and DS key records do not include timing information (other than their TTL values). Such records therefore serve merely as links in the chain of trust.

• Re-signing the RRsets and rolling over the key pairs are separate but interdependent processes.

• Re-signing is triggered by any of the following three events:

  • A change to the zone file

  • Expiry of the existing digital signature

  • Rollover of the (ZSK) key pair

TTL values do not influence re-signing.

• The trigger for the rollover of a key pair is always administrative:

  • On 'expiry'

  • In response to a security incident

  • In the context of migration to a different cryptographic algorithm

  • In the context of transfer to another operator/registrar

The timing of a rollover therefore depends on both re-signing (of the key records) and TTL settings (for flushing out cached information).

The timing aspects of DNSSEC are considered more closely in this article. The timing considerations associated with rollovers are considered in detail in RFC 7583.

Other matters to consider are the times required for propagation from hidden to public name servers and the refresh times of the TLD zone [1, 2].

Correct, functional and secure system time is a vital component of a reliable DNSSEC system. By advancing the system time on a validating resolver, a malicious actor could carry out a DoS attack on a validating resolver or flush the cache by causing the TTLs of the records to expire prematurely. Conversely, putting a machine's clock back would allow for a replay attack.

In 2015, Malhotra's team at Boston University published a paper exposing several vulnerabilities in the NTP. The authors described various ways of abusing NTP to modify system time in practice. They explained how, by adjusting a machine's system time, it was possible to interfere with various security protocols that rely on system time. The paper's publication led directly to the implementation of NTS, a cryptographically secured extension to NTPv4.

In 2019, the same Aanchal Malhotra and the team at NLnet Labs (responsible for the development of NSD, Unbound, OpenDNSSEC, Krill, Routinator and various other network tools) published a paper focusing specifically on the importance of correct (secure) system time in the context of the DNS. They outlined several scenarios in which attacks such as those described above could be carried out.

We therefore strongly advise you to ensure that all systems in your DNS infrastructure have correctly configured NTS clients. Detailed consideration is given to NTS in these articles:

• Security for Network Time Protocol standardised in RFC 8915

• Security flaws in Network Time Protocol make other (security) protocols vulnerable

Our own public NTP/NTS service (nts.)time.nl is described in the following articles:

• Accurate, secure system time is vital for DNSSEC – and vice versa!

• TimeNL: the transparent new NTP service from SIDN Labs

DNSSEC significantly increases the length of the responses that name servers send in reply to DNS queries. The reason being that each Resource Record Set (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 spoofed DNS queries to one or more DNS servers, it's 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.

There 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 both distributed attack clients (a botnet) and distributed DNS servers acting as reflectors. 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 (RFC 2827) states that each internet service provider (ISP) should filter its own outbound internet traffic on the basis of sender address. Packets that (may) originate outside the ISP's IP network should be blocked (ingress filtering). In that way, traffic from infected clients that have been recruited into a botnet is blocked at source.

However, BCP 38 has a fatal flaw: the party that bears the cost isn't the party who stands to gain. BCP 38 serves to protect other people against spoofing attacks mounted from your network.

The maximum DNS packet size transportable using the UDP protocol was originally 512 bytes. For larger packets (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 packets by means of UDP. The EDNS0 extension (Extension Mechanisms for DNS) allows much larger DNS packets, so that packets containing digital signatures can be sent using UDP where possible.

The ability to use larger UDP packets 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 name server (temporarily) limiting the number of identical responses sent to a given client address.

An attacker can abuse an authoritative name server's RRL protection mechanism to increase the probability of a cache poisoning attack being successful. That's done by first using IP address spoofing to deliberately get a caching resolver placed on a popular authoritative name server's RRL blacklist. If the attacker then gives the IP address of the resolver as the sender in a larger number of spoofed UDP packets, the authoritative name server will think that the resolver in question is the victim of a DDoS attack. That will lead the authoritative name 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 poisoning attack on the resolver, because the window for false responses will be greater.

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

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, we have developed a Domain Registration System (DRS) and established a redundant infrastructure in and around Arnhem.

Domains are registered and subsequently managed through registrars: over 1.100 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 complete.

However, the system is inevitably as secure as its weakest link. At the moment, clients remain the weakest link in the chain. Consequently, if for example a PC is infected with malware, it is possible for the malware to manipulate both the (stub) 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, a domain name's DS record could be deleted, a key could be changed, or an extra DS record could be added.

Registered key material in the .nl zone could in principle be modified by a hacker, an SIDN employee, someone working in the supply chain (internet service provider/registrar/reseller), or at the request of a government agency. However, SIDN 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.

The limitations of DNSSEC are considered in more detail here.

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 itself 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 compromise the role entrusted to it, and that has never yet happened.

Although the implementation of DNSSEC involves an investment with no direct commercial return, DNSSEC does deliver significant benefits and opportunities sufficient to support a sound business case.

• Security as a distinctive selling point:

  • For domain registrants, registrars and service providers:

    • Protection against reputational and commercial/financial damage (an aspect of information security and risk management)

    • Market profiling on the basis of use of modern internet security standards

    • For businesses, government agencies and other organisations: a properly secured point of entry for customers, partners and suppliers

    • For internet users: confidence in the security of a familiar brand or organisation's online point of entry

  • For customers and end users:

    • A properly secured point of entry for storing valuable information and performing financial transactions

  • For SIDN registrars:

    • Rebate on domain name registration fees through SIDN's incentive scheme

• DNSSEC as a cryptographically secured basic infrastructure: The addition of cryptographic security to DNS information means that the DNS infrastructure is now also suitable for the distribution of other types of information whose authenticity needs to be guaranteed. DNSSEC therefore opens the way for completely new internet applications, such as:

  • SPF/DKIM/DMARC

  • DANE

  • SSHFP

The addition of cryptographic security to DNS information means that the DNS infrastructure is now also suitable for the distribution of other types of information whose authenticity needs to be guaranteed. Thus, DNSSEC makes the DNS 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 first example is the DKIM/SPF/DMARC protocols, which protect against phishing, spam and virus/malware distribution by securing the sender (an e-mail address), the mail host (a mail system), and the contents of a message. Enabling the standards involves adding records to the domain name's DNS details. Although signing with DNSSEC is not strictly necessary for that (i.e. required by the standard), 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 chain of trust for the X.509 server 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.

The final example is SSHFP, which provides a structural solution to the 'key distribution problem' within SSH. Inclusion of the fingerprint (digital summary) of the SSH server's public key in the DNS (in an SSHFP record) enables the client to validate the public key sent by the server during the connection process. That removes the need for initial manual verification, allowing the client to proceed straight to authentication.

The following security protocols all use DNSSEC as their basis:

• ZONEMD (defined in RFC 8976): publication of a message digest of an entire zone file (in a ZONEMD record in the zone itself), assuring the integrity of the DNS information (and implicitly the authenticity of the source); DNSSEC is recommended but not mandatory; without DNSSEC security, ZONEMD functions simply as a checksum; we recently published a detailed article about ZONEMD

• DANE for OpenPGP (defined in RFC 7929): publication of public OpenPGP keys in an OPENPGPKEY record; a tool for generating records is available on Shumon Huque's website; alternatively, you can use this command: gpg2 --export-options export-dane --export [name@example.nl]

• DANE for S/MIME Certificates (defined in RFC 8162): pinning an S/MIME certificate to an e-mail address (using a hash value in an SMIMEA record); the name for the e-mail address is specified in much the same way as the name for the OPENPGPKEY record; the specification of the certificate is similar to the contents of the TLSA record

• IPSECKEY (defined in RFC 4025): publication of raw public keys in an IPSECKEY record for use with IPsec (via IKEv2); we recently published a detailed article about IPsec

• CAA (defined in RFC 8659): publication of the name of the Certificate Authority (CA) authorised to issue a new certificate for a domain (in a CAA record); the CAA records can distinguish between ordinary certificates and wildcard certificates; it's also possible to publish contact information in a CAA record to facilitate the reporting of breaches of the defined policy (similar to automatic DMARC reporting)

On the contrary, DNSSEC is a complex but well thought-out, future-proof and badly needed protocol that is now very much on the up.

Absolutely. Nearly 60 per cent of all .nl domains are now DNSSEC-enabled. Roughly 60 per cent of all queries received by the authoritative servers for .nl are from validating resolvers. And, by December 2022, roughly 60 per cent of Dutch internet users were utilising validating resolvers.

Jazeker: hoewel het originele DNS-systeem op dit moment niet onveilig is, is het weldegelijk kwetsbaar.

DNS is een van de oudste internetprotocollen die we nog steeds gebruiken. De beveiliging ervan is desondanks pas relatief laat ontwikkeld. Aanvalsmethoden [1] waren niet makkelijk uit te voeren en/of konden relatief makkelijk gepareerd worden, waarmee dergelijke aanvallen in de praktijk zeldzaam waren.

Na lange tijd relatieve rust aan het DNS-front, zijn de afgelopen jaren echter nieuwe aanvalsmethoden [1, 2] gepubliceerd. De beste verdediging tegen deze 'cache poisoning'-aanvallen is DNSSEC.

Whereas the traditional DNS is a largely administrative system, DNSSEC adds an extra layer to the distributed DNS infrastructure, featuring a security mechanism based on public-key cryptography. As a result, the modern DNS is indeed significantly more complex than the DNS used to be.

However, public-key cryptography is nowadays a standard element of many internet applications – including TLS, SSH, S/MIME, OpenPGP, ZRTP and blockchain – meaning that the underlying concepts are familiar to many people in the ICT world.

Furthermore, DNS software developers have done their best to make the complexities of DNSSEC manageable for users, e.g. by the inclusion of ready-to-use default settings. The builders of the PowerDNS software have even adopted a general philosophy of hiding the complexities from the user wherever possible, and automating as much as possible. In many cases, therefore, enabling support for DNSSEC is simply a matter of 'flicking a switch'.

DNSSEC security is based on digital signatures and a distributed chain of trust. That implies that the information in a zone must be consistent and complete before it can be signed, and that coordination is required for the addition of key material to the parent zone.

Those features mean that DNSSEC is indeed a lot less tolerant of errors than the traditional DNS. In the worst-case scenario, an entire domain can be blocked by all validating resolvers. Generally speaking, however, it's sufficient to rectify errors in the zone file before it can be signed.

The re-signing of records and the replacement of keys are now largely automated, meaning that such procedures rarely lead to problems in practice.

No, it isn't. Precisely because DNSSEC is less tolerant of errors than the traditional DNS, its implementations are extensively simplified and automated (for operators).

DNS software developers have done their best to make the complexities of DNSSEC manageable for users. In many cases, therefore, enabling support for DNSSEC is simply a matter of 'flicking a switch'.

The re-signing of records and the replacement of keys are now largely automated.

On the contrary, DNSSEC is a proven, robust technology, which by December 2022 was used by nearly 60 per cent of .nl domains and roughly 60 per cent of Dutch internet users.

No, it's very well supported. DNSSEC is now an integral feature of all actively maintained DNS server en resolver software, all popular network management software and tools, and all popular operating systems. What's more, there are no interoperability issues.

DNSSEC is additionally supported by most registrars and resellers active on the Dutch market. DNSSEC-related knowledge, experience and support are widespread amongst vendors and service providers.

Certainly: the importance of a properly secured digital point of entry has increased sharply. Its importance for businesses, government agencies and other organisations has increased, as their use of the internet to communicate with one another and with their clients/the public has increased. So too has the importance of security for clients/the public themselves, who need to be able to trust a brand or organisation online just as in the physical world.

Absolutely. The internet is increasingly used as a platform for storing valuable information and performing financial transactions. DNSSEC serves to assure internet users that they aren't being misdirected.

On the contrary, DNSSEC increases the security of internet services and reduces the risk of hacking and the associated reputational and commercial/financial damage.

DNSSEC is less tolerant of errors than the traditional DNS. It therefore requires careful implementation and its management is best automated wherever possible.

On the contrary, DNSSEC increases the security of internet services and reduces the risk of hacking and the associated reputational and commercial/financial damage.

DNSSEC is already widely used and has proven itself to be a reliable and secure extension to the DNS.

On the contrary, DNSSEC is now a standard feature of all actively maintained DNS server and resolver software, most of which is open-source software that's available for free.

Software developers have reduced the complexity of and automated the re-signing and key management/rollover processes, meaning that the additional management burden associated with DNSSEC implementation is modest.

The first time you connect to an SSH server, the client asks you to confirm the fingerprint (digital summary) of the server's public key. If you do, the public key is saved by the client (in the file '~/.ssh/known_hosts'). Then, the next time you connect to that same server, the client knows what public key the server should offer, enabling you to proceed straight to authentication.

Although most people click to confirm without further verification, that does leave you theoretically vulnerable to a man-in-the-middle (MITM) attack. To exclude that risk, you should really compare the fingerprint offered at the time of connection with the public key published on the server in question.

SSHFP is a security standard that builds on DNSSEC to offer a structural solution to that so-called key distribution problem. It provides a mechanism for recording the fingerprint in the DNS and making it available to clients (digitally signed using DNSSEC).

SSHFP begins with publication in the DNS of the fingerprint (digital summary) of the of the SSH server's public key. To that end, RFC 4255 defines a dedicated DNS record type: the SSHFP record. An SSHFP record is generated using the 'ssh-keyscan -D' command. Note, however, that the command should (strictly speaking) be run only on the server itself, in order to avoid the risk of a MITM attack.

Once the SSHFP records have been added to the zonefile and the 'VerifyHostKeyDNS yes' setting has been added to your SSH client configuration (in the directory '/etc/ssh/' or '~/.ssh/config'), your client will validate the fingerprint when connecting to the SSH server. In other words, it will compare the public key fingerprint offered by the server with the fingerprint published in the DNS. If they match, the client will proceed to authentication. If they don't match, the client will fall back on the traditional, manual confirmation.

For more information about configuring SSHFP, see this article.

On our Fedora Linux systems (version 34 and above), it wasn't necessary to enable the 'VerifyHostKeyDNS' option in order to make use of SSHFP. It was already installed (in the file '/etc/ssh/ssh_config.d/10-dnssec-trigger.conf') as part of the DNSSEC-Trigger. However, the popular terminal emulator PuTTY doesn't support SSHFP validation.

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

• May 2012: DNSSEC security for .nl domain names fully operational

• June 2012: DNSSEC (and DKIM) added to the 'use-or-explain' list

• End of June 2012: More than ten thousand .nl domains secured with DNSSEC

• July 2012: 100,000 DNSSEC-enabled .nl domain names

• August 2012: Exponential growth: more than 200,000 signed .nl domains

• August 2012: The Netherlands becomes the global leader with 355,000 signed domain names

• September 2012: Rollout exceeds all expectations: more than a million signed domain names

• October 2012: Only a handful of internet access providers support validation

• June 2013: Number of signed .nl domain names passes 1.5 million

• July 2013: Research by SIDN: lack of knowledge is the biggest obstacle to DNSSEC implementation

• September 2013: SIDN nominated for a CENTR Award three times, twice for DNSSEC-related projects

• October 2013: DNSSEC (and IPv6) made mandatory by ICANN from 2014

• January 2014: 1.7 million .nl domain names now signed

• January 2014: Half of all top-level domains now signed

• May 2014: Campus Challenge: five new DNSSEC implementations

• September 2014: A third of all .nl domain names now DNSSEC-enabled

• September 2014: DNSSEC Survey 2014: financials, large corporates, government bodies and ISPs have work to do

• December 2014: Two million .nl domain names now signed

• August 2015: Only a quarter of national government domains in Europe are DNSSEC-enabled

• October 2015: The Netherlands works to promote internet security during EU presidency

• November 2015: Olaf Kolkman receives NLUUG Award, partly because of his contributions to DNSSEC

• December 2015: SIDN starts updating the .nl zone every hour

• October 2016: STARTTLS and DANE mandatory for government organisations

• March 2017: DNSSEC Survey 2017: banks and internet companies dragging their heels

• March 2017: Government and business community start Secure E-mail Coalition

• April 2017: SIDN starts updating the .nl zone every half hour

• May 2017: Support for DANE increasing rapidly; NCSC recommends enabling STARTTLS and DANE

• July 2017: Belgian banks also perform very badly on DNSSEC security

• November 2017: DNSSEC adoption by government bodies stagnates, despite requirements and undertakings

• February 2018: EC recognises DANE as standard for tendering

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.

DLV, short for Dynamic Lookaside Validation, was a method for looking up and validating DNSSEC 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) 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. The support for DLV was limited, however.

The DLV service is now redundant and was withdrawn in September 2017. All DLV-related code has accordingly been removed from BIND version 9.16.0 and above.

Since the signing of the root zone (.) in 2010, there has been 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. As of December 2022, DNSSEC (signing) is supported by more than 90 per cent of all ccTLDs. Turkey's .tr domain is a notable exception. However, it is mainly ccTLDs in the Balkans, Africa, the Middle East and Central Asia that don't yet support DNSSEC.

The DLV function is no longer in use. 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, although the shell service remained live for some time afterwards.

All DLV-related code has accordingly been removed from BIND version 9.16.0 and above.

• General information about DNSSEC on Wikipedia:

  • https://en.wikipedia.org/wiki/Domain_Name_System_Security_Extensions

• Professional information about DNSSEC on dnssec.net:

  • http://www.dnssec.net/

• The DNSSEC Deployment Initiative:

  • https://www.dnssec-deployment.org/

• The DNSSEC standards, as defined in IETF RFCs:

  • http://tools.ietf.org/html/rfc4033

  • http://tools.ietf.org/html/rfc4034

  • http://tools.ietf.org/html/rfc4035

  • http://tools.ietf.org/html/rfc5155 (NSEC3)

  • http://tools.ietf.org/html/rfc8080 (ECDSAcryptography)

• DNSSEC-Tools, a collection of tools for operators, clients and software developers:

  • http://www.dnssec-tools.org/

• More than 30 hands-on guides to DNSSEC (by Johannes Weber):

  • Basic DNS and DNSSEC validation:

    • Basic BIND Installation

    • BIND DNSSEC Validation

    • DNSSEC Validation with Unbound on a Raspberry

    • Pi-hole Installation Guide

    • DNS Capture: UDP, IP-Fragmentation, TCP, EDNS, ECS, Cookie

    • Single DNS Query – Hundreds of Packets

  • DNSSEC signing:

    • DNSSEC Signing with BIND

    • Signing a Delegated Subdomain

    • DNSSEC with NSEC3

    • DNSSEC ZSK Key Rollover

    • DNSSEC KSK Key Rollover

    • DNSSEC KSK Emergency Rollover

    • Signed DNS Zone with too long-living TTLs

    • BIND Inline-Signing Serial Numbers Cruncher

  • DNSSEC extensions:

    • How to use DANE/TLSA

    • SSHFP: Authenticate SSH Fingerprints via DNSSEC

      • SSHFP behind CNAME

      • SSHFP: FQDN vs. Domain Search/DNS-Suffix

      • Generating SSHFP Records Remotely

    • CAA: DNS Certification Authority Authorization

    • PGP Key Distribution via DNSSEC: OPENPGPKEY

  • Testing and troubleshooting:

    • Dive into delv: DNSSEC Validation

    • Compare & Troubleshoot DNS Servers: dnseval

    • Detect DNS Spoofing: dnstraceroute

    • DNS Test Names & Resource Records

    • DNS Capture – The Records Edition

    • How to walk DNSSEC Zones: dnsrecon

    • All-in-One DNS Tool: Domain Analyzer

    • Benchmarking DNS: namebench & dnseval

• NCSC factsheet "Bescherm domeinnamen tegen phishing" (in Dutch)

• DANE SMTP checker for mail:

  • https://github.com/vdukhovni/danechec

• Ondersteuning van DKIM, SPF en DMARC in Exchange 2016 (in Dutch by Jaap Wesselius):

  • SenderID, SPF, DKIM and DMARC in Exchange 2016 – Part I

  • SenderID, SPF, DKIM and DMARC in Exchange 2016 – Part II

  • SenderID, SPF, DKIM and DMARC in Exchange 2016 – Part III

Op de Internet.nl-portal kun je je verbindingen en domeinen testen op de toepassing van 6 moderne internetstandaarden: IPv6, DNSSEC, HTTPS, DMARC, STARTTLS en DANE. De uitkomsten resulteren in een gecombineerde totaalscore, waarmee je ook een kwantitatieve indicatie krijgt van je "compliance".

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

Over the years, SIDN has published quite a number of 'hands-on' guides to DNSSEC signing on authoritative name servers:

• DNSSEC signing in BIND named

• DNSSEC signing on the PowerDNS Authoritative Server

• DNSSEC signing on an Infoblox appliance

We have also published a number of 'hands-on' articles about validation on (caching) resolvers:

• DNSSEC validation using Unbound and DNSSEC-Trigger

• DNSSEC validation on BIND named

• DNSSEC validation with the PowerDNS Recursor

• DNSSEC validation on an Infoblox appliance

An overview of the various software packages, and the key features of each, is available here.

SIDN also publishes a steady stream of DNSSEC-related news bulletins, technical articles, reports and case studies on sidn.nl.

Once you have implemented DNSSEC, we advise you to check out our hands-on guides to implementation of the mail security standards SPF/DKIM/DMARC and STARTTLS/DANE for Postfix and for Exim (the two most popular mail server software packages):

• Implementing SPF, DKIM and DMARC in Exim

• Implementing SPF, DKIM and DMARC in Postfix

• Implementing DANE in Exim

• Implementing DANE in Postfix

Finally, for an overview of the interrelationships, inter-dependencies and relative priorities of all the modern standards listed above, see our maturity model: