Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!zaphod.mps.ohio-state.edu!rphroy!caen!sdd.hp.com!wuarchive!uunet!sobeco!stacy From: stacy@sobeco.com (s.millions) Newsgroups: comp.sys.mips Subject: Re: Problems with BIND on MIPS RISC/os 4.52 Message-ID: <1991May9.151231.12910@sobeco.com> Date: 9 May 91 15:12:31 GMT References: <1991May8.112051.23205@spider.co.uk> Sender: @sobeco.com Organization: Groupe Sobeco, Montreal, Canada Lines: 141 Nntp-Posting-Host: sobmipd.sobeco.com I send mips a bug report concerning the nameserver and resolver, the reply: > The following bug report has been received by the bug system. > It has been entered into the database as bug number 08409. Shared libraries would make fixing this on conceivable, but I don't want to have to support our own version of telnet, ftp, r*, etc. So here I sit waiting for the fix for 08409 (patiently of course :-). keith@orbweb.spider.co.uk (Keith Mitchell) writes: > domain name The default domain to append to names > that do not have a dot in them. This > defaults to the domain set by the > domainname(1) command. This is a lie... [Sound effects: in my best Darth Vader impression] You don't realise the power of the Dark side of the Source. >Further, my experiments indicate that the value of `domainname` has >no effect on BIND operation. True, if you are talking about The domainname stored in the kernel (set via domainname command) not the one in /etc/resolv.conf >My problem is, that if I set up a MIPS system with a FQDN for the >`hostname`, (e.g. "redknee.spider.co.uk"), and null for `domainname`, >then it sends a whole load of spurious queries. With a "resolv.conf" >file containing: >nameserver 134.191.128.6 >nameserver 134.191.64.3 >and a "vis.conf" with: >host: dns files (telling it to the consult DNS before the > /etc/hosts file, no YP) >and I then try to resolve, say "raft", the first query it sends to >the nameserver is doubly qualified - "raft.spider.co.uk.spider.co.uk". >When this fails, it tries "raft.spider.co.uk.co.uk", and only on the >third attempt does it get it right with "raft.spider.co.uk". >My understanding was that the default domain was only appended >(once) if the name to be resolved was either single-token, or >non-local. Our set up is this, hostname's are not FQDN, and we set the domainname. our resolv.conf looks like: domain sts.sobeco.com nameserver 132.220.1.4 nameserver 132.220.1.8 If a host netserv.sobeco.com want to resolve multilis (multilis.sobeco.com) it will first try to look up multilis.sts.sobeco.com, when that fails, it will try multilis.sobeco.com and that will work. If it is trying to resolve mercure (mercure.sts.sobeco.com) it will first try mercure.sts.sobeco.com and that will work. If it tries to resolve mercure.sts, it will first try mercure.sts.sts.sobeco.com, that will fail and it will try mercure.sts.sobeco.com. Please note: right now we are very lucky... we only have two domains, sobeco.com and sts.sobeco.com, the minute we add another my life gets very miserable. If the domains are a.sobeco.com , b.sobeco.com and sobeco.com, any machine in domain sobeco.com will have to use host.a or host.b as the minimum resolvable name in the other domains, and any on in domain a that wants a host in domain b will also have to use host.b to resolve the name. I hope the resolver will work properly long before I need to add another level to our domain tree. >I can make this problem go away if I set the `hostname` to just a >single token (e.g. "redknee"). This requires a "domain spider.co.uk" >directive to be added to /etc/resolv.conf, so that the system knows >what its default domain is. The problem here, is that if I want to >run a named on the host, as a secondary or caching server, it has no >means of knowing what domain it is in unless it is set in >/etc/resolv.conf. Berkeley documentation and acknowlegded wisdom on >this list is quite clear you should *not* have a resolv.conf file on >a host running a server. Also, sendmail (5.61+IDA) does not seem to >be entirely happy with a non-FQDN `hostname`. We do have a resolv.conf on machines running a server: nameserver 127.1 It works. Sendmail 5.65+/IDA-1.3.5 is working fine here. [I now climb up on the soap box] A nameserver is just that, a server. It provides FQDN to address (and a bunch of other, stuff of course). A resolver takes a single token or partial qualified domain name and by applying the rules set out in the resolv.conf returns you a FQDN. I should be able to list all of the domain names that I want to be resolved and the order I want them in. [OK, I will get off the soap box now] >This is a fairly serious problem for me, as all these spurious, doubly- >qualified queries, which seem to me to be completely avoidable, >can badly sieze up our systems while they munge through them >waiting for the correct response. Another problem you will find, is that if the first server listed in you resolv.conf crashes, the resolver will not move on to the next. We tried to fix this by using forwarding named's on all of the hosts, but this only works some of the time, the rest of the time you get unknown host. We have had to resort to building a host table from the nameserver data and keeping that up to date on all hosts (AAAARRRRRRGGGGGGGG!!!!!!) >The problems are further compounded by the version of named supplied >with RISC/os 4.52 - I am not quite sure what release it is, but >I suspect before 4.8.1. Irrespective of release, turning on deugging >(via -d or "kill -SIGUSR1") causes the named process to bomb out. MIPS ships there named compiled without DEBUG. Is this brave or foolish? Maybe we should vote on it :-) >I really can't help feeling this shouldn't all be as involved as >this, and that I am missing something somewhere. Can anyone >with experience of running DNS on MIPS systems cast any light ? I think what you are missing is this: General rule of thumb, nameservers are necessary evil, but don't trust them. Same goes for resolvers. We ended up with a host file that looks like: xxx.xxx.xxx.xxx FQDN all aliases we want This way we will get back a FQDN regardless of the state of the nameserver or resolver. I would much rather I didn't have to do this, but this is an imperfect world, and it would seem that Murphy loves computers. -- "I am not a merry man!" stacy@sobeco.com - Worf _ST:TNG_ stacy@sobeco.ca uunet!sobeco!stacy