Using a Fake Parent domain to simplify delegations from ARIN?
Kevin Darcy
kcd at chrysler.com
Wed Oct 3 22:46:01 UTC 2007
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).
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,
>
More information about the bind-users
mailing list