Alternative to RFC2317 -- Classless Delegation

[Kevin Darcy]

Dan Mahoney, System Admin wrote:
> On Fri, 8 Dec 2006, Kevin Darcy wrote:
>
> [ka-snip]
>
>   
>>> So, then the question (and I'm sure someone has a good answer for it) is:
>>>
>>> What is wrong with the NS-only scheme of doing things?  Clearly RFC2317 is
>>> as complex as it is for a reason, but I'm curious as to why.
>>>
>>>       
>> That's perfectly valid too, and I'm surprised that RFC 2317 doesn't even
>> mention that approach (had to re-read it just to make sure).
>>
>> I think there are multiple reasons why most people shy away from this:
>> 1) More records in the parent zone, since of course all zones are
>> required to have at least 2 nameservers, versus only 1 CNAME per IP
>> address under RFC 2317 (of course $GENERATE eases this)
>> 2) More zone definitions overall
>> 3) Zone-apex PTR records. Many if not most folks are used to thinking of
>> PTRs as "leaf" nodes and aren't very comfortable with seeing them at the
>> apex of a zone.
>>     
>
> I did just think of one thing, and that's that if someone was using the 
> zone answering for the "leaf" zone as a caching server...
>
> i.e. the customer who has 192.168.1.1 has a partial 192.168.1.x zonefile 
> with of course, only his records...then goes to look up an IP he does NOT 
> have, against the same nameserver, I believe that nameserver will return 
> NXDOMAIN, even if the PTR *is* properly delegated to a secondary leaf 
> site.
>
>   
Um, maybe I misunderstood your explanation. You wouldn't have a 
1.168.192.in-addr.arpa zone in the scheme I was envisioning, you'd have 
zones x.1.168.192.in-addr.arpa through y.1.168.in-addr.arpa where "x" 
and "y" mark the start and end of your assigned range. Anything outside 
of x through y would be resolved normally.

If you're trying to delegate "upwards", e.g. the NS record for 
1.1.168.192.in-addr.arpa points to a server that knows only about 
1.168.192.in-addr.arpa, then yes, that's evil and you should avoid doing 
that, for the same reason that you shouldn't define your own rogue 
".com" domain, just because you have a bunch of domains registered 
underneath that TLD and are too lazy to define each zone separately.

- Kevin