1、 构建和部署一个新的域名服务器 – Facebook

facebook内部自2012年开始使用tinydns去做域名的解析服务，tinydns本身支持ipv6，基于CIDR的匹配和ECS匹配解析，facebook本身业务主要需求的特性功能是基于DNS递归的视图分离和ECS视图分离解析。

尽管tinydns比较简单，但是扩展性不足，另外语法和程序语言级别也存在很多问题，所以facebook决定寻求其他的解决方案去实现。对于其中需求的两个核心特性支持上，其他开源解决方案对比如下：

同时作者也介绍了，即便是存在解决方案，他们也需要后期很多的工作去集成到当前的处理流程中，另外还要考虑如何与当前的其他系统（数据检查系统，运维系统）的集成。

另外他们也考虑了使用支持插件化的DNS软件解决方式，比如CoreDNS。 为了验证可行性，工程师开始基于CoreDNS的相关的调研和开发工作。

• 三周时间的开发和测试，
• 两周时间的bug修复和并行运行，
• 两周时间去除不需要的依赖和构建单独的UPD和TCP处理层，重用一些CoreDNS服务组件.
• 一个月左右时间完成Logging,监控，重构性能测试和优化等工作。

部署后的系统得到逐步的替换过程中也解决了一些运行问题以及CoreDNS相关的Issue。另外提到了一些比如dnsperf等测试工具。

2. Alibaba云DNS-阿里巴巴

来自Alibaba的工程师介绍了其云DNS服务， 提到了一些数据比如日均解析量达到1000亿次，提供2000万区数据的管理，通过DNS管理百万级别的虚拟主机，以及10000多的内部私有区数据管理。20个数据节点提供域名解析，网络连接以及流量调度和故障处理等

同时工程师提到他们也会积极响应社区， 更新版本来支持一些比如DNS-FlagsDay项目提供TCP支持，DNSSEC支持以及考虑RFC7706和引入镜像根的方案提升解析效率、

介绍了几个使用实例：

• 权重DNS响应，通过配置不同解析记录的权重值，来使得用户能够根据权重来获取最终解析内容，类似于DNS端的LB配置
• 给VPC和隔离网络提供的DNS解析
• 应用层HTTPDNS的SDK提供整个的域名解析服务，绕过ISP的解析。

会场提到的两个问题：

1. facebook工程师提到如何保证10秒内高效的数据下发？ 稳定的链路，并没有提供太多技术细节…
2. 是否已经有HTTPS SDK提供线上使用？工程师介绍已提供给移动端开发人员使用，但是这里他们说的是HTTP而不是HTTPS

3. 创建可审计的DNS记录变更系统

工程师介绍了如何在生产环境上去监控和审计DNS记录变更的方式，传统的方式比如下面，通过告警系统去探测数据的更新、这种方式是无法捕获短期修改的数据，比如抓取周期5分钟，则一些记录可能在此间隔内被修改多次。

通过与注册局合作提供接近实时的区解析数据更新，比如通过RSYNC或者A、IXFR等， 生成类似消息流的信息经过过滤和推送到不同的消息渠道。

该项目虽然设想比较好，但是感觉实现上可能会比较困难，特别是数据源头方面，如何拿到这些数据。

4. 部署DNSSEC-Saleforce

考虑到一些合规性的要求和DNSSEC带来的可信度提升，越来越多的企业推进DNSSEC实施（Google?） Saleforce也在不断的推进去适应DNSSEC发展趋势。但是整个的迁移过程需要考虑很多的问题：

• 使用多个Vendor去Host区文件
• 区数据规模
• 动态更新频率
• 密钥轮转
• 区传输限制和性能等

对于实际部署上面之前的Talk也介绍了相关的DNSSEC部署模型： 第三方签名

同时给出了具体的迁移步骤：

1. 原vendor保持运行
2. 原vendor保持运行并提供解析，同时提供数据到新的vendor，暂时不提供服务
3. 同时保持两个vendor工作
4. 关闭原有的vendor
5. 更新DS记录

