RFC 2317
lilith at paxumbrae.com
lilith at paxumbrae.com
Fri Mar 10 22:03:06 UTC 2000
I am assuming that this Class B is non-portable, else the individual class
Cs, 64-127, could simply be assigned to your organization's
nameservers. You then would only deal with 64 zones.
If they are non-portable, your parent company needs to set up a Class B
in-addr zone for subdelegation, which will look roughtly like this:
SOA (insert parent's standard SOA here)
IN NS 1stparent.nameserver.com.
IN NS 2ndparent.nameserver.com.
0 IN NS master.nameserver.com.
IN NS slave.nameserver.com.
.
.
.
.
.
64 IN NS yourmaster.nameserver.com.
IN NS yourslave.nameserver.com.
.
.
.
.
127 IN NS yourmaster.nameserver.com.
IN NS yourslave.nameserver.com.
128 IN NS master.nameserver.com.
IN NS slave.nameserver.com.
255 IN NS master.nameserver.com.
IN NS slave.nameserver.com.
The in-addr Class B zone has to be in the parent company's named.conf
files, and of course, all 64 subdelegated Class C zones need to be in
yours, with the appropriate files.
On Fri, 10 Mar 2000
parker at bctm.com wrote:
> Kevin,
>
> > RFC 2317 was really intended for delegations below the /24 level.
> > Technically, you *could* use a similar methodology at higher levels, but
> > I can't imagine, for instance, your parent preferring to create ~16,000
> > CNAMEs (one for every possible address in your range) over the
> > "traditional" model of just delegating 64 /24's to your servers.
>
> That wasn't what I was getting at - I was thinking there might be a way
> to arrange it such that I didn't need to maintain 64 zones... our parent
> would have 64 CNAMES (one per "zone"), we would have a single
> 64-127.60.172.in-addr.arpa zone.
>
> Cheers,
>
> Ross
> --
> Ross Parker | UNIX Sys Admin, Perl and C,
> Systems/Network Admin | Networking and security
> Telus Mobility |
> | UNIX is very user friendly... it's just
> parker at bctm.com | highly selective about who it makes friends WITH!
>
>
>
>
More information about the bind-users
mailing list