karl@naitc.naitc.com (Karl Denninger) (09/25/90)
We have local domain name service implemented (we'll set up for "real" root servers and the like when our Internet link goes in). As part of this, we have one mail server, which exports /usr/spool/mail to all our workstations and each workstation has their mail service pointed back at the mail host. So far so good. BUT, we want to have the Internet (when installed) think that anything in our domain should have it's mail handled by the mailhost. Now, if I read the manuals and specs right, what I should do is insert something like this into our domain files: *.naitc.com. IN MX 0 nis.naitc.com. Which ought to, if I recall correctly, send all the mail for our domain to the mailhost (nis) for disposition. Only problem is -- it doesn't work. It appears that in.named ignores the fact that I put a period on the end of the domain name, and adds the domain again! Thus, I end up with a MX for "*.naitc.com.naitc.com"! ARGH! This is >not< what I wanted! :-) Leaving off the domain entirely gives the same result! This doesn't make sense... The real strange thing is that we also have a line in the zone file that reads: *.mcs.com. IN MX 0 bbs.naitc.com. Which works as one would expect -- a query for "mcs.mcs.com" returns a mail handler of "bbs.naitc.com". If I insert: print IN MX 0 nis.naitc.com. In the zone file it also works as I would expect and says that the machine "print.naitc.com" has a mailhost of "nis.naitc.com". What's up? Any gurus care to explain why the first example doesn't work, and the second two do? Is our in.named just plain broken? Should we bitch loudly to Sun (not that it will do any good) or get a PD copy of in.named (if one exists) and compile that? We're running SunOS 4.1. -- Karl Denninger AC Nielsen kdenning@ksun.naitc.com (708) 317-3285 Disclaimer: Contents represent opinions of the author; I do not speak for AC Nielsen on Usenet.
onoe@sm.sony.co.jp (Atsushi Onoe) (09/30/90)
In article <1990Sep25.163807.9632@naitc.naitc.com> karl@naitc.naitc.com (Karl Denninger) writes: > Only problem is -- it doesn't work. It appears that in.named ignores the > fact that I put a period on the end of the domain name, and adds the domain > again! Thus, I end up with a MX for "*.naitc.com.naitc.com"! ARGH! This > is >not< what I wanted! :-) > We're running SunOS 4.1. I think there is a problem in sendmail.mx, not in.named. sendmail.mx in SunOS 4.0 works, but the one in 4.1 it does not work. I think sendmail.mx must disable resolver options, RES_DEFNAMES and RES_DNSRCH, as you can see in deliver.c of BSD sendmail-5.64. Sun forgets this? I use adb and change the default value, and that sendmail.mx works well! Here is what I did. I've tested only on sparc. sparc# ls -l /usr/lib/sendmail.mx -r-sr-x--x 1 root 155648 Feb 8 1990 /usr/lib/sendmail.mx sparc# od -x /usr/lib/sendmail.mx | grep '0000 0006 0000 0004' 0443700 0000 0000 0000 0000 0000 0006 0000 0004 ### This may be contents of struct state (see resolv.h) ### 4443710 (octal) == 247c8 (hex) sparc# cp -p /usr/lib/sendmail.mx . sparc# adb -w sendmail.mx ?m 0 0xffffffff 0 247c8,10?X 0x247c8: 6 4 2c0 1 0 0 0 0 0 0 0 0 0 0 0 0 ### OK, this must be struct state. 247d0?X 0x247d0: 2c0 ### Hmm. This is RES_DEFAULT (resolv.h) 247d0?W 40 0x247d0: 0x2c0 = 0x40 ### disable RES_DEFNAMES and RES_DNSRCH. $q sparc# <you should try> -- Atsushi Onoe <onoe@sm.sony.co.jp> Workstation Div., Supermicro Systems Group, Sony Corporation