DNS vulnerability that makes resolvers susceptible to DDoS attacks removed
Joint research by SIDN Labs, InternetNZ and USC/ISI reveals DDoS threat to TLDs
Chose your color
Frequently visited
Frequently asked questions
The Whois is an easy-to-use tool for checking the availability of a .nl domain name. If the domain name is already taken, you can see who has registered it.
On the page looking up a domain name you will find more information about what a domain name is, how the Whois works and how the privacy of personal data is protected. Alternatively, you can go straight to look for a domain name via the Whois.
To get your domain name transferred, you need the token (unique ID number) for your domain name. Your existing registrar has the token and is obliged to give it to you within five days, if you ask for it. The procedure for changing your registrar is described on the page transferring your domain name.
To update the contact details associated with your domain name, you need to contact your registrar. Read more about updating contact details.
When a domain name is cancelled, we aren't told the reason, so we can't tell you. You'll need to ask your registrar. The advantage of quarantine is that, if a name's cancelled by mistake, you can always get it back.
One common reason is that the contract between you and your registrar says you've got to renew the registration every year. If you haven't set up automatic renewal and you don't renew manually, the registration will expire.
Wanneer je een klacht hebt over of een geschil met je registrar dan zijn er verschillende mogelijkheden om tot een oplossing te komen. Hierover lees je meer op pagina klacht over registrar. SIDN heeft geen formele klachtenprocedure voor het behandelen van een klacht over jouw registrar.
Would you like to be able to register domain names for customers or for your own organisation by dealing directly with SIDN? If so, you can become a .nl registrar. Read more about the conditions and how to apply for registrar status on the page becoming a registrar.
Joint research by SIDN Labs, InternetNZ and USC/ISI reveals DDoS threat to TLDs
Joint research by SIDN Labs, InternetNZ (operator of New Zealand's .nz domain) and USC Information Sciences Institute (US) has localised and resolved a vulnerability in the Domain Name System. The vulnerability meant that malicious actors could potentially use DNS resolvers to mount large-scale DDoS attacks on top-level domains (TLDs) and other authoritative DNS operators. Since learning of the issue from the researchers, Google has removed the vulnerability from Google Public DNS, one of the world's most popular public DNS resolvers. The researchers are calling on other DNS server and resolver operators to check whether their systems have the same weakness and, if they do, to rectify the situation urgently.
Dubbed tsuNAME by the researchers, the vulnerability makes it possible to mount DDoS attacks by exploiting pairs of name server records that point to each other. That situation is known in the industry as a 'cyclic dependency'. Attackers can exploit cyclic dependencies by getting vulnerable resolvers to send large volumes of queries to authoritative name servers. If a resolver doesn't detect the dependency, it will endlessly send DNS queries back and forth between the servers for the two domain names. The researchers identified a number of resolvers that were liable to get stuck in such loops for hours on end.
Where a resolver also doesn't cache mutually dependent NS records, the issue can support a major DDoS attack. In a situation like that, the resolver will contact the authoritative server much more often than if the records are cached, substantially increasing the volume of traffic to, for example, a TLD operator's DNS servers. If cyclic dependencies exist, the activity will continue indefinitely. The DNS uses caches to manage the load on authoritative servers and make the system scalable.
Since February, the team has been engaged in a 'responsible disclosure' process, quietly warning as many operators as possible about the vulnerability. Internationally standardised timelines were followed. Public disclosure was made today at the DNS-OARC workshop and on https://tsuname.sidnlabs.nl, the official website for the vulnerability.
A few experts have known about the vulnerability for a while, but until now there has been insufficient measured data available for the problem to be localised and resolved. The team's measurement study has now provided the necessary data.
The vulnerability can be removed by installing an additional code sequence that enables resolvers to detect cyclic dependencies and interrupt loops. An appropriate piece of code has to be provided by the resolver software's producer. Recent versions of many resolver programs are no longer vulnerable to tsuNAME. Older versions remain susceptible, however, as explained in the researchers' Security Advisory.
Authoritative DNS server operators can also make use of an open-source tool called CycleHunter. Specially developed by the research team and significantly improved by the DNS community, the tool flags up cyclic dependencies between domain names in the user's zone. The researchers emphasise that NS records can change at any time, making it advisable to scan several times a day in order to minimise the impact of misconfigurations. The Security Advisory also sets out a step-by-step problem resolution plan for authoritative DNS operators to follow.
As highlighted in the researchers' technical report, Google Public DNS was found to be the main source of repetitive queries in many cases. The issue was therefore drawn to Google's attention, and has since been fixed. Analysis performed on 9 February by researchers at SIDN Labs, InternetNZ and USC Information Sciences Institute confirmed that the previously observed DNS vulnerability was no longer present on Google's public DNS resolver. Cisco has also fixed its OpenDNS software.
SIDN Labs' Data Scientist Giovane Moura explained, "We are dedicated to promoting the security and stability of the internet infrastructure in the Netherlands, Europe and beyond. The detected vulnerability has the potential to cause serious problems. The project also emphasises the importance of collaboration in this field. After all, it isn't only the .nl domain that is potentially at risk from this vulnerability. It could cause major difficulties for all top-level domains. As any large DDoS, an attack that exploited the weakness we detected could stop people accessing the online services of banks, governments and online stores, for example."
Contact person:
Communication Manager / Spokesman
Share this article