《信息安全技术 安全域名系统实施指南》

ICS35.040

L80

中华人民共和国国家标准

GB/TXXXXX—XXXX

信息安全技术

安全域名系统实施指南

Informationsecuritytechnology—

Securedomainnamesystemdeploymentguide

（征求意见稿）

（在提交反馈意见时，请将您知道的相关专利连同支持性文件一并附上）

XXXX-XX-XX发布XXXX-XX-XX实施

GB/TXXXXX—XXXX

前言

本标准按照GB/T1.1-2009给出的规则起草。

本标准由全国信息安全标准化技术委员会（SAC/TC260）提出并归口。

本标准起草单位：

本标准主要起草人：

II

GB/TXXXXX—XXXX

信息技术安全技术安全域名系统实施指南

1范围

本标准为组织实施一个安全的域名系统提供DNS主机环境安全、DNS事务安全、DNS数据安全和DNS

安全管理方面指南。本标准可作为组织内部域名系统安全管理人员的指导。

本标准适用于使用BIND1DNS域名服务软件的环境。在可能的情况下，本标准还可用于使用其他

DNS权威软件包如NSD和MicrosoftWindowsServer域名服务软件的环境。

2规范性引用文件

下列文件对于本文件的应用是必不可少的。凡是注日期的引用文件，仅注日期的版本适用于本文件。

凡是不注日期的引用文件，其最新版本（包括所有的修改单）适用于本文件。

GB/T5271.8-2001信息技术词汇第8部分：安全（ISO/IEC2382-8:1998，IDT）

GB/T5271.9-2001信息技术词汇第9部分：数据通信（ISO/IEC2382-9:1995，EQV）

GB/T25069-2010信息安全技术术语

YD/T2586-2013域名服务系统安全扩展(DNSSEC)协议和实现要求

3术语和定义

GB/T5271.8-2001、GB/T5271.9-2001、GB/T25069-2006-2010中界定的以及下列术语和定义适

用于本文件。

3.1

域名系统domainnamesystem

将域名映射为某些预定义类型资源记录（ResourceRecord）的分布式互联网服务系统，网络中域

名服务器间通过相互协作，实现将域名（或者其他的查询对象）最终解析到相应的资源记录。

[修改自YD/T2135-2010，定义3.1.1]

3.2

名字空间namespace

一种节点与资源集合相对应的树状结构（如图1所示）。

[修改自YD/T2135-2010，定义3.1.2]

1Bind是使用最广泛的DomainNameServer，原本bind的版本一直在4.8.x-4.9.x，后经过功能大幅度改进，并修复

漏洞发展到8.1.x。现在bind有两个版本在同时发展，bind8.x和bind9.x，最新版本是8.3.3和9.2.1。

1

GB/TXXXXX—XXXX

图1域名系统名字空间示意图

3.3

域名domainname

域名系统名字空间中，从当前节点到根节点的路径上所有节点标记的点分顺序连接的字符串。

[修改自YD/T2135-2010，定义3.1.3]

3.4

域domain

域名系统名字空间中的一个子集，也就是树形结构名字空间中的一棵子树。

[修改自YD/T2135-2010，定义3.1.4]

3.5

顶级域topleveldomain

域名系统名字空间中根节点下最顶层的域。

[修改自YD/T2135-2010，定义3.1.5]

3.6

资源记录resourcerecord

域名系统中用于存储与域名相关的属性信息，简称RR。

[修改自YD/T2135-2010，定义3.1.6]

3.7

域名服务器nameserver

名字服务器

用于存储域名和资源记录及其他相关信息并负责处理用户的查询请求的服务器。

[修改自YD/T2135-2010，定义3.1.7]

3.8

区zone

域名系统名字空间中面向管理的基本单元。

2

GB/TXXXXX—XXXX

[修改自YD/T2135-2010，定义3.1.9]

3.9

权威服务器authoritativeserver

具有数据源功能的服务器。

[修改自YD/T2135-2010，定义3.1.10]

3.10

区文件zonefile

某个区内的域名和资源记录及相关的权威起始信息（StartofAuthority，SOA）按照一定的格式

进行组合构成的文件。

[修改自YD/T2135-2010，定义3.1.11]

3.11

主服务器masterserver

被配置成区数据发布源的权威服务器。

[修改自YD/T2135-2010，定义3.1.12]

3.12

辅服务器slaveserver

通过区传送协议来获取区数据的权威服务器。

[修改自YD/T2135-2010，定义3.1.13]

3.13

DNS事务dnstransactions

DNS事务类型包含4部分：DNS查询和响应、区传送、动态更新、DNS通报。

3.14

DNS查询和响应dnsquery/response

解析器与缓存域名服务器之间进行资源记录的查找与响应的过程。

3.15

区传送zonetransfer

将区的资源记录内容从主服务器向辅服务器传送的过程，用于实现主、辅服务期间的数据同步。

[修改自YD/T2135-2010，定义3.1.14]

3.16

动态更新dynamicupdates

实施现有域添加或删除个别的资源记录、为现有域删除一套特定的资源记录、删除现有域、新增一

个域的一个操作。

3.17

DNS通知报文dnsnotify

3

GB/TXXXXX—XXXX

当主DNS服务器的区文件发生变化时，主DNS服务器通知辅DNS服务器数据变化的手段。

3.18

递归服务器recursiveserver

本地域名服务器

缓存服务器

负责接受用户端（解析器）发送的请求，然后通过向各级权威服务器发出查询请求获得用户需要的

