DNS BIND之dnssec安全介绍

 

Domain Name System Security Extensions (DNSSEC)DNS安全扩展，是由IETF提供的一系列DNS安全认证的机制（可参考RFC2535）。它提供了一种来源鉴定和数据完整性的扩展，但不去保障可用性、加密性和证实域名不存在。DNSSEC是为解决DNS欺骗和缓存污染而设计的一种安全机制。
开发DNSSEC技术的目的之一是通过对数据进行数字“签名”来抵御此类攻击，从而使您确信数据有效。但是，为了从互联网中消除该漏洞，必须在从根区域到最终域名（例如， www. icann. org ）的查找过程中的每一步部署该项技术。对根区域进行签名（在根区域部署 DNSSEC ）是整个过程中的必要步骤。需要说明的是，该技术并不对数据进行加密。它只是验证您所访问的站点地址是否有效。完全部署 DNSSEC 可以确保最终用户连接到与特定域名相对应的实际网站或其他服务。尽管这不会解决互联网的所有安全问题，但它确实保护了互联网的关键部分（即目录查找），从而对 SSL (https:) 等其他保护“会话”的技术进行了补充，并且为尚待开发的安全改进技术提供了平台。
一、DNSSEC概念与原理
DNSSEC通过为通过为DNS中的数据添加数字签名信息，使得客户端在得到应答消息后可以通过检查此签名信，使得客户端在得到应答消息后可以通过检查此签名信息来判断应答数据是否权威和真实，从而为 从而为DNS数据提供数据来源验证和数据完整性检验，可以防止针对 可以防止针对DNS的相关攻击。

 

