我需要一些帮助来整理我的DNS条目.
我有一个域名,让我们说它是somecompany.com
在这个域名之外,我在AWS Cloudfront上有一个网站,可以通过www.somecompany.com& amp; somecompany.com
我还有用于电子邮件的Google Apps设置,因此用户可以使用user@somecompany.com等地址
我有一个域名,让我们说它是somecompany.com
在这个域名之外,我在AWS Cloudfront上有一个网站,可以通过www.somecompany.com& amp; somecompany.com
我还有用于电子邮件的Google Apps设置,因此用户可以使用user@somecompany.com等地址
我的问题是虽然我可以设置Google Apps DNS条目并将邮件发送到正确的地址.一旦我也设置了网站的条目,users@somecompany.com就会收到邮件.我怀疑MX记录与somecompany.com的CNAME之间存在某种类型的冲突,但我不确定如何修复它.
DNS表如下……
somecompany.com CNAME xxxxxxxx.cloudfront.net www.somecompany.com CNAME somecompany.com somecompany.com MX ASPMX.L.GOOGLE.COM somecompany.com MX ALT1.ASPMX.L.GOOGLE.COM somecompany.com MX ALT2.ASPMX.L.GOOGLE.COM somecompany.com MX ALT3.ASPMX.L.GOOGLE.COM somecompany.com MX ALT4.ASPMX.L.GOOGLE.COM somecompany.com NS ns1.openprovider.nl somecompany.com NS ns2.openprovider.be somecompany.com NS ns3.openprovider.eu somecompany.com SOA ns1.openprovider.nl dns@openprovider.eu xxxxxxxxxx somecompany.com TXT google-site-verification=xxxxxxxxxx
解决方法
CNAME无效作为域的顶部条目(位于区域顶点). foo.example.com可以是CNAME并且通常按预期工作,但是example.com(也称为“裸域”)不能.根据定义,CNAME会屏蔽所有其他记录,并且与其他记录一起无效.如果您的DNS托管服务提供商允许您以这种方式进行配置,那么它在技术上会被破坏.你经常只为一个网站而侥幸成功,但正如你所看到的,电子邮件是你不喜欢的几个地方之一.
正是由于CNAME的限制,Amazon Route 53实现了ALIAS记录的概念,用于将区域顶点的A记录指向CloudFront,Elastic Load Balancer和S3静态托管端点.这些服务为您提供端点的主机名,而不是IP地址,因此您需要在顶点处使用此类型的记录.
这种记录类型根本不是记录类型;记录本身仍然是A记录,如响应所示,但Route 53通过交叉引用在内部解析它们,以便从底层服务中找到正确的A记录,并将其返回给请求者.
我不隶属于AWS;这不是插头.从技术角度来看,如果您在CF,ELB或S3上托管站点,通常最有意义的是在Route 53上托管您的DNS,因为Alias记录在此处执行您所需的操作,并且并不总是能够正确执行与其他DNS提供商的事情.有些提供商确实有一个名为“ANAME”的东西,其行为类似于Alias,如果你提供的话,那么它也应该有效.
有关CNAME与Alias的更多信息,另请参阅Difference between A Record and CNAME in Route 53.
