如何验证DNS服务器是不是支持DNSSEC

Posted 2023-04-24

dns攻击主要有以下这几种方式：
DNS缓存感染
攻击者使用DNS请求，将数据放入一个具有漏洞的的DNS服务器的缓存当中。这些缓存信息会在客户进行DNS访问时返回给用户，从而把用户客户对正常域名的访问引导到入侵者所设置挂马、钓鱼等页面上，或者通过伪造的邮件和其他的server服务获取用户口令信息，导致客户遭遇进一步的侵害。
DNS信息劫持
TCP/IP体系通过序列号等多种方式避免仿冒数据的插入，但入侵者如果通过监听客户端和DNS服务器的对话，就可以猜测服务器响应给客户端的DNS查询ID。每个DNS报文包括一个相关联的16位ID号，DNS服务器根据这个ID号获取请求源位置。攻击者在DNS服务器之前将虚假的响应交给用户，从而欺骗客户端去访问恶意的网站。假设当提交给某个域名服务器的域名解析请求的DNS报文包数据被截获，然后按截获者的意图将一个虚假的IP地址作为应答信息返回给请求者。原始请求者就会把这个虚假的IP地址作为它所要请求的域名而进行访问，这样他就被欺骗到了别处而无妨连接想要访问的那个域名。
DNS重定向
攻击者将DNS名称查询重定向到恶意DNS服务器上,被劫持域名的解析就完全在攻击者的控制之下。
ARP欺骗
ARP攻击就是通过伪造IP地址和MAC地址实现ARP欺骗，能够在网络中产生大量的ARP通信量使网络阻塞，攻击者只要持续不断的发出伪造的ARP响应包就能更改目标主机ARP缓存中的IP-MAC条目，造成网络中断或中间人攻击。ARP攻击主要是存在于局域网网络中，局域网中若有一台计算机感染ARP病毒，则感染该ARP病毒的系统将会试图通过”ARP欺骗”手段截获所在网络内其它计算机的通信信息，并因此造成网内其它计算机的通信故障。
ARP欺骗通常是在用户局网中，造成用户访问域名的错误指向。如果IDC机房也被ARP病毒入侵后，则也可能出现攻击者采用ARP包压制正常主机、或者压制DNS服务器，以使访问导向错误指向的情况。
本机劫持
本机的计算机系统被木马或流氓软件感染后，也可能会出现部分域名的访问异常。如访问挂马或者钓鱼站点、无法访问等情况。本机DNS劫持方式包括hosts文件篡改、本机DNS劫持、SPI链注入、BHO插件等方式。
防范Arp攻击、采用UDP随机端口、建立静态IP映射、运行最新版本的BIND、限制查询、利用防火墙进行保护、利用交叉检验、使用TSIG机制、利用DNSSEC机制。
下面分别做出说明。
防范Arp攻击
主要是针对局域网的DNS ID欺骗攻击。如上所述，DNS ID欺骗是基于Arp欺骗的，防范了Arp欺骗攻击，DNS ID欺骗攻击是无法成功实施的。
采用UDP随机端口
不再使用默认的53端口查询，而是在UDP端口范围内随机选择，可使对ID与端口组合的猜解难度增加6万倍，从而降低使DNS缓存攻击的成功率。
建立静态IP映射
主要是指DNS服务器对少部分重要网站或经常访问的网站做静态映射表，使对这些网站的访问不再需要经过缓存或者向上一级的迭代查询，从而在机制上杜绝DNS欺骗攻击。
运行最新版本的BIND
使用最新版本的BIND，可以防止已知的针对DNS软件的攻击(如DoS攻击、缓冲区溢出漏洞攻击等)。应密切关注BIND安全公告，及时打好补丁。
限制查询
在BIND8和BIND9之后，BIND的allow-query子句允许管理员对到来的查询请求使用基于IP地址的控制策略，访问控制列表可以对特定的区甚至是对该域名服务器受到的任何查询请求使用限制策略。如限制所有查询、限制特定区的查询、防止未授权的区的查询、以最少权限运行BIND等。
利用防火墙进行保护
这种保护方式可以使受保护的DNS服务器不致遭受分布式拒绝服务攻击、软件漏洞攻击。原理是在DNS服务器主机上建立一个伪DNS服务器共外部查询，而在内部系统上建立一个真实的DNS服务器专供内部使用。配置用户的内部DNS客户机，用于对内部服务器的所有查询，当内部主机访问某个网站时，仅当内部DNS服务器上没有缓存记录时，内部DNS才将查询请求发送到外部DNS服务器上，以保护内部服务器免受攻击。
利用交叉检验
这种保护方式可以从一定程度上防范DNS欺骗攻击。原理是反向查询已得到的IP地址对应的主机名，用该主机名查询DNS服务器对应于该主机名的IP地址，如果一致，则请求合法，否则非法。
使用TSIG机制
TSIF(事物签名)机制(RFC2845)通过使用共享密钥(Secret Key)及单向散列函数(One-way hash function)提供信息的验证以及数据的完整性。当配置了TSIG后，DNS消息会增加一个TSIF记录选项，该选项对DNS消息进行签名，为消息发送者和接受者提供共享密钥，从而保证了传输数据不被窃取和篡改。TSIP机制的部署步骤不做赘述，相关RFC文档有详细说明。
利用DNSSEC机制
为保证客户机发送的解析请求的完整性，保护DNS服务器及其中的信息，防止入侵者冒充合法用户向他人提供虚假DNS信息，IETF(网络工程任务组)提出了DNS安全扩展(DNSSEC)的安全防范思想。
1、 DNSSEC工作原理
为提高DNS访问数据包的安全性，DNSSEC在兼容现有协议的基础上引入加密和认证体系，在每个区域都有一对区域级的密钥对，密钥对中的公钥对域名记录信息进行数字签名，从而使支持DNSSEC的接收者可以校验应答信息的可靠性。
BIND9.0支持DNS的安全扩展功能?。DNSSEC引入两个全新的资源记录类型：KEY和SIG，允许客户端和域名服务器对任何DNS数据来源进行密钥验证。DNSSEC主要依靠公钥技术对于包含在DNS中的信息创建密钥签名，密钥签名通过计算出一个密钥Hash数来提供DNS中数据的完整性，并将该Hash数封装进行保护。私/公钥对中的私钥用来封装Hash数，然后可以用公钥把Hash数翻译出来。如果这个翻译出的Hash值匹配接收者计算出来的Hash数，那么表明数据是完整的、没有被篡改的。
2、 DNSSEC的实施
1)、创建一组密钥对
#cd/vat/named
#dnssec -keygen -a RSA -b 512 -n ZONE qfnu.edu.Kqfnu.edu+002+27782
2)、生成密钥记录
#dnssec –makekeyset -t 172802 I
3)、发送密钥文件到上一级域管理员，以供签名使用
#dnssec -signkey keyset -qfnu.edu Kedu.+002+65396.private
然后将返回qfnu.edu.signedkey文件
4)、在进行区域签名之前，必须先将密钥记录添加到区域数据文件之中
#cat“$include Kqfnn.edu.+002+27782.key”>>db.qfnu.edu
5)、对区域进行签名
#dnssec –signzone -O qfnu.edu db.qfnu.edu
6)、修改named.conf里的zone语句，系统将会载新的区域数据文件
3、 DNSSEC的不足
一方面，DNSSEC安全性虽然有所提高，但是标记和校验必然产生额外的开销，从而影响网络和服务器的性能，签名的数据量很大，家中了域名服务器对骨干网以及非骨干网连接的负担，同时简明校验也对CPU造成了很大的负担，同时签名和密钥也占用了占用的磁盘空间以及RAM容量。
另一方面，安全性能方面的考虑。绝大多数的DNS软件是美国出口的，它们为了通过美国政府的安全规定而被迫降低加密算法和过程的安全强度。
第三方面，RSA算法的使用。RSA拥有美国专利，与某些厂商和组织倡导的“免费/开放”目标有所冲突，但是同时又别无选择。在成本方面也是部署中的一个问题。 参考技术A 方法A：检查一个有DNSSEC签名的域名的RRSIG(Resource Record Signature)
为了让结果看得更清楚，我们找一个配置了DNSSEC签名的域名(paypal.com)，一个支持DNSSEC的DNS服务器(4.2.2.4)，和一个不支持DNSSEC的DNS服务器(114.114.114.114)。
使用支持DNSSEC的4.2.2.4查询结果如下：
root@OpenWrt:~# dig paypal.com +dnssec @4.2.2.4