查询结果，最后返回给用户端的服务器。

[修改自YD/T2135-2010，定义3.1.15]

3.19

解析器resolver

向域名服务器发送域名解析请求，并且从域名服务器返回的响应消息中提取所需信息的程序。

[修改自YD/T2135-2010，定义3.1.16]

3.20

区签名密钥zonesigningkey

对权威域数据进行DNSSEC签名或验证的密钥对。

[修改自YD/T2586-2013，定义3.1.1]

3.21

密钥签名密钥keysigningkey

对区签名密钥对中的公钥进行数字签名或验证的密钥对。

[修改YD/T2586-2013，定义3.1.2]

3.22

DNS公钥（DNSKEY）DNSpublickey

存储权威域的公钥的资源记录。

[修改自YD/T2586-2013，定义3.1.3]

3.23

资源记录签名（RRSIG）resourcerecordsignature

存储DNS资源记录集的数字签名的资源记录。

[修改自YD/T2586-2013，定义3.1.4]

3.24

授权签名者（DS）delegationsigner

存储DNSKEY资源记录散列值的资源记录。

[修改自YD/T2586-2013，定义3.1.5]

3.25

信任锚trustanchor

4

GB/TXXXXX—XXXX

一个预先配置的DNSKEY资源记录或者DNSKEY资源记录的散列值（DS资源记录），可以作为信任链的

起始点。

[修改自YD/T2586-2013，定义3.1.6]

3.26

信任链authenticationchain

一个由DNSKEY和DS资源记录交替组成的序列。

[修改自YD/T2586-2013，定义3.1.7]

4缩略语

下列缩略语适用于本标准。

ACLAccessControlList访问控制列表

ccTLDCountryCodeTopLevelDomain国家代码顶级域名

DNSDomainNameSystem域名系统

DNSKEYDomainNameSystemKey域名系统密钥

DNSSECDomainNameSystemSecurityExtensionsDNS安全扩展

DSDelegationSigner授权签名者

FQDNFullyQualifiedDomainName完全合格域名

gTLDGenericTop-levelDomain通用顶级域名

HMACHash-basedMessageAuthenticationCode散列运算消息认证码

IETFInternetEngineeringTaskForce互联网工程任务组

KSKKeySigningkey密钥签名密钥

MACMessageAuthenticationCode消息认证码

NSECNextSecure下一个安全记录

NSEC3NextSecureversion3下一个安全记录第三版

NTPNetworkTimeProtocol网络时间协议

PKIPublicKeyInfrastructure公钥基础设施

RRResourceRecord资源记录

RRSIGResourceRecordSignature资源记录签名

SOAStartOfAuthority起始授权机构

TLDTopLevelDomain顶级域

TSIGTransactionSignatures事务签名

TTLTimeToLive生存时间

ZSKZoneSigningKey区签名密钥

5

GB/TXXXXX—XXXX

BINDBerkeleyInternetNameDomain伯克利互联网域名软件

NSDNameServerDaemon域名服务进程软件

5DNS主机环境-威胁、安全目标和保护方法

5.1主机平台威胁

DNS主机平台威胁主要包含如下：

a)操作系统、系统软件或DNS主机上的其他应用软件可能遭受攻击；

b)DNS主机的TCP/IP协议栈可能会受到洪水包攻击，造成通信中断。对应用层的攻击为发送大量

伪造的DNS查询，以压倒权威或解析域名服务器；

c)在DNS服务器的网络中，访问局域网的恶意组织可进行地址解析协议（ARP）欺骗攻击，破坏DNS

信息流；

d)因病毒、蠕虫或由缺乏文件级保护引起的未经授权的更改，用于通信的平台级配置文件被破坏，

导致DNS主机之间通信中断；

e)因病毒、蠕虫或由缺乏文件级保护引起的未经授权的更改，DNS特定的配置文件、数据文件和

包含加密密钥的文件被破坏，导致域名解析服务器不正常的运作；

f)同一局域网的恶意主机作为DNS客户端可拦截或改变DNS响应。这将允许攻击者将客户端重定向

到不同的网站。

5.2DNS软件威胁

DNS软件威胁主要包含如下：

a)DNS软件可能出现的漏洞如缓冲区溢出，导致拒绝服务；

b)DNS软件没有为配置文件、数据文件和包含签名密钥的文件提供足够的存取控制能力，以防止

未经授权的读取和更新配置文件。

5.3由DNS数据内容引起的威胁

由DNS数据内容引起的威胁主要包含如下：

a)不完全授权；

b)区漂移和区打击；

c)目标攻击信息。

5.4安全目标

保护DNS主机平台、DNS软件和DNS数据的共同目标是完整性和可用性。

5.5主机平台保护方法

保护DNS主机平台的方法如下：

6

GB/TXXXXX—XXXX

a)宜运行一个安全的操作系统；

b)宜安全配置/部署操作系统。

5.6DNS软件保护方法

保护DNS软件的最佳实践如下：

a)应运行最新版本的域名服务器软件，或安装适当补丁的早期版本；

b)应以受限权限运行域名服务器软件；

c)应隔离域名服务器软件；

d)应为每个功能建立一个专用的域名服务器实例；

e)应删除非指定主机的域名服务器软件；

f)应创建一个拓扑和地域分散的权威域名服务器以容错；

g)应通过在同一物理域名服务器的两个不同区文件或通过为不同的客户端隔离域名服务器以限

制IT资源信息暴露。

