DYNDNS.org自定义DNS返回奇怪的结果与Windows的NSLOOKUP

我写了一些关于暂时运行我自己的DNS服务器的一些时间,以帮助促进两个注册商之间的域名迁移,而不是停机。 此后,我从DYNDNS购买了CustomDNS软件包,并为我的域名sugarcreekcctexas.com填写了当前位于GoDaddy的DNSlogging。 我的目标是更改GoDaddy中的域名服务器,指向DYNDNS的域名服务器,以便在注册服务商移动期间提供DNS请求。

但是,即使我已经为testing目的预先激活了DYNDNS的服务,但是当我向DYNDNS的域名服务器请求logging时,使用Windows版本的NSLOOKUP得到了奇怪的结果。 我想明白为什么。 请注意:“A”logging似乎工作正常。 但是,我正在testing该域的MXlogging的查找,因为我从来没有从DYNDNS得到适当的结果。

以下是Windows中NSLOOKUP的输出:

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 > 

我不明白这一点。 所以,我去了DYNDNS的论坛,问他们这个问题。 他们一直很有帮助。 主要答案是DIG和NSLOOKUP在发送查询时显示正确答案。

我安装了BIND工具的Windows版本,从他们的网站上获得。 这些工具包括DIG和NSLOOKUP,至lessBIND-Blessed版本。 这些工具的输出是非常不同的:

 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 . > 

这是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 

我在我的机器上使用的NSLOOKUP.exe – 返回奇怪结果的那个 – 是带有Vista的版本。 我也尝试在股票的Windows Server 2003企业服务器nslookup和那个也产生了奇怪的结果。

我非常担心以下原因:

  1. 我意识到,NSLOOKUP是严格的诊断工具,但Windows服务器以某种方式查询Windows NSLOOKUP方式的MXlogging? 如果是这样的话,是否会阻止Exchange服务器为我的域获取适当的MXlogging?

  2. 我使用NSLOOKUP这种活动非常多。 虽然我渴望信任BIND和DNS的固有优点,但是用我的标准工具返回这些结果是可怕的。

我不得不得出这样的结论:NSLOOKUP的Windows版本有一些内在的不同 – 或者我从来没有用过这种types的查询。

任何人都可以点亮一下吗? 在进行名称服务器切换之前,我需要了解为什么发生这种情况。 最后,我可能还需要build立另一台服务器,并自行运行DNS,这个前景似乎更加危险。

谢谢!

编辑:在Windows版本的NSLOOKUP选项“设置nosearch”似乎使DYNDNS的名称服务器返回我所期望的。 所以为什么?

也许nslookup附加默认的DNS后缀? 尝试要求

 sugarcreekcctexas.com. 

代替

 sugarcreekcctexas.com 

这可能是Windows NSLOOKUP版本使用Windows DNScaching,而绑定NSLOOKUP和挖掘绕过caching。 这只是一个猜测。 尝试清除DNScaching并重新检查您的发现。 caching通常通过发布清除

 ipconfig /flushdns 

但我不确定这是否也适用于Vista。

如果我们执行从一个注册服务器到另一个注册服务器的移动,我们通常有可能在移动之前设置目标域名服务器,所以我们不会遇到任何停机时间。 它是这样工作的:

  • find新的注册商
  • tell'em你想把域xyz在那里
  • 在那里预设名称服务器条目
  • 发出转移

在传输过程中,两个名称服务器都会提供域名logging,而您的旧注册商通常会继续为您的域名logging服务一段时间,以确保使用caching(现在已过时)的名称服务器的客户端能够解决问题。