Delegating /24's from a /19

From Tue Mar 15 18:51:46 2005
Date: Wed, 16 Mar 2005 11:51:33 +1100 (EST)
From: Mark Andrews <>
Subject: Re: Delegating /24's from a /19

In article <> you write:
>Content-Type: text/plain; charset=us-ascii; format=flowed
>Content-Transfer-Encoding: quoted-printable
>Content-Disposition: inline
>>>> > 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?
>>> 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
  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 "" 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
   "*" 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