我真的不明白互联网和DNS如何运作.当我试图在维基百科上阅读它时,我被我不理解的术语所淹没.我没有计算机科学背景.

将名称服务器记录从ns1.oldserver.com更改为ns1.newserver.com时,实际发生了什么？我的意思是,什么“机器”或东西负责将用户的url查询从ns1.oldserver.com导向ns1.newserver.com？用户如何知道再也不会去ns1.oldserver.com？

同样,当我将域的A记录更改为从旧IP地址指向新IP地址时,实际发生了什么？是否与更改名称服务器记录相同？

谢谢

记录从父名称服务器委派 – 它就像一个链(或通常被描述为反向树).每个DNS客户端都知道根服务器的IP地址 – 这些是一组服务器(我认为它是13),它们提供了注册管理机构服务器的IP地址 – Nominet为.uk,eurID为.eu等.

然后,您的域名将在注册表中注册,该注册表具有您的名称服务器的地址(在您的示例中为ns1.oldserver.com).最后,您的域名服务器(或名称服务器,因为您应该至少有两个)提供实际请求.

想象一下,例如,客户想要访问www.domain.com.

这可以分为三个组件 – 所谓的顶级域(TLD),客户端在此示例中查询根服务器的.com.其中一个服务于此的名称服务器可能是a.gtld-servers.net – 根服务器将a.gtld-servers.net的IP地址提供给客户端 – 这些被称为NS和粘合记录.

接下来是本例中的实际域名 – domain.com.客户端查询a.gtld-servers.com以获取domain.com.然后,这可以返回ns1.domain.com和ns2.domain.com,并将相关的IP地址作为NS和粘合记录.

最后是主机名 – 本例中的www.因此,客户端将查询域名为www.domain.com的ns1.domain.com或ns2.domain.com,并获取网站的实际IP地址(A记录.)

所有这些都在几毫秒内完成. DNS解析器的典型超时为2秒.

要回到原始问题,当您更改名称服务器时,您正在更改注册表级别的NS记录(Nominet,eurID等)更改完成后,客户端查询domain.com的根服务器时,它将获得ns1.newserver.com的IP地址而不是ns1.oldserver.com.

全世界所有客户通常需要72小时才能注意到更改,因为它们会在域记录中指定的一段时间内缓存所有结果. NS记录通常缓存72小时甚至长达一周.因此,在进行更改后至少几天内不要让旧名称服务器脱机.

更改A记录与更改NS记录非常相似 – 您只需更改内容,例如更改数据库记录.下次有人查询您的记录时,它会获得新值(再次考虑缓存,但A记录要低得多,通常是1/2 – 1天.)

如果您可以访问Linux机器,请运行dig trace www.google.com,您将看到可能为您提供更好主意的完整查询链.

我们在AWS上有许多服务器组,它们使用三个服务器来提供站点服务.每个服务器或一组服务器位于不同的可用区域内,其中一个是重定向服务器,而另外两个是在弹性负载平衡器后面访问的主服务器.我们最终有一个客户使用Route53,并在弹性负载平衡中查找指向区域顶点域的一些细节.支持此功能的大多数DNS提供商似乎将此称为A记录的DNS别名.然而,有些网站似乎引用了一个名为ANAME记录的类似记录.这不是典型的CNAME,也不是非典型的DNAME记录.这些网站中的大多数还会返回使用它的DNSMadeEasy simplednS.

那么Route53(或其他地方)A记录ALIASes和ANAME记录之间有什么区别？有吗？这些中的任何一个是否已包含在IEFT RFC实现文档中,或者是否包含在所使用的提供程序中实现的别名记录？

[编辑]：为ANAME使用列出了错误的DNS提供商

看起来ANAME只是由 DNS Made Easy组成的标准名称,用于描述他们的服务,与Route 53 Alias的功能非常相似.

我在Stack Overflow最近描述了Alias和CNAME之间的差异,但总结一下：

为给定主机配置了CNAME的DNS服务器发出一个引用,指示正在查找的主机的规范名称,通常需要原始解析器进行第二次查询以查找该备用名称;别名(以及它的外观,ANAME)使用DNS服务器知道的“真实”目的地的内部信息,直接简单地响应请求,而不需要第二次查找,也不需要任何中间信息的可见性. DNS协议交换.

