Using a Fake Parent domain to simplify delegations from ARIN?

[Dylan Ulis]

On 10/3/07, 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.

It wouldn't really be an upwards referral; I was thinking more of a
"sideways" referral, like...

Q1: dig @chia.arin.net    1.5.168.192.in-addr.arpa.   PTR
A1: Referral to     5.168.192.in-addr.arpa.  IN NS ns1.company.com.

Q2: dig @ns1.company.com   1.5.168.192.in-addr.arpa .   PTR
A2: Referral to     5.168.192.in-addr.arpa.  IN NS ns1.group1.company.com.

Q3: dig @ns1.group1.company.com.   1.5.168.192.in-addr.arpa .   PTR
A3: Answer     host.group1.company.com.

That way still doesnt actually point down, so I'll assume that I can't
*assume* how resolvers will behave when they see something 'off' like that.


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).


Chris also suggested this, but its really not feasible in my organization
for many reasons.  The initial coordination alone due to the sheer number of
unique delegations from ARIN would be an absolute nightmare.
I was trying to figure out an easier fix to manage all of this, while making
it fairly transparent to our sub-organizations.  But, now I think we'll just
have to deal with the old stuff until it can be retired.

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.


Chris, Kevin, Doug, Barry - Thanks for the good info. It definitely
helped...

Barry - That's an interesting idea, but I really have no desire to mess with
Classless In-addr if I Really dont have to.

Thanks again,
Dylan


               - 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,
> >
>
>
>


-- 
Dylan Ulis
dylan.ulis at gmail.com