Migrating a website from one host to another is the main reason for contact with DNS. There are several ways to do this:
- send us the logins to the previous host and the domain registrar, and let M.D.G. IT handle the process
- transfer the domain to M.D.G. IT, which takes 1-2 days, and likewise let us handle the process
- update DNS yourself
if updating DNS yourself, our advice is to not move sites by updating nameservers at the registrar. This is because this leads to long, unpredictable propagation times, during which you cannot know whether website visitors are being directed to the old or new server. The two recommended ways of moving a site from one server to another are:
- drop TTLs on the existing DNS server to 300. Wait for the previous TTL to expire, then update A, MX etc records on the old host. This moves the site to M.D.G. IT. Once this has propagated, redelegate the domain to MDG IT nameservers (redelegating means replacing the old nameservers at the registrar with new nameservers.), or
- if you do not have access to the existing DNS server, we can duplicate the existing records on our nameservers, and the domain is then pointed at these. Up to this point this makes no change to where the site hosted. Once this change has propagated (~4-24 hours depending on TTLs), we can then update the local records to point traffic at the new server.
How DNS works
While DNS can seem daunting, the underlying mechanisms are relatively simple. In order to demystify what is essentially analogous to looking up a number in a phone book, we've put together this general guide to how DNS works. Before delving into the below, it's worthwhile mentioning that an understanding of DNS is by no means required to run a website. M.D.G. IT customers can either- register domains with M.D.G. IT
- transfer existing domains to M.D.G. IT
- provide 3rd party registrar logins in a support ticket
and we can set everything up as required. For those who want to understand what's going on, read on.
A simple overview of DNS
Machines on the internet are identified by numbers, called IP addresses. These look like, for example, 74.125.136.94. You can actually put an IP address in a browser and load the site hosted there.
For several reasons, including the fact that a domain name like google.com.au is easier to remember than 74.125.136.94, the internet uses domain names rather than numbers.
DNS is the process by which a URL like google.com.au is translated into its IP, 74.125.136.94. For DNS to work:
- The domain needs to be registered at a domain registrar.
- At this domain registrar, the authoritative nameservers for the domain need to be specified. This is done in the registrar's control panel, by entering the nameservers. These nameservers look like e.g.
ns11.mdgit.com.au
ns12.mdgit.com.au
Please be sure to use the nameservers that were sent in your Welcome Email, these may not be the same as the NS above - The authoritative nameservers then basically function like a phonebook, consulting the DNS zone file, which means the actual records, which need to be set up at these nameservers. To continue with the phone book analogy, the zone file is the actual page of the book with the names and numbers.
DNS hierarchy
DNS is hierarchical. When you look up a domain, you don't know where its nameservers are, so you ask one of the 13 root name servers. The (simplified) hierarchy is:
Top level nameservers. All these do is say either
"ask these other nameservers where the authoritative nameservers for the domain are", or
"the authoritative nameservers with records for google.com.au are: ns1.google.com, ns2.google.com, ns3.google.com..".
Before looking up the number, you have to ask a top level nameserver which phonebook to use. They have this information because when you enter your nameservers at the registrar, the registrar then sends this information to the top level nameservers, aka parent nameservers. There is generally more than one level of these.
You will never need to have any interaction with these nameservers, they are included in this explanation only for completeness.
Authoritative nameservers. These are your nameservers, e.g. ns11.mdgit.com.au and ns12.mdgit.com.au. These are the actual nameservers that say "google.com.au is at 74.125.237.31". They consult the zone files that are set up locally and return the corresponding record, in this case the A record.
Nameserver records are normally set up automatically when you sign up for a hosting plan.
A records, MX records, CNAME
An A record is the basic DNS record that defines what IP corresponds to a domain. If you go to ns1.google.com and ask "where is google.com.au", you're asking
"where does the A record for google.com.au point?"
;; QUESTION SECTION:
;www.google.com.au. IN A
;; ANSWER SECTION:
google.com.au. 300 IN A 74.125.237.31
In human terms, "google.com.au is at 74.125.237.31".
A CNAME record, rather than saying abc.com is at [some IP], says "abc.com is at the same place as xyz.com". There is nothing sophisticated about this, it is used simply to avoid having to update multiple records. You might have, for example,
mysite.com
mysecondsite.com
blog.mysite.com
all running on the same server, i.e. on the same IP. You can either set up A records for each, or just set up a CNAME for each of mysecondsite.com, blog.mysite.. and so on, pointing at mysite.com. Then, when the IP for mysite.com changes, the IPs for all the CNAMES pointing at it change also.
MX records are instructions as to which server handles mail for a domain. So the answer to "which server do I talk to to deliver a message for [anyone]@google.com.au is
;; ANSWER SECTION:
google.com.au. 600 IN MX 10 aspmx.l.google.com.
google.com.au. 600 IN MX 20 alt1.aspmx.l.google.com.
There are more than one, and the 10, 20 represents priority - there can be multiple such records. This is saying "try this server first, it has the lowest number (and hence the highest priority). If it's down or you can't connect then try the server with the next highest priority number."
Only one MX record is required, and if no MX record exists, the same server that the main A record points to is taken implicitly to handle mail.
TTLs
TTL stands for Time To Live. In the example above, note how the google A record includes the number 300. This indicates the time, in seconds, that the result (74.125...) should be remembered before asking this nameserver for this record again. DNS records don't generally change very often, and so DNS records are cached downstream to reduce the number of requests made.
ISP nameservers
To complicate things slightly, individual computers don't normally talk to remote DNS servers directly, but ask their network's DNS server to do the work for them. The advantage to this is that the network DNS server has probably done the lookup before, and so as long as the last lookup was within the TTL, they can say "google.com.au is at 74.125.237.31" without actually having to look anything up.
How does it work in practice?
If you want to open google.com.au in a browser, you computer needs to look up the domain's IP address. In practice this means your computer will query its network's nameservers, these are normally the ISP's nameservers. If this ISP nameserver hasn't looked up this record recently, and assuming for the sake of demonstration that it doesn't have anything cached, it will look do the lookup in this order:
- Ask a root nameserver, "where is google.com.au?"
- the root nameserver responds with:
;; AUTHORITY SECTION:
Basically saying "I don't know, but the anything that ends in .au is dealt with by a.au, b.au.."
au. 172800 IN NS a.au.
au. 172800 IN NS b.au.
au. 172800 IN NS l.au.
au. 172800 IN NS m.au.
au. 172800 IN NS n.au. - The ISP nameserver then asks one of these, e.g. a.au, and receives the answer:
;; AUTHORITY SECTION:
Again, "I don't know, but anything ending with .com.au is handled by w.au, z.au.."
com.au. 172800 IN NS w.au.
com.au. 172800 IN NS z.au. - On asking w.au, the response comes back:
;; AUTHORITY SECTION:
"The nameservers responsible for this domain are ns2.google.com.." These are the actual authoritative nameservers for google.com.au, as set up by Google at their domain registrar.
google.com.au. 14400 IN NS ns2.google.com.
google.com.au. 14400 IN NS ns1.google.com.
google.com.au. 14400 IN NS ns4.google.com.
google.com.au. 14400 IN NS ns3.google.com. - The next request then goes to the first of these and is answered with the A record:
;; ANSWER SECTION:
google.com.au. 300 IN A 74.125.237.159
What does this mean for me?
- If you run DNS at M.D.G. IT, which means that your domain is pointed at the M.D.G. IT nameservers that were sent in the welcome email, records are automatically set up locally. You can also edit these records in cPanel if your service is on a shared server, or you have a cPanel account set up for the service in question.
- If you use third party DNS, you need to make sure that records are set up correctly at these nameservers
- DNS changes need to be made with some care, because mistakes can't be instantly undone - the record is remembered for the length of the TTL.
