The following are some nslookup commands that can help when troubleshooting an incorrect or nonexistent Domain Name System (DNS) entry, such as an A record or MX record. The root for this type of problem is typically one of three things:

·         Expired domain registration

·         An error in the zone file

·         Propagation delay

Expired domain registration

One way to check domain registration is with a whois query, which can be done via the Web. The problem with doing this is that although it does give you good information, there is typically a delay between the time a domain expires and when it is removed from whois. An expired domain will continue to be shown in whois for a few days to a week, even though it cannot be resolved. As you might imagine, trouble with a domain is reported relatively soon after expiration, before any changes to whois have been made. You can view the expiration date in the whois output, but I prefer to query the domain directly with nslookup:

C:\>nslookup -q=ns microsoft.com a.root-servers.net

The above command queries the root name servers for a list of top-level domain (TLD) servers. It is only necessary if you aren’t sure what TLD servers to use for the domain. The list will be different, for example, if you are querying gatesfoundation.org than if you are querying microsoft.com because .org and .com use different TLD servers. The TLD servers for .com are below:

com     nameserver = A.GTLD-SERVERS.NET

com     nameserver = G.GTLD-SERVERS.NET

com     nameserver = K.GTLD-SERVERS.NET

com     nameserver = E.GTLD-SERVERS.NET

com     nameserver = D.GTLD-SERVERS.NET

com     nameserver = B.GTLD-SERVERS.NET

com     nameserver = I.GTLD-SERVERS.NET

com     nameserver = H.GTLD-SERVERS.NET

com     nameserver = F.GTLD-SERVERS.NET

com     nameserver = C.GTLD-SERVERS.NET

com     nameserver = M.GTLD-SERVERS.NET

com     nameserver = J.GTLD-SERVERS.NET

com     nameserver = L.GTLD-SERVERS.NET

 

Next, query a TLD server (choose one that performs best for you). What you are looking for here is a list of authoritative name servers for the domain in question:

 

C:\>nslookup -q=ns microsoft.com a.gtld-servers.net

 

microsoft.com   nameserver = ns1.msft.net

microsoft.com   nameserver = ns2.msft.net

microsoft.com   nameserver = ns3.msft.net

microsoft.com   nameserver = ns4.msft.net

microsoft.com   nameserver = ns5.msft.net

 

If a list of authoritative name servers is not returned, then the domain registration may have expired and you should tell the domain owner to contact the registrar. You can also get this information by querying a recursive name server so long as you are sure it is non-caching. You can’t always trust a cached record in this situation, as we will see.

 

Error in the zone file

Checking for an error seems simple enough, but can be tricky if the zone file has changed recently. I like to check the authoritative name server first, which you should have from the previous queries. The following example checks ns1.msft.net for the MX records associated with microsoft.com.

C:\>nslookup –q=mx microsoft.com ns1.msft.net

microsoft.com   MX preference = 10, mail exchanger = mail.global.frontbridge.com

Compare these results to the value obtained from the recursive name server being used by the person reporting a problem. Are they the same? If the record on the authoritative name server is incorrect, it may be an error made during recent changes to the zone. If the values on the authoritative and recursive name servers don’t match, you should:

·         Verify that the recursive name server does not believe it is authoritative for the domain.

o   A recursive name server that is also authoritative might continue to host a domain after authority has been moved. Servers that are both authoritative and recursive will not attempt to resolve domains for which they are authoritative.

·         Check the time to live (TTL) for the record in question.

o   If there have been recent changes to the zone, an old value might be cached by the resolving name server. Viewing the TTL will tell you how long it is necessary to wait until the changes propagate.

Propagation delay

To check for propagation delay, add the –debug option to nslookup and review the TTL in the detailed output. If a recursive name server has an old record cached, the TTL will tell you how long you will need to wait until the new value propagates. In this example, the recursive name server is 66.147.243.14.

C:\>nslookup -q=mx -debug microsoft.com 66.147.243.14

Non-authoritative answer:

microsoft.com

        MX preference = 10, mail exchanger = mail.global.frontbridge.com

        ttl = 1488 (24 mins 48 secs)

 

Note that the answer in this case indicates that the server is non-authoritative. If the value of this record is incorrect, you will need to wait 1488 seconds for the new value to propagate. Keep in mind that only those people using the caching name server that was queried will need to wait for this amount of time. You can also execute this command again and verify that the TTL is counting down correctly to zero. The server administrator has the option of clearing the cache to expedite propagation.

 

To mitigate propagation delay in zones hosted on your DNS server, set the TTL for of a record that you intend to change to something relatively short (1-5 minutes) just before you make the change. After the change is executed, restore the TTL to a normal value. This technique will work to shorten propagation times with name servers that honor the TTL value.

 

Greg Lindsay

Technical Writer

The Windows Server Networking Documentation Team