Hello,
last week, I posted the following question to the list:
Michael> Hello,
Michael> we have at our university several organizational units with
Michael> their own small computer pools. Due to various reasons
Michael> (organizational structures of German universities are quite
Michael> different from American) all these pools have their own
Michael> administration. We have a class B Internet adress
Michael> (130.83.XX.XX, going to be connected real soon now) but more
Michael> than 256 organizational units. So we need non-octet-subnets.
Michael> However, primary nameservers should be maintained by the
Michael> organizational units themselves. As far as I understood the
Michael> Manuals, it is not possible to establish a nameserver for a
Michael> non-octet-bounded subnet like 130.83.AA.AX because I can't
Michael> create a corresponding IN-ADDR.ARPA-domain. Is this correct?
Michael> Is there ANY workaround?
There were basically three kinds of responses (...commented in place)
- Change the organization (right, I don't know about American universities
but at my university this would occupy me until I retire (~40years))
- Have individual parts of the nameserver configuration file submitted
by the various administrators and concatenate them (fine, but it means
that a bug made by one administrator will invalidate the result and
postpone changes until it is fixed)
- Use fully qualified reverse-arpa entries (the one I like most. More
about this below.
I thank everyone who responded. I append the responses (some shortened)
below.
Michael Lipp
-------------------------------------------------------------------------------
Return-Path: <@mvs.hrz.th-darmstadt.de:cfe+@TRANSARC.COM>
Date: Thu, 21 Feb 1991 11:45:14 -0500 (EST)
From: Craig_Everhart@TRANSARC.COM
To: "Michael N. Lipp" <mnl@idtsun.e-technik.th-darmstadt.de>
Subject: Re: nameserver for partial (non-octet) subdomains
In-Reply-To: <9102211555.AA21866@IDTSUN.E-TECHNIK.TH-DARMSTADT.DE>
References: <9102211555.AA21866@IDTSUN.E-TECHNIK.TH-DARMSTADT.DE>
Sure. Create several IN-ADDR.ARPA delegations--as many as you need.
You couldn't need more than 128.
Craig
-------------------------------------------------------------------------------
Return-Path: <mnl>
Date: Thu, 21 Feb 91 21:15:13 +0100
From: "Michael N. Lipp" <mnl>
To: Craig_Everhart@TRANSARC.COM
Subject: nameserver for partial (non-octet) subdomains
Craig> Sure. Create several IN-ADDR.ARPA delegations--as many as you
Craig> need. You couldn't need more than 128.
Thanks for answering. However, I'm not perfectly sure that I understand
you correctly. Do you mean that I can say e.g.
secondary 1.19.83.130.in-addr.arpa 130.83.19.1
secondary 2.19.83.130.in-addr.arpa 130.83.19.1
secondary 3.19.83.130.in-addr.arpa 130.83.19.1
...
secondary 63.19.83.130.in-addr.arpa 130.83.19.1
on the 130.83-root name server, assuming that 130.83.19.1 runs the
primary nameserver for the 130.83.19."00XXXXXX"-subnet? This sounds
reasonable (there just was never an example with full length
in-adresses in the manuals).
The only (acceptable) drawback seems to me that I have to specify 64
files if I want the root-nameserver to backup the subdomain
secondary 1.19.83.130.in-addr.arpa 130.83.19.1 dtsub.rev/1
secondary 2.19.83.130.in-addr.arpa 130.83.19.1 dtsub.rev/2
...
(assuming dtsub.rev is a directory) right?
Michael
-------------------------------------------------------------------------------
Return-Path: <@mvs.hrz.th-darmstadt.de:cfe+@TRANSARC.COM>
Date: Thu, 21 Feb 1991 15:30:30 -0500 (EST)
From: Craig_Everhart@TRANSARC.COM
To: "Michael N. Lipp" <mnl@idtsun.e-technik.th-darmstadt.de>
Subject: Re: nameserver for partial (non-octet) subdomains
In-Reply-To: <9102212015.AA02225@IDTSUN.E-TECHNIK.TH-DARMSTADT.DE>
References: <9102212015.AA02225@IDTSUN.E-TECHNIK.TH-DARMSTADT.DE>
Yes. What I was alluding to was that you could issue many delegations
in place of one, if your delegations don't happen to occur on the 8-bit
boundary. It can be cumbersome to set up, and it would certainly be
cumbersome to maintain this by hand, but it is do-able in principle.
Of course, you may wish to evaluate whether achieving the delegation is
worth all the trouble, or whether your various departments should simply
collaborate on providing you with enough information for you to manage
their pieces of the in-addr.arpa domain space.
Good luck,
Craig
-------------------------------------------------------------------------------
Return-Path: <@mvs.hrz.th-darmstadt.de:rickert@MP.CS.NIU.EDU>
Date: Thu, 21 Feb 91 14:14:57 -0600
From: Neil Rickert <rickert@CS.NIU.EDU>
To: mnl@idtsun.e-technik.th-darmstadt.de
Subject: Re: nameserver for partial (non-octet) subdomains
Newsgroups: info.sun-nets
In-Reply-To: <9102211555.AA21866@IDTSUN.E-TECHNIK.TH-DARMSTADT.DE>
Organization: Northern Illinois University
Cc:
In article <9102211555.AA21866@IDTSUN.E-TECHNIK.TH-DARMSTADT.DE> you write:
...
You should be able to organize the data with $include so that each of
your subnets has its own file. If possible have a central machine with
all the files and all responsible having logins. Then with permissions
you can control who may update an individual file.
Then run a nightly script which checks for changed files, perhaps does
validation on the range of addresses in a file, and when needed
increments the SOA serial number and reloads the data.
-- =*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*= Neil W. Rickert, Computer Science <rickert@cs.niu.edu> Northern Illinois Univ. DeKalb, IL 60115 +1-815-753-6940------------------------------------------------------------------------------- Return-Path: <@mvs.hrz.th-darmstadt.de:feldt@PHYAST.NHN.UOKNOR.EDU> Date: Thu, 21 Feb 91 14:57:09 CST From: feldt@PHYAST.NHN.UOKNOR.EDU(Andy@mvs.hrz.th-darmstadt.de Feldt) To: mnl@idtsun.e-technik.th-darmstadt.de Subject: Re: nameserver for partial (non-octet) subdomains
Michael,
There is no problem with establishing a nameserver for non-octet bounded subdomains other than the headaches involved with each subdomain administrator making sure the addresses he creates fall within his subdomain. It is certainly more convenient to administer octet bounded subdomains.
Andy Feldt Department of Physics & Astronomy The University of Oklahoma Norman, Ok 73109 (405)-325-3961
------------------------------------------------------------------------------- Return-Path: <@mvs.hrz.th-darmstadt.de:sater@CS.VU.NL> Date: Fri, 22 Feb 91 9:15:47 MET From: Hans van Staveren <sater@CS.VU.NL> To: "Michael N. Lipp" <mnl%IDTSUN.E-TECHNIK.TH-DARMSTADT.DE@CUNYVM.CUNY.EDU> Subject: Re: nameserver for partial (non-octet) subdomains
Correct. If for example you give 9-bit subnet numbers and 7-bit hostnumbers the two networks 130.83.1.0-127 and 130.83.1.128-255 will each be in the zone 1.83.130.in-addr.arpa, and one of the ways to make this work is to split up the networks and pairs that sort of cooperate, or not split up the responsibility for the network domain at all, and let some central authority maintain the reverse map. This central authority must be *fast* though, and central authorities tend not to be.
------------------------------------------------------------------------------- Return-Path: <@mvs.hrz.th-darmstadt.de:katz@RPAL.ROCKWELL.COM> Date: Fri, 22 Feb 91 10:21:09 PST From: katz@RPAL.ROCKWELL.COM(Morry@mvs.hrz.th-darmstadt.de Katz) To: mnl@idtsun.e-technik.th-darmstadt.de In-Reply-To: katz@elements.rpal.com's message of Thu, 21 Feb 91 20:28:50 GMT Subject: nameserver for partial (non-octet) subdomains Reply-To: katz@RPAL.ROCKWELL.COM
we have at our university several organizational units with their own small computer pools. Due to various reasons (organizational structures of German universities are quite different from American) all these pools have their own administration. We have a class B Internet adress (130.83.XX.XX, going to be connected real soon now) but more than 256 organizational units. So we need non-octet-subnets.
However, primary nameservers should be maintained by the organizational units themselves. As far as I understood the Manuals, it is not possible to establish a nameserver for a non-octet-bounded subnet like 130.83.AA.AX because I can't create a corresponding IN-ADDR.ARPA-domain. Is this correct? Is there ANY workaround?
My understanding is similar to yours that the reverse maps couse a problem for non-octet subnets. Please let me know if anyone has any good solutions. ------------------------------------------------------ Morry Katz Rockwell Science Center administrator@rpal.rockwell.com (machine administration issues) katz@rpal.rockwell.com (other) ------------------------------------------------------
------------------------------------------------------------------------------- Return-Path: <@mvs.hrz.th-darmstadt.de:alastair@EUCAD.CO.UK> Date: Fri, 22 Feb 91 17:25:42 GMT From: Alastair Young <alastair@EUCAD.CO.UK> To: mnl@idtsun.e-technik.th-darmstadt.de Subject: Re: nameserver for partial (non-octet) subdomains ... I am in the middle of the same sort of operation. We have not (yet) divided our stuff up into "zones" but my interpretation of the way the name services etc runs implies that the IN-ADDR.ARPA stuff does not necessarily have to correspond organisationally to your domain zones. I would suggest that you organize the two separately. Use your domain zones in the normal way with each unit having its own zone nameserver. Treat the IN-ADDR.ARPA stuff as one big zone ie with the main nameserver as the master and all the others as secondary or cache servers. This means that you lose some of the advantages of distributed control of the data but as long as all the info is available everywhere it should be ok. It will be invisible to the outside world anyway.
I empasise that I haven't actually tried this, it is just conjecture.
...
Alastair Young Systems Supervisor EuCAD
-------------------------------------------------------------------------------
-----------------,------------------------------,------------------------------ Michael N. Lipp ! Institut fuer Datentechnik ! Phone: 49-6151-163776 ! Merckstr. 25 ,----------' Fax: 49-6151-164976 ! D-6100 Darmstadt ! E-Mail: xdatmnlx@ddathd21.bitnet ! (Germany) ! mnl@idtsun.e-technik.th-darmstadt.de -----------------'-------------------'-----------------------------------------
This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:06:11 CDT