前言
近期ICANN CTO办公室发表了一篇《2021年IETF年度回顾》文章。文章列举和概述了2021年发布的与DNS有关的RFC标准，值得DNS技术同学参考。然而IETF标准工作流程复杂周期长，一个标准从想法到发表RFC少则1年，多则3到5年也不鲜见。技术小伙伴可能更感兴趣的是当前技术社群发现了什么新的技术问题，有什么新的技术创新想法。也有的读者可能不关心技术细节，只希望了解DNS技术讨论的趋势和方向。本文笔者不限于已经发表的RFC，将概述近两年IETF技术社群热议的技术话题和大致分类，并附上笔者自己的一些注解，希望对读者有一些启发和帮助。如果对文中介绍的具体的技术点感兴趣，可以点击文中链接深入了解。
注： 本文主要关注DNS技术方面，IETF DNSOP, DPRIVE, ADD三个工作组的工作，不包括域名注册协议的工作。
DNS域名系统简介
互联网域名系统（DNS）提供了服务名称（域名）和IP地址两种标识符体系之间的衔接转换。绝大多数互联网应用，如在线支付、视频会议、电子邮件等，均需依赖域名系统实现网络资源的寻址及定位（更多请参考：阿里云DNS）。作为互联网的中枢神经，域名系统在网络安全体系中起着至关重要的作用，域名系统作为核心网络基础设施的地位也正在得到愈发广泛的认同。域名解析服务的平稳运行，是互联网互联互通与安全稳定的基础。大量安全事件已经表明，对于普通互联网用户而言，一旦域名解析服务发生故障，其后果与直接中断网络服务无异。
IETF DNS相关工作组概述
IETF（Internet Engineering Task Force）是国际互联网协议标准组织，我们熟悉的网络基础协议TCP/IP，DNS，OSPF, BGP，包括最近热门的QUIC 协议都是这个国际组织负责制定和维护。IETF的标准化工作主要分为路由，传输，互连(IP相关), 运行管理, 安全和应用几个领域，有超过100多个活跃的工作组来组织技术讨论。
DNSOP工作组负责了IETF 大部分DNS相关的工作，虽然DNSOP是IETF 运行管理（OPS）领域的工作组，但是有关新的DNS协议扩展和创新也是在这个工作组来完成。DNSOP是很繁忙的工作组，在过去两年（2020-2021）DNSOP工作组共发表了13篇RFC，队列中仍然活跃着10篇的工作组草案和19篇个人草案。
2014年IETF 成立DPRIVE工作组，主要关注与DNS隐私保护相关的标准和相关技术讨论，在其上开发了多个DNS加密传输协议，包括DoH，DoT, DoDT，包括如今比较热门的DNS over QUIC。工作组工作由用户侧到递归的加密传输，转向递归到权威加密传输。在过去两年（2020-2021）DPRIVE工作组一共发表了3篇RFC，队列中仍然活跃着2篇工作组草案，5篇个人草案。
最近两年由于应用层DNS，尤其是加密DNS的兴起，为了更好的专注于DNS客户端在各种网络环境中发现和选择DNS解析器，包括公共网络、私有网络和vpn，支持加密和非加密的解析器，2020年IETF成立ADD工作组来开发客户端DNS服务发现和配置协议。ADD工作组刚刚成立不久还没有发表RFC，但是在过去两年热度不减，队列中活跃着4篇工作组草案，8篇个人草案。
主要方向和热点工作
如果把IETF DNSOP，DPRIVE 和ADD工作组的标准、提案和技术话题分类的话，主要有4大几个方向：
1. DNS配置和部署（Provisioning & Deployment）
这个方向主要关注的是通过开发DNS新协议和新服务，更好的部署和运行DNS服务，例如定义新的RR，EDNS0 扩展，新的DNS运行机制等。下面是一些特点讨论和技术草案。
- 今天许多企业会使用多个DNS提供商来托管权威的DNS服务，并且要求根据不同的链路请求智能应答。如果企业的zone需要支持DNSSEC（在线签名模式），就需要支持多个签名者和多份密钥的管理。RFC 8901介绍了一种新的DNSSEC 签名模式，允许多个签名者（Multi-Signer）采用独立或者共享部分密钥的方式签名。RFC8901发布之后，草案dnssec-automation提出了一种算法和协议来让多个签名者的DNSSEC模式实现自动化。
备注：笔者曾经参与撰写的RFC8483也是针对多签名者的DNSSEC方案，不同的是RFC8483是在根区实现多方签名，只能使用同一个KSK和多个独立的ZSK签名（根区的KSK是信任锚，比较特殊）。RFC8901是针对非根区的普通zone，因此可以采用独立的KSK和ZSK来部署多签名者的 Multi-Signer DNSSEC。 |
- 在DNS服务运行中经常会遇到权威服务器不应答或错误应答的情况，RFC 8906提出一个最佳实践，介绍了各种异常应答的场景和问题，并给出针对这些应答异常对权威服务器的测试和评估方法，以及对DNS用户和服务运营者的建议
备注：除了在攻击限流情况下，DNS服务器都需要回应查询，即使这个域名不存在或者不再服务器上托管解析。在实践中，错误的应答或不应答都会干扰递归服务器的判断，进而还会影响递归的NS选择算法。 |
- 在网络管理和配置数据建模领域，IETF有一类工作是对各种协议定义对应的YANG数据模型，便于通过NETCONF协议来对网络设备进行管理和配置。RFC 9108为DNS Class 和资源记录数据定义了一些新的YANG类型和标准术语，可用于网络建模。关于YANG数据模型请参考NETCONF和YANG的相关介绍。
- 主从服务器的zone文件配置同步是一个需要需要考虑的运维问题。一般的做法是管理员手工配置增加和删除，或者用外部管控程序来自动化这个操作。为了在DNS内部实现主从服务器配置同步， 工作组草案catalog-zones引入了一个记录权威服务器zone列表信息的 “目录区catalog zone”。主服务器可以通过catalog zone与从服务器保持zone配置信息同步，减少手工或外部应用同步配置文件的风险。
- DNS应答数据中 In-domain的glue记录会放置在Addtional Section中，并不是必须携带的信息，如果包文大小超过了Bufsize, glue记录只会保留一部分（注：Glue是NS记录的地址记录）。工作组草案glue-is-not-optional修改了这个行为，要求in-domain的glue地址记录因为报文大小限制不能完全放入addtional section部分，这篇新的工作组草案要求服务器设置TC=1，客户端需要重新发起TCP的DNS查询。
备注：In-domain glue记录的存在是因为一些zone会把子zone授权的的NS记录设置成子域名，例如example.com 的NS记录是ns1.example.com，这样的NS域名称为“Bailiwick”或“in-domain”域名，它IP地址记录就叫做in-domain glue。如果应答没有Glue记录，递归就无法访问到example.com的权威服务器。 |
- DNS故障排查中经常需要回答“who answers my query?”。因为很多zone托管在多个权威服务器集群，并采用Anycast部署，不同的服务器可能会出现zone版本不一致的情况，导致使用陈旧数据的解析错误。工作组草案RRSERIAL EDNS option提出一个DNS协议扩展，在应答数据中携带zone的版本号（SOA序列号），用来排查这个应答的源头服务器服务了哪个版本的zone文件。
备注：类似与NSID通过EDNS0扩展携带主机信息，RRSERIAL和NSID一样只能支持hop-by-hop传递信息，不能够通过递归转发。另外笔者也曾发信给草案作者，这个方案除了故障排查的场景，另一个应用场景可以是递归通过比较SOA序列号来判断这个应答是否可以被接受。 |
- 【热点讨论】DNS除了能提供域名和地址解析功能外，还能够应用在服务发现和协议配置场景。为了更好增强DNS和应用在云端部署的安全、隐私和性能提升，ADD有一篇工作组草案svcb-https-RR通过引入新的资源SVCB和HTTPS两个新类型的记录，允许客户端在连接之前通过一个DNS查询做初始化，获得更多端点服务和参数信息，例如HTTPS连接的端口号/IP参数，ESNI/ECH公钥信息，zone顶端名字的CNAME记录等。
备注：这个工作草案是近几年的热点提案，获得包括apple， cloudflare等大厂的支持。IANA已经为SVCB/HTTPS授权了64/65作为新纪录的RR type号，该标准已经进入尾声。DNS将聚焦应用和智能终端的场景，用于服务发现、自动化配置、智能解析的需求，为云+端信息流通提供了更多可能。 |
2. DNS弹性和高可用（Resilience）
这个方向主要关注在各种复杂和有风险的互联网场景下，如何保证DNS稳定运行和服务高可用，例如应对DDoS风险，减少外部网络依赖，故障避免和恢复等。
- 长期以来国内外对DNS根服务器都有一些争议，实际情况是全球有13个根服务器和上千个镜像，由12个机构运营，ICANN和VeriSign分别对根区进行编辑和签名。中国没有根服务器运营权，但是有20+个根镜像。为了减少根区访问依赖外部根服务器，也为了减少DNS访问根区时可能的信息泄露风险，RFC7706提出了在本地运行根区副本的想法，达到降低根区解析延迟和减少DNS信息泄露的目标。该标准也被看成是一种通过本地根区解析达到“去中心化”的根服务器解析方案，RFC 8806是对RFC7706的更新, 放松了一些本地部署的限制支持更灵活的软件部署，增加了本地根解析失败后切换到全球根解析的能力，更新了在线的根区副本下载链接。
备注：ICANN在2021年发布了《超本地根区技术分析Hyperlocal Root Zone Technical Analysis》。据笔者了解ICANN鼓励有能力的运营者在本地运营一个本地根，以避免根服务器相关争议性问题。本地根的方案可以与ZONEMD RR（RFC 8976）结合使用，ICANN 根区演进审查委员会（RZERC）建议根区考虑研究增加ZONEMD记录。 |
- 当递归缓存数据超时无法更新数据时，会回复SERVFAIL。然而DNS这类“松散”协作的分布式数据系统，“有陈旧数据总比没有好”。因此为了提高DNS弹性，RFC 8767定义了一种递归服务器使用陈旧数据来应答查询的方法。该方法主要是应对递归服务器无法刷新缓存数据的场景，例如权威服务器被攻击，无法应答。该标准建议陈旧数据最多可以使用7天。这个方法也会让一些瞄准权威服务器的攻击方式失去吸引力。
- DNS RCODE 对异常只有有限的几类，如NXDOMAIN, NODATA, SERVFAIL, REFUSED 等。 相对DNS各种异常情况，并不能准确描述。因此RFC 8914引入了一个新的DNS协议扩展Extended DNS Error（ENE）功能，来支持DNS服务器返回给用户更加丰富的Error信息。例如递归采用RFC8767的方法使用陈旧数据应答，该应答可以结合SERVFAIL 的RCODE再返回EDE Code 3，代表这次查询应答超时，但是应答提供的是陈旧数据。这个标准还定义了“不应答”的几种ENE Code，区分了因为政策审查（censored）、安全黑名单(Blocked) 或 用户黑名单 (Filtered)，具体参考标准文本。
备注：另外有一篇工作组草案draft-ietf-dnsop-dns-error-reporting提出了一个故障报告机制，基于Extended DNS Error（ENE）定义的DNS解析错误信息，通过特殊构造的域名如_er.7.1.broken.test._er.a01.reporting-agent.example来报告给服务器a01.reporting-agent.example。这个故障报告机制可以帮助域名服务商及时发现问题，优化服务。 |
- IP分片会导致各种网络问题（RFC8900），而DNS是受到影响的协议之一，会导致丢包和DNS服务超时。为了减少DNS报文分片，一篇工作组草案 draft-ietf-dnsop-avoid-fragmentation建议通过设置合理的DNS报文大小参数，避免DNS传输过程中遇到IP分片。该草案还建议通过减少一个zone的NS数量，A/AAAA数量，采用ECDSA/EdDSA代替RSA等方法来减少相应报文大小。
- DNS解析过程会可能存在解析循环（DNS loops），例如A和B zone通过CNAME或者NS设置制造解析循环，消耗DNS技术资源。 negative-cache-loop本文档更新了在递归解析器算法中检测DNS环路的方法，要求递归解析器检测环路并通过实现Negative Caching（否定记录或不存在记录的缓存）来减少解析循环。
3. DNS安全和隐私保护（Security and Privacy）
这一块主要涉及到DNS服务的安全加固和隐私，例如DNSSEC数据签名和认证，DNS数据摘要，DNS加密传输，DNS隐私协议等，尤其是DNS隐私安全方面是最近5~6年来IETF的持续热点工作。
- 2021年发布的 RFC 9076DNS隐私考虑 是对6年前 RFC7626的更新和再版，丰富和完善了DNS在 数据、传输、服务器三个主要方面的DNS隐私风险，增加了最近今年DNS隐私的实践、运营经验和研究成果，是DNS隐私领域必读的一个标准文本。
- 在DNS加密传输领域IETF有大量的标准工作，从DoH，DoT, DoDT到近两年热门的DNS over QUIC（dnsoquic），在保证隐私加密的前提下，利用最新的传输协议QUIC来传输DNS。从加密传输场景来看，标准工作由用户到递归的加密传输场景，逐步转向递归到权威加密传输场景，讨论非认证（unauth-to-authoritativ）和认证（adot-auth）两种方式。
- 【热点讨论】由于DNS流量的中心化趋势，采用DoH/DoT的用户DNS查询信息也会集中在少数DNS运营者手中，例如Google的8.8.8.8和 Cloudflare 的1.1.1.1. 。为了减少DNS集中化带来的隐私问题，由Cloudfalre和APPLE 主导提出了 ODoH（oblivious-doh），它的想法是通过访问一个DNS Proxy 来访问递归DNS，将DNS QNAME信息与用户源地址分离，提供极致的匿名和隐私保护技术，所以ODoH也被成为匿名DNS。然而由于解析性能降低（延迟增加，调度精准度受影响），增加了系统复杂度的问题，而且ODoH的支持者说它已经被广泛部署，不愿意接受IETF的改动，因此ODoH 作为标准类草案并没有被工作组采纳，而是一个独立提交的ISE实验类草案（Experimental）。
备注：去年ODoH的讨论引起了技术社群很长时间激烈的讨论，支持ODoH的网络应用领域的人群 VS. 反对ODoH的网络运营和DNS开发领域的人群，让笔者回想起DoH标准制定的过程。一些技术人员甚至质疑ODoH增加了DNS的复杂度，让只有少数大型DNS运营者才有能力提供ODoH，从而加剧DNS服务的集中化。 |
- DNS隐私保护除了传输加密，DNS协议行为的隐私保护也是一个重点方向，其中DNS Padding(RFC 7830)和 Qname Minimization（RFC 7816）是主要的两个工作。2021年发布的RFC 9156是对RFC7816的更新和补充，由于Qname Minimization在过去几年被广泛部署，大部分递归服务器软件已经支持该标准，于是IETF将Experimental的转变为Standard Track。
- DNS Cookies (RFC7873)是一种轻量级的DNS事务安全机制，通过创建Cookie的方式为DNS服务器和客户端提供保护，防止伪造地址的各种拒绝服务放大、伪造或缓存中毒攻击。RFC 9018 介绍了一种DNS Cookie创建方法，支持不同类型DNS服务器在Anycast场景下的互联互通，并能够更好的保护用户隐私。
- RFC 8976引入了一个新的DNS资源记录ZONEMD RR，类似许多软件安装镜像发布后携带的MD信息, ZONEMD是对整个zone数据做消息摘要，保证zone文件在传输之后的数据完整性和真实性，有利于DNS区文件在互联网传输、复制、存储。从计算开销看，ZONEMD记录特别适合更新不频繁和比较小的zone，例如根区Root zone, 因此ICANN 根区演进审查委员会（RZERC）建议根区考虑研究增加ZONEMD记录。
备注：笔者认为在越来越强调本地闭环解析，不依赖外部基础设施的前提下ZONEMD会被用到更多场景，比如RPZ的区文件，中心化的区文件数据服务等。因为当DNS的区文件会经常通过互联网传输、复制、存储，对其进行消息摘要是一个必要功能，而且ZONEMD会覆盖DNSSEC 没有覆盖的内容，比如授权NS记录等。 |
- 由于采用DoH/DoT可能会破坏本地网络的网络安全策略，例如绕开本地DNS解析和防火墙，因此在DNS安全和网络管理领域有一类是如何发现和认证DNS加密服务或内网DNS服务，支持本地名字空间的DNS配置解析（split-dns），这些技术标准主要在ADD工作组讨论。2021年ADD的主要有三方面工作：使用动态主机配置协议(DHCP) 来指定网络中哪些解析器是可用的，帮助发现DHCP中没有出现的解析器的协议，以及在DNS中携带关于解析器的信息的格式。感兴趣的读者可以关注ADD文档页查找相关草案。
除了DNS隐私安全，DNSSEC也一直是IETF DNS领域的热点，不断有新的提案被提出，受限于篇幅就不在本文展开，对DNSSEC感兴趣的读者可以访问DNSOP文档页查找DNSSEC/NSEC相关技术草案文档
4. DNS运行指南和要求 （Operational Guidelines and Requirements ）
IETF有一部分技术标准草案聚焦早操作指南和技术要求，用于给DNS运营者参考，有一些草案最终可能不会成为标准RFC，但是也是有经验和研究结论的总结，具有参考意义。
2020-2021年有几篇草案分别介绍DNSSEC 解析器运营建议，大型权威DNS运营者建议，NSEC3的操作指南，DNS TCP的技术要求。其中对大型DNS运营者建议的草案值得DNS运营者注意，里面梳理了学术界对基于Anycast DNS业务的测量研究和建议，值得一读。
小结
梳理IETF DNS的技术讨论，主要在DNS安全、隐私、高可用方面。最近加密DNS（Encrypted DNS）和DNS业务发现配置成为热点，充分说明了以网络连接为中心的DNS 不断往以应用为中心转变，一方面DNS从传输协议上与应用传输协议不断对齐，不再单一的使用UDP/53 ，而是HTTPS/QUIC等，可以复用Web应用基础设施来提高加密、有连接的DNS运行效率，让智能终端和应用更快的连接上云上资源；另一方面云端的应用和业务可以通过DNS对智能终端和应用主动宣告和推送配置，让应用能够下沉与DNS结合，代表性的标准工作有svcb-https-RR，标准还未制定好就大规模的部署和应用起来。
IETF不仅仅是互联网协议的国际标准组织，也是互联网/网络工程师技术交流的平台。DNS工作组中就活跃着不少欧美主流互联网公司，网络运营商和各国网络中心的工程师。关注IETF DNS的技术讨论和话题趋势，对我们自身技术研发、架构设计和业务运营都有帮助。
附：阿里云DNS介绍
阿里云DNS（Domain Name Serivice）是国际领先DNS服务商，提供了全系列一站式的域名解析服务产品，覆盖了公网域名解析、内网域名解析、全球流量调度、移动解析以及专有云的域名解析场景。阿里云DNS在业界率先提出了云端一体技术和产品架构，为云上云下多样化的连接场景帮助企业实现数字化转型，为移动APP、智能终端/IoT、家庭/企业网络提供安全、稳定的连接和智能调度服务，当前平台日均解析服务量突破万亿。
