How to delegate public IP zone internally

Mark Andrews Mark_Andrews at isc.org
Wed Sep 7 02:33:25 UTC 2005


> On 9/6/05, Mark Andrews <Mark_Andrews at isc.org> wrote:
> >=20
> > >
> > > An admin for one of these units has decided that he doesn't want to
> > > let us - the DNS mothership -  do zone transfers anymore, negating the
> > > stealth zone idea.  As it stands, nobody outside of their unit can see
> > > their 156.xxx.yyy.0 zone.  The admin for the rogue unit is being
> > > intransigent... or am I?
> > >
> > > Is there any other way I can delegate these zones without claiming
> > > authority for 156.in-addr.arpa and breaking many public lookups?  It
> > > seems to me that the stealth slave route is the simplest,
> > > hardest-to-break route here.  If you can, please tell me otherwise.
> > >
> >         Is there a reason why you don't follow the obvious?  Get
> >         the /16's delegated from ARIN then delegate the /24 from
> >         them.  Everyone can then just follow the normal delegation
> >         path.
> 
> Yes, there is a reason and it's name is both politics and
> institutional inertia.  I am a contractor, behind enemy lines, and the
> barbed wire is thick.   But first, let me correct a false impression I
> made as I ineptly tried to obscure my client's otherwise public IP
> blocks: the rogue unit acts authoritatively for a /16, not a /24.  So,
> using just enough pointless obscurity to not get fired, we use
> fourteen /16 IP blocks internally:
> 
> 1x8.156.in-addr.arpa to 1x2.156.in-addr.arpa

	Ok that comfirms who you are working for.
 
> The rogue unit acts authoritatively for 1x6.156.in-addr.arpa.  When I
> came on the job, "we" (the root internal name servers) were configured
> as a stealth slave; it is now apparent however that "we" are being
> denied zone transfers, breaking any attempt by other units to resolve
> this zone.  The rogue admin insists that there is some way I can
> delegate this to him without acting as a slave, but I don't see how
> and he seems unwilling to directly advise me (making me wonder if he
> actually knows).
> 
> So, again, my question - my embarrassing but urgent question: is there
> a way to delegate 1x6.156.in-addr.arpa without involving ARIN or
> claiming authority for 156.in-addr.arpa?
> 
> Thanks - I know how nutty this question is, believe me.
> --Greg Chavez

	The only way that works with *all* nameservers is to allow
	the apex zones to be transfered to all the caching servers.
	These can delegate the 256 /24's if they don't want the
	PTR records to be transfers.

	Other than that you need to use vendor extensions.
	e.g.
		forward / stub zones to direct the queries to the
		correct servers in named.

	Mark
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: Mark_Andrews at isc.org



More information about the bind-users mailing list