我试图估计一夜之间更改邮件服务器的IP是否切合实际,或者这会让人们在第二天检索他们的电子邮件变得混乱.基本上,邮件服务器所在的设施将改变其IP池,这迫使我必须更改邮件服务器的A和MX记录.由于我没有更改DNS服务器本身(不将记录移动到其他权威服务器),更改是否接近即时,或者由于在最近可能查询的不同非权威DNS服务器上的缓存,它仍然需要长达48小时？

感谢您的任何见解,

中号

每个DNS资源记录都被缓存; DNS服务器本身是否移动是无关紧要的.正如Yahia所说,缓存记录的时间长度取决于记录的TTL.在执行DNS更改之前,通常的做法是将TTL从其常规值(通常为一天或更长时间)降低到非常小的值,例如5分钟.

使这个过程复杂化的是,一些表现不佳的dns缓存解析器会忽略指定的TTL并替换它们自己的值. (运行这些系统的人需要在火灾中死去,如果我当选互联网的大霸主,他们会).因此,如果它是一个重要的系统或直接控制之外的人使用的系统,建议您在要迁移的系统上设置DNAT规则,以便将发送到先前IP地址的流量重定向到新的IP地址. .

我在AWS Cloudformation中设置了一个堆栈,该堆栈已启动并正在运行.该堆栈包含一个ELB(负载均衡器)和一些EC2实例.当我们对应用程序进行新部署时,我们会构建一个新环境并删除旧环境.因此,我们必须更新Route 53中的DNS记录.我想知道旧堆栈应该保持多久.

我已经跟踪了AWS docs to use a subdomain without migrating the parent domain.父域NS记录(朝向AWS DNS)的TTL为3600.在Route 53中,我已经设置了一个带有别名的A记录到堆栈中的负载均衡器(我无法设置TTL)这里).

我无法从AWS控制台输入别名记录的TTL.然而,一些消息来源称,这一变化可能需要60 seconds.

我刚刚在本地进行了一些测试,以检查DNS获取新堆栈所需的时间.这是更新Route 53中的别名DNS记录和能够在浏览器中访问新堆栈之间的时间：

>尝试#1：~4分钟
>尝试#2：~9分钟
>尝试#3：~7分钟
>尝试#4：~15分钟

这不应该在60秒内吗？所有客户可以承受的最长时间是多少？可以减少这个时间吗？什么是删除旧堆栈的安全时间？

首先,重要的是要认识到客户端或其DNS解析器上缓存的DNS记录都是您无法控制的(请注意,我指的是DNS记录而不是您的权威名称服务器).因此,客户端和他们的DNS解析器会尊重您的TTL.

如果新访问者之前从未访问过您的网站并且其DNS解析程序未缓存您的记录(或者在很长时间之前访问过缓存已过期),他们将立即看到新记录.

Shouldn’t this be under 60 seconds?

它应该,但只有当您的客户尊重TTL时才会这样.一些客户端具有最小TTL,并且一些网络还具有DNS解析器,其可以是缓存结果.

Is it possible to reduce this time?

您必须记住,大多数访问者(假设这是一个公共站点)不会像您一样每隔几秒就坐在那里加载您的网站.大多数访问者最近可能不会访问该网站,并且他们的DNS解析程序可能没有缓存中的记录.大多数DNS解析器应该尊重你的TTL,但你不能保证这一点.

What is a safe time to delete the old stack?

你最好通过旧堆栈而不是DNS TTL来处理流量来判断这一点.如果您正在使用ELB,那么您应该能够查看旧版ELB在cloudwatch中每秒请求的请求数.等到它降到可接受的水平以下然后将其删除.

为了在切换后立即查看新堆栈,我建议只需手动刷新本地DNS缓存.让自己的客户自然地过期记录,以便看到它需要多长时间可能不会表明其他客户需要多长时间.

编辑,我注意到谷歌的公共DNS有一个工具,让你刷新缓存：

https://developers.google.com/speed/public-dns/cache

这可能会加快速度,因为很大一部分客户可能正在使用它.

我正在构建一个应用程序,每个客户都可以拥有自己的子域.
在这个例子中,他将他的子域设置为：威士忌

我在DNS中创建了一个通配符子域：
* .myapp.com A 123.123.123.123

所以当他访问我的webapp时,他会使用url：whisky.myapp.com,它将解析为123.123.123.123.

我的应用程序还使用我的客户选择的相同子域发送电子邮件(电子邮件将由sendgrid处理)：例如customer@whisky.myapp.com

但是当我尝试为sendgrid的服务器设置通配符MX记录时,我的DNS提供商不允许我这样做,理由是违反了一些标准.

例如* .myapp.com MX sendgrid.com

有什么方法可以为两者都有通配符子域名吗？

RFC1912明确承认存在通配符MX记录,但警告说

A wildcard MX will apply only to names in the zone which aren’t listed in the DNS at all.

RFC4592是一个标准跟踪RFC,它阐明了MX通配符的存在(参见2.2.1节中的示例).我很确定你的DNS提供商充满了它.

我可以想象一些DNS软件也遇到问题,或者因为他们根本不支持通配符MX记录,或者因为他们把“没有其他记录”的东西太字面化并且不允许两个通配符MX和通配符A.这个软件不符合标准,但运气好了.

考虑到客户注册时自动设置DNS记录是多么微不足道(或者应该如此),我会完全跳过通配符,让您的应用为每个客户配置DNS记录.

我有几条A记录,如下：

Subdomain             IP Address
example.example.com   198.51.100.0
example.com           203.0.113.0

并且CNAME记录如下所示：

Alias              Destination
www.example.com    example.com

我想让example.com抛出301重定向到www.example.com.

所以我将最后的A记录更改为：

www.example.com       203.0.113.0

并交换CNAME记录中的两个URL,如下所示：

example.com        www.example.com

问题：此更改是否会使example.example.com解析为203.0.113.0而不是198.51.100.0？

如果您有example.foo.com的A记录,则任何其他域的DNS记录都不会影响该记录.所以答案是否定的.

其他要记住的事实：

您不能拥有同一个完全限定域的CNAME和A记录

CNAME与301重定向不同.CNAME将返回与新域相同的IP地址.您的浏览器将转到该IP请求原始域.301重定向将导致您的浏览器对新域进行DNS查找,然后去询问新域.

我们在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提供商的边缘位置使用内部可用信息,因为提供商的基础设施内部无法获得这些信息.否则功能似乎大致相同.