5.7DNS数据内容管理-保护方法

通过分析安全暗示的内容，制定检验此类内容存在的完整限制，应验证区文件数据以满足限制来完

成区文件中不良内容的管理。

6DNS事务-威胁、安全目标和保护方法

6.1DNS查询/响应威胁和保护方法

DNS域名解析查询和响应通常涉及单一、无签名和无加密的UDP数据包。DNS查询/响应威胁主要包

含如下：

a)伪造或虚假的响应；

b)来自响应的一些资源记录的删除；

c)应用于区文件中通配符资源记录的不正确的扩展规则；

保护方法是应通过数据源认证、数据完整性验证以确保查询/响应安全。

6.2区传送威胁和保护方法

区传送在多个服务器中复制区文件以提供容错度，该容错度在DNS服务中由组织提供。区传送威胁

主要包含如下：

a)拒绝服务；

b)区传送响应信息可能被篡改。

保护方法是应通过验证签名记录和来自DNSSEC签名区的资源记录，以确保在区传送消息中对DNS

数据的保护。

6.3动态更新威胁和保护方法

7

GB/TXXXXX—XXXX

动态更新包含DNS客户端在权威域名服务器中实时改变区数据。动态更新威胁主要包含如下：

a)未授权的更新；

b)动态更新请求数据被篡改；

c)重复攻击。

保护方法是应通过相互验证、数据完整性验证以及时间戳签名，以确保动态更新安全。

6.4DNS通知报文威胁和保护方法

DNS通知报文是由主域名服务器发给辅域名服务器的消息，引起辅域名服务器启动更新操作并当区

更新发生时，执行区传送。

DNS通知报文威胁主要来自伪造的通知报文。

保护方法是应需配置辅助域名服务器以接收仅来自主域名服务器的DNS通知报文。

7DNS主机环境安全指南

7.1概述

DNS主机环境的安全配置可按照如下三类进行区分：

a)DNS主机平台安全；

b)DNS软件安全；

c)区文件的内容管理。

本标准主要用于使用BINDDNS域名服务软件的环境。在可能的情况下，本标准还可用于使用其他

DNS权威软件包如NSD和MicrosoftWindowsServer域名服务软件的环境。部分具体BIND配置命令清

单见附录A。

7.2DNS主机平台安全

运行域名服务器软件的平台主机的操作系统应进行安全加固。许多DNS平台运行于UNIX或Windows

平台。应保证：

a)已安装最新的操作系统补丁；

b)运行域名服务器软件的主机不应提供其他服务，仅配置用来响应DNS流量。

7.3DNS软件安全

保护DNS软件的方法应包含如下：

a)版本选择；

b)补丁安装；

c)使用受限特权运行；

d)在运行环境中限制其他应用程序；

e)为每个功能提供实例；

8

GB/TXXXXX—XXXX

f)控制安装软件的主机设置；

g)网络位置选择；

h)通过逻辑或物理的区文件数据隔离或为不同的客户端类型运行两个域名服务器软件实例，以限

制信息泄漏。

7.3.1运行最新版本的域名服务软件

当安装最新版域名服务器软件后，管理员应对配置参数进行必要的变更，以获得新安全特征。

不管运行新版本或较早版本，管理员均应关注组织运行环境中版本的漏洞、检测、安全修复和补丁。

7.3.2关闭版本查询

域名服务器应配置拒绝版本信息查询功能，以防止系统中运行域名服务器软件版本信息的发布。

7.3.3用受限特权运行域名服务软件

应以非特权用户的身份运行服务器软件，限制因文件损坏带来破坏性结果的目录访问。

7.3.4隔离域名服务软件

应保证DNS软件运行的平台中不包含除了必要的操作系统和网络支持软件以外的程序。因资源限制

很难实现时，应限制在同一平台上运行服务的数目。

7.3.5区分域名服务器功能

一个域名服务器实例可被配置为一个权威域名服务器、一个解析域名服务器或同时配置。解析域名

服务器应运行与权威域名服务器不同的安全策略，域名服务器实例应配置为权威域名服务器或解析域名

服务器。

权威域名服务器仅提供具有权威信息的区域名解析。安全策略应关闭权威域名服务器的递归功能，

以防止权威域名服务器发送查询到其他域名服务器，从而使用响应信息构建缓冲。禁用此项功能，可消

除对权威服务缓冲中毒威胁，同时防止反射式DDoS攻击。

解析域名服务器仅为内部客户端提供解析服务，解析域名服务器的保护措施应通过域名服务器软件

配置文件中的各种配置选项，以限制其与指定客户端交互类型来确保。

7.3.6从非指派主机中删除域名服务软件

DNS软件不应运行于未指派为域名服务器的主机中，应在未作为域名服务器的主机中删除DNS软件。

7.3.7权威域名服务器网络和地域分散

企业权威域名服务器应网络和地理位置分散，基于网络的分散应确保全部域名服务器不在单一路由

或交换设备、单一子网或单一租用线路下。地理分散应确保全部域名服务器不在同一地理位置，至少应

在外部部署一台备份服务器。

使用一台隐藏的主机时，隐藏的主权威服务器应仅接受来自辅助区域名服务器设置的区传送要求，

9

GB/TXXXXX—XXXX

并且拒绝其他的DNS查询。该隐藏主机的IP地址不应出现在区数据库设置的域名服务器中。

7.3.8通过区文件的分割限制信息发布

应用DNS分割，宜存在两个最小的物理文件或视图。其中一个在防火墙内部专门为主机提供域名解

