Change domain registrar: What you need to consider

The Internet giant Google wants to enter the domain business – the betaversion of its service is already. This could trigger a domain change movement and thus create a shock wave in the IT departments. As a boss, you only have to announce that you want to change your domain names to another registrar. Or the mail server to another provider. All services including the redesigned website of the company are to be on the net at exactly nine o’clock in the morning on Monday morning with NULL downtime. The latter will cause an additional hysteria. In order to understand why these seemingly trivial requirements when changing the domain registrar are anything but easy to solve, we need to deal a bit with the theory of the domain name system.

Resolver and resolver


There are basically two types of name servers: authoritative and recursive resolvers. With an authoritative name server, it can be assumed that the data originate from a local zone file and are secure. For caching or recursive resolven, the server fetches the data from another name server. A computer, laptop, tablet or smartphone uses the latter method when the user polls something from the Internet.


Reduce the TTL value


For example, if a user wants to send an email, the application must connect to the IP address of the mail server, and the device queries the IP address for the recursive resolver. The resolver searches the Internet and returns with the IP address of the requested server. In contrast, the authoritative name server, together with the IP address, also returns an additional value, a time span in seconds that expresses how long the information is cached.

This concept is called caching and is often used to speed up operations that do not change frequently. In the DNS world, this is a cornerstone for uninterrupted user experience and increased resilience. This time span has a name: it is called Time to Live or TTL. As a rule, it has relatively high values, since domain name information is often static. 86.400 (1 day) is a TTL guideline, which is often found in zon files.


About the author Dirk Jumpertz


Recall the above migration of the mail server. What happens if the TTL was 24 hours and the IT team changed the address of the mail server, updated the zon file of your domain name, and uploaded it again? Will the Internet accept the changes and immediately start using the new mail server? The answer is no. At least not before expiration of TTL, in this case, 24 hours.


This means that it takes 24 hours for the entire Internet to accept the change. In the meantime, you are in Grauzone, and mails are sent to the old mail server and the new mail server. At this time, you can do nothing except the storm. E-mails can be delayed, in the worst case some messages have disappeared irrevocably. A small precaution can easily prevent this nightmare: the TTL is part of the definition of your zon file and can be manipulated.


It is sufficient to lower the TTL to a much lower value, for example, 600 (10 minutes) before the actual change. This change must be 1 TTL before the actual scheduled change so that the Internet can accept the reduced TTL value. After this change, the uncertainty window is reduced to only 10 minutes and reduces possible problems to an acceptable and manageable level.


After completion of the conversion, the TTL can be reset to its original value. Administrators who manage the DNS must know the subtleties of TTL, of course, if they really want to control their zon files and manage mail server conversions without fainting.