- 10-03-22There's always a workaround: why censorship doesn't work
- 15-04-21AVG: Dutch CIOs vs. US cloud providers
- 10-03-21Grapperhaus thinks installing a backdoor does not weaken encryption
- 12-02-21Max & BIT - Secure video calling within WordPress with Jitsi
- 03-11-20BIT provides support with ISAE 3402, ISAE 3000 and SOC 2 certifications
- 20-10-20Security monitoring at BIT
- 02-10-20Deep Dive in the BIT colocation network
- 24-07-20SMF or MMF? And what exactly is dispersion on a glass fiber?
- 01-07-20Network statistics in the BIT Portal: techniques and tools
- 17-06-20Email at BIT protected against spam and phishing by using DMARC
Realtime zonefile updates for .nl?
03-06-2016 09:12:06
BIT employees are active in several organisations and bodies to represent (in random order) the company, the internet and BIT's clients. On behalf of BIT, Wido Potters is a member of the technical committee of the Association of Registrars (AoR). The AoR protects the interests of the registrars and their clients with SIDN, the organisation that is responsible for all .nl domain names. Together with Kees Monshouwer of Monshouwer Internet Services, he wrote the following blog for the newsletter of the AoR.
The zonefile is a kind of list with domain names and their settings.
A common request of registrars is realtime zonefile updates for .nl. When purchasing a domain name (and hosting package) the client could immediately start working and show the results to friends, family and colleagues. Incredible. This would mean the end of questions about the airdate of the domain name. Or not?
The technical committee of AoR shares in the desire for faster zonefile updates. However, we see a number of technical obstacles that make realtime updates undesirable, but rather increasing the frequency of the updates. At the request of the AoR, the SIDN has taken the first step towards making more updates by refreshing the zonefile every hour instead of every two hours.
Some insights into how the Domain Name System (DNS) works, is important to understand the technical obstacles. With resolving (searching) a hostname, DNS works backwards. Behind every hostname, for example www.verenigingvanregistrars.nl, there is a dot: this stands for root. So actually it says www.verenigingvanregistrars.nl. (dot). When looking up the IP address or the IP addresses you can find www.verenigingvanregistrars.nl on, the resolving name server will start with the dot, or root. The DNS is not necessary for the question asked to the root, because every resolver has the IP addresses of the root name servers saved. The resolving name server asks the root: "Where do I find www.verenigingvanregistrars.nl.?". If the domain verenigingvanregistrars.nl is not registered or only just registered but not in the zonefile, the name server will indicate that the domain does not exist and inform how long that response can be saved. This period of time is called the 'negative TTL'.
If the domain is registered and in the zonefile, the .nl name server will answer that it does not have that answer, but will also indicate the name servers of verenigingvanregistrars.nl that can be asked the same question. It will also tell you how long the redirection to these name servers (NS) can be saved. This period of time is called the 'NS TTL'. If the domain name verenigingvanregistrars.nl features DNSEC, the DS record and its saving time will also be indicated. That period of time is called the 'DS TTL'.
Finally, the name servers for verenigingvanregistrars.nl will be asked where www.verenigingvanregistrars.nl. can be found. The resolver will finally get an answer to that question and will show that to the person looking for www.verenigingvanregistrars.nl.. The answer will be saved for the duration of the set TTL.
The answer can be saved for a certain amount of time so the resolving name server does not need to play the same question-and-answer game for every single one of the clients' requests. If the one client of a big internet access provider visits the website of the AoR and the resolving name server of that provider starts asking around in the DNS, that same resolver does not need to ask the same questions a few moments later when another client visits the website of the AoR. This somewhat limits the DNS traffic and the load on the different name servers.
TTL's have another use too. During problems with updating the zonefile or the availability of the name servers, the TTL ensures that the domains without an expired TTL remain available. Nice to have, because we all know that no matter how well you have things organised, there will come a day that something goes wrong.
For a long time, SIDN published a new zone every two hours. So every two hours a zonefile was updated with information on the registered domain names, which name servers belonged to them and possible which DS record existed for that domain name with the accompanying TTL's. Recently that publication rate went up to once every hour. There are registries that update their zonefiles even more frequently. EURid. (.eu) and Verisign (.com) update their zonefile in realtime, so every change is directly entered into the zonefile. That's useful! But the speed with which changes to that zonefile are known to the entire world, is still dependent on the set TTL's. And that is something the operators of .nl have organised better than their colleagues from .eu and .com.
As a result, changes (other name servers of another DS record in case of relocation for example) for .nl domain names are known much sooner than changes for .eu and .com. However, for new registrations .eu and .com are (a little) faster than .nl.
Let's see what actually happens during a new registration. As described above, the negative TLL helps determine when a new domain name is sure to get the resolver the new answer. The negative TTL for .com is on 900 seconds. For .eu and .nl, the negative TTL is 600 seconds, so 10 minutes. It takes up to the zonefile update plus the negative TTL for a new registration to be known to all resolvers. For .eu that would be 10 minutes (realtime + 10 minutes), for .com 15 minutes (realtime + 15 minutes) and for .nl 70 minutes (1 hour + 10 minutes).
The NS TTL is important for changes to domains. The NS TTL for .nl is 3600 seconds, so an hour. For .eu and .com it is 86400 seconds, which is a day. That means that changes to the .nl domains can be known within 2 hours (1 hour zonefile update + 1 hour NS TTL), but for both .eu and .com that takes up to a day (realtime + a day).
For relocating domain names with DNSSEC, the .eu and .com situations are even worse. In addition to the NS TTL, the DS TTL is also affecting the processing time. And because you cannot act on both TTL's simultaneously, you have to calculate for both TTL's separately in the run time.
An insecure relocation, where the domain name is not protected with DNSSC during the move, takes approximately 4 hours for .nl, but for .eu and .com it can take up to 2 whole days.
For secure relocations, with DNSSEC active during the move, the run time will be even longer. Very inconvenient if a client has reasons to move the domain name as quickly as possible.
Therefore the technical committee of the AoR opts for more frequent updates of a zonefile, while maintaining the current TTL's of .nl. Please feel free to ask questions or voice opinions about this. You can contact them on com.tech@verenigingvanregistrars.nl.
By: Wido Potters and Kees Monshouwer
The zonefile is a kind of list with domain names and their settings.
A common request of registrars is realtime zonefile updates for .nl. When purchasing a domain name (and hosting package) the client could immediately start working and show the results to friends, family and colleagues. Incredible. This would mean the end of questions about the airdate of the domain name. Or not?
The technical committee of AoR shares in the desire for faster zonefile updates. However, we see a number of technical obstacles that make realtime updates undesirable, but rather increasing the frequency of the updates. At the request of the AoR, the SIDN has taken the first step towards making more updates by refreshing the zonefile every hour instead of every two hours.
Some insights into how the Domain Name System (DNS) works, is important to understand the technical obstacles. With resolving (searching) a hostname, DNS works backwards. Behind every hostname, for example www.verenigingvanregistrars.nl, there is a dot: this stands for root. So actually it says www.verenigingvanregistrars.nl. (dot). When looking up the IP address or the IP addresses you can find www.verenigingvanregistrars.nl on, the resolving name server will start with the dot, or root. The DNS is not necessary for the question asked to the root, because every resolver has the IP addresses of the root name servers saved. The resolving name server asks the root: "Where do I find www.verenigingvanregistrars.nl.?". If the domain verenigingvanregistrars.nl is not registered or only just registered but not in the zonefile, the name server will indicate that the domain does not exist and inform how long that response can be saved. This period of time is called the 'negative TTL'.
If the domain is registered and in the zonefile, the .nl name server will answer that it does not have that answer, but will also indicate the name servers of verenigingvanregistrars.nl that can be asked the same question. It will also tell you how long the redirection to these name servers (NS) can be saved. This period of time is called the 'NS TTL'. If the domain name verenigingvanregistrars.nl features DNSEC, the DS record and its saving time will also be indicated. That period of time is called the 'DS TTL'.
Finally, the name servers for verenigingvanregistrars.nl will be asked where www.verenigingvanregistrars.nl. can be found. The resolver will finally get an answer to that question and will show that to the person looking for www.verenigingvanregistrars.nl.. The answer will be saved for the duration of the set TTL.
The answer can be saved for a certain amount of time so the resolving name server does not need to play the same question-and-answer game for every single one of the clients' requests. If the one client of a big internet access provider visits the website of the AoR and the resolving name server of that provider starts asking around in the DNS, that same resolver does not need to ask the same questions a few moments later when another client visits the website of the AoR. This somewhat limits the DNS traffic and the load on the different name servers.
TTL's have another use too. During problems with updating the zonefile or the availability of the name servers, the TTL ensures that the domains without an expired TTL remain available. Nice to have, because we all know that no matter how well you have things organised, there will come a day that something goes wrong.
For a long time, SIDN published a new zone every two hours. So every two hours a zonefile was updated with information on the registered domain names, which name servers belonged to them and possible which DS record existed for that domain name with the accompanying TTL's. Recently that publication rate went up to once every hour. There are registries that update their zonefiles even more frequently. EURid. (.eu) and Verisign (.com) update their zonefile in realtime, so every change is directly entered into the zonefile. That's useful! But the speed with which changes to that zonefile are known to the entire world, is still dependent on the set TTL's. And that is something the operators of .nl have organised better than their colleagues from .eu and .com.
As a result, changes (other name servers of another DS record in case of relocation for example) for .nl domain names are known much sooner than changes for .eu and .com. However, for new registrations .eu and .com are (a little) faster than .nl.
Let's see what actually happens during a new registration. As described above, the negative TLL helps determine when a new domain name is sure to get the resolver the new answer. The negative TTL for .com is on 900 seconds. For .eu and .nl, the negative TTL is 600 seconds, so 10 minutes. It takes up to the zonefile update plus the negative TTL for a new registration to be known to all resolvers. For .eu that would be 10 minutes (realtime + 10 minutes), for .com 15 minutes (realtime + 15 minutes) and for .nl 70 minutes (1 hour + 10 minutes).
The NS TTL is important for changes to domains. The NS TTL for .nl is 3600 seconds, so an hour. For .eu and .com it is 86400 seconds, which is a day. That means that changes to the .nl domains can be known within 2 hours (1 hour zonefile update + 1 hour NS TTL), but for both .eu and .com that takes up to a day (realtime + a day).
For relocating domain names with DNSSEC, the .eu and .com situations are even worse. In addition to the NS TTL, the DS TTL is also affecting the processing time. And because you cannot act on both TTL's simultaneously, you have to calculate for both TTL's separately in the run time.
An insecure relocation, where the domain name is not protected with DNSSC during the move, takes approximately 4 hours for .nl, but for .eu and .com it can take up to 2 whole days.
For secure relocations, with DNSSEC active during the move, the run time will be even longer. Very inconvenient if a client has reasons to move the domain name as quickly as possible.
Therefore the technical committee of the AoR opts for more frequent updates of a zonefile, while maintaining the current TTL's of .nl. Please feel free to ask questions or voice opinions about this. You can contact them on com.tech@verenigingvanregistrars.nl.
By: Wido Potters and Kees Monshouwer