Date: Fri, 12 Jan 2001 12:02:33 +1100 From: Mark.Andrews@nominum.com To: Mike Andrews <mandrews@bit0.com> Cc: stable@freebsd.org Subject: Re: Weird sporadic DNS resolution problems Message-ID: <200101120102.f0C12X863536@drugs.dv.isc.org> In-Reply-To: Your message of "Thu, 11 Jan 2001 12:21:51 CDT." <Pine.BSF.4.21.0101111217090.23537-100000@mindcrime.bit0.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> 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? > 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. > > This is especially chronic because Sendmail tries to resolve domains on > incoming email (for spam protection purposes)... it will give "Domain of > sender address foo@bar does not resolve" and return a 451 code. This > causes the other end to retry periodically, unless the other end is > something like Outlook Express, in which case the customer calls me and > complains. :) > > One example domain is "farmersfrankfort.com". This was moved from us to > another site yesterday, but we still do MX for them. Looking at whois and > at the root servers, you can see that their two new nameservers are now > "cerberus.sbscorp.com" and "ns1.qwest.net". Querying the sbscorp server > works great, querying qwest doesn't -- it appears Quest never added them > to their nameserver config at all. (It has been only about 24 hours, so > it's not *too* surprising I guess...) Servers are supposed to be serving the zone *before* they are delegated to. > Anyway, when someone on one of our > dialups tries to send mail with @farmersfrankfort.com on the end, our > Sendmail is unable to resolve it and rejects the message. If I restart > (not reload) named, it will start working for a while, then die on its own > again. My theory is that if it happens to query sbscorp it's happy, if it > happens to query qwest it isn't, and caches the fact that it isn't. > > Another example is "setel.com" and "se-tel.com". We sometimes have > problems exchanging mail with them because one of their DNS servers > appears to be answering non-authoritatively. Again, I can flush my > backlog by restarting named and immediately running the sendmail queue > manually (and I could probably flush their backlog by telnetting to their > SMTP port and issuing an ETRN)... but obviously that's not exactly > elegant :) 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. > > I've tried adding "max-ncache-ttl 1" to my named config, hoping it would > help. It didn't. It's not caching a negative answer so of course this has no effect. > > 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. > > Anyone have any ideas as to what's going on, or can tell me what debugging > output to enable that I could send here that would help figure it out? > Configuration options to named that would revert to older behavior? A > whack on the head? (I could just compile an older named I guess, but I > fear opening up security holes/DoS attacks.) > > > Mike Andrews * mandrews@dcr.net * mandrews@bit0.com * 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 majordomo@FreeBSD.org > with "unsubscribe freebsd-stable" in the body of the message -- Mark Andrews, Nominum Inc. 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark.Andrews@nominum.com 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?200101120102.f0C12X863536>