2

We are currently losing some e-mail and we discovered that this is caused by a wrong DNS setting. We used a CNAME for our MX record an thats not allowed. So about 2 weeks ago we changed it to an A-record to fix the problem.

It seems all major DNS services (like OpenDNS and ISPs) have synced their records and are returning correct results on our DNS queries. But Googles DNS service (at 8.8.8.8) is still returning the CNAME values and we still some e-mails are not delivered correctly.

Query on 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

Query on 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

So is there anyone who can explain why Google is responding with a different (incorrect) result two weeks after the last change? And how can we get Google to update their DNS records correctly? Any help is very appreciated.

(Please note that other domains that are managed by the same DNS servers/tools are working fine.)

Improve this question
8
  • Is there something wrong with your SOA record? dig -t SOA wrep.nl only returns the CNAME. Am I missing something?
    – faker
    Nov 25, 2011 at 21:23
  • Wow! A recursive CNAME! I wonder who thought that was a good idea. If wrep.nl is a CNAME for druif.wrep.nl, then druif.wrep.nl is a CNAME for druif.druif.wrep.nl and so on. Not good.
    – David Schwartz
    Nov 25, 2011 at 23:06
  • @faker Indeed strange, but I solved the problem now. See my post below in a moment.
    – Mac_Cain13
    Nov 26, 2011 at 12:15
  • @DavidSchwartz Err, right. This is and was never the case. So don't know what you are talking about. (And if something like this was my problem you should provide some helpful tips and tricks to resolve the problem.)
    – Mac_Cain13
    Nov 26, 2011 at 12:18
  • @Mac_Cain13 This is a recursive CNAME: wrep.nl. 2372 IN CNAME druif.wrep.nl. This says wrep.nl is a CNAME for druif.wrep.nl, which means druif.wrep.nl is druif. {CNAME for druif.wrep.nl} or druif.druif.wrep.nl, and so on.
    – David Schwartz
    Nov 27, 2011 at 0:00

4 Answers 4

Reset to default
3

I found someone with the same problem I had on the Google public DNS Google Group. The comment from Alex Nizhner helped me solve my problem.

It seems that if you first resolve wrep.nl and this turns out to be a CNAME to druif.wrep.nl the DNS client will cache this. If then you try to resolve the MX record for wrep.nl it will respond with the cached CNAME record and will not return the correct MX record.

So I changed wrep.nl to an A-record waited for all DNS servers to get in sync and everything is working as expected now. All mail is coming through. :)

Improve this answer
2
  • Good to head the problem has been solved! Don't forget you can accept your own answer. This will help others with similar problems find the answer quickly.
    – Aron Rotteveel
    Nov 26, 2011 at 19:09
  • @AronRotteveel Will do, but have to wait 11 more hours before I'm allowed to accept. :)
    – Mac_Cain13
    Nov 27, 2011 at 9:38
2

I seem to be located not very far from you and get results that seem to be fine.

This issue might be caused by the fact that Google's Public DNS servers use anycast to route 8.8.8.8 and 8.8.4.4 to different datacentres, as indicated here. Perhaps there are some routing differences based on the location from which you are querying the servers. This could easily be tested by logging into some of your servers and performing a query on the same IP-address there.

Based on what you are writing now and what I see here, my best bet is that the problem is based on a cached entry that is still being served from some datacentres. If the issue persists, you might want to take it up to the Google Public DNS usergroup.

Query results from 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

Query results from server located in 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

Query results from 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
Improve this answer
1
  • Thanks for testing and posting the results! Turned out to be an error in my DNS configuration after all (check my own answer), but your results helped me realize it wasn't Google DNS not syncing properly.
    – Mac_Cain13
    Nov 26, 2011 at 16:05
1

Working fine here.

; <<>> 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
Improve this answer
1
  • Interesting, so it seems that when you query the Google DNS servers (from NY I guess?) you get other results then I get from the Netherlands. I tried on several machines to be sure it was not my machine going crazy. Starting to think there is one Google DNS machine (in Europe) not syncing records correctly. :(
    – Mac_Cain13
    Nov 25, 2011 at 20:51
0

Funnily enough, I noticed this the other day when working on my DNS servers.

After updating a zone to add a MX record I checked Google's server to see if it would pick it up. It picked up the new SOA serial number but still cached the old MX record.

I suspect that Google's caching method caches individual records that don't get flushed when the zone serial number changes.

Improve this answer
1
  • 1
    That's everyone's caching method. Read RFCs 1034 and 1035.
    – JdeBP
    Jan 20, 2012 at 13:30

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .