North American Network Operators Group|
Date Prev | Date Next |
Date Index |
Thread Index |
Author Index |
Re: Delegating /24's from a /19
- From: Robert Bonomi
- Date: Tue Mar 15 21:10:34 2005
> From firstname.lastname@example.org 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: email@example.com
> Subject: Re: Delegating /24's from a /19
> In article <firstname.lastname@example.org> you write:
> >Content-Type: text/plain; charset=us-ascii; format=flowed
> >Content-Transfer-Encoding: quoted-printable
> >Content-Disposition: inline
> >>>> email@example.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 =
> >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.
> >[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
> >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
It works. Yes, it requires maintainence. But it _works_. unlike the
> 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.