Akamai DNS: Providing Authoritative Answers to the World’s Queries

0x00 基本架构

Akamai是证明的CDN厂商，这篇Paper是关于其DNS服务的一个设计。Akamai DNS的基本架构如下，系统中心的核心是一个authoritative nameservers，为了提供给全球各地用户的DNS查询服务，这个authoritative nameservers的服务器数量是很大的。这些authoritative nameserver服务器分布在全球各定的100多个points of presence (PoPs)中。和一般的DNS服务一样，Akamai DNS也非常依赖于IP的anycast，即任播功能。anycast方便讲DNS请求路由到比较靠近的地方，从而降低RTT，提高性能。这里使用了24 个不同的 IPv4-IPv6 anycast prefix pairs，每个座位一个PoP的anycast cloud，为了容忍PoP的故障，这24个(clouds)是分布在100多个的PoP节点中的，但是一个PoP节点最多使用一个的prefix pair。

PoP的基本结构如下，前面是一个PoP的router，后面是运行着nameserver的若干机器。每台机器也运行着一个BGP-speaker，于router连接advertises地址prefix等的一些信息。另外的一个agent负责监控机器的健康情况。Router在接受到一个BGP advertisement时候，其会将相关信息advertises给BGP neighbors, or peers。Router接受到的anycast的数据包，会通过ECMP的方式发送到这个PoP中的一台机器，一般都是使用addr+port的hash的方式。

• authoritative nameserver支持Authoritative DNS Hosting Service (ADHS)。这里还支持DNS zones，企业可以选择6个不同的clouds集合，这里选择6个不同的cloud组成一个集合是配合后面的Attack Resiliency机制。

  Enterprises add NS records, each corresponding to a cloud in the delegation set, to every zone they own, along with the respective parent zone in the DNS hierarchy. Adding the NS records to the parent zone ensures that resolvers are directed to Akamai DNS, and will query one of the 6 clouds to obtain an answer to DNS queries for the enterprise’s zones. 
  

  这里也支持CDN redirect的功能，实现一些重定向的功能等。

• 另外Akamai DNS还有一些额外的组件：1. Mapping Intelligence，负责根据用户的一些特点来选择返回的IP，用于提高性能等目的；2. Management Portal，这个组建主要是管理等功能，比如管理DNS zones, GTM configurations, 以及 CDN properties 等；3. Communication/Control System，提供一个通用的基于publish/subscribe的元数据delivery的功能。4. Monitoring/Automated Recovery负责监控系统的健康状态；4. Data Collection / Aggregation组件负责收集系统metrics。

0x01 Resilience

Paper中很大篇幅都是来描述这个系统如何容错，以及低于外部的攻击。Akamai DNS的容错很依赖于IP的anycast的功能，这里和一般的DNS系统是一样的。另外，在一个PoP故障的情况下，会有将IP prefix从这个PoP上面withdraw的逻辑，以实现相关的流量重新路由到另外的PoP。Paper中也讨论了通过anycast容错的一些特点。初次之外，另外总结了这样的一些Failure Resiliency，

• Machine-Level Failures。机器基本的故障多数是磁盘故障，其它的组件也会出现故障。这里会在机器上面部署一个 on-machine monitoring agent。这个agent持续地运行一组测试。如果这些测试中发现了一些异常的情况，这台机器就会置为self-suspended的状态，然后发送指令让BGP-speaker 撤回 anycast advertisement，流量从而导向其它的机器。如果一个PoP的机器变成self-suspended，这个就会当作是PoP故障，使用anycast failover mechanism来处理，使流量route到其它的PoP去。

• Stale State，一般的数据更新在秒级别就能完成，但是也很容易有一些nama server的数据必能及时更新，这种一般是由于网络的问题。这里的优化方式是检查是否过期了，如果是的话，则将自己置为self- suspend状态，和前面的机器故障一样来处理。

• Input-induced Failure，这里处理的一般就是一些操作故障，输入了一些错误的东西。这里的解决方式是类似canary release的方式。选择input- delayed nameservers。这部分的服务器会延迟一个小时接受到更新的数据，且特殊处理不会受到stale数据的影响。BGP-speaker处理路由信息的时候，会给正常的server更高的Multi-Exit Discriminator (MED)值。一般情况下input-delayed nameservers接受不到DNS的数据。如果正常更新的server因为上面原因crash了，会failover到这些input- delayed nameservers上面。

• Query-of-Death，这里处理的是不正常的DNS查询到的query-of-death (QoD)问题。这种情况下不能简单地使用情况下的failover策略，因为会持续导致server故障。这里的处理方式是会探测这些异常情况，并将相关的查询保存到磁盘，使用另外的一个进程来分析这些数据，并指导防火墙drop掉类似的数据。但是这样可能导致错误的拒绝一些请求，所以这里的添加到防火墙的drop规则有一个过期时间。另外这个功能只会部署在部分的name servers上面，

  Further, this feature is only deployed on a subset of name- servers. Thus, queries similar to the QoD that do not themselves cause crashes experience a partial outage at worst while operations teams work to identify the precise cause of the crash.
  

