Path: utzoo!utgpu!water!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!bloom-beacon!gatech!ncar!tank!oddjob!mimsy!dftsrv!ames!lll-tis!mcb
From: mcb@tis.llnl.gov (Michael C. Berch)
Newsgroups: comp.mail.sendmail
Subject: Re: Sendmail/resolver problem
Message-ID: <22431@tis.llnl.gov>
Date: 18 Oct 88 20:50:29 GMT
References: <22426@tis.llnl.gov> <8XJXoXy00VsLE0VVkX@andrew.cmu.edu>
Reply-To: mcb@tis.llnl.gov (Michael C. Berch)
Organization: Lawrence Livermore National Laboratory, Livermore CA
Lines: 38

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