1

I have the following BIND zone file pointing the webserver to yyy.yyy.yyy.yyy and the nameservers and mail server to xxx.xxx.xxx.xxx:

$TTL 300
@      86400    IN      SOA     ns1.domain.com. admin.gmail.com. (
                2016012708      ; serial, todays date+todays
                86400           ; refresh, seconds
                7200            ; retry, seconds
                3600000         ; expire, seconds
                86400 )         ; minimum, seconds

domain.com. 86400 IN NS ns1.domain.com.
domain.com. 86400 IN NS ns2.domain.com.

ns1.domain.com. IN A xxx.xxx.xxx.xxx
ns2.domain.com. IN A xxx.xxx.xxx.XXX

domain.com. IN A yyy.yyy.yyy.yyy
localhost.domain.com. IN A 127.0.0.1

domain.com. IN MX 0 mail.domain.com.
mail.domain.com. IN A xxx.xxx.xxx.xxx
domain.com. IN TXT "v=spf1 +a +mx +ip4:xxx.xxx.xxx.xxx ~all"

www IN CNAME domain.com.
ftp IN A yyy.yyy.yyy.yyy.

The MX record should resolve to xxx.xxx.xxx.xxx for the mail server, but instead it returns xxx.xxx.xxx.xxx.domain.com. I have tried using "mail" instead of "mail.domain.com" in the A record, and I have tried combinations of trailing dots versus no trailing dots, thinking relative vs absolute paths might be the problem. But this has all been to no avail. Is there something obvious about the syntax that I am missing here?

meridionaljet
  • 351
  • 2
  • 4
  • 10
  • Is this a zone file in bind? Where is the SOA part? – Diamond Jan 27 '16 at 21:20
  • Yes, it is. I didn't think the SOA section was relevant, but I've added it to the post. – meridionaljet Jan 27 '16 at 21:35
  • Are you getting your results by some variant of `dig @xxx.xxx.xxx.xxx -t mx +norecurse domain.com`, and does `dig @xxx.xxx.xxx.xxx -t soa +norecurse domain.com` give you the correct serial number, and do all the other records work as expected? – Law29 Jan 27 '16 at 22:50
  • @Law29 Interesting - the returned serial number is from an earlier edit of the zone file, despite my TTL being set low in case I encountered bugs like this. – meridionaljet Jan 27 '16 at 23:10
  • @meridionaljet If you are querying the authoritative server directly (as per Law29's suggestion) caching/TTL is not a factor. If you get a different serial number you do not have the latest version loaded for whatever reason. – Håkan Lindqvist Jan 27 '16 at 23:14
  • @meridionaljet As for the described behavior, can you clarify the incorrect record that you see? The value of an `A` record cannot be anything but an IP address, so you can't get a domain name appended there. The value of an `MX` record cannot be anything but a name (ie, it cannot be an IP address), so it wouldn't make any sense that you tried to put an IP address there (however, I suppose if you did you could get a result like you describe... but that's not what the included zone data looks like). So I'm a bit confused as to what is/was going on. – Håkan Lindqvist Jan 27 '16 at 23:19
  • @Håkan Lindqvist Previously running "host -t mx domain.com" returned "xxx.xxx.xxx.xxx.domain.com" instead of "xxx.xxx.xxx.xxx" like it should. Obviously the former does not resolve. I just tried "service named restart" to see if that would help, but now the same host command returns "host domain.com not found: 1(FORMERR)". Named has given no errors. – meridionaljet Jan 27 '16 at 23:31
  • I found the issue - see answer below. – meridionaljet Jan 27 '16 at 23:53

1 Answers1

2

I found the problem after trying to restart BIND, which caused the server to go offline completely. This prompted me to run named-checkzone, which pointed out an errant "." following the ftp record (see "yyy.yyy.yyy.yyy." in original post). This was causing the file to be ignored whenever the configuration was reloaded. After fixing this, the zone file was loaded successfully and DNS queries now return "mail.domain.com" for the MX record as they are supposed to. Thanks to Law29 and Håkan Lindqvist for helping me think through this.

meridionaljet
  • 351
  • 2
  • 4
  • 10