宋林健
宋林健_个人页
宋林健
文章
2
问答
0
视频
0
个人介绍
暂无个人介绍
擅长的技术
-
发表了文章 2023-01-28
谈谈《流浪地球2》中如何正确的“重启互联网”
昨晚笔者和家人一起看了流浪地球2，延续了第一部的风格，是近期少有的国产硬科幻电影。片中各种脑洞大开，各种科技设定可圈可点，例如太空电梯，数字生命，地球发动机，量子计算机，人工智能等。但是作为互联网从业人员，当我看到其中刘德华故事线中大篇幅的关于“重启互联网”的故事情节，身上就难免有一些做痒。看完电影之后，再翻看影评有对流浪地球2科技设定的讨论，其中就有讨论重启互联网，尤其是关于重启根服务器，又带出网络一波根服务器科普的讨论。笔者在这里希望借着流浪地球2热播的档口，聊聊自己的看法（赤裸裸的蹭热点），同时YY一下如果流浪地球2的导演来找笔者咨询“重启互联网”的技术问题，我又能够提供哪些有价值的建议？“重启互联网”为什么要重启根服务器？第一个问题笔者想讨论的是，“重启互联网”中的根服务器是什么根服务器？在观影过程中笔者没注意到具体是什么根服务器，但是当根服务器成功启动，电影有两个画面都显示了 “互联网域解析成功”的字样。这个在互联网专业人士眼中，一般指的是互联网域名解析。笔者也倾向于相信电影中的根服务器大概率是DNS根服务器。相信流浪地球2的主创团队在设计该情节的时候肯定咨询了互联网相关技术专家，询问互联网有哪些是中心化的基础设施，缺少它就不能运转，价值大到能够让主角牺牲的程度。笔者猜想技术专家们可能指向了域名解析系统（DNS）根服务器。简单说，域名根服务器是一颗树状的层次化域名-IP数据库，查询一个域名的IP就必须从根服务器开始进入。所以DNS根服务器被誉为是互联网的神经中枢，是互联网访问的入口。 为啥重启互联网需要重启根服务器了，新建不行么？由于互联网几乎所有的设备、网络系统、用户都预设了固定的13个DNS根服务器作为域名解析的访问入口，在国内也经常听说谁谁谁在根服务器上搞破坏，就能够让某国某公司从互联网消失的新闻和报道。笔者谨慎估计电影主创团队在这点上受到了一些影响。互联网是中心化的么？“重启互联网”情节争议的一个主要原因是互联网中心化的设定。而大部分技术同学认为“真实的互联网是非中心化的分布式的部署方式，不存在绝对中心”。而电影中“重启互联网”情节需要所有国家根服务器都启动，达到100%才能成功。电影中出现了中国北京，日本东京和美国杜勒斯（杜勒斯机场？），有没有别的国家不确定，但确实是“一个也不能少”的情节。这好像与当前互联网的运行现状不符合，也是一些观众看到这里有一些违和的原因。 先不说电影情节的需要，仅从技术角度说，笔者认同互联网（Internet）是网络的网络(network of networks)，不存在“绝对的中心”，但是存在“相对的中心”，尤其是在互联网平台型基础设施领域。举个例子，现在大家都用微信聊天，如果哪一天微信突然掉线了，虽然一些联系人还能通过电话，email沟通，但是方便、快捷程度，和一些微信的功能可能都无法使用。所以出于网络互联互通、协作、高效、安全的需要考虑，互联上出现了很多“中心化”的平台和企业，互联网流量也集中在少数大的服务平台上。就拿笔者熟悉的DNS领域来说，有研究表明在全球排名前10万的流行域名之中，有89%的域名使用了平台型的域名解析服务，这些平台的安全稳定性出现问题，也会导致互联网大规模的故障。所以回到电影中互联网“中心化”的设定，如果重启的如果不是互联网（Internet）而是地球发动机专网(Intranet)，或者是某一个关键同步网络（sync network）可能瑕疵就没有那么明显了。另外开个脑洞，站在科幻电影的角度流浪地球计划的年代是距今30-40年后，DNS根服务器可能已经不再是层次化树形的组织形式，说不定已经用区块链把不同国家以联盟的形式都连接起来。互联网名称与数字地址分配机构ICANN还在不在也不好说了。看电影中我国在联合国的影响力，全球人民都跟着中国流浪地球方案走，那个时候互联网名字空间指定是我国主导了，需要值得信任的大国来启动关键的根服务器~这也不是不可能。“重启互联网”的架构视角从互联网架构视角看，重启互联网需要考虑那些方面了？互联网发展至今网络基础设施形成了至少三层结构的互联互通，即物理链路层互通，网络自治域AS互通，域名寻址调度的互通。只有这三层都恢复重启，互联网信息高速公路才算开通，各类应用才能平稳运行。物理层链路层互通比较好理解，就是我们看得的服务器，网络设备之间需要有物理通路，用光纤、网线连接。笔者猜测电影中需要重启互联网的原因，就是利用地球发动机已有的物理层和网络设备。所以电影中默认，物理链路层已经重启开通。电影中也提到地球发动机网络都有局域专用网络，重启互联网需要将各个专用局域网络连接起来，用公共的IP地址来进行互通，这就是自治域网络（ASN）之间的互通。不同的ASN网络按照BGP协议建立路由转发，打通IP通路。如下图，AS1，AS2和AS3分别代表三个不同的地球发动机的专有的网络，他们可以按照下图建立BGP协议。其他的地球发动机网络也可以分别和他们建立连接就可以与其他网络互通。重启了自治域网络的互通，互联网的应用还需要域名寻址调度的互通。域名寻址调度的互通一方面专网中的设备需要能够访问全局的域名系统，用户可以访问DNS的树状的层次化域名系统，这里DNS根服务器作为顶层解析入口的作用至关重要。注意：电影中没有提到需要修复物理链路（比如海底光缆），也没有提到需要建立网络间路由（专网之间互通），而只是重启根服务器，这说明当初关闭互联网是从DNS根服务器层面来切断互联互通的联系。联想当初俄乌战争期间，乌克兰也希望国际互联网组织通过根服务器切断俄罗斯的互联网。另外，需要把专网之间连接起来，专有网络内部的私有域名需要转化成公共的域名才能让其他网络用户访问，实现全网的互联互通。例如将AS1网络中abc.local 的域名转换成 abc.AS1.com，或者申请新的顶级域来专门为流浪地球计划使用。影片中出现的域名 500W-IN.PENGINE，有可能就是新增的顶级域名。通过以上三步的互通，重启互联网就有了基础的设计蓝图。关于量子计算在电影中550A/550C/550W量子计算机给我们印象深刻，为流浪地球发动机系统启动，破解无人机系统提供强大算力。那如果在流浪地球具备量子计算能力的背景下谈“重启互联网”还需要有什么技术上的考虑？笔者能想到 只是重启根服务器可能不够，因为不得不考虑可能遇到流浪地球计划反对者的攻击，让根服务器即使正常启动之后也不能正常工作。例如防范DNS解析结果被劫持和投毒的传统DNSSEC签名、传统TLS传输 加密强度可能不够用了，攻击者可以快速破解密钥算法。 跳出电影的视角，笔者观察到现今已经有不少人开始考虑和担心当将来大规模量子计算的发展后，现在广泛使用的加密算法如RSA和ECC会更容易破解。出现了不少后量子时代（POST-QUANTUM ）算法的研究和讨论，例如美国在2016年就开始的后量子密码学项目（Post-Quantum Cryptography project），到今天已经更有多轮讨论。对DNS的影响是DNSSEC采用的签名算法。现在后量子算法的一般的做法是通过加大密钥长度和签名长度，增加加密的强度。但是这样会让DNS的UDP应答包更加大，容易丢包，让网络DNS解析不稳定。从这个角度看，未来有连接的DNS over HTTP/TCP/QUIC一定会代替无连接DNS over UDP成为主流，来应对量子计算的影响。在电影中如果要充分考虑黑客对抗因素，重启互联网不应该仅仅只是重启现有的根服务器，而是替换新的根服务器，或者上传新的加密算法抵御可能的量子攻击。有哪些建议可以让电影情节不那么违和？最后YY一下如果电影导演当初来找笔者来咨询“重启互联网”的情节和设定，我可能会给他很多输入。包括别重启互联网了，重建吧，上新设备新的技术；不能再用IPv4，一定是IPv6-only起步；根服务器咱们国家先留几个；中文域名要优先支持咯。。。但考虑到对剧本不做大的改动，最主要的一个修改建议：“重启互联网”要求所有根服务器必须都成功启动，“一个也不能少”的设定可以适当放松。改成三个主要国家根服务器只要一个成功上线就好，这也是当年雪人项目三方签名的基本原理。具体到电影中可以让美、日都没能成功启动，就中国破除艰难成功启动了。一方面可以弘扬爱国主题，另一方面给互联网设计者一点面子，考虑网络系统冗余设计（redundancy）的原则。好了，以上是一个互联网从业人员的碎碎念，也蹭个热度~补充一文章发出去之后，收到了不少互联网专家朋友的意见。其中有几位专家们对电影中“关闭互联网”的设定有一些质疑。互联网的前身ARPANET当初的设计目标是在战争和极端环境，通过分布式网络、多链路冗余，保证网络的互联互通。互联网理应在流浪地球灾难的背景下发挥作用，但是电影中仅仅因为惧怕黑客攻击或者风险就关闭互联网。为什么不考虑对关键系统安全加固和隔离，引入新技术做好防御，而只是对基础设施“断网”、“脱钩”了之？所以从这一点来看，还真应该给导演们上上课，电音艺术的背后有对互联网的理解，对人类未来的信心。补充二电影科学顾问团成员的一篇 如何评价电影《流浪地球 2》？ 里面解释了为了减少“开机风暴”避免大规模DDoS攻击，为了保险起见，需要重启三台根服务器。其实现实世界中，互联网根服务器不会只有三台，而是有很多名字服务器（NS服务器），当初雪人计划有25台NS服务器。为了负载均衡和增加应答相应速度，每个域名服务器也会在不同的网络位置部署镜像，现在全球有1600+台根服务器。当根服务器启动，会同步数据到全球的镜像。数据会访问最近的镜像，不会直接访问主根服务器，因此不会产生“开机风暴”这样的极端事件。
-
发表了文章 2022-02-25
2020-2021 IETF DNS技术热点分析
前言近期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、家庭/企业网络提供安全、稳定的连接和智能调度服务，当前平台日均解析服务量突破万亿。
2023年01月
-
01.28 17:38:56
发表了文章
2023-01-28 17:38:56
谈谈《流浪地球2》中如何正确的“重启互联网”
DNS是互联网域名和IP转换，寻址调度的重要的基础设施，是互联网中少有的相对中心化的环节。《流浪地球2》中有一个重启互联网，重启(DNS)根服务器的情节，过程惊心动魄，但是从互联网专业视角看仍有一些小瑕疵。观影后笔者撰写小文，聊聊如何正确的“重启互联网”。
2022年02月
-
02.25 16:39:06发表了文章
2022-02-25 16:39:06
2020-2021 IETF DNS技术热点分析
域名系统（DNS）是互联网基础服务和协议，为互联网服务及资源名称（域名）和IP地址两种标识符体系之间的衔接转换，为互联网可扩展性，应用部署的灵活性，和业务安全稳定提供了基础能力。进入移动互联网和云平台时代，DNS作为核心网络基础设施的地位也正在得到愈发广泛的认同。IETF是互联网技术权威标准组织，也是DNS技术定制标准的主要阵地。本文将概述过去两年（2020-2021）在IETF DNS技术热点，包括当前DNS技术社群讨论的技术问题，创新想法，话题趋势和方向。
滑动查看更多
暂无更多信息
暂无更多信息