Merit Network
Can't find what you're looking for? Search the Mail Archives.
  About Merit   Services   Network   Resources & Support   Network Research   News   Events   Home

Discussion Communities: Merit Network Email List Archives

North American Network Operators Group

Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical

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
> 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:
> returns IN NS
> returns IN NS
> returns IN NS
> returns 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

> 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
> > 	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
> Version: GnuPG v1.2.3 (Darwin)
> iD8DBQFCN7SEn5zKWQ/iqj0RAtK5AJ4pagTb5Ei+uMqGf9ob9RfSHJFWnQCghs2K
> Ltjk1dF5GCdssFNx1KiczoQ=
> =Se+y
> --==========63ACF217CA8F895998F9==========--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET:

Discussion Communities

About Merit | Services | Network | Resources & Support | Network Research
News | Events | Contact | Site Map | Merit Network Home

Merit Network, Inc.