DNS 技术标准综述

      互联网设计的领军人物美国麻省理工学院的大卫-克拉克教授在《Designing an Internet》（中文译名《互联网的设计和演化》）一书中说过：“网络架构的某些方面呈现出一种近乎哲学的特征，其中之一就是实体的 “命名机制”。这是一个复杂的问题。”反观当前的互联网体系结构，域名系统（DNS）便是针对“命名机制”这一互联网设计哲学问题的回应。

      自互联网成为全球泛在的互联互通基础设施以来，其上承载应用的创新持续倒逼互联网体系结构做出调整，推动其在安全性、可用性和经济性等范畴的演进。作为互联网体系结构大厦的“四梁八柱”（命名、路由、转发）之一，DNS无论是向上托举“应用创新方案”（例如，基于域名系统的标识解析），还是向下融合“网络演进机制”（例如，基于域名系统的IPv6过渡机制），其可扩展性经受住了时间的考验，并固化在各类技术标准之中，成为全球范围内构建网络产业生态、支撑网络空间治理的重要依据。

域名系统的技术标准生态

       今天的互联网构建在以TCP/IP协议簇为核心的互联互通基础设施之上。IP地址是TCP/IP协议簇中承担数据包寻址和转发功能的关键标识。为了实现一个能够支持分布式、可扩展的“主机名到IP地址”的映射系统，域名系统应运而生（域名系统的前身是UNIX系统的主机表）。上个世纪80年代，美国南加州大学信息科学研究所的Paul Mockapetris设计了域名系统的工业标准。和其他互联网技术标准一样，域名系统的技术体系也是在互联网工程任务组（IETF）完成了标准化。IETF RFC 1034和IETF RFC1035是域名系统的核心标准，规范了命名规则、数据格式、通信协议（数据单位）、部署机制等技术要素。伴随着域名系统的商业化应用，基于注册局/注册商模型的域名注册业务也形成了自己的标准体系，也即，用于名字注册管理的EPP协议（RFC4930,Extensible Provisioning Protocol）和用于名字注册信息查询的WHOIS协议（RFC3912, WHOIS Protocol Specification）、RDAP 协议（RFC7482,Registration Data Access Protocol Query Format）。广义域名系统技术标准所约束的对象包括域名解析系统（DNS）系统和域名注册系统（EPP/WHOIS/ RDAP）。二者支撑的是不同的域名系统服务（商业）环节，并在互联互通机制和运行机制上各自独立演进。本文所要讨论的对象是“狭义域名系统”，也即域名解析系统，下文统称DNS。截止到笔者成文时间，共有超过300篇DNS技术相关的IETF RFC文档（技术标准规范和相关文档）¹。它们共同丰富了DNS的内涵和外延。

      “网络”和“应用”之间的矛盾，是推动互联网体系结构不断演进的内在动力。DNS在互联网体系结构中衔接“网络”和“应用”，其技术标准的发展历程提供了观察互联网体系结构演化的线索。笔者根据自己对DNS技术的理解加以分类，从“DNS基础功能扩展”、“DNS认证功能扩展”以及“DNS协议内核演进”三个方面介绍DNS诞生以来演化出的各类技术标准。

       本文的主线是“应用”和“网络”的关系，没有讨论不在这个主线之上的DNS技术标准。但他们依然重要，亦是事关互联网治理和域名产业生态的重要技术，例如多语种域名标签解析技术标准和域名注册机构运行技术标准等。

DNS基础功能扩展技术标准

      DNS资源记录的“类型”概念，是一种可扩展的信息发布机制。基于这种设计，DNS成为各类“网络”信息和“应用”信息检索的入口，提供了远比“IP地址解析”丰富的功能。

2.1 DNS解析杠杆

      DNS天然地存储了主机IP地址和主机名（域名）的映射关系。这种关系本质上是一种网络连接状态的外在反映。利用这种“状态”信息，DNS不仅可以“向上”为www交互、电子邮件、VoIP等“应用”提供域名解析服务，还可以“向下” 为“网络”提供优化互联互通的支撑机制。笔者把这种利用DNS附着网络信息的应用称为“DNS解析杠杆”。学术界和工业界针对这种思路有很多讨论。本文介绍两种在工业界广泛使用且在IETF完成标准化的方案来展现DNS解析的杠杆能力。

1）智能解析

      伴随着云计算和CDN技术的兴起，基于DNS面向广域网乃至全球互联网实施流量调度成为提高互联网应用质量的关键。工业界谓之“智能解析”。这一机制背后的做法是根据DNS请求来源的IP地址分配信息（地理位置、网段分布等）特征，向用户呈现不同的DNS解析结果，实施流量工程等操作。为了在DNS消息中携带以上信息，相关技术标准（RFC7871, Client Subnet in DNS Queries）对DNS协议数据单元的载荷能力和字段进行了扩展定义。

