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

部署水平分割的域名系統或者重新設計一個企業域名系統宜從主區選擇一個新的內部唯一授權。