Xref: utzoo comp.protocols.tcp-ip.domains:811 comp.mail.misc:5699 Newsgroups: comp.protocols.tcp-ip.domains,comp.mail.misc Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!wuarchive!uunet!icom!xwkg.Icom.Com!andy From: andy@xwkg.Icom.Com (Andrew H. Marrinson) Subject: Help with bind & smail3.1 when not on Internet Organization: Icom Systems, Inc. Date: 11 Jun 91 22:27:47 GMT Message-ID: Summary: Can't use bind with smail3.1 on unconnected LAN Keywords: smail, DNS, bind Sender: news@icom.icom.com (News Feed) Lines: 68 Hello, I am having a problem using Ron Karr's smail 3.1.19 with the bind name server. What is causing the problem is that I am not connected to the Internet, but have a small isolated LAN. In the past, I have used smail in such a way that it uses gethostbyname to determine if a host is on my LAN, and, if it is, to convert its name to an Internet address. Unfortunately, I know have a need to use MX records (for a Novell mail gateway) and WKS records (for a DOS machine that is on the net with TCP/IP, but doesn't have an SMTP server -- it gets its mail via UUCP). No problem, I thought, I just configure in smail's bind driver, which causes it to query the name server directly rather than using gethostbyname. I did this, and it *seemed* to work fine. Until I tried to send mail to an off-site domain, that is. It seems that bind (the Berkeley implementation of DNS, used by most Unix systems -- as if you didn't know that) is returning a response code of ``Server failure'' when a query is sent requesting a domain ``above'' ours. Thus, requesting foo.icom.com (which doesn't exist in our icom.com domain) gets a ``Name Error'' response (a.k.a. non-existent domain) as I would expect. But foo.bar.baz gets ``Server failure''. The problem is that smail treats server failure as a temporary condition, and deals with it by deferring mail transmission until some future time, whereas if the response is name error, smail tries another way of determining what address to send to, for example, UUCP. Which brings me to the questions. First, for you DNS experts, is it appropriate to get a server failure response when no name server can be found that is authoritative for the zone in question? Is there any way around this? I know I can deal with it by setting up empty zones for all the top-level domains, and that would have been fine back when there were only .com, .mil, etc., but these days that seems like a real bad way to go. I even tried adding an SOA RR owned by the domain ".", hoping that would make my server authoritative for the root domain, and everything under it, but it was no go... Finally, for you smail3.1 experts, has anyone else found a good way to deal with this? I just grabbed smail3.1.21, but it doesn't seem to do anything any differently in this regard. This is the second time I've tried to solve this, and I just don't get it. most of the RFC's and bind documentation relevant to this assume you are connected to the Internet, and therefore will simply bump the problem up to another name server. If all name servers work like this, the root server must have a hell of a master file. I thought things were looking up when I noticed a comment in RFC 1123's DNS section that said it was important that a name server work in a LAN not connected to the Internet, but it didn't say much about how to go about this. I suppose I could just get source for bind, and hack on it, but that seems like a drag. Or I could modify smail to not distinguish between server failure and name error, but that seems dangerous -- the server(s) could actually be down, in which case we want to wait and try again later. Surely, someone else has tried this? Hopefully yours, -- Andrew H. Marrinson Icom Systems, Inc. Wheeling, IL, USA (andy@icom.icom.com)