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.
Actually it isn't. Nameservers can and do detect this as it looks like a classic lame delegation. It also a sideways delgation, the zone depth didn't impove between ns1.foobar.com and ns1.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.
Well when you have a bug report saying that your nameserver doesn't work because someone tried to do a sideways delegation you have to go in there and show what is broken. This is not expected to work.
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==========--
-- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@isc.org