DNSSec的应用和问题处理

DNS Sec简介

为什么需要DNSSec？正常的DNS请求和DNS回应都是明文发送的，这里就很简单可以伪造。中间被截取的DNS请求，很简单就可以回应一个非法的DNS解析。最典型的一个安全案例：2014年9月发生的安全事件，Hotmail，Yahoo，Gmail的邮件邮箱服务器被篡改指向一个伪造的IP地址，导致了大量邮件的错误转发。这个案例也造就了DNSSec的问世。

DNSSec不是对报文进行加密，而是用于DNS解析服务器或者说NameServer和DNS Resolver之间的认证功能，其实就是在原有的DNS报文上加了一个加密签名。这个认证功能可以有效的防止DNS服务器伪造，用于主动的检查NameServer的正当性。

这里引入了一个新的概念RRsets，简单的说就是Resource Record Set，就是把相同类的同一个Zone的DNS 资源（A、AAAA、NS、SOA等）打包到一个RRsets中，加密签名添加到DNS Response报文中，这些签名用RRSIG表示。

但是签名需要被认识，如何操作。这就是最基本的非对称加密模式，Public和Privat KEY。发送RRsets使用的Key值我们称之为Zone Signing Key-ZSK，这个Key是含两部分的，Private Key保存在自己设备上，Public Key共享，使用Private Key进行加密，接收方使用Public Key进行检验收到的RRsets是否是正确的加密签名。

ZSK的Public怎么发送给对方呢？这里引入了一个DNS的新型的报文结构，DNSSEC Record。当请求nameserver的RRSets，DNS Resolver主动获取NameServer的ZSK Public信息。从而可以对RRSets携带的签名进行校验。但是又存在一个问题，怎么才能知道ZSK Public信息也是正确的信息呢？

此处的概念是一个新的Key，称之为Key Signing Key，顾名思义，它是用来保护加密ZSK的。DNSSEC Reocrd携带的信息包含两部分：KSK Public信息和ZSK Public信息。

双KEY机制

这里有个疑问：为什么使用两套Key机制？

1， 任何人都可以回ZSK Public信息，这个是无关安全的，只要启动了DNSSec，任何一个NameServer都可以把RRsets加上加密信息。因此如果仅仅只是用ZSK，依旧无法完全的防止DNS伪造。因此需要的是权威的DNS NameServer进行一系列的全套DNS链的信任。这里使用的一个新的报文DS Record(delegation signer records)，子Zone的DNSSEC KSK信息手动copy给parent Zone，从而保证建立信任链。这种情况下，一个伪造的NameServer就很难得到上下游递归迭代节点的认可。

2， KEY管理上的考虑。老化和更新机制。ZSK只需要关注自己设备的更新老化即可。KSK可以定期更新，减少交互。

3， ZSK用于真正的DNS域名解析的加密签名，可以使用简单密钥，节省时间，因为KSK已经保证了ZSK的安全。而KSK，可以使用复杂密钥。但是对于当前的CPU性能，密钥的加解密已经不再是一个很重要的性能瓶颈。

DNSSec的整个流程简介

根据前面描述的信息，整个DNSSec的流程简介如下：

a. 请求需求的RRsets，得到对应的RRSets同时附带着RRSIG签名。

b. 请求DNSSEC Record，返回DNSSEC RRsets，其中包含了KSK Public信息和ZSK Public信息，同样也带着RRSIG签名。

c. 使用Public ZSK去验证RRsets的RRSIG签名。

d. 使用Public KSK去验证DNSSEC的RRSIG签名。

F5 DNSSEC应用

基本信息解释完毕，再看F5的DNSSec的应用和一些问题定位。

DNSSec在F5上的配置关键步骤可以说完全参照协议制定：

1， 要求GTM中存在server配置，否则无法生成Key。

2， 创建DNSSec Key – Zone Signing Key和Key Signing Key。

3， DNS Profile中使能DNSSec功能。

4， 配置DNSSEC Zone。

F5应用场景上，DNSSec单独使用的比较少，基本上都是和DNS Cache或者DNS Express一起使用。

https://techdocs.f5.com/en-us/bigip-14-1-0/big-ip-dns-services-implementations-14-1-0/configuring-dnssec.html

https://techdocs.f5.com/en-us/bigip-14-1-0/big-ip-dns-services-implementations-14-1-0/configuring-dns-express.html

https://techdocs.f5.com/en-us/bigip-14-1-0/big-ip-dns-services-implementations-14-1-0/configuring-dns-caching.html

典型场景GTM_Sync_Group

1， 在GTM_Syn_Group的master-key要求一致

除了正常的配置DNSSec之外，最关键的一个是GTM_Sync_Group是共享同一个Key值的，因此当出现GTM组之间存在DNSSec问题时，最关键的是要记得使用命令f5mku -K查看Key值是否一致；如果存在不一致，需要将正常设备上的master-key复制到问题设备上执行f5mku -r <key_value>将master-key进行刷新，然后tmsh save sys config并reboot设备。

KEY的生成是TMM处理，因此KEY生成的日志是在TMM中。如果出现如下日志：那就表示master-key不正确，无法正常生成KEY值，需要查看Master-key。

<13> May 28 15:52:00 deviceA notice passphrase decryption failure (final stage)

<13> May 28 15:52:00 deviceA notice MCP message handling failed in 0x5a25c0 (16908289): May 28 15:52:00 - MCP Message:

https://support.f5.com/csp/article/K11868

K11868: The master key is not synchronized after upgrading a BIG-IP GTM synchronization group

2， DNSSEC设备RMA

当RMA设备时，只是进行UCS的导入不能解决RMA设备的Key值更新，必须gtm_add命令把Key值进行同步。

或者先使用命令从一台GTM_Sync_Group邻居将master-key进行copy过来，然后执行命令f5mku -r <key_value>将master-key进行粘贴，之后再进行load ucs操作。

https://support.f5.com/csp/article/K13542

K13542: Restoring DNSSEC or password protected configuration data to a BIG-IP GTM or BIG-IP DNS RMA unit

3， DNSSec配置信息是保存在bigip_gtm.conf中

如何检测DNSSec是否生效

1， 使用dig command ： dig @x.x.x.x domailname +dnssec，返回的domain结果是带着RRSIG的，就是DNSSEC运行正常。

2， 查看设备上的配置信息tmsh list ltm dns dnssec

查看到正常的generation信息，DNSSec的Key生成是成功的。

3， 如果是GTM_Sync_Group配置，查看key的generation信息中的creator. 对于GTM_Sync_Group，他们的key的creator是一致的

名词解释

RRsets -> Resource Record sets，资源组

RRSIG -> Resource Record Signature，加密签名

DNSSec Record -> DNSSec Record, 包含ZSK和KSK信息

ZSK -> Zone Signing Key

KSK -> Key Signing Key

DS Record -> Delegation Signer Records，DNSSEC Record的Hash