domain-name-system – NAT后面的DNS服务器

前端之家收集整理的这篇文章主要介绍了domain-name-system – NAT后面的DNS服务器前端之家小编觉得挺不错的,现在分享给大家,也给大家做个参考。
我有一个位于NAT防火墙后面的Bind 9 DNS服务器,假设面向IP的Internet是1.2.3.4

传出流量没有限制,端口53(TCP / UDP)从1.2.3.4转发到内部DNS服务器(10.0.0.1). VPS或内部Bind 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,我可以建立到1.2.3.4:53的连接(使用telnet)

从内部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

有关为什么我的VPS上的主机命令抱怨从另一个端口返回的回复的任何建议,我该怎么做才能解决这个问题?

更多信息:

从网络外部的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的默认安装绑定,配置了大约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规则被破坏了.指示是来自意外来源的错误消息回复:1.2.3.4#13731,预期1.2.3.4#53以及从客户端获取的跟踪,其中响应看起来像dns.example.com.29242> pc.external.com.43845:UDP,长度95.响应数据包的源端口应该是53,它在从DNS服务器获取的转储中是正确的(为了显示目的,解析到域).

虽然一些(特别是历史性的)解析器可能接受来自不同端口/ IP的DNS响应,但大多数不会 – 主要是出于安全原因阻止DNS spoofing and cache poisoning attacks.

无论如何,对于无连接的UDP NAT流量,您的路由器应保留先前收到的UDP DNS查询数据包中的状态数据,并将响应数据包的IP:端口元组重新映射回1.2.3.4:53 – 它显然不是.它可能是配置错误或路由器处理UDP状态表以获取端口转发情况的方式中的错误 – 所以最好的办法是打开一个包含制造商客户支持的案例(将代码升级到最新/最大事先 – 这样的问题可能以前被其他用户注意到,因此可能已经被修复了).

猜你在找的HTML相关文章