析，它同时可包含防火墙外部主机的RRsets。另一个文件为防火墙外部或DMZ区的主机提供域名解析，

不包括防火墙内部主机。

7.3.9通过不同客户端的独立域名服务器限制信息发布

针对不同类型的客户端，组织应使用两种不同权威域名服务器设置，一种设置称为外部域名服务器，

放置于DMZ区域，对外部客户端可用，服务于公共服务主机相关RRs。另一种设置称为内部域名服务器，

放置于防火墙以内，对内部客户端可用。两种架构选择的目的是保护内部主机IP地址不被外部知道。

7.4区文件内容管理

DNS区文件内容管理的唯一的保护方法是使用区文件集成检测器。集成检测器对区文件的检测依赖

于检测器中数据库的约束。部署过程中应以正确的逻辑创建约束，这些逻辑描述的实际值不同于

RRTypes格式中关键字段的参数值。

8DNS事务安全指南

8.1概述

本章介绍应用各种类型DNS事务的威胁、安全目标和保护方法的步骤，同时包含应用方法的最佳实

践。内容如下：

a)基于IP地址限制事务实体；

b)通过基于散列的消息认证码保护事务；

c)通过非对称数字签名保护事务（即DNSSEC详述，见第9章）。

8.2基于IP地址限制事务实体

部分DNS域名服务器应用程序，如BIND9.X提供访问控制声明，通过该声明可以进入指定DNS事

务处理的主机，通过声明中的IP地址或IP子网掩码（称为IP前缀）可以识别主机。

包含IP地址和/或IP前缀的列表称为地址匹配列表。地址匹配列表被用作BIND控制文件中各种访

问控制声明的控制语句。针对各种DNS事务有独立的访问控制声明，访问控制声明的语法如表1所示：

表1DNS事务访问控制语法

存取控制语句语法DNS事务

允许查询｛address_match_list｝DNS查询/响应

允许递归｛address_match_list｝递归查询

允许传送｛address_match_list｝区传送

10

GB/TXXXXX—XXXX

允许更新｛address_match_list｝动态更新

允许更新发送｛address_match_list｝动态更新

允许通知｛address_match_list｝DNS通知

黑洞｛address_match_list｝黑名单中的主机

8.2.1限制DNS查询/响应事务主体

访问控制列表可用于替代控制声明中的IP地址/IP前缀。

访问控制声明中地址匹配列表参数可包含的值如下：

a)IP地址或IP地址列表；

b)IP前缀或IP前缀列表；

c)访问控制列表（ACLs）；

d)上述三项的组合。

ACLs的定义在DNS事务限制的配置中是关键元素，DNS管理员应根据不同的DNS事务定义并创建

ACLs。

宜为每一个不同类型的DNS事务创建一个指定的可信主机列表。应被包含到适当的ACL中的主机角

色类别如下：

a)DMZ主机；

b)所有允许发起区传送的辅助域名服务器；

c)允许运行递归查询的内部主机。

除了IP地址、IP前缀或ACL，访问控制声明中的地址匹配列表参数应设置如下特定值：

a)None：不匹配任何主机；

b)b）Any：匹配全部主机；

c)Localhost：匹配运行域名服务的全部服务器IP地址；

d)Localnets：匹配运行域名服务的全部服务器IP地址和子网掩码。

密钥可被应用到ACL声明中，这表示只有知道共享密钥（或密钥对）的主机才能够进行通讯。

限制递归查询

a)通过服务器限制对内部主机IP地址指定集合的所有可接受的查询，设置该集合应用于授权区，

这样任何DNS客户端可以在区内获得资源信息；

b)通过直接配置参数将递归查询限制到指定的内部客户端IP地址集中；

c)通过定义视图将不同的响应（数据）提供给不同客户端。

8.2.2限制区传送事务实体

权威域名服务器应使用允许传递的访问控制子声明进行配置，指定可接受区传送请求的主机列表。

来自主域名服务器的区传送应限于辅助域名服务器。在辅助域名服务器中区传送应被完全禁用。允许传

11

GB/TXXXXX—XXXX

输子声明的地址匹配列表值应由辅助域名服务器和隐藏辅助域名服务器的IP地址组成。

允许传输子声明可在区声明和参数声明中使用。当它在区声明中使用时，可限制该区传送；当在参

数声明中使用时，可限制域名服务器中所有区的区传送。

8.2.3在NSD中限制区传送

NSD有一套类似的工具限于区传送仅选定一套辅助服务器。管理员应学习和使用在NSD配置文件中

的可用选项。无法创建访问控制列表（ACLs），但管理员可将区声明中辅助服务器的独立IP地址列在

NSD配置文件中。

在配置文件中，provide-xfr声明用于nsd.conf文件的区声明中，类似于一个联合声明和在BIND

配置文件中允许传送的声明。

zone:

#allowtransferfromsubnet

provide-xfr:/24

#preventtransferfromspecificIPaddressinblock

Provide-xfr:6BLOCKED

仅有一个地址应出现在provide-xfr声明中，但地址可以是一个完整的子网。provide-xfr声明允

许传送；所有其他的传送请求默认被拒绝。

8.2.4动态更新事务实体限制

通过BIND中的两个声明可以启动或限制动态更新，声明如下：

a)允许更新；

b)更新策略（仅在BIND9版本中可用）。

这些声明仅在区级而不是服务器级中设定，是区声明中的子部分。允许更新子声明启用基于IP地

