我有一个绑定在NAT防火墙后面的绑定9 DNS服务器，假设互联网面对IP是1.2.3.4
对出站stream量没有限制，端口53（TCP / UDP）从1.2.3.4转发到内部DNS服务器（10.0.0.1）。 VPS或内部绑定9服务器上没有IP表规则。
从位于互联网其他地方的远程Linux VPS，nslookup可以正常工作
# nslookup foo.example.com 1.2.3.4 Server: 1.2.3.4 Address: 1.2.3.4#53 Name: foo.example.com Addresss: 9.9.9.9 但是，在远程VPS上使用host命令时，会收到以下输出：
# host foo.example.com 1.2.3.4 ;; reply from unexpected source: 1.2.3.4#13731, expected 1.2.3.4#53 ;; reply from unexpected source: 1.2.3.4#13731, expected 1.2.3.4#53 ;; connection timed out; no servers could be reached.
从VPS，我可以build立连接（使用telnet）到1.2.3.4:53
从内部DNS服务器（10.0.0.1），主机命令似乎很好：
# host foo.example.com 127.0.0.1 Using domain server: Name: 127.0.0.1 Address: 127.0.0.1#53 Aliases: foo.example.com has address 9.9.9.9
任何build议，为什么我的VPS上的主机命令是抱怨从另一个端口回来的答复，我能做些什么来解决这个问题？
更多信息：
从networking外部的Windows主机
>nslookup foo.example.com 1.2.3.4 DNS request timeout timeout was 2 seconds Server: UnKnown Address: 1.2.3.4 DNS request timed out. timeout was 2 seconds DNS request timed out. timeout was 2 seconds DNS request timed out. timeout was 2 seconds DNS request timed out. timeout was 2 seconds *** Request to UnKnown timed-out
这是来自Ubuntu 12.04 LTS的默认安装绑定，configuration了大约11个区域。
$ named -v BIND 9.8.1-P1
TCP转储（过滤）从内部DNS服务器
20:36:29.175701 IP pc.external.com.57226 > dns.example.com.domain: 1+ PTR? 4.3.2.1.in-addr.arpa. (45) 20:36:29.175948 IP dns.example.com.domain > pc.external.com.57226: 1 Refused- 0/0/0 (45) 20:36:31.179786 IP pc.external.com.57227 > dns.example.com.domain: 2+[|domain] 20:36:31.179960 IP dns.example.com.domain > pc.external.com.57227: 2 Refused-[|domain] 20:36:33.180653 IP pc.external.com.57228 > dns.example.com.domain: 3+[|domain] 20:36:33.180906 IP dns.example.com.domain > pc.external.com.57228: 3 Refused-[|domain] 20:36:35.185182 IP pc.external.com.57229 > dns.example.com.domain: 4+ A? foo.example.com. (45) 20:36:35.185362 IP dns.example.com.domain > pc.external.com.57229: 4*- 1/1/1 (95) 20:36:37.182844 IP pc.external.com.57230 > dns.example.com.domain: 5+ AAAA? foo.example.com. (45) 20:36:37.182991 IP dns.example.com.domain > pc.external.com.57230: 5*- 0/1/0 (119)
TCP查询期间从客户端转储
21:24:52.054374 IP pc.external.com.43845 > dns.example.com.53: 6142+ A? foo.example.com. (45) 21:24:52.104694 IP dns.example.com.29242 > pc.external.com.43845: UDP, length 95
总结一下之前写过的评论和进一步的解释：
它看起来有点像你的UDP的NAT规则被破坏了。 一个指示是reply from unexpected source: 1.2.3.4#13731, expected 1.2.3.4#53的错误信息reply from unexpected source: 1.2.3.4#13731, expected 1.2.3.4#53 ，你的跟踪来自响应看起来像dns.example.com.29242 > pc.external.com.43845: UDP, length 95 。 响应数据包的源端口应为53，从DNS服务器获取的转储（为了显示目的而parsing为domain ）是正确的。
尽pipe一些（特别是历史性）parsing器可能接受来自不同端口/ IP的DNS响应，但大多数不会 – 主要是由于安全原因阻止DNS欺骗和caching中毒攻击 。
无论如何，对于无连接的UDP NATstream量，您的路由器应该保留先前接收到的UDP DNS查询包的状态数据，并将IP：端口元组重新映射回1.2.3.4:53 – 这显然不会。 这可能是一个configuration错误或路由器处理端口转发情况下的UDP状态表的方式的错误 – 所以你最好的select是打开一个与制造商的客户支持的情况下（已升级到最新/最大的代码事先 – 其他用户可能已经注意到这样的问题，因此可能已经被修复）。