我们目前正在丢失一些电子邮件，我们发现这是由错误的DNS设置引起的。 我们为MXlogging使用了CNAME，这是不允许的。 所以大约2个星期前我们把它改成了A-record来解决这个问题。
似乎所有主要的DNS服务（如OpenDNS和ISP）已经同步他们的logging，并返回正确的结果在我们的DNS查询。 但Google的DNS服务（在8.8.8.8）仍然返回CNAME值，我们仍然有一些电子邮件不能正确传递。
在OpenDNS上查询：
; <<>> DiG 9.7.3-P3 <<>> mx wrep.nl @208.67.222.222 ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 51231 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;wrep.nl. IN MX ;; ANSWER SECTION: wrep.nl. 3595 IN MX 10 druif.wrep.nl. ;; Query time: 21 msec ;; SERVER: 208.67.222.222#53(208.67.222.222) ;; WHEN: Fri Nov 25 21:36:58 2011 ;; MSG SIZE rcvd: 47 在Google DNS上查询：
; <<>> DiG 9.7.3-P3 <<>> mx wrep.nl @8.8.8.8 ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 12124 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 0 ;; QUESTION SECTION: ;wrep.nl. IN MX ;; ANSWER SECTION: wrep.nl. 2372 IN CNAME druif.wrep.nl. ;; AUTHORITY SECTION: wrep.nl. 572 IN SOA ns0.freshdns.nl. hostmaster.twilightinc.nl. 2011112401 14400 3600 604800 3600 ;; Query time: 94 msec ;; SERVER: 8.8.8.8#53(8.8.8.8) ;; WHEN: Fri Nov 25 21:38:10 2011 ;; MSG SIZE rcvd: 117
那么有没有人可以解释为什么Google会在最后一次更改后的两个星期内以不同（不正确）的结果做出回应？ 我们如何才能让Google正确地更新他们的DNSlogging？ 任何帮助，非常感激。
（请注意，由相同的DNS服务器/工具pipe理的其他域工作正常。）
我似乎离你不是很远，得到的结果似乎很好。
这个问题可能是由于Google的公有DNS服务器使用任播来将8.8.8.8和8.8.4.4路由到不同的数据中心8.8.4.4 。 根据您查询服务器的位置，可能存在一些路由差异。 这可以很容易地通过login到你的一些服务器并在那里对同一个IP地址进行查询来testing。
根据您现在正在撰写的内容以及我在这里看到的内容， 我最好的解决scheme是，问题是基于仍在某些数据中心提供的caching条目 。 如果问题依然存在，您可能需要将其提交给Google Public DNS用户组 。
来自家庭 （Zwolle）的查询结果：
; <<>> DiG 9.7.3-P3 <<>> mx wrep.nl @8.8.8.8 ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 19924 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;wrep.nl. IN MX ;; ANSWER SECTION: wrep.nl. 1566 IN MX 10 druif.wrep.nl. ;; Query time: 56 msec ;; SERVER: 8.8.8.8#53(8.8.8.8) ;; WHEN: Sat Nov 26 13:41:55 2011 ;; MSG SIZE rcvd: 47
来自阿姆斯特丹服务器的查询结果：
; <<>> DiG 9.3.6-P1-RedHat-9.3.6-16.P1.el5_7.1 <<>> wrep.nl MX @8.8.8.8 ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 23370 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;wrep.nl. IN MX ;; ANSWER SECTION: wrep.nl. 3112 IN MX 10 druif.wrep.nl. ;; Query time: 19 msec ;; SERVER: 8.8.8.8#53(8.8.8.8) ;; WHEN: Sat Nov 26 13:42:40 2011 ;; MSG SIZE rcvd: 47
来自圣何塞的查询结果：
; <<>> DiG 9.6-ESV-R4 <<>> wrep.nl MX @8.8.8.8 ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 27967 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;wrep.nl. IN MX ;; ANSWER SECTION: wrep.nl. 3599 IN MX 10 druif.wrep.nl. ;; Query time: 277 msec ;; SERVER: 8.8.8.8#53(8.8.8.8) ;; WHEN: Sat Nov 26 12:44:15 2011 ;; MSG SIZE rcvd: 47
我发现有人在Google公开DNS Google群组中遇到同样的问题。 Alex Nizhner的评论帮我解决了我的问题。
看来，如果你先解决wrep.nl，这将成为druif.wrep.nl的CNAME，DNS客户端将caching这个。 如果您尝试parsingwrep.nl的MXlogging，它将响应caching的CNAMElogging，并且不会返回正确的MXlogging。
因此，我将wrep.nl更改为一个等待所有DNS服务器同步的Alogging，现在一切正常。 所有的邮件正在通过。 🙂
在这里工作很好。
; <<>> DiG 9.6.0-APPLE-P2 <<>> mx wrep.nl ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 14549 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;wrep.nl. IN MX ;; ANSWER SECTION: wrep.nl. 2489 IN MX 10 druif.wrep.nl. ;; Query time: 52 msec ;; SERVER: 8.8.8.8#53(8.8.8.8) ;; WHEN: Fri Nov 25 15:46:53 2011 ;; MSG SIZE rcvd: 47
有趣的是，我有一天在使用DNS服务器时注意到了这一点。
在更新区域以添加MXlogging之后，我检查了Google的服务器，看看它是否会将其提取出来。 它拿起了新的SOA序列号，但仍旧caching了旧的MXlogging。
我怀疑Google的caching方法会caching单个logging，当区域序列号发生变化时，这些logging不会被刷新。