; <<>> DiG 9.9.4 <<>> paypal.com +dnssec @4.2.2.4
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 48979
;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;paypal.com. IN A

;; ANSWER SECTION:
paypal.com. 293 IN A 66.211.169.3
paypal.com. 293 IN A 66.211.169.66
paypal.com. 293 IN RRSIG A 5 2 300 20140728175119 20140628172604 11811 paypal.com. ka3J7csLBUiZIrh7YTKJ7eUBzpACe7jmr6M2wURsNCQ/dFjB9Jl018OZ 6i3BzzSYqSS2jw9TmVZMKxRLH3cmt5jc1BNI6Q9uB46DLpJJoAmXQ1rQ ss37Mb4BlK8dD4rxLJmEJh19+Kg8xXxE8iGYwLM7tkyayIjVdxbt80TE vgg=

;; Query time: 224 msec
;; SERVER: 4.2.2.4#53(4.2.2.4)
;; WHEN: Tue Jul 15 21:49:25 CST 2014
;; MSG SIZE rcvd: 241

使用不支持DNSSEC的114.114.114.114查询结果如下：
root@OpenWrt:~# dig paypal.com +dnssec @114.114.114.114

; <<>> DiG 9.9.4 <<>> paypal.com +dnssec @114.114.114.114
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 12717
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;paypal.com. IN A

