Alternative to RFC2317 -- Classless Delegation

Mark Andrews Mark_Andrews at isc.org
Sat Dec 9 14:14:15 UTC 2006


> 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).

	There are lots of ways to do it.  Just choose a naming scheme that
	fits you needs.  That's why there isn't a single scheme in RFC 2317.

> >> 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.

	You are complaining about 10 year old beta 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.

	1 and 2 are performed in the same query in the authoritative
	server in most cases (CNAME and delegating NS records are
	in the same 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.

	Pick better management software.  After 10 years of common
	practice it should be supported.

	RFC 2317 recommends one style, but we were quite aware that
	it was a arbitary choice.  All of the possible choices are
	used regularly today.
 
> ..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.

	There wern't any resolvers that didn't follow the CNAMES.
	There were (10 years ago) some broken resolvers that ignored
	the returned CNAMES, such resolvers were not RFC 1035
	compliant.

	Then there was 'dig' which didn't ask for PTR records (which is
	what implementations of gethostbyaddr(), etc. do).  Dig made
	ANY queries for -x which don't follow CNAMES.  This was because
	dig also handled 3, 2 and 1 octets, in addition to dotted quads,
	and ANY returned the NS RRsets.
 
> 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

	I wouldn't change existing delegations.  That's "make work".

	However a RFC 2317 style delegation is less work overall and
	I would use it for new delegations.

	For a /25 you have 128 child zones, 128 SOA records, 256
	NS (2 servers), 256 delegating NS records and 128 PTR record
	vs 1 child zone, 1 SOA record, 2 NS record, 2 delegating
	NS records, 128 CNAME records and 128 PTR records.

	Note:  The child also needs to be a slave of the parent.
	That way local reverse lookup work even when the links to
	the parents are down.

	Mark
 
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: Mark_Andrews at isc.org



More information about the bind-users mailing list