[comp.mail.sendmail] Sendmail/resolver problem

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 system

mcb@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