dns ttl 是什么_短DNS记录TTL和集中化是Internet的严重风险

dns ttl 是什么

昨天，DNS提供者Dyn 在大规模DDoS之后失败了 。 这导致无法访问许多受欢迎的网站，包括Twitter，LinkedIn，eBay等。 互联网似乎正在“爬行”。

我们可能会从Dyn读到一个有趣的验尸报告，但是为什么会这样呢？ 首先，使用不安全且受感染的物联网设备访问互联网，DDoS容量正在增加。 大量虚假请求涌入给定的服务器或一组服务器上，无法访问，或者无法处理请求，或者仅仅是由于服务器的网络没有足够的吞吐量来容纳所有请求，因此它们变得不可访问。

但是，为什么由于单个DNS提供商受到攻击而停止了“互联网”？ 首先，由于集中化。 互联网应该是去中心化的（尽管我认为正是由于DNS的缘故， 它是伪去中心化的 ）。 但是Dyn，UltraDNS，Amazon Route53以及Akamai和CloudFlare等服务将DNS集中化。 我不知道具体如何，但是在Moz.com的前500个网站中 ，有181个使用上述5种服务之一作为其DNS提供程序。 添加25个使用自己的Google服务，您将获得500个集中在6个实体中的200个。

但是仅靠权威性域名服务器的集中化并不会导致昨天的问题。 我认为问题的很大一部分是DNS记录的TTL（生存时间），即包含域名和IP地址之间映射的记录。 这样做的想法是，您不应该总是访问权威的名称服务器（在这种情况下为Dyn的服务器），只有在请求过程中的任何地方都没有缓存的条目时，才应单击它。 您的操作系统可能具有缓存，但更重要的是–您的ISP具有缓存。 因此，想法是，当一个ISP的订户都向Twitter发送请求时，这些请求不应转到名称服务器，而应通过在ISP的缓存中查找来解决。

如果是这种情况，则无论Dyn是否宕机，大多数用户都可以访问所有服务，因为他们可以缓存并解析其IP。 这就是互联网应该运行的适当的分布式模式。

但是，在DNS记录上设置非常短的TTL（仅几分钟）已成为一种常见的做法。 因此，几分钟后，浏览器必须询问名称服务器“我应该连接到哪个IP才能访问twitter.com？”。 这就是攻击如此成功的原因-因为没有信息被缓存，每个人都反复求助于Dyn以获取与请求的域相对应的IP。

至少可以这样说，这种做法值得高度质疑。 本文详细说明了短TTL的问题，但让我引用一些重要的内容：

TTL越低，则访问DNS的频率越高。 如果不谨慎，DNS可靠性可能比公司Web服务器的可靠性更为重要。

如果不是根本性的缺陷，那么极低的TTL（不到一分钟）的越来越多的使用是极不正确的。 关于TTL值降低趋势的最慈善解释可能是尝试创建动态负载平衡器或快速故障转移策略。 结果更有可能是通过增加负载来破坏名称服务器。

因此我们知道了风险。 不可避免地会滥用这种有问题的做法。 我决定分析问题的严重程度。 因此，我以上述前500个网站为代表，获取了它们的A，AAAA（IPv6），CNAME和NS记录，并将它们放入表格中。 您可以在该要点中找到代码 （使用dnsjava库）。

生成的CSV可以在这里看到 。 如果您想在Excel中使用它， 这是excel文件 。

我收集了一些其他信息：多少个网站具有AAAA（IPv6）记录（500个中只有79个），IPv4和IPv6之间的TTL是否不同（对于4个来说确实如此），这是DNS提供程序（这就是我的方法） （上面提到的数字），取自NS记录，有多少人使用CNAME代替A记录（仅少数）。 我还收集了A / AAAA记录的数量，以了解有多少（潜在地）使用了循环DNS （187）（值得一提：提供给我的A记录可能不同于提供给其他用户的A记录，这也是一种进行负载平衡的方法）。

结果有点吓人。 平均TTL仅约7600秒 （2小时6分钟）。 但是，当您查看第50个百分位时，情况会变得更糟（按ttl对值进行排序，得到最低的250）。 平均只有215秒 。 这意味着DNS服务器不断受到攻击，这使它们变成真正的单点故障，并且在DDoS几分钟后，“ Internet中断”。

从这张简单的图表中可以看出，只有几个网站的TTL高（所有500个网站都在X轴上，TTL在y上）：

短TTL有什么好处？ 实际上不多。 您可以灵活地更改IP地址，但是您不必经常这样做，而且–并不自动意味着所有用户都将被指向新IP，因为某些ISP，路由器和操作系统可能会忽略该IP地址。 TTL值，并保持高速缓存活动更长的时间。 您可以进行轮询DNS，这基本上是将DNS提供程序用作负载平衡器，在大多数情况下，这听起来是错误的。 它可用于地理位置路由-根据请求的地理区域提供不同的IP，但这不一定需要较低的TTL-如果缓存的发生位置离用户较近，而离授权DNS服务器更近，那么他将被指出无论如何，无论值是否经常刷新，都必须将其设置为最近的IP。

短TTL对内部基础结构非常有用–当指向内部组件（例如，消息队列，或者如果使用微服务，则指向特定服务）时，使用低TTL可能更好。 但这与从互联网访问您的主域无关。

像BitBorrent和Bitcoin这样的覆盖网络使用DNS轮循机制为新客户端提供可以连接的对等方列表的种子（您第一次使用torrent客户端会将您连接到一个服务器域，每个域都指向多个节点应该一直在线）。 但这又是一个罕见的用例。

总体而言，我认为大多数服务都应使用更高的TTL。 24小时并不是太多，由于缓存会忽略TTL值，因此无论如何都要将您的旧IP服务请求保留24小时。 这样，服务将不会在乎自动名称服务器是否关闭。 反过来，这意味着DNS提供商将不再是攻击的目标。

我了解Dyn和Route53给我们的灵活性。 但是也许我们应该考虑一种更加分散的方式来获得这种灵活性。 因为昨天的袭击可能仅仅是个开始。

翻译自: https://www.javacodegeeks.com/2016/10/short-dns-record-ttl-centralization-serious-risks-internet.html

dns ttl 是什么