North American Network Operators Group Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical Re: Delegating /24's from a /19
> >> 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: [email protected]
|