Here is a shortened version of the original question.
> When someone sends mail within our domain, there is DNS trafic from our DNS
> server to DNS servers outside our domain. This makes us dependent on the
> domain above us. It has been a thorn in the boss' side for about a year
> now. I have been tasked with solving this problem.
The problem is not with sendmail but with the intraction between sendmail
and the resolver. The _search list_ feature allows the use of short names,
e.g. when I give the resolver c-ps-sun, it appends the domain name to it
yielding a FQHN. This is good. However, sendmail gives the resolver a FQHN
which appends the domain name to that yielding nonesense. The resolver will
_search_ through a _list_ of host names as follows:
The first of these is handled locally, the next two are handled by name
servers outsode our domain. This is the DNS trafic we see going out of our
domain. This is very inefficient. It is also security hole. Piete Brooks
<Piete.Brooks@cl.cam.ac.uk> suggests reading RFC 1535, which says that the
use of partial domain matching should be avoided. He recommends using BIND
4.9.2, as do many others.
There are five options open to us. In order of increasing long term
benefit (and increasing difficulty :-), they are:
1) Live with it. When we lose the connection out of the domain, the mail
will still get through but it will take minutes.
2) Modify resolv.conf to say that the domain is "." (a single dot). We
win some and we lose some. See explanation later in the summary.
3) Force sendmail to give the resolver a short name when dealing with
local mail. I am pushing Sun to get an answer to this one.
4) Replace the resolver with BIND 4.9.2 as many have suggested.
5) Upgrade to Solaris 2.3. We will have to do this at some point, right?
> From: Geert Jan de Groot <GeertJan.deGroot@ripe.net>
> A possible 'fix' is to replace the resolver stuff with bind 4.9
> which has a nice feature:
> Search list for host-name lookup. The search list is
> normally determined from the local domain name; by
> default, it begins with the local domain name, then
> successive parent domains that have at least two com-
> ponents in their names. This may be changed by listing
> the desired domain search path following the search
> keyword with spaces or tabs separating the names. Most
> resolver queries will be attempted using each component
> of the search path in turn until a match is found.
> Note that this process may be slow and will generate a
> lot of network traffic if the servers for the listed
> domains are not local, and that queries will time out
> if no server is available for one of the domains.
> Bind 4.9 behaves much better anyway.
> From: email@example.com (Eckhard Rueggeberg)
> : > You can shorten this process by entering "domain ." in resolv.conf.
> : Please explain further the implications of the modification you suggest
> : that I make to resolv.conf.
> On the machine you sent the mail away from, the name resolver sees the
> name e.g. "emp.ewd.dreo.dnd.ca". As it is designed for _short_ hostnames,
> it tries to resolv this _local_ name by appending the default domain given
> in /etc/resolv.conf, which would give "emp.ewd.dreo.dnd.ca.ewd.dreo.dnd.ca".
> Of course your DNS server can't resolve this to a valid adress, so it asks
> the root name server for "ca", which can't resolve it either. So it omits the
> first part of the domain and thus contructs "emp.ewd.dreo.dnd.ca.dreo.dnd.ca",
> which isn't valid either. So it tries "emp.ewd.dreo.dnd.ca.dnd.ca",
> "emp.ewd.dreo.dnd.ca.dreo.ca" and "emp.ewd.dreo.dnd.ca.ca" to get finally to
> the correct "emp.ewd.dreo.dnd.ca".
> To illustrate this behaviour is quite good for _short_ hostnames, I'll give
> an example from us. The DNS server is called jumbo, default domain is
> ts.go.dlr.de :
> apollo (in ts.go.dlr.de) : no dots, no resolving needed.
> bell.es (in go.dlr.de) : appends ts.go.dlr.de
> -> bell.es.ts.go.dlr.de incorrect
> -> bell.es.go.dlr.de correct
> lane.rz.op ( in dlr.de) : appends ts.go.dlr.de
> -> lane.rz.op.ts.go.dlr.de incorrect
> -> lane.rz.op.go.dlr.de incorrect
> -> lane.rz.op.dlr.de correct
> As you see, only the parts differing from our own domain have to be given
> to ensure correct resolving. You can watch this behaviour with nslookup if
> you "set debug".
> Now I can shorten this process by entering only "go.dlr.de" as a default
> domain, because anything within "ts" will get resolved locally anyways.
> In the same manner you can shorten the process by entering "." as your
> default domain, because dot appended gives a name with a trailing dot,
> which means "this name is complete, nothing to append". This makes the
> adresses correct immediately in your case of FQHNs.
> This will affect only those services relying directly on DNS like sendmail
> and nslookup, it doesn't affect telnet, ping and ftp if you are running
> NIS. And it is valid for UNIX machines only. I don't know how to control
> name lookup for DOS machines which I assume SelectMail runs on. But it
> has to be similar there.
Geert Jan de Groot <GeertJan.deGroot@ripe.net> suggested that I use tcpdump
instead of snoop. tcpdump can be found on ftp.ee.lbl.gov. I got it but have
not installed it yet.
firstname.lastname@example.org (Eckhard Rueggeberg)
Geert Jan de Groot <GeertJan.deGroot@ripe.net>
"Gordon Lack" <email@example.com>
firstname.lastname@example.org (Pete Welcher)
"William L. Jones" <email@example.com>
This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:08:55 CDT