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

时间: 2024-10-08 22:21:28

DNSSEC的相关文章

BIND简易教程(3):DNSSec配置

目录:BIND简易教程(1):安装及基本配置BIND简易教程(2):BIND视图配置BIND简易教程(3):DNSSec配置 (本篇) DNSSec,有个半英半中的名字叫DNS安全扩展.说的好听一点,它是对域名进行签名认证,保证域名的完整性和正确性,不会被修改.DNSSec不能防御对DNS服务器的攻击,也不会对请求和应答的数据进行加密,甚至如果你不知道DNSSec这个东西的话,域名是不是完整正确的你也不知道. 实际上,给我的感觉就是,DNSSec是在花很大的力气去配置一个不怎么有用的东西.然并卵

使用TSIG 和DNSSEC 技术加固DNS 服务器

一.DNS 服务器的重要性 DNS 是因特网建设的基础,几乎所有的网络应用, 都必须依赖 DNS 系统做网址查询的指引动作.如果DNS 系统运作不正常, 即使Web 服务器都完好如初, 防火墙系统都善尽其职, 相关的后端应用服务器以及数据库系统运作正常, 因为无法在期限时间内查得到网址, 将会导致电子邮件无法传递, 想要使用网域名称去连接某个网页, 也会因查不出网络地址, 以致联机失败.2001年1月24日, 美国微软公司所管理的相关网络系统, 遭受网络黑客的拒绝服务攻击后导致全球各地的用户接近

DNS BIND之dnssec安全介绍

Domain Name System Security Extensions (DNSSEC)DNS安全扩展,是由IETF提供的一系列DNS安全认证的机制(可参考RFC2535).它提供了一种来源鉴定和数据完整性的扩展,但不去保障可用性.加密性和证实域名不存在.DNSSEC是为解决DNS欺骗和缓存污染而设计的一种安全机制.开发DNSSEC技术的目的之一是通过对数据进行数字“签名”来抵御此类攻击,从而使您确信数据有效.但是,为了从互联网中消除该漏洞,必须在从根区域到最终域名(例如, www. ic

DNS

####DNS总揽 #######DNS资源记录 DNS 区域采用资源记录的形式存储信息.每条资 源记录均具有一个类型 , 表明其保留的数据类型 – A : 名称至 IPv4 地址 – AAAA : 名称至 IPv6 地址 – CNAME : 名称至 "规范名称 " ( 包含 A/AAAA 记录的另 一个名称 ) – PTR : IPv4/IPv6 地址至名称 – MX : 用于名称的邮件交换器 ( 向何处发送其电子邮件 ) – NS : 域名的名称服务器 – SOA :"

Linux运维面试题及解答(二)

1.描述centos6系统开机启动流程: 1.1加载BIOS的硬件信息与进行自我测试,并依据设置取得第一个可启动的设备: 1.2读取并执行第一个启动设备内MBR的boot Loader(即是grub,spfdisk等程序): 1.3依据bootloader的设置加载Kernel,Kernel会开始检测硬件与加载驱动程序: 1.4在硬件驱动成功后,Kernel会主动调用init进程,而init会取得run-level信息: 1.5init执行/etc/rc.d/rc.sysinit文件来准备软件执

DNS(域名系统)与BIND(Berkeley互联网名称域)

一直以来对浏览器地址栏输入的地址有极大的困惑,为什么输入的是www?为什么结尾是.com?为什么要用"."来分隔三部分(大多数情况下)?好吧,大学后才知道,这东西学名是叫域名,而不是网民称的网址什么的:域名让我们更方便的访问,而不是要死记住那一大串的数字:ip地址: 一.先认识一下这个名称域,也可以叫ta名称空间,在空间上形象的把ta看作一棵倒置的树,数据结构里的树形结构知道吧,就跟那差不多的样子: 比如www.baidu.com 根域(.)在最后被省略不写,com是它的顶级域,bai

DNS and BIND

DNS服务器,为了获取目标IP地址,从而达到目标区域的服务器:DNS服务器可以手动指定IP地址从而将IP地址转化为域名进行访问,也可以通过域名转化为IP地址进行访问:就像我们平常使用的www.baidu.com,就是可以通过域名解析成IP地址进行访问的:那么这类域名是如何找到这个域名所表示的主机呢:我们通过访问域名或IP地址得出对应的IP地址或域名来进行访问,那这些海量的数据都是保存在哪,若都是保存在一个服务器中,这些海量的数据,要通过一个服务器去查找那效率是非常底下且不实用的:所以加州大学的伯

11111

一.逆向bof 按ESC键 :%!xxd         将显示模式切换为16进制模式 /e8d7         查找要修改的内容,/后面是要查找的内容 ESC+I键       可在文档中插入语句(insert) ESC+R键      字母替换 :%!xxd -r       转换16进制为原格式 :wq            存盘退出vi l  gdb调试程序 gdb 可执行文件名            进入调试 r                            run,执行程序

DNS服务器介绍(一)——创建DNS正反解析区域

背景介绍 DNS服务作为互联网上一个基础服务承担着将用户请求的名称转换成对应的IP或将IP转换为名称的功能.DNS实际上是将互联网上所有主机的FQDN以"."分割成若干个区域,每一个区域都有特定的主机来进行管理.以正向解析为例:当用户发起对www.contoso.com名称的解析请求时,本地DNS服务器会先查询缓存内是否有该名称的IP,如果没有此时就分为两种情况: 当客户端向本地的DNS服务器发起请求时(1),如果本地DNS服务器不允许递归查询,他会立即向客户端反馈找不到该名称对应的I