bind-8.1.2, lost MX's

[Barry Margolin]

In article <19990610101218.B12040 at tfj.rnd.uni-c.dk>,
torben fjerdingstad  <unitfj-bind at tfj.rnd.uni-c.dk> wrote:
>Sometimes mail fails, apparently because bind-8.1.2 gives
>wrong information about MX's.
>
>Our mail server is a precedence, say, 20 MX for some customers
>who have their own mail server as precedence 10.
>
>Sometimes, mail bounces because bind either says
>our mail server has the highest precedence, or
>there are no MX's for the domain name.
>
>It is hard to prove. Here is what I have (2 cases):
>
>1) This error was on my mail server, mail.net.uni-c.dk, which is
>using ns.darenet.dk for the resolver (bind-8.1.2):
>
>qmail error report:
><ca at dfu.min.dk>:
>Sorry. Although I'm listed as a best-preference MX or A for that host,
>it isn't in my control/locals file, so I don't treat it as local. (#5.4.6)
>
>In the above case, I am NOT the best preference MX, so bind must
>have delivered bogus data. The truth is:
>dfu.min.dk      preference = 15, mail exchanger = hfi02.dfu.min.dk
>dfu.min.dk      preference = 25, mail exchanger = mail.net.uni-c.dk
>
>Next,
>Using nslookup, it happens that a MX is not found. Here,

Maybe it has something to do with the 0 TTL on the hfi02.dfu.min.dk A
record.  It seems to prevent the nameserver from including the A record in
the Additional Records section of the reply.  However, that shouldn't
prevent the mailer from doing a separate lookup for the A record, so I'm
not sure why you're having this problem.

>the MX is missing in the first nslookup, while it is present in
>the second lookup. What is going on here?

Don't use -type=any when you're querying a caching server.  It only shows
the record types that happen to be in its cache at the time.  If the MX
record isn't in its cache, but other records are, it will only return the
other records.

I think some early sendmail implementations made the mistake of using ANY
queries (so that they wouldn't have to make a second query for the A record
if there aren't any MX records), but this was realized to be a mistake and
fixed years ago.  I suppose it's possible that your mailer also has this
bug.

-- 
Barry Margolin, barmar at bbnplanet.com
GTE Internetworking, Powered by BBN, Burlington, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.