North American Network Operators Group|
Date Prev | Date Next |
Date Index |
Thread Index |
Author Index |
Re: Delegating /24's from a /19
- From: Mark Andrews
- Date: Tue Mar 15 23:49:08 2005
> >> 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
> 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) =
> to use those nameservers as resolvers. Yes, if you are going to do this, =
> 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 184.108.40.206.in-addr.arpa. IN PTR=20
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
> 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 =
> 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.
> P.S. Learn to trim quotations.
> If this message was not signed with gpg key 0FE2AA3D, it's probably
> a forgery.
> Content-Type: application/pgp-signature
> Content-Transfer-Encoding: 7bit
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.2.3 (Darwin)
> -----END PGP SIGNATURE-----
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@isc.org