Alternative to RFC2317 -- Classless Delegation
Dan Mahoney, System Admin
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.
-Dan
--
"You're a nomad billygoat!"
-Juston, July 18th, 2002
--------Dan Mahoney--------
Techie, Sysadmin, WebGeek
Gushi on efnet/undernet IRC
ICQ: 13735144 AIM: LarpGM
Site: http://www.gushi.org
---------------------------
Kevin Darcy
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.
- Kevin
Dan Mahoney, System Admin
[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.
Of course, using the same server for both authoritative and caching is
already considered somewhat taboo, but this MAY be an issue that is
dealable within proper VIEW statements -- I haven't thought enough about
it.
-Dan
--
"there is no loyalty in the business, so we stay away from things that piss people off"
-The Boss, November 12, 2002
Mark Andrews
>
> 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.
It also takes more resources.
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)".
Mark
> -Dan
>
> --
>
> "You're a nomad billygoat!"
>
> -Juston, July 18th, 2002
>
> --------Dan Mahoney--------
> Techie, Sysadmin, WebGeek
> Gushi on efnet/undernet IRC
> ICQ: 13735144 AIM: LarpGM
> Site: http://www.gushi.org
> ---------------------------
>
>
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: Mark_A...@isc.org
Kevin Darcy
>
> [ka-snip]
>
>
>>>
>>> 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.
>>>
>>>
>> 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.
>
>
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
Dan Mahoney, System Admin
>> 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
--
Barry Margolin
"Dan Mahoney, System Admin" <da...@prime.gushi.org> wrote:
> On Sat, 9 Dec 2006, Mark Andrews wrote:
> >> 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.
With the NS-only scheme of things, you have to define a separate zone on
the child for each address that's delegated. Each of these will need to
have SOA and NS records, in addition to the PTR record.
With RFC 2317, you define a single zone for all the records. It's even
possible to put them in some other zone that's already defined (you
could put them in your forward zone if you want). Once you create this
zone, you populate it just like you would for a classful delegation.
--
Barry Margolin, bar...@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***
*** PLEASE don't copy me on replies, I'll read them in the group ***
Mark Andrews
> On Sat, 9 Dec 2006, Mark Andrews wrote:
>
> >
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