IP Anycast名称服务器系统在哪里实施?

时间:2014-01-20 08:18:52

标签: dns cname nameservers reverse-dns a-records

我最近几天一直在读名字服务器。对于我们的网站,我们希望优化由我们的namserver引起的访问者的等待时间。我将对IP Anycast和DNS的一般功能有一些疑问。首先让我从用户端解释我对DNS的理解:

用户X想要访问www.example.com,会发生以下步骤获取IP地址:

1.Step :用户X通过选择向其ISP或名称服务器的名称服务器发送请求。(递归名称服务器)

2.Step :如果找不到地址,递归名称服务器会向13个根名称服务器之一发送请求,以获取.com TLD的名称服务器

3.Step :查询.com名称服务器以获取虚拟名称服务器

4.Step :查询auhorative名称服务器以获取www.example.com的IP地址

首先,我意识到作为网站的所有者,您只能优化第4步,而其他所有步骤都不在我们手中。

我遇到了IP Anycast名称服务器(也用于13root名称服务器),完全理解分布式计算机的概念。但我不明白的是,决策逻辑,用户将根据他的“位置”向哪个分布式机器发送,是否已实现?我的意思是当我购买任播广播名称服务器时,逻辑应该在.com名称服务器上实现(步骤3),以便该名称服务器决定用户将发送到我的任播名称服务器的哪台机器。

对我来说真的很难理解,我问自己这是否真的有用吗?我希望有人可以帮助我解决这些理解问题。

除了我发现的,另一个为用户获得一些速度的小方法是仅使用A记录而不再使用CName记录。

还有更多方法可以优化名称服务器吗?

提前致谢!

2 个答案:

答案 0 :(得分:0)

简短的回答是:你是对的。 NameServers是您可以优化的地方,我见过的所有“IP Anycast”产品只是一个具有大量位置的NameServer设置。

他们使用与“互联网的根服务器”相同的系统,但这并不意味着他们具有相同的功能。 IP Anycast只是一种方法,可以为不同位置的多台服务器提供相同的IP地址。

