搜索
搜索

BIND9：DNS有时（！）解析时间很长或根本无法工作

debugcn 发表于 Dev
8
缺口

我的网络中的RPi3上运行的是BIND 9.9.5-9 + deb8u8-Raspbian DNS服务器。对于-并非我的本地区域的所有内容，将其配置为“仅转发”，转发器为“ {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？），由于它不支持DNSSEC，因此OpenDNS无法正确回答。因此BIND9在中抛出了一个错误syslog，指出该错误got insecure response并试图在其他地方获取它的DNSSEC验证（请参见上面的有问题的案例）。

我仍然不完全了解当时发生的情况，但是显然那是打ic开始的时候。现在，我不知道GoogleDNS服务器是否不喜欢在未首先提供相应的A？查询的情况下发出DS？-答案。但是在这两个有问题的情况下（sueddeutsche.net，dasoertliche.de），似乎条目也未正确签名，因此DNSSEC无法产生正确的验证。因此，DNSSEC后备验证（DLV）开始了（Type32769?），然后一切又都结束了。不知道为什么。

c）解决方案：在完成所有这些之后，我已经完成了以下操作，但尚未遇到任何问题（因此看来问题已解决）：

首先，我将货运代理改为 

forwarders         { 8.8.8.8; 8.8.4.4; };

这样就不再存在DNSSEC支持的混合情况。其次，我注释掉

//dnssec-lookaside   auto;

因为在仔细研究了许多tcpdumps之后，似乎每当解析速度很慢时，延迟要么是由GoogleDNS花费一些时间来给出答案（很少发生），要么是有规律的-在DLV期间发生。由于DLV目前正在逐步淘汰，因此2017年将不再提供参赛作品

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

从安全角度来看，我认为这是可以接受的。

现在，另一种解决方案是放弃GoogleDNS服务器，而仅将OpenDNS用作转发器。但是之后，我不得不注释掉上面提到的所有dnssec条目，从而完全禁用DNSSEC，因为OpenDNS不支持它。这将使我的dns查询容易受到攻击，而攻击则需要添加一个替代的安全层，例如dnscrypt（如Rui F Ribeiro所提到的）。虽然这看起来像是一个值得一做的项目（因为它完全加密了dns流量，所以不仅使其保持不变，而且攻击者无法读取），但是这超出了我当前的时间预算。

如果上面的解释有意义，那么有没有DNS专家想加入？

本文收集自互联网，转载请注明来源。

如有侵权，请联系[email protected] 删除。

编辑于
0

我来说两句

0条评论
登录后参与评论

相关文章

来自分类Dev

反向DNS区域无法正常工作BIND9

来自分类Dev

具有bind9的DNS服务器无法解析反向区域

来自分类Dev

cloneNode（）使html视频出现滞后，有时根本无法渲染

来自分类Dev

cloneNode（）使html视频出现滞后，有时根本无法渲染

来自分类Dev

高山Linux有时DNS无法解析

来自分类Dev

Bind9 DNS风格

来自分类Dev

componentDidMount没有被调用，似乎根本无法正常工作

来自分类Dev

无法使用bind9解析本地域名

来自分类Dev

无法升级bind9

来自分类Dev

无法升级bind9

来自分类Dev

BIND9无法解决

来自分类Dev

我的滑动滑杆根本无法工作

来自分类Dev

现在，visudo根本无法工作

来自分类Dev

SemanticUI jQuery根本无法正常工作

来自分类Dev

可以将bind9用作DNS解析为外部IP？

来自分类Dev

可以将bind9用作DNS解析为外部IP？

来自分类Dev

如何配置bind9从DNS根服务器开始迭代解析递归请求？

来自分类Dev

BIND9 DNS服务器-大量带有SERVFAIL和EDNS引用的失败查询

来自分类Dev

isc-dhcp-server + BIND9 + Unbound + dnscrypt和DDNS无法正常工作

来自分类Dev

使用oracle序列进行休眠根本无法正常工作

来自分类Dev

麦克风在Skype中根本无法工作

来自分类Dev

麦克风在Skype中根本无法工作

来自分类Dev

用户登录系统根本无法正常工作

来自分类Dev

英特尔无线根本无法正常工作

来自分类Dev

我根本无法让Wacom Intuos在Ubuntu中工作

来自分类Dev

故障排除错误的BIND9 DNS地址条目

来自分类Dev

托管 DNS 服务器（例如 bind9）

来自分类Dev

允许 DHCP 使用 Samba AD 更新 Bind9 DNS

来自分类Dev

警报管理器有时需要很长时间才能运行意图

Related 相关文章

  1. 1

    反向DNS区域无法正常工作BIND9

  2. 2

    具有bind9的DNS服务器无法解析反向区域

  3. 3

    cloneNode（）使html视频出现滞后，有时根本无法渲染

  4. 4

    cloneNode（）使html视频出现滞后，有时根本无法渲染

  5. 5

    高山Linux有时DNS无法解析

  6. 6

    Bind9 DNS风格

  7. 7

    componentDidMount没有被调用，似乎根本无法正常工作

  8. 8

    无法使用bind9解析本地域名

  9. 9

    无法升级bind9

  10. 10

    无法升级bind9

  11. 11

    BIND9无法解决

  12. 12

    我的滑动滑杆根本无法工作

  13. 13

    现在，visudo根本无法工作

  14. 14

    SemanticUI jQuery根本无法正常工作

  15. 15

    可以将bind9用作DNS解析为外部IP？

  16. 16

    可以将bind9用作DNS解析为外部IP？

  17. 17

    如何配置bind9从DNS根服务器开始迭代解析递归请求？

  18. 18

    BIND9 DNS服务器-大量带有SERVFAIL和EDNS引用的失败查询

  19. 19

    isc-dhcp-server + BIND9 + Unbound + dnscrypt和DDNS无法正常工作

  20. 20

    使用oracle序列进行休眠根本无法正常工作

  21. 21

    麦克风在Skype中根本无法工作

  22. 22

    麦克风在Skype中根本无法工作

  23. 23

    用户登录系统根本无法正常工作

  24. 24

    英特尔无线根本无法正常工作

  25. 25

    我根本无法让Wacom Intuos在Ubuntu中工作

  26. 26

    故障排除错误的BIND9 DNS地址条目

  27. 27

    托管 DNS 服务器（例如 bind9）

  28. 28

    允许 DHCP 使用 Samba AD 更新 Bind9 DNS

  29. 29

    警报管理器有时需要很长时间才能运行意图

热门标签

归档