DNSSec的应用和问题处理

2020-07-02 19:55:23

王晓辉

DNSSec的应用和问题处理

DNS Sec简介

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

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

这里引入了一个新的概念RRsets,简单的说就是Resource Record Set,就是把相同类的同一个ZoneDNS 资源(AAAAANSSOA等)打包到一个RRsets中,加密签名添加到DNS Response报文中,这些签名用RRSIG表示。

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


ZSKPublic怎么发送给对方呢?这里引入了一个DNS的新型的报文结构,DNSSEC Record。当请求nameserverRRSetsDNS Resolver主动获取NameServerZSK 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),子ZoneDNSSEC KSK信息手动copyparent 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去验证RRsetsRRSIG签名。

d. 使用Public KSK去验证DNSSECRRSIG签名。

F5 DNSSEC应用

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

DNSSecF5上的配置关键步骤可以说完全参照协议制定:

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

2, 创建DNSSec Key – Zone Signing KeyKey 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_Groupmaster-key要求一致

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

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信息,DNSSecKey生成是成功的。


3, 如果是GTM_Sync_Group配置,查看keygeneration信息中的creator. 对于GTM_Sync_Group,他们的keycreator是一致的

名词解释

RRsets -> Resource Record sets,资源组

RRSIG -> Resource Record Signature,加密签名

DNSSec Record -> DNSSec Record, 包含ZSKKSK信息

ZSK -> Zone Signing Key

KSK -> Key Signing Key

DS Record -> Delegation Signer RecordsDNSSEC RecordHash

发布评论 加入社群

发布评论

相关文章

Login

手机号
验证码
© 2019 F5 Networks, Inc. 版权所有。京ICP备16013763号-1