0

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, sugarcreekcctexas.com, 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:  vnsc-bak.sys.gtei.net ; initial DNS set in ROUTER
Address:  4.2.2.2

> server 204.13.248.76                 ; changing to ns1.mydyndns.org
Default Server:  ns1.mydyndns.org
Address:  204.13.248.76

> set type=MX                          ; makes NSLOOKUP query for MX records
> sugarcreekcctexas.com                ; asking for the domain's MX records
Server:  ns1.mydyndns.org
Address:  204.13.248.76

(root)  nameserver = M.ROOT-SERVERS.net
(root)  nameserver = L.ROOT-SERVERS.net
(root)  nameserver = G.ROOT-SERVERS.net
(root)  nameserver = K.ROOT-SERVERS.net
(root)  nameserver = A.ROOT-SERVERS.net
(root)  nameserver = J.ROOT-SERVERS.net
(root)  nameserver = C.ROOT-SERVERS.net
(root)  nameserver = E.ROOT-SERVERS.net
(root)  nameserver = I.ROOT-SERVERS.net
(root)  nameserver = D.ROOT-SERVERS.net
(root)  nameserver = B.ROOT-SERVERS.net
(root)  nameserver = H.ROOT-SERVERS.net
(root)  nameserver = F.ROOT-SERVERS.net
>

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:

C:\Windows\System32\dns\bin>nslookup
> server 204.13.248.76
Default server: 204.13.248.76
Address: 204.13.248.76#53
> set type=MX
> sugarcreekcctexas.com
Server:         204.13.248.76
Address:        204.13.248.76#53

sugarcreekcctexas.com   mail exchanger = 10 sugarcreekcctexas.com.s7a1.psmtp.com
.
sugarcreekcctexas.com   mail exchanger = 20 sugarcreekcctexas.com.s7a2.psmtp.com
.
sugarcreekcctexas.com   mail exchanger = 30 sugarcreekcctexas.com.s7b1.psmtp.com
.
sugarcreekcctexas.com   mail exchanger = 40 sugarcreekcctexas.com.s7b2.psmtp.com
.
>

Here's DIG

C:\Windows\System32\dns\bin>dig @204.13.248.76 sugarcreekcctexas.com MX

; <<>> DiG 9.7.0 <<>> @204.13.248.76 sugarcreekcctexas.com 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

;; QUESTION SECTION:
;sugarcreekcctexas.com.         IN      MX

;; ANSWER SECTION:
sugarcreekcctexas.com.  3600    IN      MX      40 sugarcreekcctexas.com.s7b2.psmtp.com.
sugarcreekcctexas.com.  3600    IN      MX      10 sugarcreekcctexas.com.s7a1.psmtp.com.
sugarcreekcctexas.com.  3600    IN      MX      20 sugarcreekcctexas.com.s7a2.psmtp.com.
sugarcreekcctexas.com.  3600    IN      MX      30 sugarcreekcctexas.com.s7b1.psmtp.com.

;; AUTHORITY SECTION:
sugarcreekcctexas.com.  86400   IN      NS      ns1.mydyndns.org.
sugarcreekcctexas.com.  86400   IN      NS      ns4.mydyndns.org.
sugarcreekcctexas.com.  86400   IN      NS      ns5.mydyndns.org.
sugarcreekcctexas.com.  86400   IN      NS      ns3.mydyndns.org.
sugarcreekcctexas.com.  86400   IN      NS      ns2.mydyndns.org.

;; Query time: 79 msec
;; SERVER: 204.13.248.76#53(204.13.248.76)
;; 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.

Thanks!

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

Improve this question

2 Answers 2

Reset to default
1

Maybe nslookup attaches the default DNS suffix? Try asking for 

sugarcreekcctexas.com.

instead of

sugarcreekcctexas.com
Improve this answer
4
  • Yea this is exactly what's happening. But why do I not need the trailing . when I query against, say, 4.2.2.2?
    – tcv
    Mar 10, 2010 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, 2010 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 (sugarcreekcctexas.com as opposed to sugarcreekcctexas.com.) 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 (sugarcreekcctexas.com as opposed to sugarcreekcctexas.com.) you get the correct results.
    – joeqwerty
    Mar 12, 2010 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, 2010 at 0:00
0

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.

Improve this answer
3
  • 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, 2010 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, 2010 at 21:47
  • Are you using Windows nslookup? Is it appending your dns suffix? Use set d2 to see! :)
    – tcv
    Mar 10, 2010 at 21:57

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .