Breaking up a class for delegation

Chris Buxton cbuxton at menandmice.com
Mon Sep 24 20:03:28 UTC 2007


There is likely no better way (depending on your criteria for  
"better"), unless you wanted to keep one half or the other in the /16  
reverse zone.

Using CNAME redelegation as per RFC 2317 would not make things any  
cleaner in the /16 zone. However, it could theoretically create fewer  
subzones - 2 of them, instead of 256. The downside is requiring the  
creation of 65536 (or thereabouts) CNAME records - in other words,  
256 $GENERATE statements. Ugly, in my opinion.

Chris Buxton
Men & Mice

On Sep 24, 2007, at 12:10 PM, Bischof, Ralph F. (MSFC-NNM04AA02C) 
[SAIC] wrote:

> Hello all,
>
> 	This may not be a BIND-specific question. If so, I apologize. I
> also have looked at RFC2317. Here is my dilemma:
>
> 	I have 129.164.0.0/16 that is delegated to a Center (see
> http://ws.arin.net/whois/?queryinput=N%20.%20NASA-IVV). Since the  
> Center
> is not using the whole B, they decided to give away the upper half  
> to a
> project within NASA that is needing space. Yet, the original Center  
> does
> not want to be responsible for the upper half. Therefore, I must  
> look at
> delegating half of the B to one entity and the other half to the  
> other.
>
> 	My thought is that instead of having a single delegation to the
> two nameservers as I do now, I will have to take the single delegation
> (164.129.in-addr.arpa) and give it 256 entries. The first 128 entries
> would be delegations to at least two nameservers for the original  
> Center
> and the second set of 128 entries to at least two nameservers for the
> new project. Then, each of the two delegatees (is that a word?) would
> need to also build up 128 zone files as they saw fit.
>
> 	Is there another way? If not, I am good with that idea. I just
> wanted to make sure that I have not missed something that has come out
> lately.
>
> Thank you,
> --
> Ralph Bischof
> The opinions expressed in this communication are not necessarily those
> of NASA.
>
>



More information about the bind-users mailing list