mrp%sirius.ua.OZ@uunet.uu.net (Mark Prior) (01/19/89)
I am trying to get YP to talk to Bind and of course it doesn't work! We are not connected to the DDN Internet [ yes I know it's not a supported configuration ] but what difference should that make? What I would like to know is - a. Is there anyone who has make YP and Bind work together that is not connected to the DDN Internet? b. Is there anyone with SunOS 4.0_Export that has make it work at all. Hopefully soon we will be connected to the DDN Internet and I would like to find out if my problem will go way then. Since we are in Australia, we are stuck with the Export version (unless the US DoC decides allies are good guys too :-)). Mark. PS I would like to thank Sun Australia for their attempts at persuading Sun US that non-connection to the DDN Internet isn't a good enough excuse for it not working. Mark Prior Phone : +61 8 228 5680 University Computing Services Telex : UNIVAD AA89141 University of Adelaide Fax : +61 8 224 0464 GPO Box 498 Adelaide S.AUSTRALIA 5001 ACSnet: mrp@sirius.ua.oz
jgarb@erim.org (Joe Garbarino) (01/25/89)
The problems associated with setting up interaction between yp and the
name server is twofold; inadequate documentation from Sun (the biggest
problem) and a bug in SunOS V4.0 ypserv.
Under SunOS V3.5, interacting with the named required staring up the yp
server with ypserv -i. Under SunOS V4.0, this was changed. Now you must
modify the yp makefile (/var/yp/Makefile) to do a makedbm -b when the
hosts database is made. However, due to the ypserv bug, the server still
does not contact the named. When I was running V4.0 I received a fixed
ypserv from Sun Tech Support; I believe the problem is fixed in SunOS
V4.0.1.
>>>> FLAMES <<<< All this points out a very large hole in the Sun
documentation (just one? ;-) the description of the named explains how to
set it up but not how to talk to it!!!
Joe Garbarino
ERIM
P.O Box 8618
Ann Arbor, Mi. 48107
(313)994-1200 x2508
jgarb@csd360b.erim.orgmrp@uunet.uu.net (Mark Prior) (01/25/89)
> Under SunOS V4.0, this was changed. Now > you must modify the yp makefile (/var/yp/Makefile) to do a makedbm -b > when the hosts database is made. However, due to the ypserv bug, > the server still does not contact the named. When I was running V4.0 > I received a fixed ypserv from Sun Tech Support; I believe the problem > is fixed in SunOS V4.0.1. We have the `fix' but it doesn't work for us, Sun's reason for this is that it is not a supported configuration since we are not connected to THE internet. Never mind the fact that our internet contains 100+ hosts in numerous otherwise independent sites. They obviously expect us to use YP to manage it! All I can conclude from this reasoning is that a Sun cannot be used as a root nameserver (so much for `the network is the computer'). Mark. -- Mark Prior Phone : +61 8 228 5680 University Computing Services Telex : UNIVAD AA89141 University of Adelaide Fax : +61 8 224 0464 GPO Box 498 Adelaide S.AUSTRALIA 5001 ACSnet: mrp@sirius.ua.oz
jjb@zeus.cs.wayne.edu (Jon J. Brewster) (01/26/89)
In v7n111, Mark Prior writes: >I am trying to get YP to talk to Bind and of course it doesn't work! >We are not connected to the DDN Internet [ yes I know it's not a supported >configuration ] but what difference should that make? One problem you'll surely run into is that the BIND software wants to talk to a root server as it starts up. Without a DDN connection, that will fail, of course. Another problem, which we see here when the DDN connection goes down, after in.named is running, is that ypserv seems to bog down. (We use the ypserv that interacts with named, so that things like "ping violet.berkeley.edu" work). It appears that named hangs on requests that cannot be answered, which in turn blocks ypserv, which in turn screws up our entire local domain. When I substitute the original ypserv then we are able to operate again, and at least resolve local hostnames, passwd entries, etc. >PS I would like to thank Sun Australia for their attempts at persuading >Sun US that non-connection to the DDN Internet isn't a good enough excuse >for it not working. This doesn't sound reasonable. As you may know, when you request an address binding from named which is not in your local tables, named requests the address of a name server for the domain containing the address in question. The network contains a number of root servers which answer these requests. Without a network, how will your server manage to get this information? It seems to me that if you want to use the BIND system, you'll wind up creating the equivalent of the Internet locally, including the administrative function of NIC. I *do* agree that the YP <-> BIND interface could be improved, so that losing the nameserver (or not having it) would result in something more graceful than emulating rigor mortis.
mrp@uunet.uu.net (Mark Prior) (01/27/89)
> In v7n111, Mark Prior writes: > >I am trying to get YP to talk to Bind and of course it doesn't work! > > >We are not connected to the DDN Internet [ yes I know it's not a supported > >configuration ] but what difference should that make? > > One problem you'll surely run into is that the BIND software wants to > talk to a root server as it starts up. Without a DDN connection, that > will fail, of course. We are a standalone network, we only want to talk to ourselves with IP (we use ACSnet to talk to the world) so the fact that we cannot connect to a root server doesn't matter. For our purposes WE are the root server. We have the libc_resolv.so patch that removes YP completely and we have no troubles (yet) but previous to that we were running the nameserver for the benefit of our Annex and Bridge terminal servers (I am also using the MX version of sendmail) and they were quiet happy. This would indicate to me that the nameserver is configured correctly for our purposes, we just couldn't get YP to talk to it properly when it was in the way. Mark. -- Mark Prior Phone : +61 8 228 5680 University Computing Services Telex : UNIVAD AA89141 University of Adelaide Fax : +61 8 224 0464 GPO Box 498 Adelaide S.AUSTRALIA 5001 ACSnet: mrp@sirius.ua.oz
hedrick@geneva.rutgers.edu (Charles Hedrick) (01/27/89)
I can't see why you shouldn't be able to use the name server outside the Internet. IP packets that go via the Arpanet aren't a different color. However the name server software is designed to work in an environment that has a hierarchical collection of name servers, starting with the infamous root server. So you can't just set up your local servers the way you would here. You have to set up your own root server. There are problems getting 4.0 to talk to named. But they have been solved, and Sun should be able to give you the package b. as to your second question, we have 4.0_Export source. (There is no domestic source, apparently.) As far as I can see, most of the differences between 4.0 and 4.0_Export are in libc. (1) They aren't going to affect anything relevant to named and (2) I'll bet the named update package on uunet has the domestic version of named. I understand that Sun made a real effort at getting rid of the lobotomization for 4.0, and came close to getting it done. That's a good sign I think. I've always thought that they should just move their software operation to Australia, since as far as I know there's no problem getting this stuff into the U.S., just out. I note that MKS in Canada is now shipping clones of the Unix crypt for MS/DOS, and maybe also for System V running on PC's. With the increasing importance of secure communications, the U.S. government is coming under increasing pressure on this issue. Many Unix vendors are doing half their business outside the U.S. They are not going to be able to compete with non-U.S. vendors if they have to remove all their security technology outside the U.S. I think you're going to see movement on this issue in the future.
stevo@elroy.jpl.nasa.gov (Steve Groom) (02/02/89)
jgarb@erim.org (Joe Garbarino) writes: >Under SunOS V3.5, interacting with the named required staring up the yp >server with ypserv -i. Under SunOS V4.0, this was changed. Now you must >modify the yp makefile (/var/yp/Makefile) to do a makedbm -b when the >hosts database is made. However, due to the ypserv bug, the server still >does not contact the named. When I was running V4.0 I received a fixed >ypserv from Sun Tech Support; I believe the problem is fixed in SunOS >V4.0.1. Be careful with the ypserv from SunOS 4.0.1. If ypserv loses contact with the nameserver (because named or the machine it's running on crashes), then YP goes to lunch and never comes back. Evidently ypserv caches the port number that named is listening on, and doesn't forget about it if contact is lost. Thus killing and restarting named (or rebooting the machine it's running on) will cause ypserv to lose contact with the nameserver until ypserv is restarted. The solution is to kill and restart ypserv after named is running again, but this can be difficult if YP is dead and you can't log in :-). The fix for us was to go back to the 4.0 version of ypserv. The problem has been reported to Sun, and the cause and fix were suggested by them. This bug bit us at a bad time. Both I and my co-SA were in Miami at the SUG conference (my boss says "never again!"), and the folks back home were dead in the water. We have had problems with named dying from time to time, and when it went, so did YP. We spent several hours on the phone talking them through backing out of YP completely. Only after we returned did we figure out exactly what went wrong. (No, don't suggest fixing named, we've been puzzled by that one for a long time. It sometimes tries to dereference a date value and ...) Steve Groom, Jet Propulsion Laboratory, Pasadena, CA 91109 Internet: stevo@elroy.jpl.nasa.gov UUCP: {ames,cit-vax}!elroy!stevo Disclaimer: (thick German accent) "I know noothingg! Noothingg!"
efb@ames.arc.nasa.gov (Everett F. Batey II) (02/09/89)
jjb@zeus.cs.wayne.edu (Jon J. Brewster) writes: >In v7n111, Mark Prior writes: >>I am trying to get YP to talk to Bind and of course it doesn't work! >>We are not connected to the DDN Internet [ yes I know it's not a supported Neither is my VMS MicroVAX running Twg's 3.2 TCP which allows me, I guess, to be a master server ON MY DISCONNECTED Internet. I load from my hosts file and named.(wildcard) files, or just the later. Haven't figured it all out yet, BUT it works .. come on Sun .. you can too. >One problem you'll surely run into is that the BIND software wants to talk >to a root server as it starts up. Without a DDN connection, that will >fail, of course. >Another problem, which we see here when the DDN connection goes down, Have no internet connect .. Looking clues from successful SunOS_3.3 ( YP with BIND (named) ), seems not to even answer requests from my tcp servers .. The_Main_User (So Calif SunLUG | Vta-SB-SLO-DECUS) efb@elroy.JPL.Nasa.Gov sun!tsunami!suned1!efb efbatey@nswses.arpa
zjat02@uunet.uu.net (Jon A. Tankersley) (02/19/89)
You need yet another patch. 4.0.1 fixes some problems with named, but
there are others. ypxfr for one.
I agree on the setup of named with yp. I have been struggling with it my
self prior to connecting to the outside world (slow moving wheels of the
bureaucracy). It isn't easy.
Someone asked about the setup of a local nameserver as the root.
'tis easy.... Once you know the tricks. Got this far with some help from
bind-request at Berkeley. Sun named is compatible with bind 4.8.
named.boot
__________
;
; type domain source file or host
;
directory /etc/named.dir
domain TRC.AMOCO.COM
primary . root.zone
primary TRC.AMOCO.COM named.hosts
primary AMOCO.COM amoco.zone
primary 230.129.in-addr.arpa hosts.rev
cache . named.ca
root.zone
__________
. IN SOA TRC.AMOCO.COM. postmaster.trc.amoco.com. (
1 ;Serial
3600 ;Refresh
300 ;Retry
3600000 ;Expire
3600) ;Minimum
518400 NS CR1.TRC.AMOCO.COM
CR1.TRC.AMOCO.COM. 518400 A 129.230.11.5
TRC.AMOCO.COM. 518400 NS CR1.TRC.AMOCO.COM
named.ca
__________
;
. 99999999 IN NS cr1.amoco.com.
99999999 IN NS ncc.amoco.com.
. 99999999 IN NS cr1.trc.amoco.com.
99999999 IN NS ncc.trc.amoco.com.
99999999 IN NS gpsb-gw.trc.amoco.com.
;
;
;
cr1.trc.amoco.com. 99999999 IN A 129.230.11.5
cr1.amoco.com. 99999999 IN A 129.230.11.5
ncc.trc.amoco.com. 99999999 IN A 129.230.11.1
gpsb-gw.trc.amoco.com. 99999999 IN A 129.230.11.9
resolv.conf
__________
# Domain name resolver configuration file
#
domain trc.amoco.com
# first try ourselves
#nameserver 127.0.0.1
# cr1.trc.amoco.com
nameserver 129.230.11.5
# BRL-AOS
#nameserver 128.20.1.0
#nameserver 192.5.22.82
# SRI-NIC (does not recurse)
#nameserver 10.0.0.51
#nameserver 26.0.0.73
#
# Prefer these networks over other local ones:
address 129.230.11.0
named.hosts
__________
@ IN SOA CR1.TRC.AMOCO.COM. postmaster.trc.amoco.com. (
1 ;Serial
3600 ;Refresh
300 ;Retry
3600000 ;Expire
3600) ;Minimum
IN NS CR1.TRC.AMOCO.COM.
IN NS ncc.trc.amoco.com.
IN A 129.230.11.5
IN HINFO Sun-3/260 UNIX-SunOS-4.0
IN WKS 129.230.11.5 UDP domain tftp time echo
IN WKS 129.230.11.5 TCP ( echo discard systat daytime netstat
ftp-data ftp telnet smtp time name
whois domain hostnames sunrpc tftp
rje finger link supdup uucp-path
nntp ntp whois
rje )
*.trc.amoco.com. MX 10 apctrc.trc.amoco.com.
localhost IN A 127.0.0.1
localhost IN HINFO Sun-3/260 UNIX-SunOS-4.0
....
hosts.rev
__________
1.0.0.127.in-addr.arpa. IN PTR localhost.
5.11.230.129.in-addr.arpa IN PTR cr1.
....
--