Rackspace Cloud Essentials - Using dig for DNS Verification and Troubleshooting
Have you just made DNS changes but aren't sure if they're correct? Don't want to wait for the changes to propagate before discovering a small typo?
No problem. Using the common but often ignored command
dig (domain information groper) we can query DNS servers for records, specify records, and even specify which DNS server to query.
You may already have dig installed. To find out, from your command prompt run:
If you got a message that the system couldn't find dig then it's a quick step to install it.
Ubuntu and Debian
For Ubuntu, Debian, and other distributions that use the apt package manager, run:
sudo aptitude install dnsutils
CentOS, Red Hat, Fedora
For CentOS, Red Hat, Fedora, and other distributions using the yum package manager, run:
sudo yum install bind-utils
The basics of the
dig command are very simple. Let's start by having a look at GoogleTM's records:
# dig google.com
The response is as follows:
; <<>> DiG 9.3.4 <<>> google.com ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 10147 ;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 4, ADDITIONAL: 4 ;; QUESTION SECTION: ;google.com. IN A ;; ANSWER SECTION: google.com. 103 IN A 220.127.116.11 google.com. 103 IN A 18.104.22.168 google.com. 103 IN A 22.214.171.124 ;; AUTHORITY SECTION: google.com. 71923 IN NS ns1.google.com. google.com. 71923 IN NS ns2.google.com. google.com. 71923 IN NS ns3.google.com. google.com. 71923 IN NS ns4.google.com. ;; ADDITIONAL SECTION: ns1.google.com. 300836 IN A 126.96.36.199 ns2.google.com. 300836 IN A 188.8.131.52 ns3.google.com. 300836 IN A 184.108.40.206 ns4.google.com. 300836 IN A 220.127.116.11 ;; Query time: 1 msec ;; SERVER: 18.104.22.168#53(22.214.171.124) ;; WHEN: Mon Oct 8 09:41:18 2007 ;; MSG SIZE rcvd: 212
Take it a section at a time and the output is actually incredibly informative and easy to navigate.
- Header info - At this point, the header info is not particularly interesting (it will be later on when we specify particular servers to query).
- QUESTION SECTION - We asked for the DNS record of google.com.
- ANSWER SECTION - Which gave us the Answer. In this case, three servers responded to the domain google.com along with the IP addresses.
- AUTHORITY SECTION - In other words, what Name Servers are being used by google.com?
- ADDITIONAL SECTION - This gives the IP addresses of the Name Servers found in the Authority section.
The problem with the answer is that it actually came from local DNS servers. This could be from our ISP or indeed on our local workstation or network.
To put it another way, the records displayed above have already been propagated. It will not show very recent changes.
Remember that ISPs usually cache DNS information and may not update them more than once or twice a day. This is why we have to wait for new records to be propagated and why, on occasion, you may see your new website but your friend may still be directed the old records - their ISP has not updated the records.
However, that doesn't deter you if you query the DNS server directly.
Have a look at the Authority section in the Google™ output. It lists four Name Servers. Let's directly query one of them:
# dig @ns4.google.com google.com
Notice that the specified Name Server must be prefixed with the @ symbol.
But isn't the output the same? Well, in this case, yes it is, but notice the headers:
; <<>> DiG 9.3.4 <<>> @ns4.google.com google.com
We are now querying directly ns4.google.com,which will show any changes they had made that had not been fully propagated.
This is the key to checking any DNS changes you've made in the Cloud Server Control Panel. Querying the records directly will show the changes before they are fully propagated.
To do this, append the record type to the query:
# dig @ns4.google.com google.com MX
The dig query responds back with the following answer:
;; QUESTION SECTION: ;google.com. IN MX ;; ANSWER SECTION: google.com. 10800 IN MX 10 smtp4.google.com. google.com. 10800 IN MX 10 smtp1.google.com. google.com. 10800 IN MX 10 smtp2.google.com. google.com. 10800 IN MX 10 smtp3.google.com.
We can do this with any type of record by appending the record type to the command:
# dig @ns4.google.com google.com NS
That will query the NS records only.
Naturally, there is more you can do with the dig command, and for a list of detailed settings and options available, just do a quick:
# man dig
The dig command can save a lot of time and effort when setting your domain's records. Although the manual page will give more information for very detailed searches, the methods shown in this article should suffice for most situations.
This concludes the First 48 Hour Cloud Essentials - the most important information that we thought you should have when starting as a new customer with us. Thank you for reading through to the end, though its really just the beginning! We hope you found the articles here easy to understand, and that the information helps you avoid future pifalls. Good luck, and please let us know what else we do can to make the Cloud easy for you to use.
© 2015 Rackspace US, Inc.
Except where otherwise noted, content on this site is licensed under a Creative Commons Attribution-NonCommercial-NoDerivs 3.0 Unported License
See license specifics and DISCLAIMER