Delegating /24's from a /19

Wed Mar 16 00:51:33 UTC 2005

In article <2147483647.1110902129 at imac-en0.delong.sj.ca.us> you write:
>
>--==========D714B409A8D84E671065==========
>Content-Type: text/plain; charset=us-ascii; format=flowed
>Content-Transfer-Encoding: quoted-printable
>Content-Disposition: inline
>
>>>> alex at pilosoft.com wrote:
>>>> > Either by doing DNS delegation on the zone boundary or by SWIP'ing
>>>> > the  space to the other company.
>>>>
>>>> You can SWIP it yes, but that won't help DNS on small blocks like =
>/24's.
>>>>
>SWIPping the large block won't help.  SWIPping the /24s will.
>
>>> OK, what am I missing?
>>>
>>> *ASSUMPTION*:
>>>  The holder of the /16 _has_ delegated rDNS for the 32  /24s to the /19
>>>  owner.
>>>
>>> The /19 owner can, on it's nameserver, run an "authoritative" zone for
>>> the /16 -- with _its_ /24s listed explicitly, and a wildcard pointing
>>> back to the rDNS nameserver of the /16 owner.
>>>
>Absolutely.
>
>[SNIP DNS Resolution 101 tutorial]
>
>>>
>>> _AS_LONG_AS_ the 'delegated to' nameserver has the wildcard in it
>>> pointing back to the 'parent' nameserver, this seems to work just fine.
>>> Admittedly, if the upstream block owner changes the _name_ of it's
>>> nameserver(s), the 'delegated to' nameserver  requires manual tweaking,
>>> but, realistically, "how often" does _that_ happen?
>>
>
>Seems perfectly reasonable to me.
>
>> 	This is the worst piece of "advice" I have ever seen.
>>
>Um, why?

	Firstly he does NOT have authority for the /16 reverse.  Lots
	of latent problems there.
	Secondly sideways delegations don't work.
	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).

	Delegation is the DNS is strictly hierachical.

	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.

	Mark

>> 	SWIP the nameservers.  The OP customers will be expecting to
>> 	be able to use the X.Y.Z.IN-ADDR.ARPA as the zone name.  It
>> 	also reduces the number of nameservers involved.  It is also
>> 	the clean solution.  The RIR's are all setup to handle this.
>
>That's another alternative, but, not the only one, and, in many cases,
>not the most effective.
>
>> 	For those advising RFC 2317 please read the first sentence of
>> 	the introduction.  RFC 2317 was NOT written to cover this
>> 	situation.  Go put it back in the filing cabinet and bring
>> 	it out when you have a situation that it does cover (/25-/32
>> 	sub-delegation).
>>
>While it doesn't inherently cover it, I see no reason it couldn't be
>used, although it seems unnecessarily complicated for the task.  Using
>a /16 zone with a wildcard backreference seems to me the cleanest solution,
>with SWIP coming in a close second.  In reality, the wildcard backreference
>is only needed _IF_ the nameserver is a resolver or forwarder, otherwise,
>it's useless anyway, as the nameserver in question should not be receiving
>queries outside of the space delegated to it.
>
>Owen
>
>
>--=20
>If it wasn't crypto-signed, it probably didn't come from me.
>
>--==========D714B409A8D84E671065==========
>Content-Type: application/pgp-signature
>Content-Transfer-Encoding: 7bit
>
>-----BEGIN PGP SIGNATURE-----
>Version: GnuPG v1.2.2 (Darwin)
>
>iD8DBQFCN3X1n5zKWQ/iqj0RAja3AKCMu6gl3QfPOUVlNRfNS2oulMwWHQCfeN9g
>0aDxJs9OXpzyVVqavnPNJ4s=
>=Ja+n
>-----END PGP SIGNATURE-----
>
>--==========D714B409A8D84E671065==========--
>