2）IPv6网络过渡机制

      IPv4网络和IPv6网络是两个“协议数据单元”和“标识空间”都彼此独立的网络空间，但复用同一个域名空间。二者彼此交换“网络”信息以实现共存，是全球互联网向IPv6过渡的必要手段。在各类IPv6过渡方案中，一种称为“DNS64 + NAT64”的方案将眼光投向了DNS，利用DNS来打通IPv4和IPv6两个网络空间。该方案中的DNS递归服务器，根据IPv6客户端的DNS请求内容（目标服务器）的网络协议栈（IPv4/IPv6）特征，向用户反馈不同IPv6地址结构，在本地实现面向IPv4/IPv6网络的路由分流。相关技术标准（RFC6147, DNS Extensions for Network Address Translation from IPv6 Clients to IPv4 Servers）对DNS的数据内容（DNS资源记录）进行了改造，在域名解析层面打通了IPv4和IPv6网络连接状态信息（地址翻译），实现二者的互联互通。

2.2 DNS信息扩展

      DNS的分布式特性和泛在部署现状，让它自然地成为了一个信息目录，在“IP地址和域名”映射关系之外，提供更多的以域名为检索标的物的信息查询服务。在技术层面，DNS资源记录也很容易支持新增的类型用以承载新的数据映射关系。笔者将这种通过扩展DNS资源记录类型来提供新的数据解析服务的应用，称为 “DNS信息扩展”。本文介绍其中2种形成了工业标准的典型案例。

1）主机地理信息获取

      在特定的互联互通环境中，“应用”需要获取主机的经纬度信息。通过域名的命名机制，将主机名赋予特定的计算设备，并进一步通过新的DNS资源记录类型把经纬度信息映射到主机名，便可以利用DNS基础设施在互联网上发布、获取主机的地理位置信息。相关技术标准（RFC1876, A Means for Expressing Location Information in the Domain Name System）将这一DNS资源记录类型命名为：“LOC”。

2）码号（标识）映射

      VoIP业务的出现，使得传统的电话连接穿透了电信网和互联网的信令边界，其拨号机制需要获取电信码号（E.164号码，例如手机号码）和互联网VoIP账号（例如SIP电话地址）之间的映射关系。相关技术标准（RFC2915, The Naming Authority Pointer DNS Resource Record）规范了一种将电信码号转换为域名形式放在DNS服务器中的方法，并由此定义了一种新的DNS资源记录类型“NAPTR”。“NAPTR”资源记录类型还可以用来完成OID²和域名之间的映射，实现基于域名系统的标识解析。借助特定的DNS后缀（oid-res.org），该机制复用53端口的经典DNS协议数据单元，实现OID解析跳转。

3）服务发现

      利用DNS解析技术来发现特定网络所提供的服务（“应用”）称为“基于DNS的服务发现”机制，是一种常见的DNS信息扩展机制。 也即根据域名解析出提供特定服务的主机信息（IP地址、传输机制、端口等）。相关技术标准（RFC2782, A DNS RR for specifying the location of services）定义了一种专用的DNS资源记录类型“SRV”来结构化表达特定域名所绑定的“应用”寻址信息。

DNS认证功能扩展技术标准

      为了提供一种针对DNS资源记录数据完整性的保护机制，互联网国际标准组织IETF利用数字签名技术，规范了DNS安全功能扩展技术标准（RFC4034，Resource Records for the DNS Security Extensions），也即DNSSEC。DNSSEC的加持让DNS发生了“气质性变异”，使其从一个分布式数据库进化成为一个轻量级PKI系统。DNSSEC在全球的部署，让互联网上一切面向域名的安全认证“应用”有了信任锚点。

3.1 基于DNS的身份认证 DANE

      依托DNSSEC提供的数据完整性校验机制和信任锚点，DANE（DNS-based Authentication of Named Entities，基于DNS的域名身份认证）机制，通过一种命名为“TLSA”的DNS资源记录类型为TLS（Transport Layer Security，传输层安全协议）中实体身份信息和密钥对的密码学绑定关系提供了映射机制。也即，向特定的DNS权威服务器请求解析给定主机名的“TLSA”资源记录，即可获得参与TLS连接的目标主机的密钥认证信息。相关技术标准文档（RFC 6394 , Use Cases and Requirements for DANE; RFC6698, The DANE TLS Protocol: TLSA）描述了DANE的应用场景和协议规范。