址和共享密钥技术限定动态更新的规则。

更新策略声明仅启用基于TSIG密钥技术的动态更新限制规则，在更细粒度层面启用更新限制规则。

允许更新子声明包含对区全部记录访问权限的更新。更新策略子声明可用来限制一个或多个RRTypes

访问权限的更新。

动态更新请求通常由主机发起，例如为主机动态分配IP地址的DHCP服务器。当指派一个IP地址

到一个新的主机，需将FQDN-to-IP地址表和address-to-FQDN地址表信息存储到区内主权威域名服务

器中，该信息的创建通过动态更新实现。

8.2.5限制BINDDNS通告事务实体

在服务器间启动区传送，宜通过消息告知辅助域名服务器区文件数据的变更。此项配置将允许更新

快速传输到辅助域名服务器，DNS管理员应保持通告可用。DNS管理员需为特定区域关闭此功能时，应

在该区的区声明中使用通告子声明。

12

GB/TXXXXX—XXXX

区管理员需将DNSNOTIFY消息发送到附加的服务器时，“also-notify”子声明应被增加到区声明

中，同时应指定附加服务器的IP地址作为参数值。

DNSNOTIFY消息的接收方，即辅助域名服务器，默认仅允许来自主域名服务器的通告消息。辅助

域名服务器希望接受额外服务器的通告消息时，应在区声明中增加“allow-notify”子声明，服务器的

IP地址应在该子声明中指定。

8.2.6限制NSDDNS通告事务实体

管理员可使用两项声明来传输DNSNOTIFY消息或者限制监听DNSNOTIFY消息到一个特定的IP地

址。

配置NSD以传输DNSNOTIFY消息到特定的IP地址和特定的TSIGkey，或者没有TSIG可用的情况

下，选择NOKEY。在NSD配置文件中的声明块被添加到区中，如下：

Zone:

Notify:0NOKEY

在区中的一个辅助服务器配置声明：声明IP地址接受DNSNOTIFY消息的块，如下：

zone:

allow-notify:3NOKEY

8.3基于散列消息认证码的事务保护

利用散列消息认证码验证消息来源和完整性的流程由TSIG的DNS规则指定。

通过HMAC使用共享密钥进行事务保护并不是可扩展的解决方案，TSIG规范仅在区传送和动态更新

事务中广泛应用。这些DNS事务在相同管理域中的服务器间或在前期建立的交互域中的服务器间。

通过DNS消息发送方生成的MAC或散列值被放置于追加到DNS消息中称作TSIGrecord的新RR中。

TSIG记录，除了生成的散列值外，包含内容如下：

a)散列算法的名称；

b)密钥名称；

c)生成散列的时间（时间戳）；

d)“Fudgefactor”。

为了避免攻击者捕获包含MAC的数据包进行延迟发送，接收者应读取MAC生成时间和当前时间，通

过fudgefactor计算，验证MAC是否在允许有效时间内生成。

Fudgefactor字段指定MAC生成时间后的持续时间，通过对MAC生成时间进行“Fudgefactor”

计算获得MAC生成方和验证方主机的允许时间偏差。

验证过程包括接收者找到匹配密钥，生成所接收DNS消息的散列值，与接收到的散列值进行比较。

在此过程中，接收的域名服务器执行以下验证：

a）消息验证来自一个授权来源；

b）消息传递过程中未被修改。

13

GB/TXXXXX—XXXX

建立使用TSIG来启用DNS事务的环境，需如下操作：

a)处理DNS事务的域名服务器系统时钟必须同步；

b)应具有密钥生成程序生成所需长度的密钥，密钥文件应在参与事务处理的两个服务器间安全传

输；

c)密钥信息应通过适当的声明在配置文件中指定。

8.3.1密钥生成

通过验证消息启用区传送，应为每一对域名服务器生成密钥。密钥同样被用于确保其他事务安全，

如动态更新、DNS查询和响应。DNSSEC通过多种密钥生成程序生成64位编码的二进制密钥字符串。BIND

9.X中生成密钥的程序是dnssec-keygen。

当程序生成密钥对时，扩展名key文件包含公钥字符串，扩展名private的文件包含私钥。

8.3.2在传送域名服务器中定义密钥

通过dnssec-keygen程序生成的密钥需在两个传送服务器的named.conf配置文件中定义。

8.3.3确定在NSD配置文件中的密钥

在NSD中，声明一个非常类似于8.3.2的TSIG密钥，包括一些小的语法变化。

8.3.4通知域名服务器在全部事务中使用密钥

通知服务器在全部事务中使用密钥的命令如下：

