Dissecting DNS Defences during DDoS
Recommendations for operators and developers
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.
Recommendations for operators and developers
The Internet Domain Name System (DNS) has been a frequent victim of DDoS attacks. Dyn, a large DNS provider, has been the target of a 1.6Tb/s DDoS fueled by the large IoT Mirai botnet. The Root DNS servers, too, have been victims of DDoS attacks several times -- the November 2015 attack was estimated at 35Gb/s.
The DNS has been designed with several defences strategies to improve availability and resilience, both on the authoritative servers side and on the recursive resolvers side.
Authoritative DNS servers (the ones that host entire zones, like the Root servers) rely heavily on replication by having name server replication and/or IP anycast. Name server replication is when multiple servers are used for the same zone, as with the root zone, which has 13 name servers. Each of them, in turn, can be further replicated using IP anycast, which allows the same IP address to be announced from multiple physical locations and enables BGP to map a client to each location.
On the recursive resolver side, caching (sometimes using multiple levels) of DNS answers and retrying queries are the two main tactics used to provide resilience.
Given that various strategies are in use, we have conducted a study to establish how the strategies affect DNS resilience and latency in the wild, exploring both the client-side DNS user experience and server-side traffic. To do that, we carried out controlled experiments using Ripe Atlas and analysed traffic from two production zones (.nl and the Roots).
Our study reached four main conclusions, which serve as recommendations for both operators and developers:
We found that, in the wild, caching behavior is often as expected, but about 30% of the time clients do not benefit from caching (Section 3). That observation was confirmed in both the .nl zone and the Root zones (Section 4).
On the recursive resolver side, caching and retries provide a significantly resilient client user experience during DDoS attacks (Section 5). Even with very heavy query loss (90%) on all authoritatives, full caches protect half of the clients, and retries protect 30%.
On the authoritative side, we showed that there is a large increase in legitimate traffic during a DDoS attack (up to eight times in our experiments), mainly due to retries. While DNS servers are typically heavily overprovisioned, this result suggests the need to review the level of overprovisioning (Section 6).
Finally, our results enable us to suggest why users have experienced relatively little impact from DDoS attacks on Root servers while the customers of some DNS providers felt the impact of attacks straight away (Section 8).
The full report (PDF) can be downloaded from both the SIDN and USC/ISI websites.
A previous version of this blog has appeared at the Ripe Atlas blog.
Article by:
Share this article