Dns

BIND9：DNS 有時解析（！）需要很長時間或根本不起作用

  • August 21, 2017

我有一個 BIND 9.9.5-9+deb8u8-Raspbian DNS 伺服器在我的網路中的 RPi3 上執行。它是 - 對於不是我的家庭區域的所有東西 - 配置為“僅轉發”，轉發器“{ 8.8.8.8; 8.8.4.4; 208.67.222.222; 208.67.220.220; };”。

a) 正常情況

通常，dns 解析效果很好。即使結果不在記憶體中，它們也會從轉發伺服器中獲取並在不到 100 毫秒的時間內傳遞回我的客戶端。這是一個例子：

client:~ $ time nslookup faz.net
Server:     [my_server]
Address:    [my_server]#53

Non-authoritative answer:
Name:   faz.net
Address: 40.118.6.229

real    0m0.095s […]

這就是 tcpdump 中流量的樣子，據我所知，一切都很完美，而且 DNSSEC 驗證似乎也可以正常工作：

06:48:21.880240 IP [my_client].59563 > [my_server].domain: 614+ A? faz.net. (25)
06:48:21.881246 IP [my_server].28766 > google-public-dns-a.google.com.domain: 30021+% [1au] A? faz.net. (36)
06:48:21.916031 IP google-public-dns-a.google.com.domain > [my_server].28766: 30021 1/0/1 A 40.118.6.229 (52)
06:48:21.917093 IP [my_server].44792 > google-public-dns-a.google.com.domain: 10551+% [1au] DS? faz.net. (36)
06:48:21.952356 IP google-public-dns-a.google.com.domain > [my_server].44792: 10551 0/6/1 (757)
06:48:21.956635 IP [my_server].domain > [my_client].59563: 614 1/0/0 A 40.118.6.229 (41)

b) 有問題的案例

然而，在某些情況下，它需要很長時間 - 最多 14 秒 - 才能提供結果。或者我根本沒有得到一個（即使 dig @8.8.4.4 域在大約 50 毫秒內給了我一個正確的地址。）這是一個例子：

client:~ $ time nslookup sueddeutsche.net
Server:     [my_server]
Address:    [my_server]#53

Non-authoritative answer:
Name:   sueddeutsche.net
Address: 213.61.179.40
Name:   sueddeutsche.net
Address: 213.61.179.41

real    0m4.994s […]

這就是通過 tcpdump 的這 4,9 秒的流量：

06:48:47.608104 IP [my_client].53592 > [my_server].domain: 51417+ A? sueddeutsche.net. (34)
06:48:47.609158 IP [my_server].1507 > google-public-dns-a.google.com.domain: 56678+% [1au] A? sueddeutsche.net. (45)
06:48:48.809517 IP [my_server].27279 > google-public-dns-b.google.com.domain: 22525+% [1au] A? sueddeutsche.net. (45)
06:48:50.009592 IP [my_server].37926 > resolver2.opendns.com.domain: 41597+% [1au] A? sueddeutsche.net. (45)
06:48:50.081468 IP resolver2.opendns.com.domain > [my_server].37926: 41597 2/0/1 A 213.61.179.41, A 213.61.179.40 (77)
06:48:50.082768 IP [my_server].1301 > resolver2.opendns.com.domain: 24793+% [1au] DS? sueddeutsche.net. (45)
06:48:50.233748 IP resolver2.opendns.com.domain > [my_server].1301: 24793 0/1/1 (121)
06:48:50.235373 IP [my_server].57628 > resolver1.opendns.com.domain: 8635+% [1au] DS? sueddeutsche.net. (45)
06:48:50.282862 IP resolver1.opendns.com.domain > [my_server].57628: 8635 0/1/1 (121)
06:48:50.287796 IP [my_server].32127 > google-public-dns-a.google.com.domain: 924+% [1au] DS? sueddeutsche.net. (45)
06:48:51.487853 IP [my_server].61208 > google-public-dns-b.google.com.domain: 39031+% [1au] DS? sueddeutsche.net. (45)
06:48:51.547262 IP google-public-dns-b.google.com.domain > [my_server].61208: 39031 0/6/1 (766)
06:48:51.551509 IP [my_server].52786 > resolver2.opendns.com.domain: 28853+% [1au] Type32769? sueddeutsche.net.dlv.isc.org. (57)
06:48:51.589595 IP resolver2.opendns.com.domain > [my_server].52786: 28853 NXDomain 0/1/1 (125)
06:48:51.592942 IP [my_server].30477 > resolver2.opendns.com.domain: 17693+% [1au] DS? sueddeutsche.net.dlv.isc.org. (57)
06:48:51.790903 IP resolver2.opendns.com.domain > [my_server].30477: 17693 NXDomain 0/1/1 (125)
06:48:51.792342 IP [my_server].6503 > resolver1.opendns.com.domain: 17946+% [1au] DS? sueddeutsche.net.dlv.isc.org. (57)
06:48:52.005244 IP resolver1.opendns.com.domain > [my_server].6503: 17946 NXDomain 0/1/1 (125)
06:48:52.006662 IP [my_server].52356 > google-public-dns-b.google.com.domain: 39821+% [1au] DS? sueddeutsche.net.dlv.isc.org. (57)
06:48:52.334093 IP google-public-dns-b.google.com.domain > [my_server].52356: 39821 NXDomain 0/6/1 (748)
06:48:52.342161 IP [my_server].56473 > resolver1.opendns.com.domain: 17279+% [1au] Type32769? sueddeutsche.net.dlv.isc.org. (57)
06:48:52.382211 IP resolver1.opendns.com.domain > [my_server].56473: 17279 NXDomain 0/1/1 (125)
06:48:52.383674 IP [my_server].52741 > google-public-dns-b.google.com.domain: 65018+% [1au] Type32769? sueddeutsche.net.dlv.isc.org. (57)
06:48:52.424757 IP google-public-dns-b.google.com.domain > [my_server].52741: 65018 NXDomain$ 0/6/1 (748)
06:48:52.430544 IP [my_server].domain > [my_client].53592: 51417 2/0/0 A 213.61.179.40, A 213.61.179.41 (66)