DNSSEC引入新的资源记录：
1.DNSKEY：用于存储验证 DNS数据的公钥
2.RRSIG：用于存储 DNS资源记录的签名信息
3.NSEC：存储和对应的所有者相邻的下一个资源记录 ；主要用于否定存在验证。
4.DS（Delegation Signer授权签名者），用于DNSKEY验证过程，存储密钥标签，加密算法和对应的DNSKEY的摘要信息。
二、DNSSEC功能
1.为DNS数据提供来源验证
2.为数据提供完整性性验证
3.为查询提供否定存在验证
即为否定应答消息提供验证，确认授权服务器上不存在所，确认授权服务器上不存在所
查询的资源记录））
三、部署DNSSEC有两种场景
1.配置安全的域名解析服务器(Resolver)，该服务器可以保护使用它的用户，防止被DNS 欺骗攻击。这里只涉及数字签名的验证工作。
2.)配置安全的权威域名服务器(Name Server)，对权威域的资源记录进行签名，保护服务器不被域名欺骗攻击。
四、开启DNSSEC
在BIND的配置文件(一般是/etc/named.conf)中打开DNSSEC选项
dnssec-enable yes;
dnssec-validation yes;
dnssec-lookaside auto;
注：
dnssec-enable: 是否支持DNSSEC开关,默认为yes。
dnssec-validation: 是否进行DNSSEC确认开关,默认为no。
dnssec-accept-expired: 接受验证DNSSEC签名过期的信号,默认为no。
dnssec-lookaside：当设置dnssec-lookaside,它为验证器提供另外一个能在网络区域的顶层验证DNSKEY的方法。
dnssec-must-be-secure: 指定验证等级,如果选yes,named只接收安全的回应,如果选no,一般的dnssec验证将允许接收不安全的回应。
五、DNSSEC中KSK和ZSK
KSK表示密钥签名密钥 (Key Signing key) （一种长期密钥）
ZSK 表示区域签名密钥 (Zone Signing Key) （一种短期密钥）
如果有足够的时间和数据，加密密钥最终都会被破解。对于 DNSSECv中使用的非对称密钥或公钥密码系统而言，这意味着攻击者可通过强力攻击方法或其他方法确定公钥-私钥对的私钥部分（该部分用于创建对 DNS 记录的有效性进行验证的签名），从而使 DNSSEC 提供的保护失效。 DNSSEC 使用短期密钥（即区域签名密钥 (ZSK) ） 来定期计算 DNS 记录的签名，同时使用长期密钥（即密钥签名密钥 (KSK) ） 来计算 ZSK 上的签名，以使其可以得到验证，从而挫败了这些破解企图。 ZSK 被频繁更改或滚动，以使攻击者难以“猜测”，而期限较长的 KSK 则经过一个长得多的时段之后才更改（当前的最佳做法是以年为单位设置此时段）。由于 KSK 对 ZSK 进行签名而 ZSK 对 DNS 记录进行签名，因此只需具有 KSK 即可对区域中的 DNS 记录进行验证。 它是以 授权签名者 (Delegation Signer, DS) 记录形式传递到“父”区域的一个 KSK 示例 。父区域（例如，根区域）使用其自己的、由其自己的 KSK 签名的 ZSK 对子区域（例如， .org ）的 DS 记录进行签名。
这意味着，如果 DNSSEC 被完全采用，则根区域的 KSK 将是每个经 DNSSEC 验证的域名（或尚待开发的应用程序）的验证链的一部分。
六、密钥对生成
dnssec-keygen -a RSASHA1 -b 1024 -n ZONE zonename
1.DNSSEC标准中指定使用非对称密钥来生成和验证签名;
2.参数a表示使用的加密算法（三种算法:DSA/RSA/椭圆曲线DSA）
2.参数b用来制定密钥长度；
密钥长度需要考虑到密钥的可靠性和性能，
以及如何根据需要在两者之间取得平衡。
3.参数n指定密钥类型（ZONE/HOST）
4."zonename"密钥的名字（密钥的所有者密钥的所有者）
实例：
#/home/slim/bind/sbin/dnssec-keygen -a RSASHA1 -b 1024 -n ZONE test.com
Generating key pair...............++++++ ..++++++
Ktest.com.+005+28938
# ls
Ktest.com.+005+28938.key  #.key公有密钥
Ktest.com.+005+28938.private #.private私有密钥
5.根据DNSSEC部署经验，至少需要两种类型密钥才能地对DNSSEC域区进行安全的管理
ZSK（Zone-Signing Key）区签名密钥——用于签名域区内的数据
KSK（Key-Signing Key）密钥签名密钥——用于签名ZSK并创建区的"安全入口点"
dnssec-keygen -a RSASHA1 -b 1024  –f KSK -n ZONE zonename
实例：
#/home/slim/bind/sbin/dnssec-keygen -a RSASHA1 -b 1024 -f KSK -n ZONE test.com
Generating key pair.........++++++ ....++++++
Ktest.com.+005+23668
# ls
Ktest.com.+005+23668.key
Ktest.com.+005+23668.private
七、文件签署
签署之前，先将KSK和和ZSKZSK公有密钥添加到域区文件中。可以使用如下方式：
$INCLUDE到zonefile或者cat Kzonename+<alg>+<fing>.key >> zonefile
在区文件test.com.zone末尾添加如下信息
$INCLUDE "Ktest.com.+005+23668.key"
$INCLUDE "Ktest.com.+005+28938.key"

dnssec-signzone -o zonename –f result.file [-N INCREMENT][-k KSKfile] [-t] zonefile [ZSKfile]
1.签名工具BIND自带
2.参数o指定所有域区文件起始
3.-N INCREMENT序列号自增
4.参数-K指定KSK文件名称
5."zonefile"被签名的zone文件
6.ZSKfile制定ZSK文件名称
7.-f指定输出文件名称
8.-t显示统计信息
实例：
../bind/sbin/dnssec-signzone -o test.com test.com.zone
Verifying the zone using the following algorithms: RSASHA1.
Zone fully signed:
Algorithm: RSASHA1: KSKs: 1 active, 0 stand-by, 0 revoked
                    ZSKs: 1 active, 0 stand-by, 0 revoked
test.com.zone.signed
签名后输出文件为test.com.zone.signed
签署域区的过程主要包括：
1.将域区文件中的资源记录按照规则进行排序
2.为域区中的每个资源记录生成一个NSEC记录
3.将生成的签名信息存储在相应的RRSIG记录中
4.签名后文件比原域区文件更大

八、加载签名后的区数据
更新named.conf文件
zone "test.com" IN {
        type master;
        file "zone/test.com.zone";
};
改为
zone "test.com" IN {
        type master;
        file "zone/test.com.zone.signed";
};