来自WIKIPEDIA(http://en.wikipedia.org/wiki/Anycast) 在因特网上,任播通常通过使用边界网关协议来实现,以同时从因特网上的许多不同位置宣布相同的目的地IP地址范围。这导致寻址到此范围内的目标地址的数据包被路由到网络上宣布给定目标IP地址的“最近”点。

如果您正在使用像ASCIO这样的大型ISP或使用ULTRADNS的人,您可能不必太担心这一步骤,但如果NS是本地ISP,则值得考虑。确保您的访问者所在的NS。

我认为这是您接触“IP Anycast”产品的地方。没有我见过提供任何攻击步骤1-2-3的东西,而是提供了一个大型的NameServers设置,允许它们减少由于网络的接近而导致的解析时间。

如果您了解该优惠适用于根NameServer设置,请告诉我,因为我希望看到这一点。

答案 1 :(得分:0)

您的问题实际上与编程无关,而是与操作有关,并且有点太含糊(“ 还有更多其他方法可以优化名称服务器吗?”)。

但是让我们尝试为您提供指示。

  

用户X要访问www.example.com,需要执行以下步骤来获取IP地址:

那么您的以下描述基本上是正确的。请注意,默认情况下直到最近,在每个步骤中,递归名称服务器都会将查询的整个名称发送到每个名称服务器。最近,QNAME Minimization成为一种标准,现在递归名称服务器只能将它需要回复的标签发送给每个authoritativ名称服务器。这样可以在不更改协议的情况下提高隐私性,但是由于某些权威的名称服务器在以这种方式查询时无法正常工作,因此今天这种方法并不流行。

作为域名所有者,您实际上只能在最后一步产生影响。但是请记住,递归名称服务器具有缓存,因此,例如,根名称服务器的列表以及.COM名称服务器的列表是如此“热”(经常需要),因此它们肯定总是位于解析器的缓存中,因此基本上步骤1和步骤2很少发生(通常在开始时缓存为空)。

  

我遇到了IP Anycast域名服务器(也用于13root域名服务器),并且完全理解了分布式计算机的概念。但是我不明白的是,根据用户的“位置”将决策逻辑,用户将被发送到哪台分布式计算机的地方执行?

首先,IP广播不是特定于DNS的,它在这里非常受欢迎,因为

  1. 它解决了所有大型TLD都具有的负载平衡/故障转移问题
  2. 它与基于UDP的DNS一起使用特别好,它是一种简单的单查询单答复协议。

因此,理论上任何服务都可以任意广播。这意味着给定的IP地址只会出现在世界上的不同位置。

概括地说,提供商之间的Internet流量(AS编号)在对等点交换,它们互连,每个提供商都说:“我知道IP块192.0.2.0/24,请向我发送所有流量”,等每个块 (同样,这是一个摘要。块是由RIR分配的,是的,默认情况下,它不是经过太多身份验证的,因此,当另一个提供商在不应该的情况下也说“给我流量”时,就会发生BGP劫持-这是因为恶意目标或简单的人为错误)。

对于普通的(技术术语:“单播”)IP地址,只有单个提供商(AS)会在某个地方宣布它(技术上:宣布其阻止而不仅仅是单个IP​​),并且将以如下方式配置所有内容:无论交换开始于何处,对于该单个IP作为目的地,它将到达完全相同的框。

相反,对于任播IP地址,单个提供者或多个提供者(即多个自治系统)将在全球各地(对等点)宣布该IP。在每个对等点,此IP的流量将由提供者在该对等点宣布,然后将其路由到“附近”的特定服务器。在对等点A和对等点B上发布相同IP的消息,将在数据中心X的一侧驱动相应的流量,而在数据中心Y的另一侧则驱动相应的流量。

对于客户端,只要一切正常,只要所有回复服务器对同一查询做出相同反应,它就不会更改任何内容。客户端甚至不知道IP,或者有时不知道IP是任意广播的,或者当另一个客户端执行相同操作时,它想定位到X。

因此,简而言之,域名服务器在这方面“无可奉告”。在DNS解析的每个点上,当他们需要联系名称服务器NS1时,他们都知道其IP地址是IP1,并且他们通常完全打开与该IP的UDP(或TCP)连接。如果正在进行任何广播,则底层IP和BGP协议将使响应来自适当的“关闭”服务器。

请注意,对于DNS,以这种方式进行的任何广播都可以实现以下两者:

  1. 故障转移:如果一台服务器死亡,则在提供适当监视的情况下,其提供商撤回其IP公告,即该本地副本消失了,流量将自动(按顺序秒)转移到宣布相同IP的任何其他实例

  2. 负载平衡:粗鲁地说,如果您在2个位置上任一个IP广播,则每个IP都应接收50%的流量。实际上,这是不正确的,而且要进行预测甚至监视是非常复杂的(读:不可能),因为这完全取决于对等点,提供者之间的协议以及其他各种策略(简单的示例:如果您在两个点对等首先,只有一个提供商向您发送流量,而另一方面,您有100个提供商与您交换流量,那么您可能会获得更多的连接到第二个实例……当然,如果在第一个对等点有单个提供商是拥有数百万客户的ISP,其他100个提供商都是单个小型组织...)

因此,某些域名服务器是任意广播的。如今,所有根目录都是如此(但16个月前并非如此,因为b.root-servers.org是最后登上任播旅行车的人),以及所有大型TLD,有时甚至还有更多一个“ Anycast DNS提供商”。

对于任何域名,您都可以基于任何广播的域名服务器的“云”,找到一些提供商,为其提供DNS服务。

例如参见

现在关注一个完全不同的主题:

  

除此以外,我发现另一种为用户提高速度的小方法是仅使用A记录,而不再使用CName记录。

这并不是您真正能从中得到的东西,CNAME记录在许多其他情况下很有用。

同样,您需要记住,有缓存。 因此,即使您的配置是:

www.mywebsite.example CNAME www.mywebsite.example.somegreatCDN.example
www.mywebsite.example.somegreatCDN.example A 192.0.2.128

的确,这意味着在纸上有两个DNS请求最终可以进行HTTP查询,但是实际上,这些内容将被缓存(今天,大型1.1.1.1或{ {1}}或8.8.8.8(实际上也是任意广播的),因此差异可以忽略不计(并且仅影响第一次,直到再次出现在缓存中才影响)……尤其是在HTTP的情况下以及后来打开的所有内容,经常有数十个连接下载javscript源代码,CSS文件,字体等,这些内容可能托管在其他位置。

许多网站使用9.9.9.9记录而没有负面影响。例如,现在请参见CNAME

www.amazon.com

但是,您可能会争辩说,某些名称将比其他名称更受欢迎,因此在缓存中保留的时间更长,这是肯定的情况。

最后:

  

还有其他一些方法可以优化域名服务器吗?

基于什么?我们触及了上面的各个主题,所有都是妥协,您为了获得其他东西(冗余等)而牺牲了一些东西(可能只是“金钱”)。没有什么通用规则可以声明这种妥协何时有意义,这在很大程度上取决于您的情况和您要采取的措施。

您是对的,应该为此感到祝贺,出于安全和性能方面的考虑,您应该花一些时间在DNS设置上。尽管通常会在大型HTTP设置上投入大量资金来维持各种问题或活动高峰(但有时即使是最好的失败,有时也会看到最近发生的Amazon Prime Day开张是巨大的失败),但人们通常会忘记DNS,因为它在基础结构级别上尚不为人所知或理解(使用UDP使它已经在所有其他已知协议中脱颖而出,因为这种情况很少见。)

例如,存在另一种完全不同的东西(与任意广播正交,因此无论有无广播都可以使用,目标是不同的):“ geo-DNS”表示名称服务器何时响应与客户问的地方。例如,这旨在为网络服务器提供一个不同的IP,该IP距离客户端更近(因此,在这种情况下,网络服务器本身可能不会被广播)。仅通过查看DNS数据包中的源IP即可完成此操作,但这通常还不够好,因为权威的名称服务器仅将递归名称服务器中的源IP视为真正的IP,而不是真正的最终客户端,并且如今拥有大量开放的公共资源。递归名称服务器的位置应该相距很远,因此您还具有一个称为EDNS客户端子网的特定DNS选项,可以在递归和权威名称服务器之间传递该DNS选项,以便它们获得最终客户端的真实IP地址(实际上是一个块而不是单个IP​​)隐私原因)并可以对此采取行动。