mcb@tis.llnl.gov (Michael C. Berch) (10/14/88)
The discussion of sendmail/resolver interaction and rooted vs. non-rooted lookups prompts me to post in search of a solution -- or at least a pointer in the right direction -- to our sendmail/resolver problem. I'm pretty sure it can be fixed in sendmail.cf (possibly by the method mentioned of adding a "." to indicate a rooted domain name), or perhaps elsewhere in the resolver/server area. The problem is that we are unable to send mail *locally* among our machines when the sending machine is unable to communicate with either the second-level name server above it, or with the Internet (i.e., the root servers). Presumably this should not occur. Assume our two machines are a.foo.bar.gov and b.foo.bar.gov, and someone on "a" sends to "user@b". Our sendmail.cf canonicalizes "b" by appending the default domain name, "foo.bar.gov", and the host "b.foo.bar.gov" is sent to the resolver. When sendmail goes out to the server, the query actually is res_mkquery(b.foo.bar.gov.foo.bar.gov) [other args omitted] i.e., it appends the default domain name *again*. This query is answered NXDOMAIN, and it drops the least-significant-part of the appended domain and tries again: res_mkquery(b.foo.bar.gov.bar.gov) If no server for bar.gov is reachable, the query fails and the mail is requeued with "Name Server Failure for host b.foo.bar.gov". If the bar.gov NS is reachable, the query is answered NXDOMAIN, and it tries again: res_mkquery(b.foo.bar.gov.gov) which requires a root server, and if we can't reach the Internet, then it fails as above and is undeliverable. The sendmail binary involved is denoted "SMI 4.0" and is the one mentioned by Casey Leedom and Bill Nowicki in the discussion of Sun mx-sendmail's on NAMEDROPPERS recently. I don't personally have the source but presumably we have access to it here. What I would like to do is have sendmail not need to loop local queries through the root at all. I'm sure it shouldn't have to. The two alternatives seem to be 1) DON'T canonicalize local names in the sendmail.cf before they are resolved, allowing the resolver query-builder to tack the default domain on itself, or 2) make sure that all names, including local names, are rooted names so that the local server will give a quick, authoritative answer on the first try. Michael C. Berch mcb@tis.llnl.gov / uunet!tis.llnl.gov!mcb / ames!lll-tis!mcb
cfe+@andrew.cmu.edu (Craig F. Everhart) (10/15/88)
Ideally, you would get to specify (from your sendmail.cf) whether the
underlying getcanonname() routine should attempt appending default domain names
or not. Actually, you can specify whether to try default domain names: if you
append a ``.'' to the domain name, the resolver isn't supposed to try to append
default names.
I believe that the list of ``default domains'' attempted does not include the
parent's top-level domain, precisely so that one doesn't bang on the root
servers looking for ``gov.gov'' or whatever. That is, using your example, if
your host name is a.foo.bar.gov and you're looking up b.foo.bar.gov, your
resolver will try
b.foo.bar.gov.foo.bar.gov
b.foo.bar.gov.bar.gov
b.foo.bar.gov
That is, it isn't supposed to be trying
b.foo.bar.gov.gov
And if you ask about ``b.foo.bar.gov.'', it shouldn't be appending any suffixes.
Craig Everhart
Andrew message systemmcb@tis.llnl.gov (Michael C. Berch) (10/19/88)
In article <8XJXoXy00VsLE0VVkX@andrew.cmu.edu> cfe+@andrew.cmu.edu (Craig F. Everhart) writes: > Ideally, you would get to specify (from your sendmail.cf) whether the > underlying getcanonname() routine should attempt appending default > domain names or not. Actually, you can specify whether to try default > domain names: if you append a ``.'' to the domain name, the resolver isn't > supposed to try to append default names. Right. That's what prompted me to ask; if the final rule before name resolution appends the dot, then everything should work fine, but I wondered if there was some trivial way to avoid doing that, since I don't see very many sites that actually append the dot, yet many (most? :-)) sites seem to have sendmail and the resolver working together reasonably well. > I believe that the list of ``default domains'' attempted does not include the > parent's top-level domain, precisely so that one doesn't bang on the root > servers looking for ``gov.gov'' or whatever. That is, using your example, if > your host name is a.foo.bar.gov and you're looking up b.foo.bar.gov, your > resolver will try > b.foo.bar.gov.foo.bar.gov > b.foo.bar.gov.bar.gov > b.foo.bar.gov > That is, it isn't supposed to be trying > b.foo.bar.gov.gov Yeah, that looked odd to me, too. But it really did do it, on a machine that is a resolver client (remote-only server via /etc/resolv.conf) of the real name server. On the name server machine it doesn't do that, which leads me to believe that there may be something wrong with the resolv.conf file on the clients. Also, the general-case problem remains -- we in foo.bar.gov don't want to be stuck even when the bar.gov name server is unreachable (it is on a different network). Thanks for your help. Michael C. Berch mcb@tis.llnl.gov / uunet!tis.llnl.gov!mcb / ames!lll-tis!mcb
emv@a.cc.umich.edu (Ed Vielmetti) (10/19/88)
In article <22431@tis.llnl.gov> mcb@tis.llnl.gov (Michael C. Berch) writes: >... we in foo.bar.gov don't want to be stuck even when the bar.gov >name server is unreachable (it is on a different network). If your name server is not under your administrative control, and you depend on a name server for production work, then I can suggest several solutions: - turn foo.bar.gov into a domain, and have hosts be your-name-here.foo.bar.gov. Have the bar.gov allocate authority for foo.bar.gov to your name server and make sure that your own server works. - if you're unwilling to rename machines, run an unannouced primary on your subnet, and update the tables with rdist or what have you. Or run a real secondary server there. If you are hosed because your name server doesn't work often enough, fix your name server, don't hack up your sendmail. If your service provider isn't providing adequate service, do it yourself. --Ed