Delegating /24's from a /19

Wed Mar 16 02:08:39 UTC 2005

> From owner-nanog at merit.edu  Tue Mar 15 18:51:46 2005
> Date: Wed, 16 Mar 2005 11:51:33 +1100 (EST)
> From: Mark Andrews <Mark_Andrews at isc.org>
> To: nanog at merit.edu
> Subject: Re: Delegating /24's from a /19
> Cc: 
>
>
> In article <2147483647.1110902129 at 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 at 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
>