Delagation
Barry Margolin
barmar at genuity.net
Thu Apr 13 21:18:44 UTC 2000
In article <38F62A4B.8056087C at daimlerchrysler.com>,
Kevin Darcy <kcd at daimlerchrysler.com> wrote:
>Barry Margolin wrote:
>
>> In article <38F61F82.DB8AA479 at daimlerchrysler.com>,
>> Kevin Darcy <kcd at daimlerchrysler.com> wrote:
>> >I've often wondered why people prefer to delegate these "classlessly
>> >delegated" PTR-containing zones from the in-addr.arpa tree at all. The zone is
>> >just a container: it can be *anything* that's under the control of the entity
>> >wishing to maintain the entries. By hanging the container zone off of
>> >in-addr.arpa, you're basically doubling the workload of the provider
>-- not only
>> >do they have to generate ($GENERATE?) the CNAMEs, but they also have
>to delegate
>> >the container zone. This is an inequitable division of work, and I think it
>> >underlies one of the reasons why many ISP's simply refuse to do "classless
>> >delegation".
>>
>> Most of the work is in creating the CNAME records. Delegating the reverse
>> subdomain is a minor addition, and I don't think it has anything to do with
>> why some ISPs don't do classless delegation. I believe the main reason is
>> that some of them simply aren't familiar with it.
>
>Agreed, that's almost certainly the main reason. But the workload I think
>is another
>reason. A lot of smaller ISP's probably only have 1 person who really
>knows DNS very
>well, and they're probably already busy enough setting up forward zones.
I still don't understand what "workload" you're talking about? How much
more work is it to type:
32/27 IN NS ns1.customer.com.
32/27 IN NS ns2.customer.com.
before typing the 32 CNAME records. Even if they're using $GENERATE,
typing 3 lines isn't much more work then typing 1. The file is already
open, so what's the problem?
--
Barry Margolin, barmar at genuity.net
Genuity, 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