;; ANSWER SECTION:
paypal.com. 300 IN A 66.211.169.3
paypal.com. 300 IN A 66.211.169.66

;; Query time: 577 msec
;; SERVER: 114.114.114.114#53(114.114.114.114)
;; WHEN: Tue Jul 15 21:49:57 CST 2014
;; MSG SIZE rcvd: 60

我们可以看到，支持DNSSEC的服务器多返回了一串非常长的RRSIG(Resource Record Signature)，这就是DNSSEC中非常重要的数据签名。
而不支持DNSSEC的服务器就完全没有返回这些信息了，由此我们可以很容易区分一台DNS服务器是否支持DNSSEC。
不过，目前配置了DNSSEC签名的域名非常少，据我所知一般有些国外政府域名有，当然paypal也有，而国内几乎没有（国内的支付宝并没有）。
如果一个域名本身就没有配置DNSSEC签名，那么无论你是通过什么样的DNS服务器查询dnssec数据，结果都是一样的。
那如果我们不知道哪些域名配置了DNSSEC签名，难道就无法验证DNS服务器是否支持DNSSEC了？
当然不是！我们有...
方法B：自残测试法！
由于当我们启用了Dnsmasq的dnssec–check–unsigned选项，Dnsmasq就会检查DNS返回的数据是否经过签名。（注意，这个签名是DNS服务器本身对发出的数据包的签名，用于证明这个数据包确实发送自我这个服务器且没有被修改，和域名本身是否有DNSSEC签名毫无关系。）
如果DNS服务器返回的数据包没有经过DNS服务器签名，那么Dnsmasq就会丢弃这个解析结果，因为启用这个选项后它只接受签名过的数据。
所以，做法就是：
把Dnsmasq的DNS设置为你要测试的那个DNS服务器（注意！只写这一个DNS，别的都不写）；
启用Dnsmasq的dnssec-check-unsigned选项；
域名解析验证。
如果你还可以解析域，说明这个DNS支持DNSSEC；如果你发现什么域名都解析不了了，那么就是因为这个DNS服务器不支持DNSSEC，导致Dnsmasq不信任返回的所有数据了。
国内目前支持DNSSEC的服务器，不能说稀少吧，只能说我一个都没发现。而国外的公共DNS，我们熟知的那些除了OpenDNS有它自己的一套DNScrypt加密体系而没有采用DNSSEC其他倒基本都是支持的。
我测试过支持DNSSEC的国外公共DNS如下：
Google Public DNS： 8.8.8.8 | 8.8.4.4
Norton DNS： 199.85.126.20 | 199.85.127.20
Comodo DNS： 8.26.56.26 | 8.20.247.20
DNS Advantage： 156.154.70.1 | 156.154.71.1
NTT DNS： 129.250.35.250 | 129.250.35.251
Verizon DNS： 4..2.2.1 | 4.2.2.2 | 4.2.2.3 | 4.2.2.5 | 4.2.2.6
目前，由于国内并没有支持DNSSEC的公共DNS，也几乎没有配置了DNSSEC签名的域名，因此CloudXNS暂无支持DNSSEC的打算。
不过，在未来产品优化提升足够美好的时候，不排除会率先在国内支持DNSSEC的可能。
原文系转载，出处：LifeTyper