現在據我所知，似乎在 06:48:50.081468 my_server 從 resolver2.opendns.com 得到了正確的響應，而 google 沒有提供任何東西。然後 my_server 向 resolver2.opendns.com 回复 DNSSEC 驗證請求。這不應該是 my_server 將結果返回給 my_client 的地方嗎？為什麼不這樣做？

這是第二種情況，對於 dasoertliche.de，應該可以正常工作的域：

23:39:01.569234 IP [my_client].52174 > [my_server].domain: 57873+ A? dasoertliche.de. (33)
23:39:01.570413 IP [my_server].60368 > resolver2.opendns.com.domain: 39796+% [1au] A? dasoertliche.de. (44)
23:39:01.617721 IP resolver2.opendns.com.domain > [my_server].60368: 39796 1/0/1 A 82.98.79.52 (60)
23:39:01.618712 IP [my_server].41112 > resolver2.opendns.com.domain: 47487+% [1au] DS? dasoertliche.de. (44)
23:39:01.667144 IP resolver2.opendns.com.domain > [my_server].41112: 47487 0/1/1 (100)
23:39:01.668616 IP [my_server].24077 > resolver1.opendns.com.domain: 13310+% [1au] DS? dasoertliche.de. (44)
23:39:01.854327 IP resolver1.opendns.com.domain > [my_server].24077: 13310 0/1/1 (100)
23:39:01.856006 IP [my_server].38412 > google-public-dns-a.google.com.domain: 56597+% [1au] DS? dasoertliche.de. (44)
23:39:03.056263 IP [my_server].35182 > google-public-dns-b.google.com.domain: 45370+% [1au] DS? dasoertliche.de. (44)
23:39:04.256333 IP [my_server].47744 > google-public-dns-a.google.com.domain: 50222+% [1au] DS? dasoertliche.de. (44)
23:39:04.305620 IP google-public-dns-a.google.com.domain > [my_server].47744: 50222| 0/0/1 (44)
23:39:04.306296 IP [my_server].45040 > google-public-dns-a.google.com.domain: Flags [S], seq 3961861791, win 29200, options [mss 1460,sackOK,TS val 11766745 ecr 0,nop,wscale 7], length 0
23:39:04.345835 IP google-public-dns-a.google.com.domain > [my_server].45040: Flags [S.], seq 2448404480, ack 3961861792, win 42408, options [mss 1380,sackOK,TS val 4100658423 ecr 11766745,nop,wscale 7], length 0
23:39:04.345899 IP [my_server].45040 > google-public-dns-a.google.com.domain: Flags [.], ack 1, win 229, options [nop,nop,TS val 11766749 ecr 4100658423], length 0
23:39:04.346167 IP [my_server].45040 > google-public-dns-a.google.com.domain: Flags [P.], seq 1:47, ack 1, win 229, options [nop,nop,TS val 11766749 ecr 4100658423], length 4662876+% [1au] DS? dasoertliche.de. (44)
23:39:04.385803 IP google-public-dns-a.google.com.domain > [my_server].45040: Flags [.], ack 47, win 332, options [nop,nop,TS val 4100658463 ecr 11766749], length 0
23:39:04.394945 IP google-public-dns-a.google.com.domain > [my_server].45040: Flags [P.], seq 1:752, ack 47, win 332, options [nop,nop,TS val 4100658472 ecr 11766749], length 75162876 0/6/1 (749)
23:39:04.394975 IP [my_server].45040 > google-public-dns-a.google.com.domain: Flags [.], ack 752, win 240, options [nop,nop,TS val 11766753 ecr 4100658472], length 0
23:39:04.398143 IP [my_server].45040 > google-public-dns-a.google.com.domain: Flags [F.], seq 47, ack 752, win 240, options [nop,nop,TS val 11766754 ecr 4100658472], length 0
23:39:04.401876 IP [my_server].37878 > resolver2.opendns.com.domain: 50849+% [1au] Type32769? dasoertliche.de.dlv.isc.org. (56)
23:39:04.437774 IP google-public-dns-a.google.com.domain > [my_server].45040: Flags [F.], seq 752, ack 48, win 332, options [nop,nop,TS val 4100658515 ecr 11766754], length 0
23:39:04.437858 IP [my_server].45040 > google-public-dns-a.google.com.domain: Flags [.], ack 753, win 240, options [nop,nop,TS val 11766758 ecr 4100658515], length 0
23:39:04.456088 IP resolver2.opendns.com.domain > [my_server].37878: 50849 NXDomain 0/1/1 (124)
23:39:04.457411 IP [my_server].38743 > resolver2.opendns.com.domain: 45844+% [1au] DS? dasoertliche.de.dlv.isc.org. (56)
23:39:04.658497 IP resolver2.opendns.com.domain > [my_server].38743: 45844 NXDomain 0/1/1 (124)
23:39:04.659855 IP [my_server].39296 > resolver1.opendns.com.domain: 17204+% [1au] DS? dasoertliche.de.dlv.isc.org. (56)
23:39:04.708134 IP resolver1.opendns.com.domain > [my_server].39296: 17204 NXDomain 0/1/1 (124)
23:39:04.713195 IP [my_server].55899 > google-public-dns-a.google.com.domain: 5854+% [1au] DS? dasoertliche.de.dlv.isc.org. (56)
23:39:04.780837 IP google-public-dns-a.google.com.domain > [my_server].55899: 5854 NXDomain 0/6/1 (736)
23:39:04.786940 IP [my_server].27908 > resolver1.opendns.com.domain: 4148+% [1au] Type32769? dasoertliche.de.dlv.isc.org. (56)
23:39:05.267688 IP resolver1.opendns.com.domain > [my_server].27908: 4148 NXDomain 0/1/1 (124)
23:39:05.269026 IP [my_server].38523 > google-public-dns-a.google.com.domain: 60609+% [1au] Type32769? dasoertliche.de.dlv.isc.org. (56)
23:39:06.469277 IP [my_server].58501 > google-public-dns-b.google.com.domain: 5485+% [1au] Type32769? dasoertliche.de.dlv.isc.org. (56)
23:39:06.572296 IP [my_client].52174 > [my_server].domain: 57873+ A? dasoertliche.de. (33)
23:39:07.669762 IP [my_server].52520 > google-public-dns-a.google.com.domain: 43149+% [1au] Type32769? dasoertliche.de.dlv.isc.org. (56)
23:39:07.706440 IP google-public-dns-a.google.com.domain > [my_server].52520: 43149| 0/0/1 (56)
23:39:07.706903 IP [my_server].59047 > google-public-dns-a.google.com.domain: Flags [S], seq 4227748459, win 29200, options [mss 1460,sackOK,TS val 11767085 ecr 0,nop,wscale 7], length 0
23:39:07.747595 IP google-public-dns-a.google.com.domain > [my_server].59047: Flags [S.], seq 719567413, ack 4227748460, win 42408, options [mss 1380,sackOK,TS val 3894129283 ecr 11767085,nop,wscale 7], length 0
23:39:07.747657 IP [my_server].59047 > google-public-dns-a.google.com.domain: Flags [.], ack 1, win 229, options [nop,nop,TS val 11767089 ecr 3894129283], length 0
23:39:07.747982 IP [my_server].59047 > google-public-dns-a.google.com.domain: Flags [P.], seq 1:59, ack 1, win 229, options [nop,nop,TS val 11767089 ecr 3894129283], length 5821405+% [1au] Type32769? dasoertliche.de.dlv.isc.org. (56)
23:39:07.788998 IP google-public-dns-a.google.com.domain > [my_server].59047: Flags [.], ack 59, win 332, options [nop,nop,TS val 3894129324 ecr 11767089], length 0
23:39:07.789344 IP google-public-dns-a.google.com.domain > [my_server].59047: Flags [P.], seq 1:739, ack 59, win 332, options [nop,nop,TS val 3894129325 ecr 11767089], length 73821405 NXDomain$ 0/6/1 (736)
23:39:07.789372 IP [my_server].59047 > google-public-dns-a.google.com.domain: Flags [.], ack 739, win 240, options [nop,nop,TS val 11767093 ecr 3894129325], length 0
23:39:07.790414 IP [my_server].59047 > google-public-dns-a.google.com.domain: Flags [F.], seq 59, ack 739, win 240, options [nop,nop,TS val 11767093 ecr 3894129325], length 0
23:39:07.796565 IP [my_server].domain > [my_client].52174: 57873 1/0/0 A 82.98.79.52 (49)
23:39:07.831137 IP google-public-dns-a.google.com.domain > [my_server].59047: Flags [F.], seq 739, ack 60, win 332, options [nop,nop,TS val 3894129366 ecr 11767093], length 0
23:39:07.831221 IP [my_server].59047 > google-public-dns-a.google.com.domain: Flags [.], ack 740, win 240, options [nop,nop,TS val 11767097 ecr 3894129366], length 0