3.2 基于DNS的域密钥的邮件发送源认证 DKIM

      电子邮件和域名解析有显而易见的关系。邮件地址的认证问题很自然地可以归属到域名安全范畴。基于邮件发送方对邮件信息的签名，DKIM（DomainKeys Identified Mail）机制允许邮件接收者通过查询签名者的域名得到相应的公钥信息，进而验证邮件签名以判断邮件地址的真伪。得益于DNSSSEC对域名关联信息的安全性加持，签名者的公钥信息不再额外需要一个专门独立的可信第三方进行背书，仅需验证者向DNS提供签名者公钥信息的资源记录解析查询。相关技术标准文档（RFC 5585, DKIM Service Overview; RFC6376, DKIM Signatures; RFC 5617, DKIM Author Domain Signing Practices）对DKIM的运行机制和技术规范进行了说明。

3.3 基于DNS的IPSec密钥信息查询

      IPSec是保障主机之间安全通信的重要手段之一，也是部署最为广泛的“网络”层安全技术。如果某个主机期望与目标主机建立IPSec连接，该主机必须获取目标主机的公钥信息以及隧道模式信息。如果目标主机设置了主机名（域名），将以上信息通过DNS发布是一种便捷简单的方式。基于这种思路，一种新的DNS资源记录IPSECKEY被设计出来，用来发布主机的IPSec认证密钥信息和操作模式信息。技术标准文档（RFC4025, A Method for Storing IPsec Keying Material in DNS）规范了这一扩展应用的数据格式和操作协议。

3.4 基于DNS的CA授权信息

      面向域名来签发数字证书（典型如基于X.509的Web PKI）是一种常见的授权形式。域名持有人对特定数字证书签发机构（CA）的授权信息是该机制的必要安全要素。该授权信息的公开，可以降低来自不安全证书颁发机构意外或蓄意为域名签发证书的风险。相关技术标准（RFC6844, DNS Certification Authority Authorization Resource Record）定义了一种称为“CAA”的DNS资源记录类型。基于该记录类型，域名持有人可以将“针对自己域名的数字证书签发行为”授权（限制）到指定的CA。

DNS协议内核演进技术标准

      RFC1035定义了DNS协议数据单元最初的形态。伴随着互联网“应用”在效率、安全、稳定性等方面提出新要求，DNS内核，包括DNS协议数据单元格式、DNS消息传输模式以及DNS会话管理等技术要素也随“网络”技术一道发生变化，以回应互联网“应用”的新要求。

4.1 DNS协议数据单元扩展

      首当其冲的DNS协议内核变化是DNS协议数据单元。以DNSSEC为代表的DNS新技术让DNS消息尺寸开始膨胀并超过经典的512字节UDP限制。为了尽可能避免使用TCP作为传输机制带来的开销，IETF定义了一种称为EDNS0（RFC6891, Extension Mechanisms for DNS）的DNS报文扩展机制，并在字段设置上进行了一系列规范。EDNS0技术标准的出现，让基于UDP的DNS报文具备了支持更大的“载荷尺寸”的能力，为DNSSEC的部署以及今后其他应用奠定了基础。

4.2 DNS消息加密信道

      尽管DNS是一种公开查询系统，但用户的DNS查询行为存在泄漏隐私的风险。DNS消息的加密传输机制成为近年来工业界和学术界一个热门的研究话题。目前，在IETF形成工业标准的方案有两种：其一是面向DNS的TCP传输机制，使用TLS来构建加密信道（RFC7858, Specification for DNS over Transport Layer Security）；其二是先将DNS的协议数据单元使用结构化语言表达（例如JSON），再适配到HTTPS消息中进行加密传输（RFC8484, DNS Queries over HTTPS）。值得一提的是，DNS消息加密信道一般部署在DNS解析终端和DNS递归解析服务器之间，而不是DNS递归解析服务器和DNS权威服务器之间。

4.3 多播DNS

       为了在局域网（一个广播域）提供一种“零配置”风格的服务发现机制，美国苹果公司的技术专家提出了多播DNS的概念。多播DNS复用现有DNS消息结构，向广播地址（IPv4地址224.0.0.251或IPv6地址FF02::FB）上的5353端口发起域名解析操作，实现了在没有传统专用DNS服务器的情况下局域网内的主机之间的相互发现和通信。相关技术标准（RFC6762，Multicast DNS; RFC6763, DNS-Based Service Discovery）对多播DNS协议以及基于多播DNS的服务发现机制进行了规范。