对于整个迁移过程需要制定必要的回退机制，预防解析数据出现问题，比如双签状态，修改NS TTL间隔（降低递归缓存时间），另外对于大型企业实施DNSSEC迁移依然需要做好充分的准备和流程以及事后的监测才可以。

5. DOH/DOT的部署-COMCAST

COMCAST的工程师介绍了他们在推进DOH和DOT方面的一些进展，当前他们生产环境每天的查询量接近6000亿次查询（接近700百万QPS的水平），同时平台需要支持UDP.TCP以及DNSSEC的验证（2012年起开始实施），另外提供双栈接入。工程师介绍了实施DOH和DOT的初衷：

• 减少MITM窃听和攻击
• 防止中间域名的恶意修改
• 提升DNS隐私保护

同时提到了他们对于数据的一些处理方式，比如正常情况下，所有查询信息将被保持24小时（除存在安全或者网络问题需要进行分析的时候例外）另外不会使用这些数据作为市场分析和广告相关的业务。

为了实施DOH和DOT，需要考虑的一些问题：

• 如何复用当前的基础架构
• 保证用户使用体验
• 如何进行性能测试，当前并没有太多相关的测试工具可用
• 假如业务全部迁移到DOH上，当前服务器容量能处理多少查询
• 如何处理TLS卸载和多TCP连接
• CDN对于用户的影响

当前ComCast提供了测试版本的DOH： https://doh.xfinity.com/dns-query

另外ComCast也提到了他们之前为了实现儿童保护而实现的一些技术依赖于传统的DNS解析流程，如果直接切换的话，可能导致一些旁路失效。企业网络实现DNS查询也存在一些分离视图的方式，这也会导致查询服务的失效（Mozilla提供一定的配置去支持内部网络的解析，解决内外网解析分离的问题）。

ComCast内部通过实现DOH的转换器将用户的查询传递到内部的DNS解析服务器并返回用户请求，这里提到了一些工具比如DOX以及DOH-Client等

一些相关资料：

• https://github.com/Encrypted-DNS-Deployment-Initiative
• https://github.com/m13253/dns-over-https
• https://github.com/wttw/dox

6. 加速DNSSEC签名-DENIC

DENIC工程师介绍了在生产环境加速域名DNSSEC签名时间的相关工作和经验。主要是集成一些当前的开源系统比如Kubernets容器技术和KnotDNS来实现。主要流程:

• 域名注册并通过接口上传到注册局
• 注册局数据库提取变更记录生成对应的RRSet的JSON数据
• 每秒去抓取一次变更记录，将其通过动态更新的方式下发的DNS签名服务器上
• 签名服务器通过AXFR和IXFR来传递到隐藏主服务器，然后下发到其他的DNS解析服务器
• 另外通过异步验证的方式来检查区数据，一旦失败，则停止部署并触发相关的重置

同时DENIC也逐步推进软件HSM解决方案，利用SoftHSMv2来管理密钥

7. DoH和DoT的性能分析 – 普林斯顿大学

分享讨论了实际运行环境中使用DNS， DoT和DoH的相关性能比较， 主要集中比较了Cloudflare， Google以及Quad的性能分析比较。同时比较了在不同的网络环境下的页面载入性能的比较，包括普通网络环境，移动4G和 3G。一些结果发现部分DOH测试可能在某一些环境中因为HTTP缓存等问题，获得比普通DNS53更快的解析速度，可能会被归结到边缘缓存以及CDN的问题。

提问环节提到的一些问题：虚拟化环境中的UDP和TCP传输性能差异需要考虑进去，另外提到的还有tcp keepalive以及超时时间，BBR tcp调优等问题

8. DoH优选策略 – Cloudflare

分享讨论了如何让浏览器去选择合适的DoH服务器，考虑两个方面，一个是从哪里获得DoH服务器列表，第二个是如何选择DoH发送查询。比如传统的DNS解析是按照内置（Resolver配置文件）列表和RR(Round+Robin)的方式使用，但是这种情况下不够灵活，比如一些内外部分离的解析，并且可能性能达不到较好的表现。

这里Cloudflare提供了一种方式并提交了一篇draft来解析, 通过在HTTP查询头部加入一个新的定义：

 DoH-Preference: "https://dnsserver.example.net/dns-query{?dns}";
       max-age=15768000

