For what it's worth, I've also experienced problems with
Sendmail+BIND interaction. I've specifically had problems receiving
mail from dml.com, which hosts the zebra mailing list.
I finally had to resort to putting an entry in /etc/hosts so that
I could get mail from the mailing list.
Without the entry in /etc/hosts, I get the same sendmail error:
Domain of sender address [EMAIL PROTECTED] does not resolve
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.
I'm pretty sure the problem is on my end (Sendmail and/or BIND) or
else a lot of people on the zebra mailing list would be complaining
about how dml.com doesn't resolve.
On Fri, Jan 12, 2001 at 04:34:37PM -0500, Mike Andrews wrote:
> On Fri, 12 Jan 2001 [EMAIL PROTECTED] wrote:
>
> > > When one (but not both) of the nameservers for a domain replies
> > > non-authoritatively, named will cache a negative response, rather than
> > > asking the other nameserver.
> >
> > No. It caches that the server is lame for the zone then tries
> > other servers.
> >
> > > Subsequent lookups return an immediate
> > > failure.
> >
> > And what is logged when that happens?
>
> At the time of those lookups, nothing from Bind. Sendmail logs "Domain of
> sender address foo@bar does not resolve". When it caches that the server
> is lame, bind does log the expected "Lame server on foo.blah" message.
>
>
> > > Restarting the nameserver, and then immediately querying the
> > > same problematic domain DOES work, but only the first query. After a few
> > > minutes/hours the domain stops working again.
> >
> > This sounds more like a bad delegation, parent and child
> > zones dissagreeing on the nameserver RRset, than a lame
> > server.
>
> > Servers are supposed to be serving the zone *before* they are
> > delegated to.
>
> Either way, the other guys have their nameserver screwed up pretty badly.
> I knew this already, though...
>
>
> > Well both the servers for setel.com are lame as are se-tel.com.
> >
> > If all the sources of information are bad what do you expect
> > the namesever to do.
>
> Hm. My named thinks ns2.se-tel.com is definitely lame, but not ns1 (at
> least it's never logging ns1 as lame...)
>
>
> > > In one sense this is "not my problem" because their name server shouldn't
> > > be answering non-authoritatively in the first place. But the fact that
> > > this started happening after a make world a few months ago, and that I
> > > feel it should be a slight bit more tolerant of other people's sloppy
> > > configurations, makes it my problem.
>
> And this is the real question that remains:
>
> Why did receiving email from places with one lame and one not-lame
> nameserver work reliably in 4.1.1-RELEASE, and not in 4.2-STABLE?
>
> I realize (like in the farmersfrankfort.com) case that it's Qwest's
> problem (not mine) that the second nameserver for that domain is lame. But
> in 4.1.1-RELEASE it would still eventually get the right info from the one
> that did work. It doesn't anymore. What changed in Bind or Sendmail to
> make it less tolerant of everyone else's broken nameservers? I'm starting
> to wonder, like Mike Tancsa's earlier response, if this is maybe specific
> to Sendmail, or a Bind+Sendmail interaction...
>
>
> Mike Andrews * [EMAIL PROTECTED] * [EMAIL PROTECTED] * http://www.bit0.com
> VP, sysadmin, & network guy, Digital Crescent Inc, Frankfort KY
> Internet access for Frankfort, Lexington, Louisville and surrounding counties
> www.fark.com: If it's not news, it's Fark. (Or something like that.)
>
>
>
>
>
>
>
>
> To Unsubscribe: send mail to [EMAIL PROTECTED]
> with "unsubscribe freebsd-stable" in the body of the message
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-stable" in the body of the message
