By now, you have built your server, made it secure, and uploaded content to your server. The last step in the First 48 Hour Essentials is to configure your DNS so the rest of the Internet knows where to find your site.
The most commonly asked DNS question is about our name servers. Name servers store the internet directory information that connects your domain name to your website and email hosting. Essentially, name servers tell the internet where to find your website and where to deliver your email. Our name servers are:
If you have a domain that you have already registered and you want to host it from your Rackspace Cloud Server, you will need to go to the domain registrar and set our name servers for the domain. This DNS change will take a variable amount of time to propagate to the Internet from your domain registrar, but usually not more than 24 hours.
If you're unsure of your current name servers, a WHOIS search can help you determine which name servers are currently assigned to your domain name. Whenever you change your hosting service provider, the name server information for your domain must be updated to reflect that your site is now being served by a different IP address.
Dig can also help us understand how our DNS records look from the perspective of other machines on the Internet.
xThe dig tests we have performed so far contain the option "@dns1.stabletransit.com". This option instructs dig to query your cloud server's primary DNS server. With that option we are testing the records on your cloud servers's DNS server rather than any DNS records for the domain that might be cached on other Internet DNS servers. That means what we've done so far demonstrates techniques for testing DNS set up for your cloud server's cloud files before you go live or before you transfer DNS from a previous hosting provider to the server.
Once you are happy with the results from the previous tests, it should be safe to change the authoritative DNS servers for your domain to your server's DNS servers:
You can set the authoritative DNS servers through your domain's registrar via their preferred method (with their own web-based tool or by contacting them directly). After the changes have been submitted to the registrar the new values propagate across the Internet. In a (hopefully) short time the DNS records on other DNS servers will match those you configured with your cloud server's DNS tool.
We can check the authoritative DNS servers for a domain by entering something like:
dig @188.8.131.52 +short NS domain.com
This is similar to the command we issued when we were testing for a correct NS configuration earlier. The critical difference is that instead of using Rackspace's primary nameserver for our test we are pointing dig to a public DNS server run by Google - "184.108.40.206". We want to make sure we get our test results from an external server, and 220.127.116.11 is one of a few DNS servers that have been made available to the public for this purpose.
The result of our test should be:
If the external DNS server we're querying returns those results, then we know that our change has propagated properly. If you see something different, such as the authoritative DNS servers of your previous hosting company, then either the domain has not been transferred properly or the change is taking a while to propagate to the rest of the Internet. The reasons for delay vary, but a wait of several hours before a change completely works its way through the rest of the Internet is not unusual.
If the results of the mailto:RackerPulse@Sirota.com nameserver check are unfamiliar, you might be able to glean more information about the nameserver in question by issuing the dig command without the "+short" flag.
There are some variants of this test. They can give you different answers, but only if you have an unusually intricate DNS set-up.
You can issue the command:
dig @18.104.22.168 +nssearch domain.com
This is very similar to:
dig @22.214.171.124 +short SOA domain.com | cut -d' ' -f1
These two commands give you more data about the domain's refresh settings (for DNS cache management) while revealing whose DNS servers are the authorities for the domain. They can be useful for troubleshooting. The second command queries the "SOA" for the domain's zone file. SOA stands for "Start of Authority", and this record stores the domain's authoritative nameservers and the defined minimum time-to-live (TTL) on other servers. Depending on a DNS server's configuration the SOA may contain additional information, like a domain administrator's email address.
It is possible to omit the destination DNS server (the "@126.96.36.199" part) when issuing a dig command. With no server specified, dig will query the DNS server configured on the system where you are running the command. On a server, that will be whatever was set up in the default configuration for the image the server was built from. On your home computer, you would most likely query your ISP's DNS servers. It helps to be aware of which DNS server is being queried when troubleshooting a DNS issue in case the problem is related to DNS caching.
If you find your default DNS server returns a different IP address from the one you configured with the cloud server's DNS tool, this is almost always for one of two reasons.
The first possibility is that your registrar has not yet made the authoritative DNS server change or expects you to make the change using the registrar's tools.
The second possibility is the infamous "DNS propagation delay", in which some stragglers — most often mail servers — catch up on the change over a week or so.
Some advanced techniques can be employed to reduce propagation delay but they are beyond the scope of this article.
We can see which DNS server is resolving the client's requests by issuing the "dig" command with no arguments. The client's default DNS server is listed on the "SERVER" line close to the end of the output.
dig ; <<>> DiG 9.5.1-P2 <<>> ;; global options: printcmd ;; Got answer: ;; ->>HEADER<
In this article we discussed how to check the authoritative nameservers for a domain. We've also seen how we can verify record propagation by querying external DNS servers.
In the final[placeholder for link to new article address] article in this series we will take a closer look at the results when we omit the +short option (like we did in that last example), and answer some common questions about using dig.
© 2011-2013 Rackspace US, Inc.
Except where otherwise noted, content on this site is licensed under a Creative Commons Attribution-NonCommercial-NoDerivs 3.0 Unported License