来告诉浏览器如何去如何选择合适的服务器，如果该记录存在在列表中，则优选该记录， 里面的max-age作为缓存DoH服务器的时间。

本篇Draft位置： <https://tools.ietf.org/html/draft-schinazi-httpbis-doh-preference-hints-00

9. 权威DNS服务器在TLS方面的考虑 – Verisign

DNS隐私标准发展时间线， 介绍了整个的隐私保护的发展变化情况，下图的很多标准是为了减少数据的传递和被探测到的风险。

Verisign工程师介绍了ADoT(Authoritative DNS over TLS )也就是集中在权威服务器与递归进行交流方面的隐私保护需要考虑的一些方面：

• TLS 1.3及以上版本更安全，性能也更好一些，尽量优选
• 同时做好TLS相关版本的检查和监测，防止出现一些安全和脆弱性的问题出现
• TLS 1.3引入恢复Resumption机制，提供了更有效的资源使用方式 ，但是也可能会引入一些Replay的风险
• 为了保护当前DNS服务运行，可以通过路由器四层协议进行服务的分离（基于端口号的流量拆分），或者通过IP地址来划分

另外关于客户回话连接方面可以考虑的一些地方：

• 持续连接的数量
• 读写buffer的大小
• 会话超时时间
• 关闭等待状态时间
• 连接超时时间

提问阶段： 是否可以使用TSA记录来管理服务发现的问题。是否考虑Quic协议的应用，本地根协议能否替代ADOT等问题。

9. DNS服务器的选择 -CZNIC

CZNIC的工程师分析了当前递归服务器在权威服务器查询方面的选择问题，通过部署测试环境，收集数据来获得分析的结果。

提到的一些工具：

• 利用模板完成Systemd配置自动生成，而权威服务器配置延迟来模拟实际查询。
• 利用Linux命名空间来管理IP网络
• 配置netem规则来产生不同的延迟效果
• 收集pcap文件进行分析

测试一： 通过10*10ms梯度构建不同的权威服务器延迟配置最高100ms， 观察不同DNS软件的行为. 发现Bind和PowerDNS都会选择最佳的服务器来查询，Knot呈现梯度递减的趋势。而 unbound则呈现轮询的查询规则。当发送足够数量的数据包的时候，查询逐步趋向于稳定。

测试二：设置一个NS为延迟为0，4个设置为50ms，一个设置为无响应的时候的行为分析： bind会分布在不同的可用服务器上，但是不太均匀。Knot则表现比较平均。PowerDNS则基本上发到了一个DNS服务器。

测试三：设置一个快速的DNS服务器，但是DNSSEC配置为过期状态，另一个为较慢的DNS服务器，但是配置为DNSSEC验证有效： Bind和Ubound发送两次查询正常响应，PowerDNS则仍旧选择最快的服务器查询(导致100%的Serverfail)，Knot则大部分发送到最快的也导致了90%的Servefail,

Ubound会设置一定的阈值，观察大概处于100ms以为，如果延迟都低于该值则随机查询，否则进行优选。

提问阶段，有工程师提到并没有RFC规定必须对于DNSSEC验证失效的情况下进行重试，PowerDNS的100%Serverfail并没什么问题。

10. DNS-FlagDay 2020

ISC工程师重新提到了DNS-FlagDay的相关内容，解决IP数据分帧的问题

• 对于较大的UDP响应推荐切换到TCP连接。
• 缺省的EDNS大小设置为1232
• 一些不合规范的情况包括：
  • 权威服务器未开启TCP支持
  • 权威服务没有提供合适EDNS大小
  • 递归服务器忽略TC=1

当选择TCP连接的时候可以更好的处理IP分帧的问题，提供DNS防伪造，同时也是DoH和DoT需要的基础（TCP连接）

• 开启TCP处理，检查TCP防火墙
• 设置EDNS大小1232
• 权威服务器不要发送过大的数据包

提问环节有两位工程师都提到，是否考虑减少UDP响应大小，而不是提供过大的处理方式。