Delegating /24's from a /19

Owen DeLong owen at delong.com
Tue Mar 15 23:55:29 UTC 2005


>>> 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?

> 	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


-- 
If it wasn't crypto-signed, it probably didn't come from me.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 186 bytes
Desc: not available
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20050315/90df1aab/attachment.sig>


More information about the NANOG mailing list