DNS and NSLOOKUP primer.
It’s essential to have a solid understanding of DNS for IT infrastructure support. It’s used pretty much everywhere, internally in the LAN and externally on the Internet. In this article, we’ll be looking at how it works, and how to use Nslookup to confirm changes – in particular if made by a third party.
There are many websites which will report DNS results, but these are often fairly useless if testing recent changes to a record. NSLOOKUP is a tool that’s provided in all modern Windows system and offers quicker and more accurate lookups.
There’s a few bit’s that are essential to understand about DNS, before NSLOOKUP can be useful to you. Here’s a quick overview of it’s basic DNS functions:
Basics:
Domain Name service: At its most basic level, the DNS system simply maps names to IP addresses. This makes the internet for more friendly to users – instead of typing in 31.13.93.33 into our browsers, we can type in facebook.com. Numbers are fine for computers, but we humans aren’t that great at remembering lots of random numbers that change intermittently, so DNS makes life a lot easier.
DNS Client: All modern computers run a DNS client. This is a small component of the operating system that works in the background and asks the DNS server what the IP address is for the site or service you have requested.
DNS server: The computer responsible for answering the requests of the DNS client. There are two main types – authoritative and non-authoritative. It’s very important to understand the difference.
DNS servers can be said to be authoritative for a specific domain. In our case (rscc.co.uk) our authoritative servers are ns1.rscc.co.uk and ns2.rscc.co.uk. We share these servers, so they can also said to be authoritative for a lot of other domains. The settings for RSCC.co.uk amongst others are stored on these servers in a simple text documents called a zone file. The DNS server consults this text record when answering requests. A typical zone file may be seen here.
An ISP’s DNS servers are typically only authoritative for their own domains. For example, if a customer on the BT broadband network tries to visit our website, BT’s DNS servers request the address from our DNS servers and then relay the response back to their customers.
NSLOOKUP is a fantastic tool that allows accurate and quick lookups – more so than using web based tools. It’s build into windows.
Start a command prompt in windows and simply type nslookup.
To find the ip address of a host or domain, simply type it in:
>Rscc.co.uk
Non-authoritative answer
89.145.78.62
By default it just returns simple A records. These are the most basic type of record that map names to addresses. Our web site is a computer with the IP address 89.145.78.62.
Why non-authoritative? – Because this reply is coming from our internal server, not the authoritative one.
To find out what the authoritative servers are, type in:
>Set type=ns (note: changes lookup type to look for authoritative Name server, rather than A record)
>Rscc.co.uk
Result:
Server.rscc.local
Non authoritative answer.
Nameserver = ns1.rscc.co.uk
Nameserver= ns2.rscc.co.uk
Now we know what the authoritative servers are, we can query them directly by changing the server we use within Nslookup.
>server ns1.rscc.co.uk
>set type=a (changes it back to an A type lookup from NS)
>rscc.co.uk
Address: 89.145.78.62
Note that this time it doesn’t say non-authoritative.
This is an important distinction when troubleshooting DNS, especially confirming changes. We may not care too much what non-authoritative servers are saying at a specific point in time – their information may be out of date. When we need to confirm changes have been made correctly and not wait X hours to find out, we need definite answers.
We can also find out where the Email server for a domain is:
>set type=mx (note – mx=Mail eXchanger)
>rscc.co.uk
Answer: exchange.rscc.co.uk
So far so good. What often confuses things when troubleshooting is DNS caching.
When the client requests an address, it stores that address for a while. If it’s needed again, it can quickly look in its local cache rather than looking it up again.
Servers also apply this same trick. If your ISP’s server has looked up rscc.co.uk from our authoritative server, it will store that result for future reference. If any other customers ask for this address, it doesn’t need to ask our servers, it just gives them the same address they got last time.
The period of time either a server or client will cache a record for is controlled by the authoritative server. It has a setting on each record called a TTL (time-to-live) which tells the other DNS servers and clients how long to store that record. Often by default this is 24 hours.
Caching is essential – it saves lots of bandwidth and makes the Internet a faster place to visit. But it can make testing a troubleshooting difficult if you don’t understand what is going on behind the scenes.
Scenario:
A company has moved their website or email to a new server. They (or their ISP) update their DNS records to reflect that the web site or email now resides at a new IP address – from 1.1.1.1 to 2.2.2.2
Rather than wait for the TTL period to expire, they want to be absolutely sure that the authoritative server is returning the correct result.
>nslookup
>answer 1.1.1.1
Clearly they still have the old address is their local cache.
It’s simple enough to clear the local cache – from an elevated command prompt type
>ipconfig /flushdns
This will force the client to look the address up again.
However they still get the same result. This is because the internal DNS server they are using has also cached the previous result.
You can clear the local server cache (on a windows server) in a slight different manner.
>net stop dns
>net start dns
They run a lookup again. Same result.
Because their ISP’s server (that the local server refers to) has also cached the old result. Not a lot that can be done about that, other than wait for the TTL to expire. However – we need to know in this instance that the change has been made correctly to avoid possible downtime.
It’s at time like this that NSLookup is invaluable. You can quickly and easily switch to another free server or to the authoritative one..
>nslookup
>server 8.8.8.8
>answer 2.2.2.2
The correct answer is returned as the free server (in this case provided by google) hasn’t looked up that address recently and so doesn’t have it in its cache. It gets the new address from the authoritative server.
So using these techniques we can troubleshoot and test DNS changes effectively and without guesswork.
Another little tip is to consider changing your TTL on a particular record to a much lower level in advance of making a change. This makes it much quicker for the Internet at large to ‘catch up’ with your changes, or to revert them should something unexpected happen.
TTL is measured in seconds – setting it to 3600 (1 hour) at least 24 hours in advance of making the changes is generally a good idea. Note that it must be done in advance, as any requests made prior to the TTL changing will not lookup the new TTL value, they will consult their cached value.
If you were to change your TTL to one hour in advance of making the changes, the entire Internet should be seeing your new site/email server at the correct address within 1 hour rather than the ‘up to 24 hours’ you often see documented or referred to.