同樣，在 23:39:01.617721 my_server 收到了來自 resolver2.opendns.com 的正確答案，但出於某種原因，我不明白 my_server 和 google dns 伺服器之間會出現大量通信。

任何想法這裡發生了什麼以及如何改善這種情況？

c) 更新

根據要求，這是free…的輸出

[my_server]:~ $ free
            total       used       free     shared    buffers     cached
Mem:        996448     331696     664752      15752      29808     180668
-/+ buffers/cache:     121220     875228
Swap:            0          0          0

…和vmstat：

[my_server]:~ $ vmstat
procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
1  0      0 664752  29808 180676    0    0     0     1   20   23  0  0 100  0  0

d) 更新 2：

剛剛發現我/var/log/syslog有關於 dasoertliche.de 的解決問題的條目（第二個有問題的案例）。如下：

Dec 13 23:39:01 raspi-server named[642]:   validating @0x713c0030: de SOA: got insecure response; parent indicates it should be secure
Dec 13 23:39:01 raspi-server named[642]: error (no valid RRSIG) resolving 'dasoertliche.de/DS/IN': 208.67.220.220#53
Dec 13 23:39:01 raspi-server named[642]:   validating @0x712c0030: de SOA: got insecure response; parent indicates it should be secure
Dec 13 23:39:01 raspi-server named[642]: error (no valid RRSIG) resolving 'dasoertliche.de/DS/IN': 208.67.222.222#53
Dec 13 23:39:04 raspi-server named[642]: success resolving 'dasoertliche.de/DS' (in '.'?) after reducing the advertised EDNS UDP packet size to 512 octets
Dec 13 23:39:04 raspi-server named[642]:   validating @0x711c2040: dlv.isc.org SOA: got insecure response; parent indicates it should be secure
Dec 13 23:39:04 raspi-server named[642]:   validating @0x73401378: dlv.isc.org SOA: got insecure response; parent indicates it should be secure
Dec 13 23:39:04 raspi-server named[642]: error (no valid RRSIG) resolving 'dasoertliche.de.dlv.isc.org/DS/IN': 208.67.220.220#53
Dec 13 23:39:04 raspi-server named[642]:   validating @0x713c0030: dlv.isc.org SOA: got insecure response; parent indicates it should be secure
Dec 13 23:39:04 raspi-server named[642]: error (no valid RRSIG) resolving 'dasoertliche.de.dlv.isc.org/DS/IN': 208.67.222.222#53
Dec 13 23:39:04 raspi-server named[642]: error (insecurity proof failed) resolving 'dasoertliche.de.dlv.isc.org/DLV/IN': 208.67.220.220#53
Dec 13 23:39:05 raspi-server named[642]:   validating @0x712c0030: dlv.isc.org SOA: got insecure response; parent indicates it should be secure
Dec 13 23:39:05 raspi-server named[642]: error (insecurity proof failed) resolving 'dasoertliche.de.dlv.isc.org/DLV/IN': 208.67.222.222#53
Dec 13 23:39:07 raspi-server named[642]: success resolving 'dasoertliche.de.dlv.isc.org/DLV' (in '.'?) after reducing the advertised EDNS UDP packet size to 512 octets

