Adopting DNSSEC is never too late

Threat status

The DNS is a crucial Internet service. It underpins most of the activities we carry out on the net. If it breaks down, nothing works. If it is hijacked or impersonated, we can find ourselves redirected to goodness knows where. The problem has been around for a long time: bits circulating on the net are at the mercy of alteration by actors along the way. But the DNS has an additional vulnerability: in relying on the User Datagram Protocol (UDP) by default, which does not provide any authentication of the sender’s IP address, not even simplistic, it allows an attacker to inject fake responses into the resolver², which will then be transmitted to the user.

It is not easy to give precise figures for the occurrence of these attacks in the real world³. Attacks that poison the resolver are designed to be very discrete and have not been much studied. But laboratory experiments show that they are perfectly possible.

DNSSEC

The solution to all these problems of authentication (verifying that the data really come from the expected source) and integrity (verifying that the data have not been altered on the way) is well known in the world of the Internet – cryptography (or encryption). More precisely, it is the use of one of the services provided by cryptography: the signing of data. The manager of a domain signs the data and any subsequent change to these data will invalidate the signature. A possible attacker will still be able to alter the bits, but the operation will be detected. It is thus not possible to be diverted from a domain to a phishing website without noticing it.

We need to stress one point: for DNSSEC to provide effective protection, two different actors must come into play; the technical manager of the domain, who has to sign the domain, and the technical manager of the resolver, who has to validate the signatures.

Deployment

Since encryption has become so routine nowadays on the Internet, it may seem surprising that DNSSEC, which uses only classic cryptographic solutions, is not universally deployed. Unfortunately this is a common security problem, in general and in cybersecurity in particular: with each attack come concerns, indignation and resolutions to do better, but after a few weeks all this is forgotten and everything goes on as before. DNSSEC also suffers from the fact that many other security weaknesses exist, and that they may be considered more crucial. To take just one example, if an organisation does not apply security updates immediately on its servers, but leaves them vulnerable for months or even years, it would not be reasonable to push for deployment of DNSSEC: there is more urgent work to be done.

Consequently, DNSSEC is currently insufficiently deployed.  The root and the overwhelming majority of TLDs (including .fr, of course) are signed with DNSSEC⁴. But many second- (or lower) level domains are not signed.

There is another difficulty that we should point out. Many resolvers validate or verify these signatures. This is notably the case with the access provider Free, or all the major public DNS resolvers, such as those of Google, Quad9, Cloudflare or the future resolver DNS4EU promoted by the European Commission. But some resolvers still do not validate signatures.

Understanding, implementing and maintaining DNSSEC

To encourage this deployment, Afnic is organising a two-day DNSSEC training session for people in charge of managing, maintaining and supervising DNS infrastructure, whether with authoritative servers, hosting DNS zones, or with resolvers.

With a view to equipping participants to understand, implement and provide DNSSEC to their clients/users on a daily basis, the training session will include a review of the workings of the DNS, a detailed presentation of the risks, an explanation of the workings of DNSSEC and varied practical exercises on Unix machines.

In conclusion

DNSSEC is now a necessary component of DNS security. The objective is to see it deployed on a wide-spread basis. Afnic participates actively in this deployment, through its operational activity on the .fr domain, of course, but also through its training activity and by developing DNS and DNSSEC testing software, notably Zonemaster.

^{1 – https://stats.labs.apnic.net/dnssec}

^{2 – An oft-cited name is that of Dan Kaminsky, who, although he did not invent this attack, did considerably developed and enhanced it in 2008.}

^{3 – It must be borne in mind that almost all data on the number of cyberattacks are rough guesses, with no precise or documented methodology.}

^{4 – The more so as ICANN obliges TLDs under contract with it to be DNSSEC signed.}