4.4 有状态DNS

      “仅适用于局域网（一个广播域）”是基于多播DNS的服务发现机制的天然制约。技术文档（RFC7558, Requirements for Scalable DNS-Based Service Discovery / Multicast DNS Extensions）明确指出，在多链路网络和低功耗网络之上实现基于DNS的服务发现需要新的技术。改造单播DNS来实现可扩展的服务发现机制成为工业界的共识和IETF标准化的方向。但是，传统的单播DNS被设计用来查询相对静态的数据。在轮询频率不是太高的情况下，传统单播DNS能够有效地返回更新结果。为了能够让用户实时获取服务信息的变化，一种称为“DNS主动推送”的方法被设计出来。基于该方法，DNS 客户端向DNS服务器订阅“感兴趣”的资源记录集合，从而获得信息更新的异步通知。DNS主动推动机制在传统的“基于UDP的无状态DNS” 框架内是无法完成的。为了支撑DNS主动推动机制在“订阅管理”“解析状态管理”等范畴的技术特征，“有状态DNS”技术标准应运而生。“有状态DNS”的诞生，改变了传统DNS的“尽力而为”模式，把DNS查询变成一种可靠的面向连接的通信机制。“有状态DNS”是DNS诞生以来一次革命性升级，提高了DNS在不同网络环境的适用性，为未来“网络”技术的创新提供了巨大潜力。相关技术标准（RFC8490, DNS Stateful Operations; RFC8765, DNS Push Notifications）对“有状态DNS”协议以及基于“有状态DNS”的DNS主动推送机制进行了规范。

DNS技术标准发展总结与展望

      互联网的“网络”和“应用”在持续演进和分化。5G核心网（边缘计算）、工业互联网、卫星互联网的部署，不仅为“应用”构建了不同物理特征的网络环境，也带来了更为复杂的信任模型。DNS技术体系如何扩展适配到新的互联互通环境和信任模型，是值得持续探索的方向。笔者认为有三点值得注意：

1）DNS技术组件复用

      本文在“DNS基础功能扩展”、“DNS认证功能扩展”两个部分介绍了若干利用DNS将各类“网络”信息及“应用”信息附着到域名（主机名）之上的案例。这种成熟的方法值得继续发扬。学术界和工业界有声音认为，不应加重DNS的职责负担，从而影响其核心功能“IP地址解析”。这种观点有道理，但不能因噎废食。在实际操作中，需要合理地设计名字空间（授权关系）和物理资源分布，将DNS的核心功能和扩展功能分流到不同的计算资源节点。同时，实施方案注意区分“技术”（设备、代码）和“标准”（互联互通规则），实施主体可以先在试点网络复用DNS的技术组件启动“私有化实现”的DNS资源记录类型。如有国际范围的互联互通需求，可以在IETF谋求国际标准化的DNS资源记录类型。

2）新互联互通条件下的DNS

      DNS诞生于窄带网络时代。互联网的先驱们精妙地设计了DNS的协议数据单元和交互机制，最大程度地保障DNS这一基础服务的可用性。但当时的限制条件（带宽、计算、存储）在今天乃至未来的网络已不再成立。笔者认为，DoH（RFC8484, DNS Queries over HTTPS）出现的意义，不仅仅是提供了一种DNS消息加密机制，而是展示了一种协议数据单元和协议传输消息相互独立（解耦）的可能性。这种“可能性”（应用层之下的会话层、表示层）在OSI七层模型里就有“顶层设计”。但受制于TCP/IP诞生时代的没有实施。面向未来网络对更安全、更高效、更易扩展的DNS的需求，DoH的发明和标准化为DNS数据传输机制的改造探索出了一条新路。

3）不同网络边界的DNS

       脱离了网络管理边界来泛泛地谈网络设计是“无源之水”。对于一个具体的管理域（家庭网络、企业网网络、运营商网络等）来说，“内网”和“外网”背后所蕴含的不同信任模型是统筹“网络”和“应用”设计的关键（效率和安全的权衡）。RFC1035所定义的DNS本质上是一种“外网DNS”。因此传统DNS技术特征在应付“内网”（包括企业内网、以及“云”“边”的计算系统）场景需求时显得不是得心应手。有状态DNS（RFC8490, DNS Stateful Operations）起源于“企业内部网络”，在DNS的会话管理上另辟蹊径，基于DNS服务范围从“发散”到“收敛”的改变，提出了一种具有连接和状态管理功能的DNS服务。面向特定专用网络低时延、高可靠的DNS的演进需求，持续挖掘有状态DNS的扩展能力以及在不同网络的部署机制，是一个非常有价值的研究方向。

¹：https://powerdns.org/dns-camel/

²：ITU-T, X.672, Information technology – Open systems interconnection – Object identifier resolution system