當我轉到 Debian 7 上的本機連接埠範圍時，我可以看到我的臨時連接埠範圍是：
cat /proc/sys/net/ipv4/ip_local_port_range
32768 61000
我的/etc/sysctl.conf是空的。
通常，這表示從此名稱伺服器解析器發出的所有請求都應使用該範圍內的連接埠。但是，使用 時tcpdump，當我查看使用 建立的 DNS 請求和應答時dig，我可以看到該請求可以使用低至 1500 的發送連接埠。
例如，在下面的tcpdump範例 ( tcpdump udp and port 53 and host server.domain) 中，請求來自連接埠 15591 dig。
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綁定兩個乙太網路連接埠。
解析器是伺服器本身
#cat /etc/resolv.conf
nameserver ::1
但它的作用完全相同，nameserver 127.0.0.1因為 ipv4 和 ipv6 共享/proc/sys/net/ipv4/ip_local_port_range（參考）而且我也嘗試過。
為了避免與 IPv6 混淆，我決定只使用 IPv4。我只nameserver 127.0.0.1加到/etc/resolv.conf.
以下結果僅nameserver 127.0.0.1適用/etc/resolv.conf。
然後，我發出了rndc flush從解析器刷新 DNS 快取的命令，dig google.com
我打開了第二個終端機視窗並輸入tcpdump udp and port 53：
有很多記錄，但我注意到，無論請求（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 的連接埠的輸入流量。如果我這樣做，我會減慢或阻止 DNS 解析。
更新：謝謝，我知道如果我想使用伺服器作為 DNS 解析器，這意味著我必須考慮 UDP 連接埠範圍 1024:65535 是臨時連接埠範圍。
答案1
我不認為您的設定有任何問題ip_local_port_range，或者它通常不適用於這種類型的場景，我寧願相信這與使欺騙 DNS 回應變得更加困難直接相關。
strace我們在您的輸出中看到您已將dig資料封包發送到127.0.0.1（在那裡運行的某個解析器伺服器），但tcpdump輸出似乎與該解析器伺服器的流量相關，而不是dig本身。
普通的舊 DNS（沒有 DNSSEC）僅依賴 [事務 id（16 位元）](https://www.rfc-editor.org/rfc/rfc1035#section-4.1.1) 和*問題*中的資料部分將透過UDP 收到的回應與先前發送的查詢進行比對。
由於 UDP 資料報很容易被欺騙，並且如果您有特定名稱作為目標，則只需猜測 16 位隨機性，這使得在真正的答案到達之前很有可能猜測正確的交易 ID（平均猜測 32k 次） 。
因此，所有現代解析伺服器將不遺餘力地隨機化來源端口增加需要猜測的隨機位的數量。
您確實想要盡可能大的連接埠範圍，因此大概它會在> 1024的整個連接埠範圍內隨機化，與作業系統的預設處理方式相比，這將增加大量的隨機性。
即，我認為忽略套接字本地端口的正常作業系統處理只是被認為是“最佳實踐”。