jf@ap.co.umist.ac.uk (John Forrest) (11/13/90)
Here is another great comment, from daemon.c in the sendmail 5.65+IDA source:
/*
** Don't do recursive domain searches. An example why not:
** Machine cerl.cecer.army.mil has a UUCP connection to
** osiris.cso.uiuc.edu. Also at UIUC is a machine called
** uinova.cerl.uiuc.edu that accepts mail for the its parent domain
** cerl.uiuc.edu. Sending mail to cerl!user with recursion on
** will select cerl.uiuc.edu which maps to uinova.cerl.uiuc.edu.
** We leave RES_DEFNAMES on so single names in the current domain
** still work.
**
** Paul Pomes, CSO, UIUC 17-Oct-88
*/
Where this comment is actually positioned, with Sendmail trying to open a port,
this makes some sense (probably alot, but I haven't thought this bit fully
through). However, further down we find:
# ifdef NAMED_BIND
/*
** See note in makeconnection() above for why we disable
** recursive domain matching. -pbp
*/
_res.options &= (~RES_DNSRCH & 0xffff);
/*
** But make sure default domain qualification is enabled -
** it may have been disabled in deliver.c. -nr
*/
_res.options |= RES_DEFNAMES ;
# endif /* NAMED_BIND */
hp = gethostbyname(hbuf);
if (hp == NULL) {
/* try lowercase version */
(void) strcpy(tmphbuf, hbuf);
(void) makelower(tmphbuf);
/* Could be just an MX record; look for anything */
ret = getcanonname(tmphbuf,sizeof(tmphbuf));
That is, the same modification has been added to where sendmail tries to use BIND
to retrieve the canonical name. Nett effect? Well, domain searching doesn't work
- that is the effect explicitly required by this mod. This is a pitty - it means
you have to use other means to do what BIND will do automatically. For instance,
in our domain:
ap.co.umist.ac.uk
users expect to be able to resolve:
ap.co.umist -> ap.co.umist.ac.uk
cns.umist -> cns.umist.ac.uk
newcastle -> newcastle.ac.uk
all of this will be done by the domain searching, but no with just DEF_NAMES. In
fact, the latter only is next to useless - you can't even say jf@ap. This is one
problem I have with this particular change, the second is that I can't see the
point - unless I am very much mistaken, cerl!user will be converted to
user@cerl.uucp before looking up here, and cerl.uucp should not resolve to any
local domain. Have I missed something here. The second point, is there any
advantage of calling "gethostbyname" in the fragment above before "getcanonname"?
I'm tempted to take the former out, but would like to hear if there are problems
created.
John Forrest
PS. Thanks to Neil Rickert for describing the advantages of getcanoname failing
if the entry has its best MX back to the local node. Isn't this capability a
reason for tacking out tghe call to gethostbyname ?rickert@mp.cs.niu.edu (Neil Rickert) (11/14/90)
In article <1990Nov13.125434@ap.co.umist.ac.uk> jf@ap.co.umist.ac.uk (John Forrest) writes: >Here is another great comment, from daemon.c in the sendmail 5.65+IDA source: > > /* > ** Don't do recursive domain searches. An example why not: >(...) > >Where this comment is actually positioned, with Sendmail trying to open a port, >this makes some sense (probably alot, but I haven't thought this bit fully >through). However, further down we find: > ># ifdef NAMED_BIND > /* > ** See note in makeconnection() above for why we disable > ** recursive domain matching. -pbp > */ > _res.options &= (~RES_DNSRCH & 0xffff); > > /* > ** But make sure default domain qualification is enabled - > ** it may have been disabled in deliver.c. -nr > */ I admit to the '-nr' being me. There is some outdated documentation here. I guess that should be cleaned up some time. >to retrieve the canonical name. Nett effect? Well, domain searching doesn't work >- that is the effect explicitly required by this mod. This is a pitty - it means >you have to use other means to do what BIND will do automatically. For instance, More precisely, domain qualification works only for single unqualified names. But you do have the option of using DOMAINTABLE for qualification. As I mentioned above, some of the documentation for this needs cleaning up. Perhaps this behavior needs to be made an option selected with a preprocessor define. But consider the following scenario: It is quite conceivable that at some time in the future our French French department will have a computer 'eiffel.fr.niu.edu'. It is possible that there will also be a host 'eiffel.fr' in France. With RES_DNSRCH enabled, any attempt to send mail to 'eiffel.fr' would instead end up at 'eiffel.fr.niu.edu' This sort of thing is no problem in interactive programs such as telnet or ftp, where the user can see what is happening and work around it. But email processing is in the background, and is hard to work around. I prefer to consciously decide whether to do this qualification, based on DOMAINTABLE entries, rather than leave it to chance. If however, you don't like this, you could always eliminate the statements in domain.c and daemon.c which turn off RES_DNSRCH. But DON'T touch any statement which also turns off RES_DEFNAME or you may have problems. >local domain. Have I missed something here. The second point, is there any >advantage of calling "gethostbyname" in the fragment above before "getcanonname"? >I'm tempted to take the former out, but would like to hear if there are problems >created. I believe the original Berkeley sources do not have the gethostbyname() call. But here are the reasons you should not remove it: 1. gethostbyname() is cheaper. There are many more copies of A and CNAME records lying around in the nameservers. This function call is only used in domain qualification, so if a short route can be found with the A record, it is a worthwhile savings. 2. We made some other changes from Berkeley code. This effects the case when MX wildcards are presumed to exist for the local domain. The Berkeley code is to only search for A and CNAME records, and not for MX records. Since the IDA configs use domain qualification for validation and mailer selection, this would result in a crippled performance when wildcards are a problem. In place of this, we now turn off RES_DEFNAME and RES_DNSRCH (only if wildcards are a problem) in canonicalizing a name. This would prevent any domain qualification had there not been a prior call to gethostbyname() which can find A and CNAME records with RES_DEFNAME still enabled. > >John Forrest -- =*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*= Neil W. Rickert, Computer Science <rickert@cs.niu.edu> Northern Illinois Univ. DeKalb, IL 60115. +1-815-753-6940