九、DNSSEC验证流程验证流程
在父区验证
1、在验证时，解析器在父区查找被验证区的DS记录
2、如果不存在，向DLV注册机构发出一个对DLV记录的请求
3、如果成功，DLV资源记录被当做这个区的DS记录
4、在递归服务器上进行验证

注：DLV旁路认证概念旁路认证概念
1.DLV—DNSSECLookasideValidation
2.DLV是一个DNS服务器,提供DNSSEC签名认证的信任链解决方案，递归服务器配置的信任锚点是DLV，就可以认证域，进而认证权威域授权的信任的权威域。
递归服务器的配置：dnssec-lookaside 当设置dnssec-lookaside,它为验证器提供另外一个能在网络区域的顶层验证DNSKEY的方法
dnssec-lookaside "." trust-anchor dlv.cnnic.cn
trusted-keys {
dlv.cnnic.cn 256 3 5 "qWmA7OpfdqvqMtLCzZTm982aTaeC6tTRiPUOFDVMXEkIuM14T8Tw6jg2qmX7JUtriYHAGwIQ+9jzYyRziSFdijaO2elgh90NMW0jIcjZ+3cHehpETCEUar813SHN38biRu4UL0EQ/X5C5LJyh1djaw8eZFXxaLyT8fcJedBZtYE=";
}

十、发布公钥
要让其他人验证你的数字签名，其他人必须有一个可靠的途径获得你的公开密钥。DNSSEC通过上一级域名服务器数字签名的方式签发你的公钥。用dnssec-signzone 时，会自动生成keyset-文件和dsset-开头的两个文件，分别存储着KSK的DNSKEY记录和DS记录。作为test.net区的管理员，你需要把这两个文件发送给.net的管理员，.net的管理员需要把这两条记录增加到.net区中，并且用.net的密钥重新签名。
test.net. 86400 IN NS ns.test.net.
86400 DS 15480 5 1 (
F340F3A05DB4D081B6D3D749F300636DCE3D
6C17 )
86400 RRSIG DS 5 2 86400 20060219234934 (
20060120234934 23912 net.
Nw4xLOhtFoP0cE6ECIC8GgpJKtGWstzk0uH6
………
YWInWvWx12IiPKfkVU3F0EbosBA= )
如果你的上一级域名服务器还没有配置DNSSEC，你不得不另找其他方式了，比如，把上述两个文件提交到一些公开的trust anchor数据库中发布，或者直接交给愿意相信你的解析服务器的管理员，配置到他们的trust anchor文件中。
注：配置Trust anchor
要给解析服务器配置可信锚(Trust Anchors)，也就是你所信任的权威域的DNSKEY。理想情况下我们可以配置一个根的密钥就够了，但是目前DNSSEC还没有完全部署的情况下，我们需要配置很多安全岛(Secure Island)的密钥，可以从很多公开的网站下载这些可信域的DNSKEY文件，包括：
(1)Root Zone DNSSEC Trust Anchors：https://www.iana.org/dnssec/。2010年7月部署实施，如果DNSSEC全部部署成功，这一个公开密钥就足够了。
(2)The UCLA secspider ： https://secspider.cs.ucla.edu，由美国加州大学洛杉矶分校(UCLA)张丽霞教授的实验室维护。
(3)The IKS Jena TAR：https://www.iksjena.de/leistungen/dnssec.php
这些文件大概是这样的格式：
trusted-keys {
"test.net." 256 35 "AQPzzTWMz8qS…3mbz7Fh
...
fHm9bHzMG1UBYtEIQ==";
"193.in-addr.arpa." 257 3 5 "AwEAAc2Rn….HlCKscYl
...
kf2kOcq9xCmZv….XXPN8E=";
};
假设上述trust anchors的文件为/var/named/trust-anchors.conf，则在/etc/named.conf中增加下面一行：
include "/var/named/se-c-trust-anchors.conf";
---------------------  
作者：slimina  
来源：CSDN  
原文：https://blog.csdn.net/zhu_tianwei/article/details/45082015  
版权声明：本文为博主原创文章，转载请附上博文链接！