In article <2147483647.1110902129@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@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==========--