Keith Mitchell <keith@spider.co.uk> (05/08/91)
I have been grappling for some time now with trying to get BIND
working properly on our various MIPS machines, and must admit to
being no further, and still rather confused.
My confusion arises from various inconsistencies between the MIPS
and Berkeley documentation for BIND, and between various MIPS manual
pages on the subject. Some of this is not new, but here I will only
refer to the 4.52 RISC/os release.
The main question is: should the value returned by the `hostname`
command be fully qualified or not ?
In the Berkeley documentation, it categorically says that it should
be. But in the MIPS "resolv.conf" man page, it implies that the
domain should be set by the "domainname" command:
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.
However, in my experience, `domainname` is normally associated with
the YP/NIS domain only, and indeed in the "getdomainname" man page it says:
At the current time, only the Network Information Service
(NIS) makes use of domains.
Further, my experiments indicate that the value of `domainname` has
no effect on BIND operation.
The other thing which suggests that a FQDN should be used for the
hostname, is that the "hostname" command supports the "-s" option,
for truncating a FQDN to just the first token. This is not
documented.
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.
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`.
The other way I can make this problem go away is to make the
`hostname` a FQDN with a "." at the end, but this has even more dire
implications for mail.
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.
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.
While I can probably put 4.8.3 named up to fix this, replacing
the resolver libabries is out of the question, and I would
like to try and get the existing resolvers to behave sensibly
before I try sorting named out.
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 ?
Thanks,
Keith Mitchell (postmaster)
Spider Systems Ltd. Spider Systems Inc.
Stanwell Street 12 New England Executive Park
Edinburgh, Scotland Burlington
Phone: +44 31-554 9424 MA 01803
Fax: +44 31-554 0649 +1 (617) 270-3510
keith@spider.co.uk keith%spider.co.uk@uunet.uu.net
...!uunet!ukc!spider!keith zspz01%uk.ac.ed.castle@nsfnet-relay.ac.uklgy@phys.washington.edu (Laurence Yaffe) (05/09/91)
Keith Mitchell <keith@spider.co.uk> writes: >I have been grappling for some time now with trying to get BIND >working properly on our various MIPS machines, and must admit to >being no further, and still rather confused. >My confusion arises from various inconsistencies between the MIPS >and Berkeley documentation for BIND, and between various MIPS manual >pages on the subject. Some of this is not new, but here I will only >refer to the 4.52 RISC/os release. >The main question is: should the value returned by the `hostname` >command be fully qualified or not ? > [deleted] >The other thing which suggests that a FQDN should be used for the >hostname, is that the "hostname" command supports the "-s" option, >for truncating a FQDN to just the first token. This is not >documented. > [deleted] >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`. I can't speak about what's "right" (or is that "politically correct" :-)), but I can say that on all of our MIPS, Sun and Ultrix machines: `hostname` returns a non-qualified name, `domainname` returns the local domain name, /etc/resolv.conf contains a line "domain <some>.<domain>.<name>" (consistent with what "domainname" returns), sendmail and other BIND queries work fine. On our MIPS machines which run named servers, we do have /etc/resolv.conf files. Past experimentation showed this to be absolutely necessary. As to related sendmail problems, the only issue I know of is the following: Most versions of sendmail (including those shipped by MIPS and Sun) return the fully qualified hostname in the $w variable, whereas the Ultrix version apparently returns the unqualified hostname. (Thanks DEC.) Because of this, we use a sendmail.cf which can be configured to accept either form. It works. -- -------------------------------------------------------------------------- Laurence G. Yaffe Internet: lgy@newton.phys.washington.edu University of Washington Bitnet: yaffe@uwaphast.bitnet
stacy@sobeco.com (s.millions) (05/09/91)
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