Attack Resiliency

外部的攻击，比如DDoS是很常见的。Akamai DNS这里描述了处理这类攻击的一些方式。第一个抵御这些工具的方式是分布式的部署服务。比如每个enterprise会赋予唯一的一个 6 anycast clouds提供服务，一个cloud又由多个的PoP提供服务。这些PoP分布在世界各地，可以处理大量的请求。一个PoP不会处理一个以上的clouds中，所有一个PoP被攻击到饱和了还可以有其它的可以使用。另外，如果攻击一个使用Akamai DNS的enterprise的话，一个enterprise A和另外一个enterprise B至少会有一个cloud是不同了，可以减轻攻击A的时候对B的影响。另外，一个PoP节点在收到DDoS攻击的时候，可以选择是自己处理这些攻击请求，还是withdraw advertisements，这样可以将流量导向其它的PoPs。下面是在这种情况下，human operator来处理的逻辑：

另外，在name server中，内置了一个mitigation mechanisms来处理。每个nameserver接受到的查询请求会给一个penalty score，用来表示这个请求的legitimacy，可疑的查询会接受到一个更大的penalty。处理这些请求的时候，penalty低的请求可以得到更多的资源来处理。在攻击的类似上面，这里总结了这样的一些：

• Volumetric，这种攻击就是为了耗尽系统的带宽，经常通过DNS reflection or NTP reflection来放大攻击。这种攻击的处理比较简单，一般的方式是drop掉53端口的packet，or 通过 QR-bit来识别DNS reflection流量，

  In practice, we observe that the bottleneck for volumetric attacks is usually upstream from the nameservers as we have sufficient compute capacity to filter in the firewall at a higher rate than the bandwidth available in peering links. Thus, volumetric attacks are the only class of attacks listed here that typically fall into the category of bandwidth saturating rather than compute saturating. 
  

• Direct Query，这种攻击就是简单地感动DNS请求，可能会耗尽系统的带宽和计算资源。实际的观察中，计算资源更容易事瓶颈，这里的处理方式是一个rate limiting filter模块，为rate limiter设置一个根据历史记录得到的query qps限制( a rate limit on a per-resolver basis)。超过了限制会为对应的查询设置一个penalty score。这种方式对于攻击者使用少量的IP source地址工具的时候比较有效，如果使用了大量的IP的话，就比较麻烦。实际上，一段时间内，查询的来源是比较固定的。如果遇到了这种情况，系统就转而使用 allowlist filter的策略，不在这个list中会被赋予一个penalty, de-prioritizing的操作。

• Random Subdomain，频繁的选择一个随机的子域名查询，这种攻击处理起来相对比较复杂。为了处理这个问题，这里引入了NXDOMAIN filter。对于DNS查询中的NXDOMAIN响应，filter会记录下响应的per zone一些统计信息。如果统计值超过了一个阈值，这里会将超过了阈值的zones中的valid hostnames构建出一个tree结构，查询不在这个tree里面的数据的时候，会被赋予一个penalty score。

• Spoofed Source IP，伪造源IP的情况下， rate limit filter会变得效率低，allowlist filter依然会比较有效。但是伪造的是一些已知的resolvers的时候，这个allowlist filter也会有问题。这里使用的方式称之为hop-count filtering。hop-count filte通过在历史数据上面学习正常的(allowlist中)DNS查询的IP Packet的TTL，如果目前的查询的IP Packet的TTL和之前学习到的超过了一个阈值，会赋予这样的请求一个penalty score，

  We observe in the DNS traffic arriving at our nameservers that the IP TTL is consistent per source IP address, with only 12% of source IP addresses showing any variation in IP TTL over one hour and 4.7% ever varying by more than ±1.
  

• Spoofed Source IP & IP TTL，除了伪造Source IP之外，这里还处理了TTL，会使得这个更难处理。为了处理这个问题，这里引入了 loyalty filter的方式。每个nameserver独立地追踪发动过DNS请求的resolver。后面接受到不在loyalty filter中的resolver的请求的时候，这个查询会被赋予一个penalty score，

  Recall the use of anycast for our nameservers and that each resolver is routed to a PoP via BGP. Thus, allowlisted resolvers only appear in the loyalty filter of nameservers to which the allowlisted resolver is routed. 
  

0x02 评估

这里的具体信息可以参看[1].

参考

1. Akamai DNS: Providing Authoritative Answers to the World’s Queries, SIGCOMM ‘20.