20201120-DNS服务named启动时获取DNSKEY报“

        应Centos6 end of Life重新搭建内部DNS服务器，启动DNS服务时，获取DNSKEY报“timed out”异常，报错如下：

Nov 19 15:42:29 ebs-36006 named[18432]: managed-keys-zone: Unable to fetch DNSKEY set '.': timed out

跟踪全天的日志：这个报错每小时都会出现，偶尔会出现获取正常，正常消息如下：

Nov 19 15:43:04 ebs-36006 named[18473]: managed-keys-zone: Key 20326 for zone . acceptance timer complete: key now trusted

执着于baidu/google搜索问题解决办法，效率低下，耽误时光，痛定思痛，遂成斯文。

OS：CentOS Linux release 7.6.1810 (Core)

bind Version:bind-9.11.4-26.P2.el7.x86_64

一、技术面：原因分析及解决

一）原因分析

1.由于内部DNS启用dnssec，所以内部DNS会向根域名(13个根节点)获取DNSKEY信息；出去安全性的考虑这个DNSKEY的有效期限很短，所以内部DNS服务器隔一段时间就要去重新获取一次。

2.又因为DNS默认情况下使用的UDP协议(端口53)，所以我的环境中只开放UDP 53端口；然而，UDP协议传输数据是不稳定的，所以域名服务其实一般情况下为了稳定同步信息，其实是优先利用TCP协议(端口53)的；不仅是同步这个DNSKEY,比如内部DNS主从同步都是优先利用TCP 53端口的。

3.出于安全性最小开放端口的原因，我的环境只开放UDP 53端口的出口。

二)解决

开放TCP 53端口

iptables -A OUTPUT -p tcp --dport 53 -j ACCEPT

ip6tables -A OUTPUT -p tcp --dport 53 -j ACCEPT

二、思路面：解决方式误区

       虽然前述原因分析中所述技术层面原因都知道，但是一开始真的没有进入技术分析思维中。

低效解决步骤：

1.通过baidu/google搜索异常日志，查看是否BUG、是否有遇到相同的问题的解决方法；然后结果是惨痛的，网上都说是IPv6的原因，解决方法还写的有模有样，我反反复复尝试。

然后并没有解决问题，搜索、调试折磨我两三天。

2.痛定思痛，还是要回到问题分析的常规思路上来；A：开Debug，B：tcpdump抓包。只消半晌的功夫，定位问题、原因分析、本地环境、α环境测试全部OK。

正确解决思路：

1.看log及关联信息进行分析--能够解决最好，不能解决马上下一步；

2.baidu/google简单搜索下是否存在BUG或者比较清晰的解决思路--如果没有切莫执着；

3.开debug，开网络(tcpdump)或者系统(strace)跟踪.