Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I wrote some time back about running my own DNS server temporarily in order to help facilitate the move of a domain name between two registrars with no down-time. I have since purchased the CustomDNS package from DYNDNS and have populated the DNS records for my domain,, which is currently at GoDaddy. My goal is to change the nameservers at GoDaddy to point to DYNDNS' nameservers so they can serve DNS requests during the registrar move.

However, even though I've pre-activated DYNDNS' service for testing purposes, I am getting strange results with Windows' version of NSLOOKUP when I ask for records from DYNDNS' nameservers. I want to understand why. Please note: 'A' records seem to work fine. However, I am testing the lookup of MX records for the domain, since I've never gotten proper results from DYNDNS.

Here's the output of NSLOOKUP from Windows:

Default Server: ; initial DNS set in ROUTER

> server                 ; changing to
Default Server:

> set type=MX                          ; makes NSLOOKUP query for MX records
>                ; asking for the domain's MX records

(root)  nameserver =
(root)  nameserver =
(root)  nameserver =
(root)  nameserver =
(root)  nameserver =
(root)  nameserver =
(root)  nameserver =
(root)  nameserver =
(root)  nameserver =
(root)  nameserver =
(root)  nameserver =
(root)  nameserver =
(root)  nameserver =

I didn't understand this. So, I went to DYNDNS' forums and asked them about the issue. They've been very helpful. The primary answer is that both DIG and NSLOOKUP show the proper answer when they send the queries.

I installed the Windows version of BIND's tools, gotten from their website. These tools include DIG and NSLOOKUP, at least the BIND-blessed versions. The output from these tools is very different:

> server
Default server:
> set type=MX
Address:   mail exchanger = 10
.   mail exchanger = 20
.   mail exchanger = 30
.   mail exchanger = 40

Here's DIG

C:\Windows\System32\dns\bin>dig @ MX

; <<>> DiG 9.7.0 <<>> @ MX
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 6152
;; flags: qr aa rd; QUERY: 1, ANSWER: 4, AUTHORITY: 5, ADDITIONAL: 0
;; WARNING: recursion requested but not available

;         IN      MX

;; ANSWER SECTION:  3600    IN      MX      40  3600    IN      MX      10  3600    IN      MX      20  3600    IN      MX      30

;; AUTHORITY SECTION:  86400   IN      NS  86400   IN      NS  86400   IN      NS  86400   IN      NS  86400   IN      NS

;; Query time: 79 msec
;; WHEN: Wed Mar 10 10:57:47 2010
;; MSG SIZE  rcvd: 319

The NSLOOKUP.exe I am using on my machine -- the one that returns weird results -- is the version that comes stock with Vista. I have ALSO tried nslookup on a stock Windows Server 2003 Enterprise server and that one also produced the weird results.

I'm quite concerned for the following reasons:

  1. I realize that NSLOOKUP is strictly a diagnostic tool, but will Windows servers somehow query for MX records in the Windows NSLOOKUP way? And if so, will that prevent, say, an Exchange server from getting proper MX records for my domain?

  2. I use NSLOOKUP an awful lot for this kind of activity. While I am eager to trust in the inherent goodness of BIND and DNS, having my standard tool return these results is scary.

I am forced to conclude that there's something inherently different about the Windows version of NSLOOKUP -or- I've never used it right for these types of queries.

Can anyone shed some light? Before I make the nameserver switch, I need to understand why this is happening. At the end, I may still have to bring up another server and run DNS on my own, a prospect that seems even more perilous.


EDIT: The option "set nosearch" in Windows' version of NSLOOKUP seems to make DYNDNS' nameservers return what I expect. So.... why?

share|improve this question
up vote 1 down vote accepted

Maybe nslookup attaches the default DNS suffix? Try asking for

instead of
share|improve this answer
Yea this is exactly what's happening. But why do I not need the trailing . when I query against, say, – tcv Mar 10 '10 at 21:27
This is solely a client (= nslookup) issue. You will need to add the trailing . regardless of the server you query. – al. Mar 11 '10 at 0:52
@al: Dang it. I was going to post the exact same answer yesterday, but got interrupted before I could post. This doesn't appear to be a function of nslookup but a function of the DNS server being qeuried against. If you query against the DYNDNS servers without the root domain ( as opposed to you get the results as detailed in the OP's question, whereas if you query against one of the Google public dns servers (for example) without the root domain ( as opposed to you get the correct results. – joeqwerty Mar 12 '10 at 4:11
Interesting. I guess at this point it'd make sense to look into the actual packets to see what exactly gets queried. – al. Mar 15 '10 at 0:00

It might be that the windows nslookup version ustilizes the windows DNS cache while binds nslookup and dig bypass the cache. This is just a guess. Try to purge the DNS cache and recheck your findings. The cache is usually cleared by issueing

ipconfig /flushdns

But I'm not sure if this also works for Vista.

If we perform moves from one registrar to another we usually have the possibility to setup the target nameservers prior to the move so we don't experience any downtime. It works like this:

  • find new registrar
  • tell'em you want to put domain xyz there
  • preset the nameserver entries there
  • issue the transfer

While the transfer is pending both nameservers serve the domain records and your old registrar would usually continue to serve your domain records for some time to ensure that clients using the cached (now outdated) nameserver will be able to resolve.

share|improve this answer
Two different people asked NetSol about this and we both were told that we cannot do anything with dns until the domain transfer is complete. – tcv Mar 10 '10 at 21:28
Not very customer friendly.. However I just tried resolving your domain through dyndns from here. Everything seems fine and it resolve to the same IP as domaincontrol does. – fen Mar 10 '10 at 21:47
Are you using Windows nslookup? Is it appending your dns suffix? Use set d2 to see! :) – tcv Mar 10 '10 at 21:57

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.