[comp.unix.ultrix] Name server problems in Ultrix 4.0

andy@bakerstreet.DAB.GE.COM (Andy Hazeltine) (10/04/90)

I have noticed some strange behavior with the Ultrix 4.0 named.  Our
internal network is not connected to the Internet so we run our own
root servers.  The primary and secondary servers are all vaxen running
Ultrix.  Recently one of the secondary servers was upgraded to Ultrix
4.0.   When this server is queried for the list of name servers, it
returns the correct list of servers but it lists multiple copies of the
addresses for the servers.

Here is an example. Ge-dab.ge.com, atlast.dab.ge.com, and puma.atl.ge.com
are running Ultrix 3.1 and Bind 4.8.3.  Sunblossom.ge.com is running
Ultrix 4.0 and the 4.0 named. Ge-dab is the primary server.

Here is the response from nslookup using sunblossom (4.0) as the server:
Note the multiple addresses and the incorrect address for ge-dab.

     > set querytype=ns
     > .
     Server:  sunblossom.GE.COM
     Address:  3.2.4.20
     Aliases:  sunblossom.DAB.GE.COM
     
     (root)  nameserver = atlast.DAB.GE.COM
     (root)  nameserver = puma.ATL.GE.COM
     (root)  nameserver = sunblossom.GE.COM
     (root)  nameserver = ge-dab.GE.COM
     atlast.DAB.GE.COM       internet address = 192.35.21.160
     atlast.DAB.GE.COM       internet address = 3.2.4.83
     atlast.DAB.GE.COM       internet address = 192.35.21.160
     atlast.DAB.GE.COM       internet address = 3.2.4.83
     atlast.DAB.GE.COM       internet address = 192.35.21.160
     atlast.DAB.GE.COM       internet address = 3.2.4.83
     atlast.DAB.GE.COM       internet address = 192.35.21.160
     atlast.DAB.GE.COM       internet address = 3.2.4.83
     atlast.DAB.GE.COM       internet address = 192.35.21.160
     atlast.DAB.GE.COM       internet address = 3.2.4.83
     atlast.DAB.GE.COM       internet address = 192.35.21.160
     atlast.DAB.GE.COM       internet address = 3.2.4.83
     atlast.DAB.GE.COM       internet address = 192.35.21.160
     atlast.DAB.GE.COM       internet address = 3.2.4.83
     puma.ATL.GE.COM internet address = 129.203.1.22
     puma.ATL.GE.COM internet address = 129.203.1.22
     puma.ATL.GE.COM internet address = 129.203.1.22
     puma.ATL.GE.COM internet address = 129.203.1.22
     sunblossom.GE.COM       internet address = 3.2.4.20
     sunblossom.GE.COM       internet address = 3.2.4.20
     sunblossom.GE.COM       internet address = 3.2.4.20
     sunblossom.GE.COM       internet address = 3.2.4.20
     sunblossom.GE.COM       internet address = 3.2.4.20
     sunblossom.GE.COM       internet address = 3.2.4.20
     ge-dab.GE.COM   internet address = 3.17.4.0
     >
     
Here is the correct response using atlast as the server:
Note all of the other servers give the correct response.

     > set q=ns
     > .
     Server:  atlast.DAB.GE.COM
     Address:  3.2.4.83
     
     (root)  nameserver = ge-dab.GE.COM
     (root)  nameserver = sunblossom.GE.COM
     (root)  nameserver = puma.ATL.GE.COM
     (root)  nameserver = atlast.DAB.GE.COM
     ge-dab.GE.COM   inet address = 3.2.4.11
     ge-dab.GE.COM   inet address = 3.5.4.10
     ge-dab.GE.COM   inet address = 192.35.21.11
     ge-dab.GE.COM   inet address = 3.17.4.11
     sunblossom.GE.COM       inet address = 3.2.4.20
     puma.ATL.GE.COM inet address = 129.203.1.22
     atlast.DAB.GE.COM       inet address = 3.2.4.83
     atlast.DAB.GE.COM       inet address = 192.35.21.160

