Delegating Part Of Class C?

Barry Margolin barmar at bbnplanet.com
Wed Jul 21 23:38:39 UTC 1999


In article <Pine.GSO.4.10.9907210845210.7573-100000 at q7.q7.com>,
Joe Pruett  <joey at q7.com> wrote:
>ok, here is one of my pet peeves.  i think rfc2317 is bad.  there are
>still lots of resolvers out there that get confused by getting a cname
>back when it asked for a ptr.  another of my pet peeves is that cnames are
>evil :-).  when i delegate subnet stuff, i delegate each in-addr with an
>ns directly:
>
>1.1.1.10.in-addr.arpa.	IN	NS	ns.client.com.
>
>of course this means that the client has to create a zone for each ip, but
>it works with all resolvers i've seen.  i think the extra work is well
>worth the improvement in correct behaviour.

The main flaw with this is that you have to have a separate NS record for
every entry.  If the customer changes the name of their server, you have to
update all of them, rather than a single delegation record for the subnet.

Also, when dealing with barely-competent customers (who for some reason
insist on doing their own primary DNS, even though it's included for free
in our service) I find it easier to tell them to create a domain
0-26.1.1.10.in-addr.arpa (I use a hyphen instead of RFC 2317's slash to
avoid stumbling over problems with some server versions) and then populate
it with PTR records just as if it were a "normal" reverse domain, than
trying to explain to them that it's really OK to have 64 separate zones
with a top-level PTR record in each.

-- 
Barry Margolin, barmar at bbnplanet.com
GTE Internetworking, Powered by BBN, Burlington, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.


More information about the bind-users mailing list