現在一切都開始變得更有意義了，我相信。我猜想發生了什麼：OpenDNS 似乎不支持 DNSSEC，所以當 my_server 從 OpenDNS 取回初始（正確）解析並要求 DNSSEC 時，它一定認為響應不安全，因為沒有正確的 DNSSEC 響應。因此，從 23:39:01.856006 開始，它試圖從 google DNS 獲得確認。但是以下幾行是syslog什麼tcpdump意思？為什麼有幾秒鐘Google沒有回复，Google和 my_server 之間的回復和以下資訊交換意味著什麼？

經過更多研究，問題似乎如下：

初始設置包含支持DNSSEC的轉發器（GoogleDNS 8.8.8.8、8.8.4.4）和一些不支持的轉發器（OpenDNS 208.67.222.222、208.67.220.220）。根據以下配置，我在完全啟用 DNSSEC 的情況下執行 BIND9：

dnssec-enable      yes;
dnssec-validation  yes;
dnssec-lookaside   auto;

a)每當請求 (A?) 被轉發到GoogleDNS伺服器時，my_server 都會得到回复 (A)，發送 DNSSEC 查詢 (DS?) 並得到正確的答案。解決方案完成，簽名確認，一切正常，案例關閉（見上文，正常案例）。

b)每當請求 (A?) 被轉發到OpenDNS伺服器時，my_server 都會收到回复 (A)，發送一個 DNSSEC 查詢 (DS?)，OpenDNS 由於不支持 DNSSEC 而無法正確回答。所以 BIND9 在 中拋出了一個錯誤syslog，指出它got insecure response並試圖在其他地方獲得它的 DNSSEC 驗證（見上文，有問題的案例）。

