Alternative to RFC2317 -- Classless Delegation

[Dan Mahoney, System Admin]

On Sat, 9 Dec 2006, Mark Andrews wrote:

>
>> Hey all,
>>
>> Recently, we at work have had to delegate out some DNS records, and at the
>> request of the customer-being-delegated to, instead of doing the complex
>> rfc2317 intermediate-zone/cname/ns records, they simply asked us to drop
>> in NS records in place of the PTR records.
>>
>> This works fine: reverse lookups for the affected IPS all work, and it
>> would appear that it doesn't violate anything.  Just as if I was going to
>> delegate lab.bar.com to my development lab, I would put in an NS record
>> for lab.bar.com to my lab's DNS servers.  At least it doesn't "feel"
>> wrong, but that's why I'm writing.
>>
>> Further, with RFC2317, there exists the need to be in agreement with the
>> delegator about what domain to serve.  i.e. to delegate 192.168.1.0-7
>> (those are IPs, not the name of the zone) to my customer, I would need to
>> tell him to configure the zone
>>
>> x.0-7.1.168.192.in-addr.arpa. (going by recipe 6.4 of the DNS & Bind
>> Cookbook)
>> -or-
>> x.0/29.1.168.192.in-addr.arpa. (going by RFC 2317)
>> -or-
>> x.customer1.168.192.in-addr.arpa (assuming a case where IPs were assigned
>> in random groups, i.e. not necessarily consecutive -- for example on a
>> block where the same customer has the first 8 and the last 8 -- this
>> would be done to have him able to save himself from having to set up a
>> zone for EVERY service).
>>
>> Plus, there's the management of CNAMES.  We're in the process of switching
>> over to having all our zonefiles being DB-generated, so it's trivial to
>> change at this point, but it means much extra pain to those being
>> delegated to.
>>
>> With the NS-only scheme, he is able to serve the zone "naturally"...i.e.
>> by using the normal PTR records, as any other DNS management software
>> (webmin, powerDNS, MS-DNS) would expect, instead of whatever variant is
>> above (further complicated by the fact that I'm sure we're not the only
>> ones doing delegation).
>>
>> 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.
>
> 	Because it is more work overall especially for the child.

Can you clarify that?  From my POV it's...

Define a standard in-addr.arpa. zone.

or

Define whatever zone the whim of the parent defines (with the knowledge 
that different parents will have totally different syntaxes), with 
possibly illegal characters by your resolver software.

> 	It also takes more resources.

1) look up the record, get a cname pointing at the child zone
2) look up the NS for the child zone.
3) look up the zone at the child server.

or

1) look up the record, get an NS record pointing at the child server.
2) look up the zone at the child server.

> 	RFC 2317 is not complex. It's just "add a CNAME at the well
> 	known reverse name to somewhere else where the PTR record
> 	is (or will be)".

"just" ?

..and add NS records for each sub-zone you're delegating to,

..and make sure you're in agreement with the child as to which 
non-standard (even by the RFC) and oft-unsupported by DNS management 
software zone syntax you're using.

..and optionally slave the zone BACK from the child to the parent server 
to deal with buggy resolvers which do not properly follow the CNAME in a 
reverse zone.

I totally understand the RFC, believe me.  This post was more an attempt 
to ask what was WRONG with the "just add an NS record" mentality. 
Admittedly, I wound up partially answering my own question, but comparing 
a portion of a class-c in-addr.arpa. zone is certainly NOT the same as 
defining your own com.  Also, sad as it is to admit it: people ARE doing 
it this way, this isn't just some method I pulled out of my rear end, and 
I believe, as long as the child nameserver is configured not to answer 
recursively for ANYONE -- the more I think about it even views cannot 
help here -- it still works.

Given light of this, I'm probably going to wind up going the full rfc2317 
route, but it's going to be hell changing over, since from our customer 
point of view, there's nothing WRONG with the current situation.  The only 
possible damage is if THEY have someone pointing at their servers, and are 
answering wrong.  Again, that's from their perspective -- and going inline 
with the RFC limits that damage, but at the cost of making it look like 
we're unnecessarily making things harder for them.

-Dan

--

--------Dan Mahoney--------
Techie,  Sysadmin,  WebGeek
Gushi on efnet/undernet IRC
ICQ: 13735144   AIM: LarpGM
Site:  http://www.gushi.org
---------------------------