DNSSEC

1  DNSSEC的背景和目的

域名系统（Domain Name System，DNS）是一些“Too simple, Too Naive”的互联网先驱者设计的，它象互联网的其他协议或系统一样，在一个可信的、纯净的环境里运行得很好。但是今天的互联网环境异常复杂，充斥着各种 欺诈、攻击，DNS协议的脆弱性也就浮出水面。对DNS的攻击可能导致互联网大面积的瘫痪，这种事件在国内外都屡见不鲜。

尽管DNS的安全问题一直被互联网研究和工程领域广为关注，但是有一种普遍存在的攻击却始终没有解决，即DNS的欺骗和缓存污染问题。DNS安全扩 展（DNS Security Extension, 即DNSSEC）主要是为了解决这一问题而提出的（尽管它还有其他用途）。因此，在介绍DNSSEC的原理之前有必要简单介绍DNS欺骗和缓存污染攻击的 原理。

1.1   DNS欺骗攻击和缓存污染

用户在用域名（www.example.com）访问某一个网站时，用户的计算机一般会通过一个域名解析服务器（Resolver Server，也称递归服务器（Recursive Server））把域名转换成IP地址。解析服务器一般需要通过查询根域名服务器（root）、顶级域名服务器（TLD）、 权威域名服务器（Authoritative Name Server），通过递归查询的方式最终获得目标服务器的IP地址，然后交给用户的计算机。在此过程中，攻击者都可以假冒应答方（根、顶级域、权威域、或 解析服务器）给请求方发送一个伪造的响应，其中包含一个错误的IP地址。发送请求的用户计算机或者解析服务器很傻、很天真地接受了伪造的应答，导致用户无 法访问正常网站，甚至可以把重定向到一个伪造的网站上去。由于正常的DNS解析使用UDP协议而不是TCP协议，伪造DNS的响应报文比较容易；如果攻击 者可以监听上述过程中的任何一个通信链路，这种攻击就易如反掌。

更加糟糕的是，由于DNS缓存（Cache）的作用，这种错误的记录可以存在相当一段时间（比如几个小时甚至几天），所有使用该域名解析服务器的用户都无法访问真正的服务器。攻击者可能是黑客、网络管理者等等（比如利用用户的拼写错误，把对不存在域名NXDOMAIN的访问重定向到一个广告页面），但本文不去讨论这些攻击者的身份和动机。

1.2   DNSSEC的目标、历史和意义

上述攻击能够成功的原因是DNS 解析的请求者无法验证它所收到的应答信息的真实性，而DNSSEC给解析服务器提供了防止上当受骗的武器，即一种可以验证应答信息真实性和完整性的机制。 利用密码技术，域名解析服务器可以验证它所收到的应答（包括域名不存在的应答）是否来自于真实的服务器，或者是否在传输过程中被篡改过。

