Domain Name system or DNS is basically an internet service which translates the domain names into IP address. A domain name is actually available in alphabetic manner and is very easy to remember like www.amazon.com. But the internet world is based upon the IP addresses. Whenever you use the domain name of any website, the DNS ultimately convert it into IP address. For example a domain name of the website www.toysforyou.com is being translated by the DNS into an IP address 184.108.40.206. It’s a quite difficult decision for anyone to switch from its older server to a new one. Because if you are shifting your website from one server to another has to face a lot new changes
So, we often avoid switching the server only just when we will find a good financial deal or may be we want to upgrade his server. But besides all these minor problems, the basic and major problem which forces us to shift the server is the DNS caching problem. DNS caching is basically a program that contains the entries which translate the domain names to IP addresses. The DNS cache become poisoned or polluted when unofficial domain names or IP addresses inserted in it. A DNS cache might be corrupted because of the technical glitches or administrative accidents. But mostly DNS cache poisoning is linked up with the computer viruses or other external hazards. It also might happened that because of DNS caching problem your emails are delivered to the other server or some of your users will still browse your website on the older server as you have switched from that server a long time ago. These DNS caching problems will be resolved by a simple and easy DNS trick given below.
But before to do this process in a most effective and successful way, we need to understand a little bit about how DNS caching works. When an authoritative DNS server (for example a domain on which we are switching) receives a query from a DNS resolver and if that query is successful then that query will cache that response for a predefined time. It actually means that the specific sever will use the cached information for that amount of time and will not go for further queries from the authoritative server. Because of this, that specific timer is then defined in the authoritative server and we can this work until all the remote servers will follow the standards. You have a full control over your DNS authoritative server for a thriving and successful operation.
TTL value is the parameter which is going to be tweaked here. The TTL value is basically use to verify the default (technically, minimum) TTL (time-to-live) for DNS entries but currently it is used fro the negative caching. The definition of TTL value from RFC1921 is given below :
“The default TTL (time-to-live) for resource records – how long data will remain in other nameservers’ cache. ([RFC 1035] defines this to be the minimum value, but servers seem to always implement this as the default value) This is by far the most important timer. Set this as large as is comfortable given how often you update your nameserver. If you plan to make major changes, it’s a good idea to turn this value down temporarily beforehand. Then wait the previous minimum value, make your changes, verify their correctness, and turn this value back up. 1-5 days are typical values. Remember this value can be overridden on individual resource records.”
In the above mentioned definition RFC briefly describes you the simple way to do the whole process. Now I will explain you by an example where I will run BIND9 as an authoritative nameserver and the zone domain_ to_ move.com. If you are using a particular DNS server then configuration based on that server will look different just similar to that different DNS server run by you. Just see below we have a very simple file zone that looks like this (the IPs are private ones just for the exemplification):
; zone 'domain_to_move.com' $TTL 86400 @ IN SOA ns1.domain_to_move.com. hostmaster.domain_to_move.com. ( 2006052101 ; Serial 10800 ; Refresh 3 hours 3600 ; Retry 1 hour 604800 ; Expire 1 week 86400 ); Minimum 24 hours @ NS ns1.domain_to_move.com. @ NS ns2.domain_to_move.com. @ A 192.168.0.10 @ MX 10 mail.domain_to_move.com. ; Nameservers ns1 A 192.168.0.1 ns2 A 192.168.0.2 ; Mail mail A 192.168.0.10 ; Web www CNAME domain_to_move.com
The zone file’s first line ($TTL 86400) is defining the default TTL for the entire existing records to 86400 seconds (means 24 hours). We have to lower this value to a smaller value at least up to 60 seconds. This reveals that any of the remote servers will not cache the record for more than one minute.
; zone 'domain_to_move.com' $TTL 60 @ IN SOA ns1.domain_to_move.com. hostmaster.domain_to_move.com. ( 2006052102 ; Serial ...
After that we have to activate the new configuration after restocking the DNS server. At this stage we have to wait for some time for the previous TTL amount of time (here 1 day) to make it confirm that no other remote DNS server has that information in the cache. After this critical step we can easily proceed further and change the actual IPs to point to the new server. We have observed from this example that nameserver will not be changed but if you are shifting to the new server then you should take care of one thing the namesevers will be configured in the same way. Once the move has complete, you must get back to some normal TTL value as this will minimize the DNS traffic and allow again having the information properly cached.
To know how the remote servers will see your DNS zone and check all the parameters, visit this link: http://www.dnsreport.com/