Date: Wed, 1 Jan 2003 18:13:30 +0100 From: Peter Much <pmc@citylink.dinoex.sub.org> To: Terry Lambert <tlambert2@mindspring.com> Cc: Gregory Neil Shapiro <gshapiro@FreeBSD.ORG>, Peter Much <pmc@citylink.dinoex.sub.org>, hackers@FreeBSD.ORG Subject: Re: sendmail: how to get the named of FreeBSD4.7 standards compliant? Message-ID: <20030101181330.C8233@disp.oper.dinoex.org> In-Reply-To: <no.id> from "Terry Lambert" at Dec 31, 2002 09:19:38 PM References: <no.id>
next in thread | previous in thread | raw e-mail | index | archive | help
! ! Gregory Neil Shapiro wrote: ! > pmc> While it is true that the said sendmail-option solves the problem ! > pmc> (if sendmail is new enough to understand it), I could nowhere find ! > pmc> information on how to fix the bug in the nameserver - that is, ! > pmc> in the nameserver that is packaged with FreeBSD 4.4 or 4.7. ! > ! > FreeBSD's nameserver is fine. The problem is the remote nameserver ! > authorative for the domain in question. That nameserver is incorrectly ! > returning SERVFAIL instead of NODATA (or possibly NXDOMAIN) for AAAA ! > queries. Nothing needs to be fixed in FreeBSD's nameserver. Sorry, Gregory, but You missed me entirely. What I am talking about is a limited test environment consisting _only_ of FreeBSD Systems. So what You name "the remote nameserver" is very well (or not well, in this case) a FreeBSD 4.4 or 4.7 nameserver! What is actually happening (I investigated further with tcpdump) is the following: (When I say "local" i mean the local machine, when i say "remote" i mean another machine in the limited test environment, when i say "outbound" i mean a linkup from the environment to the internet.) 1. a mail for remote delivery is locally created. 2. the local sendmail has the directive smarthost "gate". 3. the local nameserver is master/primary for the test environment domain, which is "oper.dinoex.org" (this does not exist in the real world). This nameserver has an MX for "gate" pointing to "gate-e", which is the LAN network interface name of "gate". It also has an A record for "gate-e". 4. sendmail asks the nameserver for various things during its startup and while parsing the mail (local interfaces, final destination hostname) - all of these work as to be expected. 5. sendmail enters delivery mode and asks for the MX record for "gate", and gets "gate-e.oper.dinoex.org". 6. Then it asks the nameserver for the "AAAA" record of "gate-e.oper.dinoex.org" (which does not exist - the nameserver answers by sending the zonefile header (seems ok?). Then sendmail asks again for the "AAAA" record of "gate-e" (without domain). Now the local nameserver does not answer, but tries to propagate the query up! If there is an outbound connection active, this query will go out to some internet forwarder (or possibly the root nameservers), and from there likely return as not existing - then the mail will be delivered. But if there is currently no outbound connection available, then this query will return with SERVFAIL, and then sendmail does put the mail into "deferred" state. Background: This environment should be configured to use an internet connection for internet-relevant things, but to work flawlessly without such a connection as long as matters do concern only systems within the LAN. That means, if I write a mail to hackers@freebsd.org, then it is obvious that there will be outbound traffic to lookup and verify this hostname (and likely the mail will be deferred if the outbound linkup is inactive). But if I write a mail to another system within the LAN, this has to work without an outbound connection. And usually it does, except for this AAAA lookup of the unqualified mail hub interface adress. ! However, it's possible to address the problem by placing a ! caching-only nameserver between you and the nameserver with ! the problem, and hitting the local nameserver, and letting it Difficult, as this nameserver runs on the local host. ! recurse only if the data isn't in cache. This will address ! the second and subsequent requests, but the first one will ! still take however long it takes the proxy request to time ! out, before the cache is loaded (and converts the SERVFAIL ! into a NODATA, but only for AAAA or A6 requests that receive ! no response or a SERVFAIL response). ! ! It's also possible to rip out IPv6 support entirely, which is ! what the people who won't fix their nameserver software are ! tacitly recommending. Yes, Ted, I understand well. And I see a lot of workarounds to get rid of the problem - the most simple would be to just upgrade all sendmail binaries so they understand the BrokenAAAA option. (Or even simpler in this case, to keep the internet connection up all time.) But this is, now that I have tracked and understood the problem, not my primary intention. Now I want to understand what is actually going wrong here and why. I do not think that my approach -to have an environment that is able to access the internet and is also able to run on its own- is essentially wrong. But in this case I am not even sure who is to blame: named or sendmail, or my named configuration (rather cookbook) - and while I am quite good in understanding mail matters, I am not all too experienced concerning nameservers or even IPv6. So I feel the need for a bit of competence gathering. Another matter is: this stuff is obviously creating network traffic and load on the root nameservers. What good for? And anyway, I would not have posted to "hackers" if I thought this a trivial matter.;-) ! I would be real tempted to automatically generate complaint ! email to the technical contact in the whois database for all ! AAAA/A6 requests that fail that way, instead, if the delay ! bthered me (which it doesn't). Well, in this case that technical contact would be me, and that's why I'm asking. ;-)) rgds, PMc To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030101181330.C8233>