尽管从原理上来说DNSSEC并不复杂，但是从1997年第一个有关DNSSEC的标准RFC 2065 [2] 发布至今已经十多年了，直到最近一两年才有了可观的进展。1999年IETF对DNSSEC标准进行了修订RFC 2535[3]，但很快被证明这次修订是失败的。直到2005年，一个可用的DNSSEC标准才制定出来（RFC 4033-4035）[4][5][6]，目前主流域名服务软件（如BIND ）实现的也是这一版本。2008年，IETF又发布了一个NSEC3（RFC5155）[7]标准，以提高DNSSEC隐私保护能力。 随着DNSSEC的推广，也许还会有一些新的问题和新的修订，DNSSEC标准仍在发展过程中。

尽管DNSSEC的目标仅限于此（即不保护DNS信息的保密性和服务的可用性），但是，DNSSEC的成功布署对互联网的安全还有其他好处，比如提高电子邮件系统的安全性，甚至把DNS作为一个公钥基础设施（PKI）。

本文所介绍的DNSSEC工作原理基于RFC 4033-4035，关于DNS工作原理、配置和数字签名技术超出了本文的范围，感兴趣的读者可以参考[8]。在此基础上简单介绍最常用的域名服务系统 （BIND）的基本配置过程，最后DNSSEC在国际上的布署情况以及可能给网络安全带来的影响。

2  DNSSEC原理

简单的说，DNSSEC依靠数字签名保证DNS应答报文的真实性和完整性。权威域名服务器用自己的私有密钥对资源记录（Resource Record, RR）进行签名，解析服务器用权威服务器的公开密钥对收到的应答信息进行验证。如果验证失败，表明这一报文可能是假冒的，或者在传输过程、缓存过程中被篡 改了。 RFC 4033概要介绍了DNSSEC所提供的安全功能并详细介绍了相关的概念，下面通过一个简化的实例介绍DNSSEC的工作原理 。

如图2所示，一个支持DNSSEC的解析服务器（RFC4033中Security-Aware Resolver）向支持DNSSEC的权威域名服务器（Security-Aware Name Server）请求域名www.test.net.时，它除了得到一个标准的A记录（包含IPv4地址）以外，还收到一个同名的RRSIG记录，其中包含 test.net这个权威域的数字签名，它是用test.net.的私有密钥来签名的。为了验证这一签名的正确性，解析服务器可以再次向test.net 的域名服务器查询响应的公开密钥，即名为test.net的DNSKEY类型的资源记录。然后解析服务器就可以用其中的公钥验证上述 www.test.net. 记录的真实性与完整性。

图2 DNSSEC基本工作原理

但是，解析服务器如何保证它所获得的test.net.返回的公开密钥（DNSKEY记录）是真实的而不是假冒的呢？ 尽管test.net.在返回DNSKEY记录的同时，也返回对这个公钥的数字签名（名为test.net的RRSIG记录）；但是，攻击者同样可以同时 伪造公开密钥和数字签名两个记录而不被解析者发现。

象基于X509的PKI体系一样，DNSSEC也需要一个信任链，必须有一个或多个开始就信任的公钥（或公钥的散列值），在RFC 4033中称这些初始信任的公开密钥或散列值为“信任锚（Trust anchors）”。信任链中的上一个节点为下一个节点的公钥散列值进行数字签名，从而保证信任链中的每一个公钥都是真实的。理想的情况下（DNSSEC 全部布署），每个解析服务器只需要保留根域名服务器的DNSKEY就可以了。

在上面的例子中，假设解析服务器开始并不信任test.net.的公开密钥， 它可以到test.net.的上一级域名服务器net.那里查询test.net.的DS（Delegation Signer， 即DS RR）记录，DS RR中存储的是test.net. 公钥的散列值（比如用SHA-1算法计算得到的160比特数据的16进制表示）。假设解析服务器由管理员手工配置了.net的公钥（即Trust Anchor），它就可以验证test.net.公钥（DNSKEY）的正确与否了。

 

摘自：http://blog.chinaunix.net/uid-7210505-id-3344641.html