server{

keys{.;

};

相同的声明可作为acl声明的条目，如下：

aclkey_acl{

.;

};

8.3.5密钥文件创建和密钥配置流程

TSIG密钥长度最小应为112位。

应为每一对通信主机生成单独的TSIG密钥。

当密钥字符串复制到域名服务器的密钥文件之后，通过dnssec-keygen程序生成的两个文件应仅可

被服务器管理员账户访问，或者删除，文件的副本应被销毁。

密钥文件应在网络中安全传递到与生成密钥的域名服务器进行通信的域名服务器。

配置文件中定义TSIG密钥的声明不应直接包含密钥字符串。密钥字符串应在独立的密钥文件中定

义，通过在配置文件的密钥声明中包含地址进行引用。每一个TSIG密钥应有一个独立的密钥文件。

14

GB/TXXXXX—XXXX

密钥文件应被域名服务器运行的软件账户管理。授权位应被设置，这样密钥文件可被运行域名服务

器软件的账户读取或修改。

在一对服务器间用于签名消息的TSIG密钥应在进行通信的两个服务器声明中指定。应确保请求信

息和特定事务的事务信息被签名以保证安全。

在区中共享一个私钥的通信双方服务器的每一个配置文件中，双方通信所使用的密钥名称应被指

定。

8.3.6使用TSIG的安全区传送

区传送事务中的服务器通信双方应被引导使用通过密钥声明定义的密钥。通信双方通常包括主域名

服务器和辅助域名服务器。主域名服务器被配置仅接收与区传送请求消息一起的，来自使用命名密钥发

送MACs的辅助域名服务器的区传送请求。

在主域名服务器的区传送请求中，辅助域名服务器被设置使用密钥NS1-NS2.。

在NSD中，没有使用TSIG密钥时，区选项“provide-xfer”用来表明IP地址可要求服务器上的区

进行区传送。

8.3.7使用TSIG或SIG（0）的安全动态更新

基于TSIG的动态更新限制可在BIND8.2中设定，后续版本通过区声明中的allow-update子声明

实现。

字符串定义的是TSIG密钥。配置声明实例的应用是拥有名为

密钥的主机可允许主权威域名服务器中区文件的动态更新请求。

使用SIG（0）验证动态更新消息，所使用的密钥首先应具有存储在DNS的公钥，这样验证的客户

端可以获取该密钥，作为进行访问控制之前的步骤。在此之后，更新的域名服务器应获得密钥并处理动

态更新请求。

8.3.8使用TSIG密钥配置动态更新转发限制

BIND9.1.0及其后续版本允许辅助域名服务器接受动态更新请求，并转发到主权威域名服务器。

为避免对转发更新请求的辅助域名服务器主机未进行限制，BIND启用一个新的具有动态更新转发特征

的allow-update-forward子声明。

8.3.9使用TSIG/SIG（0）密钥细粒度动态更新

Allow-update子声明依据动态更新发起者设定动态更新限制，使用域/子域域名和RR类型关系进

行动态更新访问限制，BIND9和后续版本在区声明中提供update-policy子声明。update-policy子

声明使用TSIG密钥进行限制。

9安全的DNS查询/响应指南

9.1在BIND与NSD中配置DNSSEC

15

GB/TXXXXX—XXXX

应配置域名服务器来运行DNSSEC进程，该域名服务器用于部署DNSSEC签名区或查询区。DNSSEC

实施规范应按照YD/T2586-2013执行。

在BIND中，通过添加命令行到指定配置文件的选项中。

options{

dnssec-enableyes;

};

在NSD中，该选项不是必需的。

9.2DNSSEC机制和操作

DNSSEC机制包括两个主要过程：签名和验证。签名过程的首要任务是生成与区文件中的每个RR相

关联的数字签名，数字签名及其相关信息被封装在一个RRTypeRRSIG的特殊RR中，权威域名服务器利

用自己的私钥对RR进行签名。

在解析服务器用公钥验证与区中的RRsets相关签名之前，必须建立对该公钥的信任。在DNSSEC

中，解析服务器运行一个名为创建信任链的子进程来达到这一要求，利用权威服务器的公钥对收到的应

答信息进行验证。

DNSSEC进程包含域名服务器操作和解析器操作。

域名服务器操作如下：

a)公/私密钥对的生成；

b)私钥的安全存储；

c)公钥的发布；

d)区签名；

e)密钥更新（密钥的更改）；

f)区重签名。

解析器操作如下：

a)配置信任锚；

b)创建信任链和签名验证。

9.3公私密钥对的生成

DNSSEC应采用非对称密钥进行数字签名的生成和验证，推荐使用两种不同类型的密钥，一种是密

钥签名密钥（KSK），用于对区文件中的密钥集（DNSKEYRRSet）进行签名；另一种是区签名密钥（ZSK），

用于对区中的所有RRSets进行签名。

KSK和ZSK密钥对生成的决策参数如下：

a）数字签名算法；

数字签名算法应基于推荐标准算法，宜使用RSA非对称算法和SHA-1消息摘要算法；对于顶级域名

服务器，还应支持非对称算法SM2算法（256bits）和消息摘要算法SM3。

16

GB/TXXXXX—XXXX

b）密钥长度；

密钥长度的选择应为密钥安全性与执行效率的最佳平衡点，对KSK应加强密钥安全性，对ZSK应着

重加强效率。

c）加密周期。

加密周期长短取决于密钥暴露的风险大小，对KSK密码周期建议是1-2a，对ZSK密码周期建议是

1-3个月。

9.4私钥的安全存储

当域名服务器不支持动态更新时，ZSK和KSK相对应的私钥应保存在物理上安全、无网络访问的机

器上。支持动态更新时，与ZSK相对应的私钥应单独保存在域名服务器上，并且应具有适当的保护措施。

9.5公钥的发布和建立信任锚

DNSSEC-aware解析器要验证一个特定区的区数据，它首先应知道并信任该区或其任一父节点的公

钥。信任点应从该区到其父节点、父节点的父节点直到根区的节点中，靠近根区的安全的节点开始。

无论信任链的开始节点在哪里，DNSSEC-aware解析器相关联的域名服务器需知道开始节点的公钥。

在DNS中没有用于公钥认证的第三方的方式，公钥需通过其他程序进行分发。

