Delegating /24's from a /19

Wed Mar 16 04:22:24 UTC 2005

...snip...

>> Um, why?
>
> 	Firstly he does NOT have authority for the /16 reverse.  Lots
> 	of latent problems there.

Nor is he claiming it.  Nowhere on the internet is there anything saying
that the entire /16 should be looked up against his nameserver.  No 
reference
should exist pointing to his nameserver as authoritative for the /16.
The convenience of having a zone file that is based on a /16 that he owns
part of does not create authority out of thin air, nor does it make any
meaningful claim to authority except to a system which (mistakenly) attempts
to use those nameservers as resolvers.  Yes, if you are going to do this, it
is a prerequisite that your nameserver _NOT_ be anyone's resolver.

> 	Secondly sideways delegations don't work.

Huh?  I'm not sure what you mean by "sideways delegations".  It is
perfectly acceptable, for example, for:

a.root-servers.net returns 16.172.in-addr.arpa. IN NS ns1.arin.net.
ns1.arin.net returns 124.16.172.in-addr.apra. IN NS ns1.foobar.com.
ns1.foobar.com. returns 124.16.172.in-addr.arpa. IN NS ns1.subsidiary.com.
ns1.subsidiary.com. returns 5.124.16.172.in-addr.arpa. IN PTR 
foo.subsidiary.com.

This does work.  This is what is being proposed.

> 	Thirdly I'm sick and tired of having to debug stupid
> 	schemes ISP's come up with to try to avoid SWIPing the
> 	nameservers in situations like this.  They don't work
> 	or they don't meet the customers expectations (i.e.
> 	they have a /24 and should just be able to use x.y.z.in-addr.arpa
> 	and have it work reliably).
>
So don't debug them.  As long as ARIN has all of the /24s within the /19
pointing as NS records to the nameserver which contains the partially
populated /16 zone file (or which secondaries each of the relevant /24 zones
from their true owners), things work just fine.  Nothing really to debug.

> 	Delegation is the DNS is strictly hierachical.
>
I don't see where the above breaks this.

> 	You either SWIP the new servers or you slave the zones
> 	from the customer.  In both cases you are following the
> 	delegation heirarchy.  Note even if you slave the zones
> 	you still have to ensure the delegation is correct.
>
I guess we will have to agree to disagree on this.  I will point out that
the above solution is working in a number of networks without problem.
Sure, if you screw it up, it doesn't work.  That's true of DNS generally.

Owen

P.S.  Learn to trim quotations.

-- 
If this message was not signed with gpg key 0FE2AA3D, it's probably
a forgery.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 186 bytes
Desc: not available
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20050315/73de1ab1/attachment.sig>