Does anyone have any ideas why the Ultrix 4.0 server acts like
this?

--
Andy Hazeltine
andy@ge-dab.ge.com, hazeltin@crdgw1.ge.com

hagan@scotty.dccs.upenn.edu (John Dotts Hagan) (10/06/90)

We have the server duplication problem as well.  For example:

Script started on Fri Oct  5 18:59:21 1990
% nslookup
Default Server:  LOCALHOST.upenn.edu
Address:  127.0.0.1

> set q=ns
> upenn.edu.
Server:  LOCALHOST.upenn.edu
Address:  127.0.0.1

upenn.edu       server name = GRASP.CIS.UPENN.EDU
upenn.edu       server name = OPERATIONS.DCCS.UPENN.EDU
upenn.edu       server name = REMOTE.DCCS.UPENN.EDU
GRASP.CIS.UPENN.EDU     inet address = 130.91.6.7
GRASP.CIS.UPENN.EDU     inet address = 130.91.6.7
GRASP.CIS.UPENN.EDU     inet address = 130.91.6.7
OPERATIONS.DCCS.UPENN.EDU       inet address = 128.91.254.1
OPERATIONS.DCCS.UPENN.EDU       inet address = 128.91.254.1
OPERATIONS.DCCS.UPENN.EDU       inet address = 128.91.254.1
OPERATIONS.DCCS.UPENN.EDU       inet address = 128.91.254.1
OPERATIONS.DCCS.UPENN.EDU       inet address = 128.91.254.1
REMOTE.DCCS.UPENN.EDU   inet address = 128.91.2.13
REMOTE.DCCS.UPENN.EDU   inet address = 128.91.2.13
REMOTE.DCCS.UPENN.EDU   inet address = 128.91.2.13
REMOTE.DCCS.UPENN.EDU   inet address = 128.91.2.13
REMOTE.DCCS.UPENN.EDU   inet address = 128.91.2.13
REMOTE.DCCS.UPENN.EDU   inet address = 128.91.2.13
> set q=a
> operations.dccs.upenn.edu
Server:  LOCALHOST.upenn.edu
Address:  127.0.0.1

Name:    operations.dccs.upenn.edu
Addresses:  128.91.254.1, 128.91.254.1, 128.91.254.1, 128.91.254.1
          128.91.254.1

> remote.dccs.upenn.edu
Server:  LOCALHOST.upenn.edu
Address:  127.0.0.1

Name:    remote.dccs.upenn.edu
Addresses:  128.91.2.13, 128.91.2.13, 128.91.2.13, 128.91.2.13
          128.91.2.13, 128.91.2.13

> server grasp.cis.upenn.edu
Default Server:  grasp.cis.upenn.edu
Addresses:  130.91.6.7, 130.91.6.7, 130.91.6.7

> operations.dccs.upenn.edu
Server:  grasp.cis.upenn.edu
Addresses:  130.91.6.7, 130.91.6.7, 130.91.6.7

Name:    operations.dccs.upenn.edu
Address:  128.91.254.1

> ^D% exit
% 
script done on Fri Oct  5 19:00:02 1990


Notice that A records are reported back multiple times - in fact,
operations.dccs.upenn.edu
is listed 5 times in the NS request, and reports 5 addresses (all the same)! 
Then,
remote.dccs.upenn.edu is listed 6 times in the NS request, and has the same A
record come
back 6 times!

The last server, GRASP.CIS.UPENN.EDU, is not running the Ultrix 4.0 named.  It
is using bind 4.8
on a Sun.  It reports the correct information, but got its zone information from
then primary
name server operations.dccs.upenn.edu.  So I don't think it is a problem of
configuration - just
a bug with the Ultrix 4.0 name server.

--Kid.

treese@crl.dec.com (Win Treese) (10/08/90)

Yes, it's a bug.  I verified it on some of our systems.

Please file an SPR on it (having the paperwork helps immensely).

Thanks for letting us know.

Win Treese						Cambridge Research Lab
treese@crl.dec.com					Digital Equipment Corp.