[78687] in North American Network Operators' Group
Re: Delegating /24's from a /19
daemon@ATHENA.MIT.EDU (Owen DeLong)
Tue Mar 15 23:23:06 2005
Date: Tue, 15 Mar 2005 20:22:24 -0800
From: Owen DeLong <owen@delong.com>
To: Mark Andrews <Mark_Andrews@isc.org>, nanog@merit.edu
In-Reply-To: <200503160051.j2G0pXCp024743@drugs.dv.isc.org>
Errors-To: owner-nanog@merit.edu
--==========63ACF217CA8F895998F9==========
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
...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=20
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=20
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.
--=20
If this message was not signed with gpg key 0FE2AA3D, it's probably
a forgery.
--==========63ACF217CA8F895998F9==========
Content-Type: application/pgp-signature
Content-Transfer-Encoding: 7bit
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (Darwin)
iD8DBQFCN7SEn5zKWQ/iqj0RAtK5AJ4pagTb5Ei+uMqGf9ob9RfSHJFWnQCghs2K
Ltjk1dF5GCdssFNx1KiczoQ=
=Se+y
-----END PGP SIGNATURE-----
--==========63ACF217CA8F895998F9==========--
