Date: Thu, 18 Jan 2001 00:14:03 -0600 From: Christopher Schulte <christopher@schulte.org> To: jason@routermonkey.com Cc: Mark.Andrews@nominum.com, Mike Andrews <mandrews@bit0.com>, stable@freebsd.org Subject: Re: Weird sporadic DNS resolution problems Message-ID: <20010118001402.A60881@schulte.org> In-Reply-To: <20010113123754.B1299@fry.routermonkey.com> References: <20010113123754.B1299@fry.routermonkey.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> The interesting difference in my problem (I think it's interesting...) > is that neither of the nameservers for dml.com are lame; they both > return valid A records for dml.com using dig, but my named seems to > think that there isn't an A record until I stop and restart named. > Then, when I do an nslookup / dig, it returns the correct result for > a while, until it stops working again. For what it's worth, my take: This could be broken down into a 2-part problem. One being bind not returning DNS data to sendmail, and two being that sendmail then defers the message based on the assumption that the lack of DNS data is in fact real. Sendmail is doing exactly what it should, IMHO. It relies on correct information from its nameserver(s), which in this case I don't think it's getting. I ran into the *exact* same problem with bind on a Linux machine. I then had several FreeBSD (and other *nixes like Solaris, OpenBSD, etc) fail with sendmail because my linux server would not give out data on domains for which: 1) the master servers did not set the authority bit in their DNS responses. 2) the TTL on the MX record for the domain was set to some low value, like 3600 seconds. Every single domain which sendmail had these delivery problems matched those two criteria points. What would happen is that on a bind restart, the MX data would be correctly cached for the TTL period (usually one hour) and then subsequent MX record lookups after the TTL expired would return serverfail, and from that point on sendmail would defer the mail because it thought the sender domain did not exist (and thus probably spam). Now, It seems like this problem sprouted its head when I moved up to bind 8.2.2-P7 from 8.2.2-P5. The BSD (Open, Free) boxes all had either 822p7, or some 823. Could this be a result of broken master nameservers and a change in how bind handled their responses? Flame away if I'm totally wrong. -- christopher matthew schulte geek boy gone bad christopher@schulte.org http://www.schulte.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20010118001402.A60881>