DNS Overview
From SuperbHosting.net Support Wiki
Contents |
Life of a DNS Query
To fully understand the information you receive when querying DNS servers, it's important to have a solid and fairly general understanding of how DNS works. This section describes what goes on behind the scenes when you try to access a website by domain name. To simply review how to query DNS servers, jump to the next section.
When trying to access a website by domain name, the first place the computer checks is its local DNS cache. Any time the computer performs a successful DNS lookup, it stores that result in a local DNS cache for a length of time specified by the TTL field in the DNS response. (TTL stands for Time To Live, which is the time in seconds to cache a DNS result).
If the local system doesn't already have the DNS information it's looking for, it sends a query to the recursive DNS server(s) it's configured to use. (Configured in TCP/IP properties on Windows, /etc/resolv.conf in Linux/BSD). Now it's the recursive DNS server's turn to see if it has the DNS entry cached. Just like the local system, the recursive DNS server caches DNS responses for a time set by the TTL field in the DNS entry. If it can't find the DNS entry it's looking for, it sends a query to the TLD (Top Level Domain) name server for the domain being looked up.
The TLD of a domain name is the .com or .org part of the name. Each TLD has its own set of name servers. Each TLD name server contains entries for every single domain registered within that TLD. These entries don't contain all the DNS information for all of the domains though, they just contain the name and IP address for the authoritative name servers for all of their domains. When the query reaches the TLD name server, it sends a response back to the recursive DNS server with the authoritative name servers, and the IPs to reach them at.
The recursive DNS server now sends a query to the authoritative name servers for the domain, which should be able to respond with the IP to domain mapping that is being looked for. Finally this information is passed back to the client system that initiated this whole lookup process in the fist place.
Effects of DNS Caching
Because DNS results may be cached at multiple places along the way, changes made at the authoritative name/server level aren't always instantly noticed by everyone. For example, if you view a website at 6:00am, which has a DNS TTL set to 86,400 (which is 24 hours in seconds) but then the DNS zone file is changed at 6:30am, then your local system won't see the updated DNS until the next DNS query after 6:00am the following day, when the cached DNS information expires.
If a different user goes to that same site at 6:35am the day the DNS change is made, and not in the previous 24 hours, they will immediately get the new DNS information.
There is a simple method of working around this. If you are planning on changing your DNS but it currently has a TTL of 24 hours, change that by a couple of minutes. Make sure to do this 24 hours before making the change. That way, once the change has been made, no cached entries of the old information will exist for more than a couple minutes. When the new information is in, set the TTL back up to 12-24 hours to avoid excessive load on the DNS server.
How to Lookup DNS Information
Unfortunately, Windows is painfully lacking in its set of built-in DNS lookup utilities. To perform detailed DNS lookups, you will need command line access to a Linux/BSD server, or a good web based tool to do the lookups for you.
Whois
The whois command is useful for gathering information about domain name registration and authoritative name servers. The syntax is pretty straight forward i.e. whois superb.net.
To do a whois lookup using a web-based tool, you can simply do a search on Google for 'whois', or use one of the following sites:
From the information you get, the most important section will look like this:
Domain Name: SUPERBHOSTING.COM Registrar: ENOM, INC. Whois Server: whois.enom.com Referral URL: http://www.enom.com Name Server: NS1.SUPERB.NET Name Server: NS2.SUPERB.NET Name Server: NS3.SUPERB.NET Name Server: NS4.SUPERB.NET Name Server: NS5.SUPERB.NET Status: clientDeleteProhibited Status: clientTransferProhibited Updated Date: 19-dec-2006 Creation Date: 18-jan-1999 Expiration Date: 18-jan-2008
The registrar tells you where the domain was registered. If it doesn't say Enom, INC. or register.com, then the domain name was not registered through Superb Registrar. This information is important, because only the registrar can change the authoritative name servers for a domain. If we are not the registrar, we can't change their authoritative name servers no matter how much they ask.
If DNS suddenly stopped working, it's also a good idea to check the updated date and expiration date. When a domain name registration expires, most registrars update the authoritative name servers to point to their own, and extend the expiration date by a year. If this is the case, just like any other authoritative name server change, the registrar needs to be contacted.
Dig
The other incredibly useful DNS query tool on Linux/BSD servers is called dig. To fully learn all of the options with dig, read the man page, the basic syntax though is
"dig superb.net A"
Where A is the type of record you're looking for (A, MX, TXT, CNAME), A is the default type and is what is queried if you don't specify a type.
With a basic dig lookup, the system your checking from does a normal DNS lookup for that DNS record, and generates output like:
#dig superb.net ; <<>> DiG 9.3.4 <<>> superb.net ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 57563 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;superb.net. IN A ;; ANSWER SECTION: superb.net. 6789 IN A 66.148.93.21 ;; Query time: 2 msec ;; SERVER: 66.36.226.50#53(66.36.226.50) ;; WHEN: Wed Sep 28 13:16:26 2005 ;; MSG SIZE rcvd: 44
This shows that the A record for superb.net is 66.148.93.21
The real power of dig comes in when you add the fact that you can specify what name servers you want dig to query against, instead of going to your recursive name servers. This is useful to avoid any delay for DNS records being cached. i.e. you can do a whois lookup for a domain, and then directly query any of that domain's name servers with the syntax of:
- dig <domain> <optional query type> @<name server of your choice> or
- dig superb.net A @ns2.superb.net
With this you can verify that DNS records are the same across all of the authoritative name servers independently, or even query a non-authoritative name server before it goes live, to make sure everything is functioning properly.
Who Manages What
Because people often don't understand the life cycle of a DNS query from above, they often don't understand who to contact for DNS modifications. The primary reasons for modifications are to change the authoritative name servers being used or to change the zone file stored at the authoritative name server.
The authoritative name servers can only be set by the registrar. If SuperbHosting.net isn't the registrar for the domain, we can't change the name servers that it's pointing to. If we are the registrar, you can enter a ticket through your myCP® customer portal to have the nameservers updated accordingly.
