本互联网草案完全符合BCP 78和BCP 79的规定。vbl.。
互联网草案是互联网工程任务组(IETF)的工作文件。请注意，其他小组也可以将工作文件作为互联网草稿分发。目前的互联网草稿列表在https://datatracker.ietf.org/drafts/current/.。vbl.。
互联网草案是有效期最长为6个月的草案文件，可随时更新、替换或被其他文件淘汰。使用互联网草稿作为参考材料或将其作为正在进行的工作以外的引用是不合适的。
版权所有(C)2020 IETF Trust和确认为文档作者的人员。版权所有。vbl.。
本文件受BCP78和IETF Trust有关IETF文件(https://trustee.ietf.org/license-info))的法律规定的约束，自本文件发布之日起生效。请仔细阅读这些文档，因为它们描述了您对本文档的权利和限制。本文档中提取的代码组件必须包括简化的BSD许可证文本，如信托法律规定的第4.e节所述，并且如简化的BSD许可证中所述，提供的代码组件不提供担保。vbl.。
域名系统(DNS)是一个独特的分布式数据库，是大多数Internet应用程序的重要服务。虽然DNS是分布式的，但它依赖于集中的、受信任的注册商来提供全局唯一的名称。随着人们对DNS在互联网上的核心作用的认识的提高，各种机构正在利用他们的权力(包括法律手段)对DNS进行攻击，从而威胁到互联网上信息的全球可用性和完整性。vbl.。
DNS不是以安全为目标设计的。这使得它非常容易受到攻击，特别是对于拥有整个民族国家的技术能力的攻击者来说。本规范描述了一种抗审查、保护隐私和分散的名称系统：GNU名称系统(GNS)。它旨在提供DNS的安全替代方案，特别是在遇到审查或操纵时。GNS可以将名称绑定到任何类型的加密安全令牌上，使其在某些方面能够加倍，甚至可以替代当今的一些公钥基础设施，特别是用于Web的X.509。vbl.。
本文档包含GNU名称系统[GNS]的GNU名称系统(GNS)技术规范，GNU名称系统是一个完全分散且抗审查的名称系统。GNS为域名系统(DNS)提供了一种隐私增强的替代方案。GNS的设计包含了与DNS集成和共存的能力。GNS基于PetName系统的原理，并以简单分布式安全基础设施(SDSI)的思想为基础，通过将安全标识符分散映射到可记忆的名称来解决一个中心问题：即在没有可信机构的情况下不可能提供全局的、安全的和可记忆的映射。GNS使用SDSI设计中的传递性，将受信任的根替换为安全的授权委派，从而使Petname在非常强的对手模型下操作时对其他用户有用。vbl.
本文档定义了供实施者使用的资源记录、解析过程、加密例程和安全注意事项的标准有线格式。vbl.。
本文档中的关键字"；必须"；，"；必须"；，"；不得"；，"；不应该"；，"；不应该"；，"；推荐"；，"；可以"；，"；和"；可选"；应按照[RFC21中所述解释。vbl.。
GNS中的区域由公钥/私钥ECDSA密钥对(d，zk)定义，其中d是私钥，zk是相应的公钥。GNS采用曲线25519[RFC7748](也称为。Edwards25519)与ECDSA方案([RFC6979])。在下面的代码中，我们对加密原语使用以下命名约定：Ó。
是256位的ECDSA私钥。在GNS中，记录使用派生自第#34；d&34；节的密钥进行签名，如第4节所述。
是对应于d的ECDSA公钥。它在[RFC6979]中被定义为曲线点d*B，其中B是椭圆曲线的群生成器。公钥用于唯一标识GNS区域，称为区域密钥。vbl.。
GNS实施者必须提供一种机制来创建和管理本地区域的资源记录。通过创建区域密钥对来建立本地区域。可以将记录添加到每个区域，因此必须提供资源记录和区域的(本地)持久性机制。此本地区域数据库由GNS解析器实现使用，并用于发布记录信息。vbl.。
GNS资源记录保存区域中特定记录的数据。资源记录格式定义如下：Ó。
0 8 16 24 32 40 48 56+-+-+|到期|+-+-+|数据大小|类型|+-+。--+|标志|DATA/+-+/
表示记录的绝对64位到期日期。自1970年1月1日午夜(0小时)以来的微秒(以网络字节顺序表示)。vbl.。
以字节和网络字节顺序表示数据字段的32位大小。vbl.。
是32位资源记录类型。此类型可以是第3节中定义的GNS资源记录之一，也可以是[RFC1035]中定义的DNS记录类型，或任何互补的标准化DNS资源记录类型。该值必须以网络字节顺序存储。请注意，2^16以下的值保留通过IANA进行分配([RFC6895])。vbl.。
可变长度资源记录数据负载。内容由资源记录的相应类型定义。vbl.。
标志指示资源记录周围的元数据。标志值为0表示所有标志均未设置。下面说明了资源记录的32位标志值中的标志分布：？
.5 4 3 2 1 0-+-+/.|SHADOW|EXPREL|SUPL|PRIVATE|/|-+-+。
如果设置了此标志，则解析程序应忽略此记录，除非相同记录类型的所有(其他)记录都已过期。用于允许区域发布者将记录的未来值放入分布式哈希表，从而在记录更改时提高性能。这样，未来的值可以传播，并且可以在转换变为活动状态之前进行缓存。vbl.。
记录的过期时间值是相对时间(仍以微秒为单位)，而不是绝对时间。对于从分布式哈希表获取的记录，解析程序永远不会遇到此标志，但在解析程序查找本地托管的区域的私有记录时可能会出现此标志。vbl.
这是一份补充记录。它是在提供其他记录的基础上提供的。此标志表示此记录未与相应名称下的其他记录一起显式管理，但可能对应用程序有用。对于从分布式哈希表获取的记录，只有解析器才会遇到此标志。vbl.。
这是此对等方的私人记录，因此不应在分布式哈希表中发布。因此，对于从分布式哈希表获取的记录，解析器永远不会遇到该标志。在解析本地区域中的标签时，仍应将私有记录视为与常规记录一样。vbl.。
第10节描述了GNS记录类型的注册表。该注册表的注册策略是先到先得，如[RFC8126]中所述。在请求新条目时，强烈建议仔细考虑以下标准：修复：Ausdenken是wir da gerne haetten。vbl.。
在GNS中，标签对区域的委托通过PKEY记录表示。PKEY资源记录包含要委派到的区域的公钥。PKEY记录必须是标签下的唯一记录。不允许其他记录。PKEY数据条目的格式如下：
可以通过GNS2DNS记录将标签委托回DNS。资源记录包含解析程序在DNS中继续使用的DNS名称，后跟DNS服务器。这两个名称都采用[RFC1034]中为DNS名称定义的格式。GNS2DNS数据条目具有以下格式：
0 8 16 24 32 40 48 56+-+-+|域名|/||+-+-+|域名服务器名称|/。/||+-+。
要使用的DNS服务器。可以是点分十进制形式的IPv4/IPv6地址或DNS名称。它也可以是以顶级域结尾的相对GNS名称。该值为UTF-8编码(也适用于DNS名称)，以0结尾。vbl.。
期望在应用层提供DNS名称的应用程序可以使用传统主机名记录。最常见的用例是HTTP虚拟主机，它不能按原样与GNS名称一起使用，因为这些名称可能不是全局唯一的。期望在具有IPv4或IPv6地址的单个资源记录中一起找到LEHO资源记录。LEHO数据条目具有以下格式：？
注意：如果应用程序在HTTP请求标头(例如"；Host："；标头)中使用LEHO值，则必须将其转换为Punycode表示[RFC5891]。vbl.。
区域管理员可以使用昵称记录来发布有关此区域更喜欢引用的标签的指示。这是对其他区域在创建包含此区域的公共区域密钥的PKEY(第3.2节)记录时使用的标签的建议。此记录只能存储在空标签"；@"；下，但可以在任何标签下随记录集一起返回，作为补充记录。第6.2.6节详细说明解析器必须如何处理补充和非补充NICK记录。NICK数据条目具有以下格式：？
表示区域的首选标签的UTF-8字符串(不是以0结尾)。此字符串不能包含"；."；字符。vbl.。
在GNS中，名称中的每个"；."；都委托给另一个区域，GNS查找期望在一个记录集中返回所有必需的有用信息。这与DNS用于SRV和TLSA记录的特殊标签不兼容。因此，GNS定义了装箱记录格式来装箱SRV和TLSA记录，并将它们包括在与其关联的标签的记录集中。例如，"；_https._tcp.example.org"；的TLSA记录将存储在"；example.org"；的记录集中，作为具有服务(SVC)443(Https)和协议(PROTO)6(TCP)和记录类型"；TLSA"；的箱式记录。有关参考，另请参阅[RFC2782]。框数据条目具有以下格式：Ó。
0 8 16 24 32 40 48 56+-+-+|协议|服务|类型|+-+-+|记录数据|/|。|+-+-+。
装箱记录的16位服务值，即端口号。以网络字节顺序。vbl.。
是一个可变长度字段，包含DNS中为相应类型定义的类型的数据格式。vbl.。
0 8 16 24 32 40 48 56+-+-+|托管对等公钥||(256bit)|+-+-+|协议|服务名称。|+-++/||+-+-+
用于标识宿主对等方的服务的共享密钥，用于派生连接到服务所需的端口号。服务名称必须是以0结尾的UTF-8字符串。vbl.。
GNS资源记录在分布式哈希表(DHT)中发布。我们假设DHT提供两个功能：get(Key)和put(key，value)。在GNS中，资源记录按其各自的标签分组，在分布式哈希表中的单个资源记录块(RRBLOCK)中以密钥"；Q"；：PUT(Q，RRBLOCK)加密并一起发布。从区域密钥和所包含记录的相应标签导出的密钥。vbl.。
prk_h：=HKDF-Extract("；Key-Derivation"；，ZK)h：=HKDF-Expand(PRK_h，Label|"；GNS"；，512/8)d_h：=h*d mod Lzk_h：=h mod L*zkq：=SHA512(ZK_H)。
vbl.。
我们使用[RFC5869]中定义的基于散列的密钥派生函数(HKDF)。提取相采用HMAC-SHA512，展开相采用HMAC-SHA256。vbl.。
是使用HKDF检索的密钥材料，使用字符串Key-Derivation&34；作为SALT，使用公共区域密钥"；ZK&34；作为初始密钥材料。vbl.。
是512位HKDF扩展结果。扩展信息输入是标签和字符串"；gns"；的串联。vbl.。
是使用密钥材料从区密钥"；ZK&34；导出的256位公钥。vbl.
是发布资源记录块的512位分布式哈希表密钥。它是对应于派生私钥"；d_h"；的公钥"；zk_h"；上的SHA512散列。vbl.。
我们指出，"；ZK&34；与"；h；的乘法是点乘，而"；d&34；与"；h；的乘法是标量乘法。vbl.。
GNS记录按其标签分组，并在分布式哈希表中作为单个块发布。分组的记录集可以与任何数量的补充记录配对。补充记录必须设置补充标志(参见第3节)。所包含的资源记录使用对称加密方案加密。GNS实现必须根据底层分布式哈希表的属性和建议发布RRBLOCK。这可能包括定期更新发布。GNS RRBLOCK具有以下格式：
0 8 16 24 32 40 48 56+-+-+|签名|+-+-+|公钥|+-。-+-+|大小|目的|+-+-+|到期|+-+-。-+|bdata/|+-+-+。
符合[RFC6979]的512位ECDSA确定性签名。对公钥字段后面的数据计算签名。签名是使用派生的私钥"；d_h"；创建的(参见第4节)。vbl.。
是用于验证签名的256位公钥"；zk_h"；。该值的焊线格式在[RFC8032]的第5.1.5节中定义。vbl.。
一个32位值，包含公钥字段后面的签名数据的长度(按网络字节顺序)。除了BDATA的长度之外，该值始终包括字段Size(4)、Purpose(4)和Expires(8)的长度。当使用32位值时，实现可能会拒绝发布远远低于4 GB的特定大小的块。但是，必须支持62千字节的最小数据块大小。vbl.。
指定RRBLOCK何时过期，加密块应从分布式哈希表中删除并缓存，因为它可能已过时。但是，应用程序可能会继续使用未过期的单个记录，直到它们过期。该值必须设置为此块中包含的资源记录的过期时间，且过期时间最短。如果记录块包括影子记录，则考虑所有具有匹配类型的影子记录的最大到期时间和非影子记录的到期时间。这是自1970年1月1日午夜(0小时)以来的64位绝对日期(以微秒为单位)，按网络字节顺序排列。vbl.
使用对称加密方案将资源记录集合RDATA加密到GNS RRBLOCK的BDATA字段中。RDATA的导线格式如下所示：
0 8 16 24 32 40 48 56+-+-+|RR计数|呼气/+-+-+/-tion|数据大小|+。-+-+|类型|标记|+-+-+|数据/|+-+-。-+|到期|+-+-+|数据大小|类型|+。-+-+|FLAGS|DATA/+-/-//填充/。
一个32位值，包含按网络字节顺序跟随在此字段之后的可变长度资源记录的数量。vbl.。
这些字段在第3节的资源记录格式中定义。这些资源记录的RR计数总数必须存在。vbl.。
填充必须在所有二进制八位数中包含值0。填充必须确保没有RR计数字段的RDATA的大小是2的幂。作为特殊例外，具有(仅)PKEY记录类型的记录集永远不会被填充。请注意，具有PKEY记录的记录集不能包含其他记录。vbl.。
对称密钥和初始化向量从记录标签和区域密钥导出。对于资源记录块有效载荷的解密，对称密码的密钥材料#34；K#34；和初始化向量#34；IV#34；导出如下：
prk_k：=HKDF-Extract("；gns-AES-CTX-KEY"；，ZK)prk_iv：=HKDF-Extract("；gns-AES-ctx-iv"；，zk)k：=HKDF-Expand(PRK_k，Label，512/8)；IV：=HKDF-Expand(PRK_iv，Label，256/8)。
vbl.
HKDF是[RFC5869]中定义的基于散列的密钥派生函数。具体地说，HMAC-SHA512用于提取阶段，HMAC-SHA256用于扩展阶段。输出密钥材料是用于对称密钥的64个八位字节(512位)和用于初始化向量的32个八位字节(256位)。我们将得到的密钥材料分为256位的AES[RFC3826]密钥和256位的TWOFISH[TWOFISH]密钥：
0 8 16 24 32 40 48 56+-+-+|AESKEY|+-+-+|TWOFISHKEY|+。-+-+。
0 8 16 24 32 40 48 56+-+-+|AESIV|+-+-+|TWOFISH IV|+-+--。-+-+-+。
密钥和IV用于CFB128-AES-256和CFB128-TWOFISH-256链式对称密码。这两种密码都用于密码反馈(CFB)模式[RFC3826]。vbl.。
GNS中的所有标签都采用UTF-8[RFC3629]编码。这不包括通过Idna规范[RFC5890]国际化的DNS记录(如CNAME记录)中的任何DNS名称。vbl.。
通过递归查询分布式哈希表记录存储来解析GNS中的名称。在下面，我们定义如何启动解析以及如何处理解析中的每个迭代。vbl.。
名称的GNS解析必须从使用区域公钥指示的给定起始区域开始。有关如何确定起始区的详细信息，请参阅第8节。
当请求GNS名称解析时，客户端可以提供所需的记录类型。如果需要，GNS解析器将使用期望的记录类型来指导处理，例如通过提供VPN记录到A或AAAA记录的转换。但是，在检索到资源记录集之后，仍必须由客户端根据所需的记录类型对记录集进行过滤。vbl.
在递归名称解析的每个步骤中，都有一个权威区域ZK和一个要解析的名称。该名称可能为空。最初，权威区是起始区。如果名称为空，则将其解释为顶点标签"；@"；。vbl.。
验证并按下。
..