Using a Fake Parent domain to simplify delegations from ARIN?

[Barry Margolin]

In article <fe1a24$2r44$1 at sf1.isc.org>, Kevin Darcy <kcd at chrysler.com> 
wrote:

> Modern resolvers only accept referrals which point "down", i.e. to a 
> lower level of the hierarchy than what they asked for, so your plan is 
> doomed to failure in the general case. You might find some buggy old 
> resolvers here and there that accept an "upwards" referral, but then 
> their cache would get "poisoned" with an entry for your "fake parent 
> zone" that would blind them to the parts of that namespace which you 
> don't happen to control.
> 
> The only reasonable approach that comes to mind is for ns1.company.com 
> -- I assume that name stands for multiple nameservers -- to take on the 
> hosting of all of the various in-addr.arpa zones. You could then slave 
> all those zones from the various groups' nameservers internally, no-one 
> on the Internet would know or care that you're only a slave for the zone 
> (this is sometimes known as a "hidden master" architecture, and it's 
> fairly common).

Actually, there's another way to do it.  You can use the RFC 2317 
mechanism of filling up the /24 reverse zone with CNAME records.  While 
this is normally only done when delegating a portion of a /24, there's 
no reason why it can't be done for ALL the records in the /24.

> 
> Note that, although it's not completely kosher, your client 
> organizations could probably get away with making the NS records at the 
> apex of a given reverse zone a *superset* of the delegating NS records, 
> in order to spread out and optimize the query load. (Mark will probably 
> jump all over me for suggesting such a thing). This "supersetting" 
> theoretically shouldn't give rise to any glue issues, unless you try to 
> give your nameservers names in the reverse (in-addr.arpa) namespace.
> 
>                                                                          
>                - Kevin
> 
> 
> Dylan Ulis wrote:
> > I recently began working for a very large company, that has a very
> > fragmented IP space.  In the past, many groups in our company got IP space
> > directly from ARIN.  Now, things are done through a central office that
> > manages IP's (and Reverse DNS).
> > The problem is our legacy space that is delegated from ARIN directly to our
> > sub-groups.  If someone with the legacy space wants to change DNS servers
> > for their Reverse Zones, the change gets processed at 1)the central company
> > IP office (for record keeping purposes)  and then 2) ARIN (for the actual
> > DNS change).
> >
> > I am looking to simplify this process so we dont have to go through ARIN for
> > every change inside our company.  I would like to change all ARIN
> > delegations to point to our main company servers.  Then, create a Fake
> > Parent zone on our company's DNS servers, so we can delegate out to the
> > groups that actually own the space.  (Below is an example... I'm just using
> > private IP space so I dont have to use our real IP's)
> >
> > Example current ARIN delegations:
> > 5.168.192.in-addr.arpa.  IN NS ns1.group1.company.com.
> > 15.168.192.in-addr.arpa. IN NS ns1.group2.company.com.
> > 25.168.192.in-addr.arpa. IN NS ns1.group3.company.com.
> >
> > Planned future ARIN delegations:
> > 5.168.192.in-addr.arpa.  IN NS ns1.company.com.
> > 15.168.192.in-addr.arpa. IN NS ns1.company.com.
> > 25.168.192.in-addr.arpa. IN NS ns1.company.com.
> >
> > NEW Zone Hosted n ns1.company.com.
> > 168.192.in-addr.arpa. IN NS ns1.company.com.
> >
> >
> > So my question:
> > Is this bad Internet/DNS practice to have the 168.192.in-addr.arpa. zone on
> > ns1.company.com, even though we don't own the whole /16?
> > Will this taint cache's of other DNS servers if we now answer
> > authoritatively for a zone we don't own?
> >
> > Thanks,
> >

-- 
Barry Margolin, barmar at alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***
*** PLEASE don't copy me on replies, I'll read them in the group ***