YD/T 2908-2015
基本信息
标准号： YD/T 2908-2015
中文名称：基于域名系统(DNS)的 IP 安全协议认证密钥存储技术要求
标准类别：通信行业标准(YD)
标准状态：现行
出版语种：简体中文
下载格式：.zip .pdf
下载大小：2849398
相关标签： 基于 域名 系统 安全 协议 认证 密钥 存储技术
标准分类号
关联标准
出版信息
相关单位信息
标准简介
YD/T 2908-2015.Technical requirements for DNS-based IP Sec keying material storage.
1范围
YD/T 2908规定了一种基于DNS的IPSec认证密钥及加密点信息存储方法，该方法可用于从DNS权威服务器获取IPSec目标系统的密钥信息和加密点信息。本标准规定了该资源记录的数据格式及其使用方法。
YD/T 2908适用于部署有安全的DNS服务(通过DNSSEC或类似技术实现)的系统。
2规范性引用文件
下列文件对于本文件的应用是必不可少的。凡是注日期的引用文件，仅所注日期的版本适用于本文件。凡是不注日期的引用文件，其最新版本(包括所有的修改单)适用于本文件。
IETF RFC 596关于Telnet许可的重考虑(Second Thoughts on Telnet Go-Ahead)
IETF RFC 1035域名一实现与规范(DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION)
IETF RFC 2407 ISAKMP的IPSec解释域 (The Intermet IP Security Domain of Interpretation for ISAKMP)
IETF RFC 2536域名系统的DSA密钥和签名(DSA KEYs and SIGs in the Domain Name System (DNS))
IETF RFC 3110域名系统的RSA/SHA-I签名与RSA密钥(RSA/SHA-1 SIGs and RSA KEYs in the Domain Name System (DNS))
IETF RFC 3548 Basel6、 Base32 与Base64编码(The Base16, Base32, and Base64 Data Encodings)
3术语、定义和缩略语
3.1术语和定义
下列术语和定义适用于本文件。
3.1.1
客户端 Client
用来建立连接用来发送请求的一个程序。
1范围
YD/T 2908规定了一种基于DNS的IPSec认证密钥及加密点信息存储方法，该方法可用于从DNS权威服务器获取IPSec目标系统的密钥信息和加密点信息。本标准规定了该资源记录的数据格式及其使用方法。
YD/T 2908适用于部署有安全的DNS服务(通过DNSSEC或类似技术实现)的系统。
2规范性引用文件
下列文件对于本文件的应用是必不可少的。凡是注日期的引用文件，仅所注日期的版本适用于本文件。凡是不注日期的引用文件，其最新版本(包括所有的修改单)适用于本文件。
IETF RFC 596关于Telnet许可的重考虑(Second Thoughts on Telnet Go-Ahead)
IETF RFC 1035域名一实现与规范(DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION)
IETF RFC 2407 ISAKMP的IPSec解释域 (The Intermet IP Security Domain of Interpretation for ISAKMP)
IETF RFC 2536域名系统的DSA密钥和签名(DSA KEYs and SIGs in the Domain Name System (DNS))
IETF RFC 3110域名系统的RSA/SHA-I签名与RSA密钥(RSA/SHA-1 SIGs and RSA KEYs in the Domain Name System (DNS))
IETF RFC 3548 Basel6、 Base32 与Base64编码(The Base16, Base32, and Base64 Data Encodings)
3术语、定义和缩略语
3.1术语和定义
下列术语和定义适用于本文件。
3.1.1
客户端 Client
用来建立连接用来发送请求的一个程序。
标准图片预览
标准内容
ICS35.100.05
中华人民共和国通信行业标准
YD/T2908-2015
基于域名系统(DNS)的IP安全协议认证密钥存储技术要求
Technical requirementsforDNS-basedIPSeckeying material storage
2015-10-14发布
2016-01-01实施
中华人民共和国工业和信息化部发布前
2规范性引用文件
3术语、定义和缩略语
3.1术语和定义·
缩略语·
概述·
存储格式
RDATA结构
优先级·
网关类型·
算法·
网关·
6呈现格式
安全考量
7.1资源记录安全性分析
7.2针对不安全的IPSECKEY资源记录的主动攻击附录A（资料性附录）IPSECKEY资源记录举例参考文献
YD/T2908-2015
YD/T2908-2015
本标准按照GB/T1.1-2009给出的规则起草。请注意本文件的某些内容可能涉及专利。本文件的发布机构不承担识别这些专利的责任。本标准由中国通信标准化协会提出并归口。本标准起草单位：互联网域名系统北京市工程研究中心有限公司、北龙中网（北京）科技有限责任公司、中国科学院计算机网络信息中心（中国互联网络信息中心)。本标准主要起草人：马迪、钱炜烁、沈烁、邢志杰、卢文哲、毛伟
本标准主要参考IETFRFC4025，同时存在以下差异：将IETFRFC4025的举例章节放到了资料性附录。一为了方便读者理解，本标准5.3中对“线性编码域名”一词加以简要说明。II
YD/T2908-2015
基于域名系统(DNS)的IP安全协议认证密钥存储技术要求0范围
本标准规定了一种基于DNS的IPSec认证密钥及加密点信息存储方法，该方法可用于从DNS权威服务器获取IPSec目标系统的密钥信息和加密点信息。本标准规定了该资源记录的数据格式及其使用方法。本标准适用于部署有安全的DNS服务（通过DNSSEC或类似技术实现）的系统。规范性引用文件
下列文件对于本文件的应用是必不可少的。凡是注日期的引用文件，仅所注日期的版本适用于本文件。凡是不注日期的引用文件，其最新版本（包括所有的修改单）适用于本文件。IETFRFC596关于Telnet许可的重考虑（SecondThoughtsonTelnetGo-Ahead）IETFRFC1035域名—实现与规范（DOMAINNAMES-IMPLEMENTATIONANDSPECIFICATION）IETFRFC2407ISAKMP的IPSec解释域（TheInternetIPSecurityDomainof InterpretationforISAKMP）IETFRFC2536域名系统的DSA密钥和签名（DSAKEYsandSIGsintheDomainNameSystem(DNS)）IETFRFC3110域名系统的RSA/SHA-1签名与RSA密钥（RSA/SHA-1SIGsandRSAKEYsintheDomain Name System (DNS))
IETFRFC3548Base16、Base32与Base64编码（TheBase16,Base32,andBase64DataEncodings）0术语、定义和缩略语
0.0术语和定义
下列术语和定义适用于本文件。0.0.0
客户端Client
用来建立连接用来发送请求的一个程序。0.0.0
资源记录ResourceRecord
每个域所包含的与之相关的资源0.0缩略语
下列缩略语适用于本文件。
Domain Name System
Internet Protocol
InternetProtocol Security
Pointer Record
RSAAlgorithm
Digital SignatureAlgorithm
互联网域名系统
互联网协议
IP安全协议
反向地址解析资源记录
RSA加密算法
数字签名算法
YD/T2908-2015
IKSAKMP
0概述
Internet Security Association and Key ManagementProtocol
InternetKeyExchange
Network Address Translation
NetworkAddress andPortTranslation互联网安全关联钥匙管理协议
因特网密钥交换
网络地址转换
网络地址与端口转换
在目前的网络环境下，IPSec是保障主机之间安全通信的重要手段之一，也是部署最为广泛的IP层安全技术。
假设有这样一台主机（可能是出于政策要求或者技术规范），必须首先与目标设备建立IPSec隧道连接，然后才能进行正常的通信。在多数情况下，这台主机是有办法确切地获知目标设备的DNS域名的。要么是显式地得知DNS域名：要么是针对一个特定的IP地址执行DNSPTR查询；或者通过其他方式，例如：通过提取目标设备的“user@FQDN”名称中的DNS有关的部分。在上述这些情形中，该主机都有必要获取一个公钥来验证该目标主机：有时候，它还需要获得一些指示信息，以便决定自已是应该直接与目标主机联系，还是通过另一个作为网关的节点来间接地联系目标主机。
0存储格式
O.0RDATA结构
IPSECKEY资源记录中的RDATA包括：优先级、网关类型、公钥值、算法类型、以及网关地址（可选）。如图1所示。
567890123456789012345678901
优先级
0.0优先级
网关类型
图OIPSECKEY资源记录的RDATA结构网关
这是一个8比特字段，用于标识该记录的优先级；其意义参见IETFRFC1035第3.3.9小节。如有多条IPSECKEY资源记录可用，则其中存储的网关地址将按照记录的优先级数值递增顺序依次被尝试：如果两个网关地址的优先级相同，那么实际顺序将取决于具体实现。0.0网关类型
网关类型字段指示网关字段所存储内容的格式。一共定义了以下几个可能的值：2
—0：无网关：
——1：一个4字节的IPv4地址：—一2：一个16字节的IPv6地址：YD/T2908-2015
一3：一个线性编码域名（开头用一个字节来存储域名中包含的字符个数，即长度；后面跟着指定长度的字符串表示具体的域名）。由于线性编码域名是自描述的，所以其长度也是隐含可知的。该域名不得压缩。5.4算法
算法字段指示公钥所使用的加密算法及其格式。定义了以下几个可能的值：
一—0：无密钥：
一1：采用DSA密钥，见IETFRFC2536中规定的格式一2：采用RSA密钥，见IETFRFC3110中规定的格式。5.5网关
网关字段存储一个网关地址，通过与该网关地址建立IPSec隧道连接，可以与资源记录中指定的实体通信。
一共定义了3种格式：
一一网关字段存储一个32位的IPv4地址，其数据部分是一个按照IETFRFC1035中第3.4.1小节规定的IPv4地址。这是一个32位的数字，按照网络字节序存储。一一网关字段存储一个128位的IPv6地址，其数据部分是一个按照IETFRFC596中第2.2节规定的IPv4地址。这是一个128位的数字，按照网络字节序存储。一网关字段存储一个线性编码的域名，按照IETFRFC1035中第3.3节规定的格式存储。域名不得压缩。
5.6公钥
本标准中定义的两种公钥类型（RSA和DSA），都完全遵照其相应的KEY资源记录中的格式。具体说来，公钥字段包含的是KEY资源记录中的算法特定部分，即KEY资源记录中开头4个字节后面的全部数据。这也是KEY资源记录中，应被DNSSEC算法定义文档所详细规定的部分。此类文档同时也会规定一种消息摘要算法，用于生成SIG资源记录：不过，这些消息摘要算法相关的规定与IPSECKEY资源记录无关。
未来如果有新的加密算法产生，且打算被DNSSEC（在KEY资源记录中）和IPSECKEY资源记录同时采用，则它们将很可能沿用这两种记录中现成的公钥编码方式。除非特别说明，IPSECKEY资源记录中的公钥字段格式不变。该算法应仍然是针对IPSECKEY资源记录应用设计的，且应为其赋予相应的IPSECKEY算法类型编码：这个编号可以跟DNSSEC中的算法编号不同。DSA密钥格式依照RFC2536规定，RSA密钥格式依照IETFRFC3110规定。有以下改动：IETFRFC2065中关于RSA/MD5的早期规定是，指数和模数不得超过2552比特。IETFRFC3110中针对RSA/SHA1，将这一限制放宽到4096比特。而在IPSECKEY资源记录中，对RSA的公钥长度则几乎全无限制：只有2字节长度编码所导致的65535字节长度限制。该长度限制的放宽仅针对IPSECKEY资源记录有效：对KEY资源记录无效。
YD/T2908-2015
6呈现格式
IPSECKEY资源记录可能存储在一个DNS区文件中。优先级、网关类型、算法和网关字段是强制要求的：用Base64编码加密过的公钥块则是可选的。如果并未指定公钥，则资源记录的公钥字段应是0字节长。算法字段是一个无符号整数。没有定义相应的助词符。如果没有指定网关，则“网关类型”字段应置零，且“网关”字段应置为“”。“公钥”字段是以经Base64编码的公钥格式存储的。Base64格式中允许空白字符。关于Base64的详细定义，见IETFRFC3548第5.2节。IPSECKEY资源记录的通用呈现格式如下：INIPSECKEY（优先级网关类型算法网关基于Base64编码的公钥）
示例参见附录A。
0安全考量
0.0资源记录安全性分析
本标准所涉及的一切公钥信息交换，皆通过密钥管理协议来实现。例如，ISAKMP/IKE协议（见IETFRFC2407
IPSECKEY资源记录中所存储的信息应当被完整地、无修改地传递给客户端。传递的方式取决于该信息的使用者。该资源记录的服务器和终端用户之间应存在某种信任关系。该信任关系可能是端到端的DNSSEC验证、一条指向另一个安全信息源的TSIG或者SIG（O）隧道、或者是一条主机上的本地安全信道：也可能是上述各种方法的灵活组合。IPSECKEY资源记录所提供的密钥信息可抗被动攻击。公钥信息可以随意分发给任意第三方，而不会给IPSec会话的安全性造成任何影响。IPSec和IKE提供了针对主动攻击和被动攻击的保护。基于本资源记录的任何衍生规范应在其文档中仔细地说明其采用的信任模型：如果要采用DNSSEC信任模型，应证明采用该信任模型的合理性。假设存在针对DNS的主动攻击，导致客户端查到错误的地址（地址伪造），进而查询错误的QNAME记录，将最终导致中间人攻击。然而，此种问题的存在与是否采用IPSECKEY资源记录并无关系。O.0针对不安全的IPSECKEY资源记录的主动攻击0.0.0总论
7.2条讨论针对DNS的主动攻击。此类攻击需要抓取并篡改DNS请求和响应报文。DNSSEC可用于抵抗此类攻击，本条要讨论的是DNSSEC不可用的环境下的问题，而这并不是我们门推荐的部署环境0.0.0针对IPSECKEY公钥信息的主动攻击第一种主动攻击方式就是，攻击者把公钥信息换成自已控制的密钥或者一段垃圾信息。至于网关字段，要么是未改动、或者是null。这样，IKE协商过程将与原始终端系统直接进行。此类攻击若要成功，攻击者应针对IKE协商过程实施中间人攻击。而这种攻击，要求攻击者有能力在IKE和通信内容数据包的转发路径上截获并算改数据包如果攻击者无法实施这一针对IKE协商过程的中间人攻击，则IKE协商过程失败，导致“拒绝服务攻击”。
YD/T2908-2015
如果攻击者不仅能发起针对DNS的主动攻击，还处于一个能够对IKE和IPSec协商过程实施中间人攻击的网络节点位置，那么攻击者将有能力破坏IPSec信道。需要注意的是，攻击者应有能力同时对IKE协商的两端实施DNS主动攻击，才能最终成功。0.0.0针对IPSECKEY网关信息的主动攻击第二种攻击，是攻击者篡改网关地址，使其指向自已控制的机器。然后，攻击者要么换掉公钥、要么删除公钥。如果公钥被删除了的话，攻击者可以在另外一条记录中提供自已的公钥。这种攻击方式会造成一个简单的中间人攻击，因为攻击者可以随后与真实的自标节点建立一条旁路信道。请注意，与上述情形一样，这也要求攻击者同时还能对响应者发起主动攻击。请注意，中间人仅仅把明文数据包转发给真实的目标设备是不够的。因为，当目标设备把“自已期望明文通信”返回给发送端设备的时候，发送端设备可能已经设置好了“期待加密通信”的政策。因此攻击者不得不侵入双向的通信流量。在某些情况下，攻击者可以通过地址/端口映射（NAT/NAPT）来实现全面的入侵。
这种攻击方式比第一种要容易一些，因为攻击者不必处于端到端的转发路径上。攻击者只要能篡改DNS应答数据包就可以了。这是比较容易实现的，可以通过各种数据包篡改技术、或者攻击DNS缓存就可以实现。
如果IPSECKEY资源记录的端到端完整性受到怀疑，那么客户端应限制IPSECKEY资源记录的使用：只有当资源记录持有者的域名跟网关字段相匹配时才可以使用。因为，当资源记录持有者域名中的网关部分为空时，IPSECKEY资源记录中的网关字段应为空，才被视为合法的匹配。这样一来，在未验证的情况下（没有DNSSEC或者通往发送者的信任链）获取的任何非空的“网关”字段应被忽略。
这条规则有效地消除了针对网关字段的攻击。而这一攻击被认为是容易得多的，因为攻击者并不需要处于转发路径上。
当IPSECKEY资源记录中“网关类型”字段的值为3时，网关字段保存的将是一个域名。接下来，把这个域名翻译为IP地址或者IPSECKEY资源记录的后续查询交互也将成为中间人攻击的目标。如果第二个查询的端到端完整性受到怀疑，则上述的规则仍然适用。即，当查到的网关地址与最开始的IPSECKEY资源记录查询中的QNAME不一致时，该IPSECKEY资源记录将被丢弃。5
YD/T2908-2015
附录AWww.bzxZ.net
（资料性附录）
IPSECKEY资源记录举例
示例1：某节点地址为192.0.2.38，接受以自已为加密点的IPSec隧道，其IPSECKEY资源记录如下：38.2.0.192.in-addr.arpa.
INIPSECKEY（1012
192.0.2.38AQNRU3mG7TVTO2BkR47usntb102uFJtugb06BSGvgqt4AQ--)示例2：某节点地址为192.0.2.38，仅发布其公钥。其IPSECKEY资源记录如下：38.2.0.192.in-addr.arpa
INIPSECKEY（1002
AQNRU3mG7TVTO2BkR47usntb102uFJtugbo6BSGvgqt4AQ-=）示例3：某节点地址为192.0.2.38，已经将自已的权威授权给192.0.2.3节点，以该节点来代表IPSec隧道。其IPSECKEY资源记录如下：38.2.0.192.in-addr.arpa.
INIPSECKEY（1012
192.0.2.3AQNRU3mG7TVTO2BkR47usntb102uFJtugbo6BSGvgqt4AQ-）示例4：某节点地址为192.0.1.38，已经将自已的权威授权给域名为\mygateway.example.com\的节点。其IPSECKEY资源记录如下：
38.1.0.192.in-addr.arpa
INIPSECKEY（1032
mygateway.example.com.AQNRU3mG7TVTO2BkR47usntb102uFJtugbo6BSGvgqt4AQ）示例5：某节点地址为2001:0DB8:0200:1:210:f3fffe03:4d0，已经将自已的权威授权给2001:0DB8:c000:0200:21节点。其IPSECKEY资源记录如下：
SORIGIN1.0.0.0.0.0.2.8.B.D.0.1.0.0.2.ip6.arpa.0.d.4.0.3.0.e.f.f.f.3.f.0.1.2.0INIPSECKEY（1022
2001:0DB8:0:8002:2000:1AQNRU3mG7TVTO2BkR47usntb102uFJtugbo6BSGvgqt4AQ）6
小提示：此标准内容仅展示完整标准里的部分截取内容，若需要完整标准请到上方自行免费下载完整标准文档。
中华人民共和国通信行业标准
YD/T2908-2015
基于域名系统(DNS)的IP安全协议认证密钥存储技术要求
Technical requirementsforDNS-basedIPSeckeying material storage
2015-10-14发布
2016-01-01实施
中华人民共和国工业和信息化部发布前
2规范性引用文件
3术语、定义和缩略语
3.1术语和定义·
缩略语·
概述·
存储格式
RDATA结构
优先级·
网关类型·
算法·
网关·
6呈现格式
安全考量
7.1资源记录安全性分析
7.2针对不安全的IPSECKEY资源记录的主动攻击附录A（资料性附录）IPSECKEY资源记录举例参考文献
YD/T2908-2015
YD/T2908-2015
本标准按照GB/T1.1-2009给出的规则起草。请注意本文件的某些内容可能涉及专利。本文件的发布机构不承担识别这些专利的责任。本标准由中国通信标准化协会提出并归口。本标准起草单位：互联网域名系统北京市工程研究中心有限公司、北龙中网（北京）科技有限责任公司、中国科学院计算机网络信息中心（中国互联网络信息中心)。本标准主要起草人：马迪、钱炜烁、沈烁、邢志杰、卢文哲、毛伟
本标准主要参考IETFRFC4025，同时存在以下差异：将IETFRFC4025的举例章节放到了资料性附录。一为了方便读者理解，本标准5.3中对“线性编码域名”一词加以简要说明。II
YD/T2908-2015
基于域名系统(DNS)的IP安全协议认证密钥存储技术要求0范围
本标准规定了一种基于DNS的IPSec认证密钥及加密点信息存储方法，该方法可用于从DNS权威服务器获取IPSec目标系统的密钥信息和加密点信息。本标准规定了该资源记录的数据格式及其使用方法。本标准适用于部署有安全的DNS服务（通过DNSSEC或类似技术实现）的系统。规范性引用文件
下列文件对于本文件的应用是必不可少的。凡是注日期的引用文件，仅所注日期的版本适用于本文件。凡是不注日期的引用文件，其最新版本（包括所有的修改单）适用于本文件。IETFRFC596关于Telnet许可的重考虑（SecondThoughtsonTelnetGo-Ahead）IETFRFC1035域名—实现与规范（DOMAINNAMES-IMPLEMENTATIONANDSPECIFICATION）IETFRFC2407ISAKMP的IPSec解释域（TheInternetIPSecurityDomainof InterpretationforISAKMP）IETFRFC2536域名系统的DSA密钥和签名（DSAKEYsandSIGsintheDomainNameSystem(DNS)）IETFRFC3110域名系统的RSA/SHA-1签名与RSA密钥（RSA/SHA-1SIGsandRSAKEYsintheDomain Name System (DNS))
IETFRFC3548Base16、Base32与Base64编码（TheBase16,Base32,andBase64DataEncodings）0术语、定义和缩略语
0.0术语和定义
下列术语和定义适用于本文件。0.0.0
客户端Client
用来建立连接用来发送请求的一个程序。0.0.0
资源记录ResourceRecord
每个域所包含的与之相关的资源0.0缩略语
下列缩略语适用于本文件。
Domain Name System
Internet Protocol
InternetProtocol Security
Pointer Record
RSAAlgorithm
Digital SignatureAlgorithm
互联网域名系统
互联网协议
IP安全协议
反向地址解析资源记录
RSA加密算法
数字签名算法
YD/T2908-2015
IKSAKMP
0概述
Internet Security Association and Key ManagementProtocol
InternetKeyExchange
Network Address Translation
NetworkAddress andPortTranslation互联网安全关联钥匙管理协议
因特网密钥交换
网络地址转换
网络地址与端口转换
在目前的网络环境下，IPSec是保障主机之间安全通信的重要手段之一，也是部署最为广泛的IP层安全技术。
假设有这样一台主机（可能是出于政策要求或者技术规范），必须首先与目标设备建立IPSec隧道连接，然后才能进行正常的通信。在多数情况下，这台主机是有办法确切地获知目标设备的DNS域名的。要么是显式地得知DNS域名：要么是针对一个特定的IP地址执行DNSPTR查询；或者通过其他方式，例如：通过提取目标设备的“user@FQDN”名称中的DNS有关的部分。在上述这些情形中，该主机都有必要获取一个公钥来验证该目标主机：有时候，它还需要获得一些指示信息，以便决定自已是应该直接与目标主机联系，还是通过另一个作为网关的节点来间接地联系目标主机。
0存储格式
O.0RDATA结构
IPSECKEY资源记录中的RDATA包括：优先级、网关类型、公钥值、算法类型、以及网关地址（可选）。如图1所示。
567890123456789012345678901
优先级
0.0优先级
网关类型
图OIPSECKEY资源记录的RDATA结构网关
这是一个8比特字段，用于标识该记录的优先级；其意义参见IETFRFC1035第3.3.9小节。如有多条IPSECKEY资源记录可用，则其中存储的网关地址将按照记录的优先级数值递增顺序依次被尝试：如果两个网关地址的优先级相同，那么实际顺序将取决于具体实现。0.0网关类型
网关类型字段指示网关字段所存储内容的格式。一共定义了以下几个可能的值：2
—0：无网关：
——1：一个4字节的IPv4地址：—一2：一个16字节的IPv6地址：YD/T2908-2015
一3：一个线性编码域名（开头用一个字节来存储域名中包含的字符个数，即长度；后面跟着指定长度的字符串表示具体的域名）。由于线性编码域名是自描述的，所以其长度也是隐含可知的。该域名不得压缩。5.4算法
算法字段指示公钥所使用的加密算法及其格式。定义了以下几个可能的值：
一—0：无密钥：
一1：采用DSA密钥，见IETFRFC2536中规定的格式一2：采用RSA密钥，见IETFRFC3110中规定的格式。5.5网关
网关字段存储一个网关地址，通过与该网关地址建立IPSec隧道连接，可以与资源记录中指定的实体通信。
一共定义了3种格式：
一一网关字段存储一个32位的IPv4地址，其数据部分是一个按照IETFRFC1035中第3.4.1小节规定的IPv4地址。这是一个32位的数字，按照网络字节序存储。一一网关字段存储一个128位的IPv6地址，其数据部分是一个按照IETFRFC596中第2.2节规定的IPv4地址。这是一个128位的数字，按照网络字节序存储。一网关字段存储一个线性编码的域名，按照IETFRFC1035中第3.3节规定的格式存储。域名不得压缩。
5.6公钥
本标准中定义的两种公钥类型（RSA和DSA），都完全遵照其相应的KEY资源记录中的格式。具体说来，公钥字段包含的是KEY资源记录中的算法特定部分，即KEY资源记录中开头4个字节后面的全部数据。这也是KEY资源记录中，应被DNSSEC算法定义文档所详细规定的部分。此类文档同时也会规定一种消息摘要算法，用于生成SIG资源记录：不过，这些消息摘要算法相关的规定与IPSECKEY资源记录无关。
未来如果有新的加密算法产生，且打算被DNSSEC（在KEY资源记录中）和IPSECKEY资源记录同时采用，则它们将很可能沿用这两种记录中现成的公钥编码方式。除非特别说明，IPSECKEY资源记录中的公钥字段格式不变。该算法应仍然是针对IPSECKEY资源记录应用设计的，且应为其赋予相应的IPSECKEY算法类型编码：这个编号可以跟DNSSEC中的算法编号不同。DSA密钥格式依照RFC2536规定，RSA密钥格式依照IETFRFC3110规定。有以下改动：IETFRFC2065中关于RSA/MD5的早期规定是，指数和模数不得超过2552比特。IETFRFC3110中针对RSA/SHA1，将这一限制放宽到4096比特。而在IPSECKEY资源记录中，对RSA的公钥长度则几乎全无限制：只有2字节长度编码所导致的65535字节长度限制。该长度限制的放宽仅针对IPSECKEY资源记录有效：对KEY资源记录无效。
YD/T2908-2015
6呈现格式
IPSECKEY资源记录可能存储在一个DNS区文件中。优先级、网关类型、算法和网关字段是强制要求的：用Base64编码加密过的公钥块则是可选的。如果并未指定公钥，则资源记录的公钥字段应是0字节长。算法字段是一个无符号整数。没有定义相应的助词符。如果没有指定网关，则“网关类型”字段应置零，且“网关”字段应置为“”。“公钥”字段是以经Base64编码的公钥格式存储的。Base64格式中允许空白字符。关于Base64的详细定义，见IETFRFC3548第5.2节。IPSECKEY资源记录的通用呈现格式如下：INIPSECKEY（优先级网关类型算法网关基于Base64编码的公钥）
示例参见附录A。
0安全考量
0.0资源记录安全性分析
本标准所涉及的一切公钥信息交换，皆通过密钥管理协议来实现。例如，ISAKMP/IKE协议（见IETFRFC2407
IPSECKEY资源记录中所存储的信息应当被完整地、无修改地传递给客户端。传递的方式取决于该信息的使用者。该资源记录的服务器和终端用户之间应存在某种信任关系。该信任关系可能是端到端的DNSSEC验证、一条指向另一个安全信息源的TSIG或者SIG（O）隧道、或者是一条主机上的本地安全信道：也可能是上述各种方法的灵活组合。IPSECKEY资源记录所提供的密钥信息可抗被动攻击。公钥信息可以随意分发给任意第三方，而不会给IPSec会话的安全性造成任何影响。IPSec和IKE提供了针对主动攻击和被动攻击的保护。基于本资源记录的任何衍生规范应在其文档中仔细地说明其采用的信任模型：如果要采用DNSSEC信任模型，应证明采用该信任模型的合理性。假设存在针对DNS的主动攻击，导致客户端查到错误的地址（地址伪造），进而查询错误的QNAME记录，将最终导致中间人攻击。然而，此种问题的存在与是否采用IPSECKEY资源记录并无关系。O.0针对不安全的IPSECKEY资源记录的主动攻击0.0.0总论
7.2条讨论针对DNS的主动攻击。此类攻击需要抓取并篡改DNS请求和响应报文。DNSSEC可用于抵抗此类攻击，本条要讨论的是DNSSEC不可用的环境下的问题，而这并不是我们门推荐的部署环境0.0.0针对IPSECKEY公钥信息的主动攻击第一种主动攻击方式就是，攻击者把公钥信息换成自已控制的密钥或者一段垃圾信息。至于网关字段，要么是未改动、或者是null。这样，IKE协商过程将与原始终端系统直接进行。此类攻击若要成功，攻击者应针对IKE协商过程实施中间人攻击。而这种攻击，要求攻击者有能力在IKE和通信内容数据包的转发路径上截获并算改数据包如果攻击者无法实施这一针对IKE协商过程的中间人攻击，则IKE协商过程失败，导致“拒绝服务攻击”。
YD/T2908-2015
如果攻击者不仅能发起针对DNS的主动攻击，还处于一个能够对IKE和IPSec协商过程实施中间人攻击的网络节点位置，那么攻击者将有能力破坏IPSec信道。需要注意的是，攻击者应有能力同时对IKE协商的两端实施DNS主动攻击，才能最终成功。0.0.0针对IPSECKEY网关信息的主动攻击第二种攻击，是攻击者篡改网关地址，使其指向自已控制的机器。然后，攻击者要么换掉公钥、要么删除公钥。如果公钥被删除了的话，攻击者可以在另外一条记录中提供自已的公钥。这种攻击方式会造成一个简单的中间人攻击，因为攻击者可以随后与真实的自标节点建立一条旁路信道。请注意，与上述情形一样，这也要求攻击者同时还能对响应者发起主动攻击。请注意，中间人仅仅把明文数据包转发给真实的目标设备是不够的。因为，当目标设备把“自已期望明文通信”返回给发送端设备的时候，发送端设备可能已经设置好了“期待加密通信”的政策。因此攻击者不得不侵入双向的通信流量。在某些情况下，攻击者可以通过地址/端口映射（NAT/NAPT）来实现全面的入侵。
这种攻击方式比第一种要容易一些，因为攻击者不必处于端到端的转发路径上。攻击者只要能篡改DNS应答数据包就可以了。这是比较容易实现的，可以通过各种数据包篡改技术、或者攻击DNS缓存就可以实现。
如果IPSECKEY资源记录的端到端完整性受到怀疑，那么客户端应限制IPSECKEY资源记录的使用：只有当资源记录持有者的域名跟网关字段相匹配时才可以使用。因为，当资源记录持有者域名中的网关部分为空时，IPSECKEY资源记录中的网关字段应为空，才被视为合法的匹配。这样一来，在未验证的情况下（没有DNSSEC或者通往发送者的信任链）获取的任何非空的“网关”字段应被忽略。
这条规则有效地消除了针对网关字段的攻击。而这一攻击被认为是容易得多的，因为攻击者并不需要处于转发路径上。
当IPSECKEY资源记录中“网关类型”字段的值为3时，网关字段保存的将是一个域名。接下来，把这个域名翻译为IP地址或者IPSECKEY资源记录的后续查询交互也将成为中间人攻击的目标。如果第二个查询的端到端完整性受到怀疑，则上述的规则仍然适用。即，当查到的网关地址与最开始的IPSECKEY资源记录查询中的QNAME不一致时，该IPSECKEY资源记录将被丢弃。5
YD/T2908-2015
附录AWww.bzxZ.net
（资料性附录）
IPSECKEY资源记录举例
示例1：某节点地址为192.0.2.38，接受以自已为加密点的IPSec隧道，其IPSECKEY资源记录如下：38.2.0.192.in-addr.arpa.
INIPSECKEY（1012
192.0.2.38AQNRU3mG7TVTO2BkR47usntb102uFJtugb06BSGvgqt4AQ--)示例2：某节点地址为192.0.2.38，仅发布其公钥。其IPSECKEY资源记录如下：38.2.0.192.in-addr.arpa
INIPSECKEY（1002
AQNRU3mG7TVTO2BkR47usntb102uFJtugbo6BSGvgqt4AQ-=）示例3：某节点地址为192.0.2.38，已经将自已的权威授权给192.0.2.3节点，以该节点来代表IPSec隧道。其IPSECKEY资源记录如下：38.2.0.192.in-addr.arpa.
INIPSECKEY（1012
192.0.2.3AQNRU3mG7TVTO2BkR47usntb102uFJtugbo6BSGvgqt4AQ-）示例4：某节点地址为192.0.1.38，已经将自已的权威授权给域名为\mygateway.example.com\的节点。其IPSECKEY资源记录如下：
38.1.0.192.in-addr.arpa
INIPSECKEY（1032
mygateway.example.com.AQNRU3mG7TVTO2BkR47usntb102uFJtugbo6BSGvgqt4AQ）示例5：某节点地址为2001:0DB8:0200:1:210:f3fffe03:4d0，已经将自已的权威授权给2001:0DB8:c000:0200:21节点。其IPSECKEY资源记录如下：
SORIGIN1.0.0.0.0.0.2.8.B.D.0.1.0.0.2.ip6.arpa.0.d.4.0.3.0.e.f.f.f.3.f.0.1.2.0INIPSECKEY（1022
2001:0DB8:0:8002:2000:1AQNRU3mG7TVTO2BkR47usntb102uFJtugbo6BSGvgqt4AQ）6
小提示：此标准内容仅展示完整标准里的部分截取内容，若需要完整标准请到上方自行免费下载完整标准文档。