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 -- If it wasn't crypto-signed, it probably didn't come from me.