Re: Delegating /24's from a /19

[Robert Bonomi <bonomi () mail r-bonomi com>]

> 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