[78678] in North American Network Operators' Group
Re: Delegating /24's from a /19
daemon@ATHENA.MIT.EDU (Owen DeLong)
Tue Mar 15 18:56:15 2005
Date: Tue, 15 Mar 2005 15:55:29 -0800
From: Owen DeLong <owen@delong.com>
To: Mark Andrews <Mark_Andrews@isc.org>, nanog@merit.edu
In-Reply-To: <200503152120.j2FLKfo3025492@drugs.dv.isc.org>
Errors-To: owner-nanog@merit.edu
--==========D714B409A8D84E671065==========
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
>>> alex@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?
> 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==========--
