Made DNS changes? Not sure if they are 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', we can query DNS servers for records, specify records and even specify which DNS server to query.
The basics of the dig (domain information groper) command are very simple. Let's start by having a look at Google's records:
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 18.104.22.168 google.com. 103 IN A 22.214.171.124 google.com. 103 IN A 126.96.36.199 ;; 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 188.8.131.52 ns2.google.com. 300836 IN A 184.108.40.206 ns3.google.com. 300836 IN A 220.127.116.11 ns4.google.com. 300836 IN A 18.104.22.168 ;; Query time: 1 msec ;; SERVER: 22.214.171.124#53(126.96.36.199) ;; 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.
Firstly we have the header info which, at this point is not particularly interesting (it will be later on when we specify particular servers to query).
Next we have the Question. We asked for the DNS record of google.com.
Which gave us the Answer. In this case 3 servers responded to the domain google.com along with the IP addresses.
Next is the Authority section. In other words what Name Servers are being used by google.com.
And lastly, the 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 the intrepid Slicer as they 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
Note the specified Name Server must be prefixed with the @ symbol.
It's the same
But isn't the output the same? Well, in this case, yes it is but note the headers:
; <<>> DiG 9.3.4 <<>> @ns4.google.com google.com
we are now querying ns4.google.com directly 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 Slicehost Management Panel. Querying the records directly will show the changes before they are fully propagated.
In this example I am going to use one of my own domains - mov2.net.
I use the Slicehost DNS Manager so I'm going to query that directly:
dig @dns1.stabletransit.com mov2.net
The output is as follows:
; <<>> DiG 9.3.4 <<>> @dns1.stabletransit.com mov2.net ; (1 server found) ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 60798 ;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 3, ADDITIONAL: 3 ;; QUESTION SECTION: ;mov2.net. IN A ;; ANSWER SECTION: mov2.net. 3600 IN A 188.8.131.52 ;; AUTHORITY SECTION: mov2.net. 3600 IN NS dns1.stabletransit.com. mov2.net. 3600 IN NS dns2.stabletransit.com. ;; ADDITIONAL SECTION: dns1.stabletransit.com. 3600 IN A 184.108.40.206 dns2.stabletransit.com. 3600 IN A 220.127.116.11 ;; Query time: 1 msec ;; SERVER: 18.104.22.168#53(22.214.171.124) ;; WHEN: Mon Oct 8 10:17:07 2007 ;; MSG SIZE rcvd: 154
Well, everything seems ok but I want to check for my mail (MX) records.
To do this I simply append the record type to the query:
dig @dns1.stabletransit.com mov2.net MX
Part of the output is as follows:
;; QUESTION SECTION: ;mov2.net. IN MX ;; AUTHORITY SECTION: mov2.net. 3600 IN SOA dns1.stabletransit.com. hostmaster.mov2.net. 1 28800 7200 604800 3600
I have the correct question (it's querying for MX records) but no answer.
There is a good reason for that: I haven't created the records.
Create the Record
OK, now I've entered the MX records I can directly query them (you may have to wait a couple of minutes for the record to be added to the Name Server):
dig @dns1.stabletransit.com mov2.net MX
The relevant part of the output:
;; QUESTION SECTION: ;mov2.net. IN MX ;; ANSWER SECTION: mov2.net. 3600 IN MX 0 mail.mov2.net.
Good. That seems correct to me. Now I have to wait until the records are fully propagated but I do know that they are correct.
I can do this with any type of record by appending the record type to the command:
dig @dns1.stabletransit.com mov2.net NS
That will query the NS records only.
Naturally, there is more you can do with the 'dig' command and a quick:
will give detailed settings and options that are available for use.
Using the dig command can save a lot of time and effort when setting your domain's records. Although the manual will give more information for very detailed searches, the methods shown in this article should suffice for most situations.