Damned DNS.
So I’ve been wrestling with some funky DNS problem for a while now, and I just can’t figure out the issue. I’m using TinyDNS as the nameserver on two machines, and something keeps going wacky with the MX record for neuro-tech.net. When I check it out using the DNS tools (dig/host/whatever), it looks OK:
luke@flux:~$ host -t mx neuro-tech.net neuro-tech.net mail is handled by 0 a.mx.neuro-tech.net.
Then when I lookup the MX name, it seems correct also:
luke@flux:~$ host -a a.mx.neuro-tech.net Trying "a.mx.neuro-tech.net" ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 10133 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 2 ;; QUESTION SECTION: ;a.mx.neuro-tech.net. IN ANY ;; ANSWER SECTION: a.mx.neuro-tech.net. 85308 IN A 212.13.198.74 ;; AUTHORITY SECTION: neuro-tech.net. 258108 IN NS ns2.oceanlake.com. neuro-tech.net. 258108 IN NS ns1.oceanlake.com. ;; ADDITIONAL SECTION: ns1.oceanlake.com. 171708 IN A 69.20.65.214 ns2.oceanlake.com. 171708 IN A 69.20.65.215 Received 134 bytes from 127.0.0.1#53 in 3 ms
To me it all looks good. But for some reason, mail sent from Gmail bounce about half the time with the error message being “Unable to determine MX for neuro-tech.net”, and I periodically get bounced and unsubscribed from Debian mailing lists. I’ve even appealed to the TinyDNS mailing list for help; a few people helped out and I thought I had corrected the records, but it still has problems.
Ugh.
derek said,
June 21, 2004 @ 9:22 am
How’s email from Gmail to Oceanlake?
Luke said,
June 21, 2004 @ 9:25 am
Flawless. Which is fucked, since the configuration for the two MX records (4 actually - .com, .com.sg, and .jp) are all the same.
Fun stuff. I think I may soon give up on TinyDNS and just use Bind.
Peter Pentchev said,
June 21, 2004 @ 10:26 am
Yeah, I saw your post on the djbdns list and I was like, ‘Wow! Luke uses djbdns - great!’ :)
I wonder if the problem may be in the oceanlake.com setup. The people on the list mentioned that you need to have the same nameserver addresses for neuro-tech.net that your parents give, and you seem to have fixed that. However, this also holds true for oceanlake.com :)
[roam@straylight ~]> dnsq ns oceanlake.com h.gtld-servers.net
2 oceanlake.com:
99 bytes, 1+2+0+2 records, response, noerror
query: 2 oceanlake.com
answer: oceanlake.com 172800 NS ns1.oceanlake.com
answer: oceanlake.com 172800 NS ns2.oceanlake.com
additional: ns1.oceanlake.com 172800 A 69.20.65.214
additional: ns2.oceanlake.com 172800 A 69.20.65.215
[roam@straylight ~]> dnsq ns oceanlake.com 69.20.65.214
2 oceanlake.com:
98 bytes, 1+2+0+2 records, response, authoritative, noerror
query: 2 oceanlake.com
answer: oceanlake.com 259200 NS a.ns.oceanlake.com
answer: oceanlake.com 259200 NS b.ns.oceanlake.com
additional: a.ns.oceanlake.com 259200 A 69.20.65.214
additional: b.ns.oceanlake.com 259200 A 69.20.65.215
[roam@straylight ~]>
The first set of responses is from a gTLD server: the names and addresses that you have given to your registrar. They say that the oceanlake.com domain is managed by ns1 and ns2.oceanlake.com.
The second set of responses - the ones from ns1/2.oceanlake.com themselves - say something different: they give the same set of IP addresses, but a different set of names. So try changing the oceanlake.com NS records (the ‘.’ ones) to something like:
.oceanlake.com:69.20.65.214:ns1.oceanlake.com
.oceanlake.com:69.20.65.215:ns2.oceanlake.com
…and see if that helps :)
Luke said,
June 21, 2004 @ 10:34 am
Hm, thanks Peter. You may be right - I’m going to try updating the records. Cross your fingers ;-)
Peter Pentchev said,
June 21, 2004 @ 12:11 pm
Yikes.. good for you to follow my advice, but I missed something else: apparently, you have A records for ns1/2.oceanlake.com somewhere else (either ‘+’ or ‘=’ lines). If you do, and you’ve pasted the lines directly from my reply - along with the IP addresses - then your tinydns thinks that you have explicitly instructed it to send the IP addresses several times. Witness:
[roam@straylight ~]> dnsq ns oceanlake.com ns1.oceanlake.com
2 oceanlake.com:
227 bytes, 1+2+0+10 records, response, authoritative, noerror
query: 2 oceanlake.com
answer: oceanlake.com 259200 NS ns1.oceanlake.com
answer: oceanlake.com 259200 NS ns2.oceanlake.com
additional: ns1.oceanlake.com 259200 A 69.20.65.214
additional: ns1.oceanlake.com 259200 A 69.20.65.214
additional: ns1.oceanlake.com 259200 A 69.20.65.214
additional: ns1.oceanlake.com 259200 A 69.20.65.214
additional: ns1.oceanlake.com 86400 A 69.20.65.214
additional: ns2.oceanlake.com 259200 A 69.20.65.215
additional: ns2.oceanlake.com 259200 A 69.20.65.215
additional: ns2.oceanlake.com 259200 A 69.20.65.215
additional: ns2.oceanlake.com 259200 A 69.20.65.215
additional: ns2.oceanlake.com 86400 A 69.20.65.215
[roam@straylight ~]>
The fact that there are four items in the additional section for each of the nameservers means that the data file contains four lines with both a name and an IP address - four mappings of the same name to the same IP address. You only need one of those - the rest just make the response bigger than absolutely needed, and may sometimes lead to a confusion, like in this case where there are different TTL’s on the different lines.
It’s okay to do this every once in a while - hell, I just checked and I have duplicate name->address mappings on five different hosts in two domains :) Still, it might be better to fix it - just remove the IP addresses from the places where they are not really needed. If you have a ‘.’ line specifying ns1 as a nameserver, and you place the IP address there, you do not need a ‘+’ line or a ‘=’ line or anything like that for ns1.oceanlake.com: just use the name, tinydns will have learned the address from the ‘.’ line. So either do it as:
.oceanlake.com::ns1.oceanlake.com
+ns1.oceanlake.com:69.20.65.214
…or just:
.oceanlake.com:69.20.65.214:ns1.oceanlake.com
and no ‘+’ line.
Also, look through your data file for other lines containing both the name ‘ns1.oceanlake.com’ and the IP address; e.g. you do NOT need something like this:
.neuro-tech.net:69.20.65.214:ns1.oceanlake.com
If you have defined the name->address mapping somewhere else, this will suffice:
.neuro-tech.net::ns1.oceanlake.com
(and yeah, I seem to be in a long-speech mode today.. sowwy)
Luke said,
June 21, 2004 @ 12:17 pm
OK, damn, thanks :-) Lemme try this.
Luke said,
June 21, 2004 @ 12:31 pm
Already, I didn’t realize that the first instance in the nameserver component of a hostname generated the A pointer. Fixed it up, it should work well.
Thanks Peter, you da man.
Peter Pentchev said,
June 21, 2004 @ 12:46 pm
Naah… you still have to wait a couple of days to see if mail still bounces :) If it does, I’ll just have made you work for nothing :P
Luke said,
June 21, 2004 @ 12:47 pm
Heh, I hear that. It’s tempting to lower the TTL values to the minimum since I have a knack for screwing it up :-)
derek said,
June 21, 2004 @ 10:12 pm
You’ll know pretty much right away, Gmail is still trying to send the original bounced message I sent a week ago (I get notices daily).
This is interesting. It’s hard to believe that this would be problem. I realize that email is still not exactly considered a sacred form of business communication, but for it to fail simply because an SMTP (or MX) response is larger than expected.
Maybe it’s a function of TinyDNS, but bouncing mail because of a slightly unexpected response time seems a little excessive. Or, it could have been a problem with Gmail.
Did you have any problems getting mail from any other providers (hotmail, yahoo etc.)? This may be a problem with their mail servers.
derek said,
June 21, 2004 @ 10:17 pm
Argh. Preview preview preview. ;)
Sentences are numbered accordingly.
3. It’s hard to believe that this would be the problem.
4. .. larger than expected, that just seems a little too unreliable.
8. .. problem with their (meaning google’s) mail servers.
Wine on a Monday night is not all it’s cracked-up to be.
Luke said,
June 21, 2004 @ 10:24 pm
Yeah, I thought those things too. I also subscribe to the Debian users mailing list and periodically get bounced from it. So it’s not just Google’s MTA that’s screwing up. The Tinydns documentation refers specifically to this kind of bug happening in BIND - when an MTA is trying to lookup the MX record, it can fail for various, weird, decades-old reasons.
derek said,
June 21, 2004 @ 11:30 pm
I can understand with mailing lists or listservs. Far too many products implement their own, strange (in some cases), non-standard complaint practices when it comes to mail-headers that can cause havoc in mass-mailers.
However, for simple mail transfer, relying on RFC specifications that are decades-old in any current software (and believe me, I understand the problems with straying) still seems a little strange given how many people rely on the medium.
Luke said,
June 21, 2004 @ 11:34 pm
Yep, agreed. It’s more strange though - sometimes e-mails to the oceanlake.jp domain bounce. And the ones that bounce are sent from Exim, Exchange, Postfix, etc. Crazy stuff.