当我进入Debian 7的本地端口范围时，我可以看到我的临时端口范围是：
cat /proc/sys/net/ipv4/ip_local_port_range 32768 61000 我的/etc/sysctl.conf是空的。
通常这意味着来自这个名称服务器parsing器的所有请求都应该使用该范围内的端口。 但是，使用tcpdump ，当我看到一个DNS请求和答案创build与dig ，我可以看到，请求可以使用发送端口低至1500。
例如，在以下tcpdump示例（ tcpdump udp and port 53 and host server.domain ）中，请求来自端口15591.它远低于我们之前看到的临时端口的服务器最低端口限制：32768。换句话说，使用dig ，DNS请求超出本地端口范围。
11:57:33.704090 IP baremetal.15591 > M.ROOT-SERVERS.NET.domain: 41939% [1au] A? r.arin.net. (39) 11:57:33.704400 IP baremetal.41573 > M.ROOT-SERVERS.NET.domain: 40945% [1au] A? t.arin.net. (39) 11:57:33.704541 IP baremetal.22658 > M.ROOT-SERVERS.NET.domain: 44090% [1au] AAAA? t.arin.net. (39) 11:57:33.705295 IP baremetal.13277 > M.ROOT-SERVERS.NET.domain: 42356% [1au] A? v.arin.net. (39) 11:57:33.705499 IP baremetal.48755 > M.ROOT-SERVERS.NET.domain: 32253% [1au] A? w.arin.net. (39) 11:57:33.705639 IP baremetal.55309 > M.ROOT-SERVERS.NET.domain: 64660% [1au] AAAA? w.arin.net. (39) 11:57:33.705812 IP baremetal.56652 > M.ROOT-SERVERS.NET.domain: 43023% [1au] A? y.arin.net. (39) 11:57:33.706012 IP baremetal.26383 > M.ROOT-SERVERS.NET.domain: 42377% [1au] AAAA? y.arin.net. (39) 11:57:33.706172 IP baremetal.12895 > M.ROOT-SERVERS.NET.domain: 13206% [1au] AAAA? z.arin.net. (39)
我想知道什么可以改变我的Debian 7和8上的临时端口的端口范围。唯一值得一提的是。 我已经使用其中的一个ifenslave ＆一个使用ifenslave绑定两个以太网端口。
parsing器是服务器本身和
#cat /etc/resolv.conf nameserver ::1
但它与nameserver 127.0.0.1完全一样，因为/proc/sys/net/ipv4/ip_local_port_range ＆ /proc/sys/net/ipv4/ip_local_port_range共享/proc/sys/net/ipv4/ip_local_port_range （ 参考 ）＆我也试过了。
为了避免与IPv6混淆，我决定只使用Ipv4。 我只在/etc/resolv.conf添加了nameserver 127.0.0.1 。
以下结果仅在/etc/resolv.conf nameserver 127.0.0.1 。
然后，我发出rndc flush清除parsing器的DNScaching，并dig google.com
我打开第二个terminal窗口并键入tcpdump udp and port 53 ：
很多logging，但我注意到，无论请求（A，PTR …）和接收主机，DNS请求都可以从低于32768的端口发出
>strace -f dig www.google.com 2>&1 | egrep 'sendmsg|recvmsg|connect|bind' open("/usr/lib/libbind9.so.80", O_RDONLY) = 3 [pid 10651] bind(20, {sa_family=AF_INET, sin_port=htons(0), sin_addr=inet_addr("0.0.0.0")}, 16) = 0 [pid 10651] recvmsg(20, 0x7f5dd95cab60, 0) = -1 EAGAIN (Resource temporarily unavailable) [pid 10651] sendmsg(20, {msg_name(16)={sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("127.0.0.1")}, msg_iov(1)=[{"\251\261\1\0\0\1\0\0\0\0\0\0\3www\6google\3com\0\0\1\0\1", 32}], msg_controllen=0, msg_flags=0}, 0 <unfinished ...> [pid 10651] <... sendmsg resumed> ) = 32 [pid 10651] recvmsg(20, {msg_name(16)={sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("127.0.0.1")}, msg_iov(1)=[{"\251\261\201\200\0\1\0\1\0\4\0\4\3www\6google\3com\0\0\1\0\1"..., 65535}], msg_controllen=32, {cmsg_len=32, cmsg_level=SOL_SOCKET, cmsg_type=0x1d /* SCM_??? */, ...}, msg_flags=0}, 0) = 184
这个问题与我的防火墙有关。 由于临时端口可以从（我自己的猜测）1024到65000发出，这意味着我不能阻止来自高于1024的端口的inputstream量，就像过去一样。 如果我这样做，我会放慢或阻止DNSparsing。
更新：谢谢，我明白，如果我想使用服务器作为DNSparsing器，这意味着我不得不考虑UDP端口范围1024：65535是短暂的端口范围。
我不认为你的ip_local_port_range设置有什么问题，或者它通常不适用于这种types的场景，我相信这是直接关系到欺骗DNS答复更难。
我们在你的strace输出中看到，你已经dig了一个127.0.0.1 （运行在那里的一些parsing器服务器）的数据报，但是tcpdump输出似乎与来自parsing器服务器的stream量有关，而不是dig自己。
普通的旧DNS（不含DNSSEC）只依赖于事务ID（16位）和问题部分的数据，将通过UDP收到的响应与之前发送的查询进行匹配。
使用UDP数据报很容易被欺骗，只有16位的随机性，如果你有一个特定的名字作为目标，这使得很有可能在真正的答案到来之前猜出正确的事务id（平均32k猜测） 。
因此，所有现代的parsing器服务器都会自行去随机化源端口，以增加需要猜测的随机比特数。
你真的想要尽可能多的端口，所以它可能会随机在1024以上的端口范围内，与你的操作系统默认的处理能力相比，这会增加大量的随机性。
也就是说，我认为这被认为是“最佳实践”，忽略了sockets本地端口的正常操作系统处理。