DNSSEC-aware解析器的信任锚列表中的条目决定了来自一个区的签名后的应答是否安全。解析器

收到一个区发送来的应答，在执行签名验证之前，应首先对该区的公钥建立信任。必须通过信任列表中

的记录建立起一个信任链的方式建立信任，应答才是安全的。

9.6区签名

当签名区文件时，应采取以下操作：

a)将区文件按照域名规范的顺序进行排序；

b)为区中的每个所有者名称生成一个NSEC记录；

c)使用KSK为DNSKEY记录集生成签名。使用KSK生成的签名应以离线方式，利用离线存储的KSK

私钥或者安全、受保护的模块；然后DNSKEYRRSet与其RRSIGRR一起，被加载到主权威域名

服务器；

d)使用ZSK为域区中的所有记录集生成签名。

9.7信任链和签名验证的建立

父区通过子区公钥的散列值的数字签名保证其子区的真实性。该散列值存储在DSRR中，父区必须

是一个签名区。

根据信任链的缺失或存在，一个签名区可以是如下一种类型：

a）安全岛（自签名区）；

b）链式安全区。

对一个独立安全区的数字签名服务器保护的区数据包括以下基本任务：

17

GB/TXXXXX—XXXX

a）公钥/私钥对的产生；

b）私钥的安全存储；

c）在区文件中，DNSKEYRR分发公钥；

d）区数据（区签名）的数字签名的生成。

区安全链中的附加任务如下：

a)由一个安全区安全传输KSK给它的父区。完成这种带外传输可以不涉及任何域名系统处理；

b)父区把子区的KSK存储在一个特殊的密钥集目录中，为这个密钥产生一个散列值，将这个散列

值存储在DSRR中。父区为这个DSRR产生数字签名（RRSIGRR），将它包含到其他授权信息

中。

签名响应需要验证的区（例如，目标区）是信任链的叶节点。这个操作的先决条件是对区的ZSK

建立信任。通过以下操作，对一个区的ZSK建立信任：

a）父区的授权推荐；

b）子区KSK的授权。

在链式安全区的情况下父区的授权信息包括如下内容：

a）子区的NSRRs：这些NS记录的授权来源是子区，提供的NSRRs是暗示或推荐；

b）相关RRs：它们提供NSRRs（简称名字服务器的IP地址）中的特定服务器位置；

c）DSRR：它提供子区中KSK或者ZSK的散列值；

d）RRSIGRR：它包括DSRR（DSRR的签名）。

9.8域名系统查询/响应的附加保护措施

域名系统查询/响应处理的DNSSEC保护规范包括下列通信：

a）域名系统从远程权威域名服务器到局部解析域名服务器的响应；

b）域名系统从远程缓存域名服务器到局部解析域名服务器的响应。

域名系统响应信息的保护必须扩展到存根解析器以及解析的域名服务器路径,路径的保护方法是由

存根解析器的性质和网络设置决定的。

为了有完整的端到端的域名系统请求/响应保护，存根解析器类型的最低要求是应有执行原始授权

和响应数据完整性的能力。non-DNSSEC-aware存根解析器和DNSSEC-aware非验证的存根解析器应有这

种能力。non-DNSSEC-aware存根解析器可以利用此标记位为提示，找到解析域名服务器是否能够成功

确认在响应的回复和授权部分所有数据的签名。DNSSEC-aware非验证的存根解析器可以利用这个可信

路径来检查它接收的响应信息的头信息中AD位的设置。（与前面的non-DNSSEC-aware存根解析器和

DNSSEC-aware非验证存根解析器相对应。）

9.9DNSSEC-aware区的动态更新

第6.3节列出了一个区文件在动态更新过程中的各种逻辑操作。四种逻辑操作可被看作两种基本的

操作即：RR的增加和RR的删除。更新RR是增加和删除两个基本操作的组合。在非安全区的区文件中

18

GB/TXXXXX—XXXX

增加和删除RR不会对其他RRs有额外的操作。然而，在安全区中有个NSECRR（和一个相应的RRSIGRR）

来覆盖域名空间中的缺口。

在区中，每个唯一的所有者名称有一个NSECRR。这个NSECRR指向在规范顺序中的下一个所有者

名称。在规范顺序中的NSECRR的最后一个所有者指向区的顶端域名。所以，在一个区中，NSECRRs

在概念上形成一个循环的链接链表遍历唯一的区名称。

10通过DNS数据内容管理最小化信息泄漏指南

10.1选择SOARR中的参数值

SOA资源记录中的数据值可以规范主服务器和辅服务器之间的通信，应保证SOA资源记录中数据值

的正确性。具体值为：

区SOARR的刷新值应参考可预见的刷新频率。区签名时，刷新值应小于RRSIG的有效期。

区SOARR的重试值应是刷新值的1/10。

区SOARR的终止值应是2—4周。

最小TTL的值应在30min到5d之间。

10.2RRType中的信息泄漏

DNS管理员应注意对攻击者有利的HINFO、RP、LOC或者其他可能泄露信息的RR类型，以及使用分

离式DNS时区的外部试图。除了支持操作策略，应尽量避免使用这些RR类型。

DNS管理员在将TXT资源记录添加到区文件之前，应检查记录中可能出现的信息泄漏数据。

10.3使用RRSIG有效期最小化密钥泄漏

涉及一个区的DNSKEY资源记录集的RRSIG的有效期范围应是2d到1周。对于一个拥有授权的子域，

