MXレコードがGoogleDNSサーバーによって正しく更新されない
現在、一部の電子メールが失われていますが、これはDNS設定が間違っていることが原因であることがわかりました。 MXレコードにCNAMEを使用しましたが、これは許可されていません。そのため、約2週間前に、問題を修正するためにAレコードに変更しました。
すべての主要なDNSサービス（OpenDNSやISPなど）がレコードを同期し、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
では、最後の変更から2週間後にGoogleが異なる（誤った）結果で応答する理由を説明できる人はいますか？そして、どうすればGoogleにDNSレコードを正しく更新させることができますか？どんな助けでも大歓迎です。
（同じDNSサーバー/ツールによって管理されている他のドメインは正常に機能していることに注意してください。）
Google public DNS Google Group で同じ問題を抱えている人を見つけました。 Alex Nizhnerからのコメントは、私の問題を解決するのに役立ちました。
最初にwrep.nlを解決し、これがdruif.wrep.nlのCNAMEであることが判明した場合、DNSクライアントはこれをキャッシュするようです。その後、wrep.nlのMXレコードを解決しようとすると、キャッシュされたCNAMEレコードで応答し、正しいMXレコードを返しません。
そこで、wrep.nlをAレコードに変更し、すべてのDNSサーバーが同期するのを待って、すべてが期待どおりに機能するようになりました。すべてのメールが届いています。 :)
私はあなたからそれほど遠くない場所にいるようで、問題ないように見える結果が得られます。
この問題は、 GoogleのパブリックDNSサーバーがエニーキャストを使用 をルーティングするという事実が原因である可能性があります8.8.8.8および8.8.4.4ここに示すように、さまざまなデータセンターに。おそらく、サーバーにクエリを実行している場所に基づいて、ルーティングにいくつかの違いがあります。 これは、いくつかのサーバーにログインし、そこで同じIPアドレスでクエリを実行することで簡単にテストできます。
あなたが今書いていることと私がここで見ていることに基づいて、私の最善の策は、問題がまだいくつかのデータセンターから提供されているキャッシュされたエントリに基づいていることです。問題が解決しない場合は、 Google Public DNSユーザーグループ までお問い合わせください。
home（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
Amsterdam：にあるサーバーからのクエリ結果
; <<>> 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
San Joseからのクエリ結果：
; <<>> 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
ここでうまく機能しています。
; <<>> 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サーバーで作業しているときにこれに気づきました。
ゾーンを更新してMXレコードを追加した後、Googleのサーバーをチェックして、それが取得されるかどうかを確認しました。新しいSOAシリアル番号を取得しましたが、古いMXレコードをキャッシュしていました。
Googleのキャッシュ方法では、ゾーンのシリアル番号が変更されてもフラッシュされない個々のレコードがキャッシュされると思われます。