除此之外,Alias提供的功能是能够使用Route 53拥有的有关S3网站端点,ELB和Cloudfront的当前有效IP地址的信息,以响应具有权威信息的A记录查询.近乎实时的准确性,如果您使用这些服务,则不是任何其他提供商可以使用的;当然,情况恰恰相反,Route 53 Alias不能用于查找和返回Route 53本身不具备的信息.您不能只使用“任何”目标作为别名 – 只有我在上面提到的三种服务的端点,或者在Route 53内的同一托管区域中的其他记录.

从这个意义上讲,ANAME和Alias不等效,具体取决于提供后端的服务…除非ANAME指向(内部)静态信息.

如果目标是S3,ELB或CloudFront,则另一个DNS主机服务上的ANAME记录将无法提供与Route 53相同的功能,就像Route 53上的Alias无法返回指向的路径一样另一个CDN提供商的边缘位置使用内部可用信息,因为提供商的基础设施内部无法获得这些信息.否则功能似乎大致相同.

我有一个来自MediaTemple的域名,我想指向AWS上的服务器EC2实例.在我的注册商网站上,我指定了AWS名称服务器.使用Route 53我创建了指定的DNS记录(NS,A,SOA).我等了>传播更改24小时但我无法通过我的域名访问我的网站.

使用站点https://www.whatsmydns.net/#A/mywebsitehere.com检查我的记录我发现我的A记录失败了. NS记录看起来很好.

我在托管区域中定义了A记录.不知道从哪里开始.

您没有example.com的A记录.您有* .example.com的A记录,其中不包含example.com.你需要两个记录.

我正在做一些域名的工作.我正在更新它们.通过使用dig我可以查询我们的名称服务器,我可以看到正确的名称已更新.但是我们的办公室dns缓存仍然显示旧名称.昨天我将TTL设置为10分钟,所以我不必等待很长时间.但有没有办法欺骗办公室的DNS缓存更新？我可以做些什么偷偷摸摸的小技巧让事情变得更容易？

更新让我们假设我无法访问服务器,无法重启服务器？还有什么我可以做的吗？

假设您的DNS服务器在PC而不是路由器等：

Linux缓存刷新：

/etc/init.d/nscd restart

或者没有nscd的发行版

/etc/init.d/named restart

单个机器的Windows客户端缓存刷新：

ipconfig /flushdns

办公室服务器的Windows服务器缓存刷新(感谢ericmayo更正)：

1. Navigate to Administrator Tools
2. expand the server object
3. right click cached objects
4. select clear cache

Mac(可能？！)：

dscacheutil -flushcache

如果你有一个路由器的Web GUI等,那里会有一个选项.

Cross platform cache flushing如上

About DNS and caching

除了区域文件传输之外,DNS区域文件中的SOA记录是否有任何目的？如果DNS服务器不依赖于区域文件传输进行复制(而是依赖于某些分布式后端数据库),那么是否有任何理由拥有SOA记录？通过DNS查询日志查看,我甚至从未见过客户端甚至请求SOA记录.

我认为“主名称服务器”和“管理员”字段可能有一些用处,但通常主要名称服务器是通过NS记录获得的.

是的,SOA记录无论如何都有用.虽然常规客户端通常不直接查询SOA记录,但它会以否定响应返回！

如果你要分析你的名字服务器的响应而不是传入的查询,我认为你会看到SOA记录更多.

但是,如果未使用作为DNS规范一部分的区域传输方法,则SOA记录的某些字段不再相关.

如果我们看一下SOA记录的字段：

MNAME：主名称服务器的名称.在动态更新的上下文中使用,在某些情况下也用作区域传输实现的一部分.

RNAME：技术联系电子邮件.系统本身并没有真正使用它,而是信息性的.

SERIAL：区域序列号,用于区域传输.

REFRESH：刷新间隔,用于区域传输.

重试：重试间隔,用于区域传输.

EXPIRE：到期间隔,用于区域传输.

MINIMUM：曾经是最小的TTL但现在用作负面反应的TTL.

因此,我们可以看到MNAME,RNAME和MINIMUM并非特定于区域转移规范.

除此之外,我会说负面响应在DNS和SOA MINIMUM字段中的工作方式尤其是无论区域同步如何实现都需要SOA记录的主要原因.因此,如果没有每个区域中的SOA记录,您就无法实现正常工作的权威名称服务器.