涉及DS资源记录的RRSIG的有效期范围应是几d到1周。DNSSEC管理员可根据内容管理和DNSSEC工

具为区的全部内容选择一个签名有效期。

DNS管理员应选择一个单一的对整个区有效的签名。同时，当密钥泄漏或需紧急更新时，DNS管理

员应选择一个能够最大限度地减少风险的签名有效期。

10.4散列认证否定存在

NSEC3资源记录包含下一个名称、资源记录类型位图以及迭代和盐值。迭代和盐值两个值应定期更

改以维持区列举的保护。

一个区使用NSEC3资源记录签名，当区完全重签名时，盐值应改变。盐值应是随机的，且长度应

足够短，宜选择1到15个字节，以防止FQDN对于DNS协议而言太长。

一个区使用NSEC3资源记录签名，迭代值的选取应根据提供给客户和攻击者可用的计算能力。该

值应每年进行审查，并且当评估条件的变化时增加。使用SHA-1时，初始值应在1—200次之间；使用

SHA-256时应在1—100次之间。

19

GB/TXXXXX—XXXX

11DNS安全管理操作指南

11.1组织密钥管理实践

DNS是一个企业基础设施的重要组成部分，处理密钥管理的DNSSEC操作应符合由企业保持的覆盖

其他数据认证密钥的策略。

11.2计划的密钥更新（密钥的生命周期）

密钥在使用一段时间之后易被破解，必须改变ZSK和KSK。

KSK更新频率应小于ZSK。KSK应每1-2y更新一次，ZSK应每1-3月更新一次。

11.2.1局部独立安全区的密钥更新

在新密钥用来签名之前，DNS管理员需公开这个密钥作为区文件的一个DNSKEYRR。

预先公开公钥的安全区应在密钥更新之前的至少一个TTL时间段内执行。

在删除旧公钥后，区应基于区文件中剩余密钥生成一个新签名。

11.2.2信任链连接安全区的密钥更新

一个全局的安全区使用两种密钥集：ZSK和KSK。

11.2.3链式安全区的ZSK密钥更新

在全局可信区涉及ZSK更新的操作与在局部安全区ZSK更新的操作没有差异。

11.2.4链式安全区的KSK密钥更新（手动无撤销位）

KSK是为安全区的安全父域提供信任的密钥，当一个区改变它的KSK时，KSK更新的区应：

a）生成一个新的KSK，并添加到区密钥集中；

b）用新KSK和旧KSK对区密钥集签名；

c）使用父域可以验证的方式联系新KSK及其父域；

d）父域必须生成新的包含新KSK散列值的DSRR，然后对最新生成的DSRR签名。

11.2.5链式安全区中的KSK密钥更新（使用撤销位）

KSK更新过程如下所述：

a)管理员添加新的KSK，但是不用它生成签名；

b)等待一个预计算时间，宜为30d；

c)在即将传出的KSK处设置撤销位，并用KSK密钥签署DNSKEYRRset。授权父域用新的KSK散

列值添加一个新的DS；

d)等待一个预计算时间，宜为30d；

e)删除旧KSK，仅使用新KSK重签名。联系授权父域删除旧KSK相应的DSRR。

11.3紧急密钥更新

20

GB/TXXXXX—XXXX

当区中密钥泄漏或者私钥丢失时，应执行紧急密钥更新和重签名。

11.3.1紧急ZSK更新

目前使用的ZSK已经泄漏时，区管理员应立刻更新到新密钥。

新ZSK已经泄漏时，在区密钥集中应立即替换它。

一旦ZSK泄漏，区管理员应尽快初始化KSK更新。

11.3.2紧急KSK更新

执行一个紧急KSK更新时，DNS管理员应有紧急联络信息，以供上一层父域区使用。

在紧急子域子区KSK更新时，父域区必须具有一个紧急联络方式，可用于它的授权子域子区，也应

有一个获取子区新KSK的安全方式。

应将泄露期缩短到最少，使区管理员可以尽可能短地保留有效期间签名。

11.4重签名区

在以下情况下，区文件应重签名。

a）签名已经到期或即将到期；

b）区文件的内容已经改变；

c）一个签名密钥已经泄露或者计划更换。

有两种策略可以重签名区数据：

a)完全重签名。删除所有现有的签名记录，重新排序区文件，重新生成所有的NSECRRs，最后

生成新的签名记录；

b)增量式重签名。当区文件内容的变化自上次生成签名以后已经最小化时，通常在动态更新后的

情况下使用增量式重签名。

11.5DNSSEC算法的迁移

当转换到一个新的DNSSEC算法时不宜在转换的同时进行其他密钥维护操作。管理员选择在扩展时

间周期内使用两个签名算法来操作时，宜错开密钥维护操作。

当转换完成后，验证器无法验证由未知算法生成的RRSIGs时，区变得可证不安全，不理解新算法

的终端用户验证器应采取行动。

11.5.1使用多重签名算法的密钥更新特别注意事项

区管理员必须保持两个不同的密钥生存期，即在发行当前ZSK的同时提前发行下一个ZSK。一个

区的密钥集中将有三个DNSKEYRRS：一个激活的KSK，一个激活的ZSK，以及一个提前发行的ZSK。

宜错开密钥更新以减少在区中预发行的密钥数量。

11.6DNSSEC在分割区的部署

11.6.1理想解决办法：内部授权

21

GB/TXXXXX—XXXX

部署水平分割的域名系统或者重新设计一个企业域名系统宜从主区选择一个新的内部唯一授权。