From owner-nanog@merit.edu Tue Mar 15 18:51:46 2005 Date: Wed, 16 Mar 2005 11:51:33 +1100 (EST) From: Mark Andrews <Mark_Andrews@isc.org> To: nanog@merit.edu Subject: Re: Delegating /24's from a /19 Cc:
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.
Did you note that it was _not_ 'advice', that I was *ASKING* "what am I missing?"
Um, why?
Firstly he does NOT have authority for the /16 reverse. Lots of latent problems there.
Can you elucidate on these "latent problems"?
Secondly sideways delegations don't work.
Education request: _when_ and/or _how_ do they "not work"? If machine A answers only for what it knows about, and refers everything else to machine B, and machine B answers for everything except what it knows that machine A knows aboud, and refers *only* those requests to machine A it appears to me that it doesn't really matter _which_ machine you send the query to -- the "right" machine will provide the _correct_ answer.
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).
I see a lot of hand-waving, and a paucity of facts there -- commonly referred to as "spreading FUD". Could you describe the failure modes of the specific scheme presented -- on the assumption that it *is* implemented as described -- and explain how/why the customer's expectations are not being met; given that the customer with the /24 customer *is* using the "x.y.z.in-addr.arpa" zone on their server.
Delegation is the DNS is strictly hierachical.
I take it that this means that it is "forbidden" to make "authoritative" 'blackhole' zones for _named_ domains that you don't want any contact with, too. e.g. a corporate resolver redirecting all fetches from "*.doubleclick.com" to a bitbucket server -- one that responds with an "empty" page to any http request. And that running authoritative local rDNS zones for 10/8, 172.16/12, and 192.168/16 is also not allowed. Note: this speeds up traceroute (and similar toys) considerably, when the path goes through devices numbered in RFC1918 space. One wild-card for the entire zone, unless I happen to be using some of that space internally on _my_ network. At the 'corporate' -- not ISP -- level, I have found numerous reasons to run 'authoritative' zones for name-space that was *not* hierarchically delegated to me. e.g. when management is exchanging e-mail with people in Central America, where the name server for the recipient's domain is routinely "not available" fore extended periods, yet the MX for that mail (in a different domain) is resolvable and reachable. Running a 'bogon' authoritative name-server for that domain lets management "get _their_ job done", without the failures attributable to the problem remote name-server. It works. Yes, it requires maintainence. But it _works_. unlike the alternative.
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