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: Owen DeLong
  • Date: Tue Mar 15 23:23:45 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 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

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.

	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.

Attachment: pgp00008.pgp
Description: PGP signature

Discussion Communities

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

Merit Network, Inc.