我仍然不完全明白當時發生了什麼，但顯然那是打嗝開始的時候。現在我不知道 GoogleDNS 伺服器是否不喜歡在沒有先提供相應的 A? 查詢的情況下給出 DS?-answers。但在這兩種有問題的情況下（sueddeutsche.net、dasoertliche.de），似乎這些條目也沒有正確簽名，因此 DNSSEC 沒有產生正確的驗證。所以 DNSSEC-lookaside 驗證 (DLV) 開始了 ( Type32769?) 並且它再次向南。不知道為什麼。

**c) 解決方案：**畢竟，我做了以下事情，還沒有遇到任何問題（看來問題已經解決了）：

首先，我將轉發器切​​換為僅

forwarders         { 8.8.8.8; 8.8.4.4; };

這樣就不再有 DNSSEC 支持的混淆。二、我註釋掉了

//dnssec-lookaside   auto;

因為在探勘了大量的 tcpdump 之後，似乎每當解析速度很慢時，延遲要麼是由於 GoogleDNS 需要一些時間來給出答案（很少發生），要麼是 - 經常 - 在 DLV 期間發生。由於 DLV 目前正在逐步淘汰，2017 年不再提供條目

https://www.isc.org/blogs/dlv/

我相信從安全的角度來看這是可以接受的。

現在另一種解決方案是放棄 GoogleDNS 伺服器，只使用 OpenDNS 作為轉發器。但是我不得不註釋掉上面提到的所有 dnssec 條目，完全禁用 DNSSEC，因為 OpenDNS 不支持它。這將使我的 dns 查詢容易受到攻擊，這需要添加一個替代的安全層，例如dnscrypt（如 Rui F Ribeiro 所述）。雖然這看起來像一個有價值的項目（因為它完全加密了 dns 流量，因此不僅保持它不變，而且攻擊者也無法讀取它），但它有點超出我目前的時間預算。

如果上面的解釋有意義，有任何 DNS 專家想要插話嗎？

引用自：https://unix.stackexchange.com/questions/330237

相關問答

Dns

如何列出我的 BIND9 作為主機管理的所有域名？

  • April 14, 2020
檢視問答
Dns

這個區域語法有什麼區別嗎？

  • December 19, 2018
檢視問答
Dns

如何配置 bind9 以迭代解析遞歸請求，從 dns 根伺服器開始？

  • April 19, 2018
檢視問答
Debian

主機命令成功，但 DNS 無法解析

  • April 16, 2018
檢視問答
Dns

命名配置中的 localhost 和 localnets 有什麼區別

  • December 29, 2016
檢視問答
Centos

PowerDNS 為所有請求返回 ServFail

  • January 24, 2016
檢視問答