Sharing PTR zone, Across Multiple Views

[#1]

(NOTE:  Architecture issue, looking for possible ways in which this might be solved.)

Description-

---------------------------

We have a maintenance responsibility for two External Views (i.e. both Internet facing) which have two corresponding sets of servers (four members each) that service the two views, ONE... for Recursive services, and ONE... for Non-Recursive services.  We have most of the domains (Forward and Reverses) in the NON-RECURSIVE set (Generally we are moving almost everything towards the non-recursives like everyone else), HOWEVER... there are some of the older ones that are going to stay in the View with the RECURSIVE set of servers.  That can't be changed for the moment, unfortunately.

SO... the problem arises as we add (mostly) Host records (which are the combination Forward As and PTR Reverses) in one or the other view.  IF... the PTR zone is homed in a view where the Host record is deployed, the associated PTR records get added.  IF NOT.... that PTR DOES NOT GET ADDED to the other view where the PTR ZONE IS DEPLOYED and delegated.  That is the way it's supposed to work, right?  The views are separate, and don't know anything about each other?!?!??

I NEED... THE PTR (i.e. the host record) TO BE ADDED TO THE DELEGATED PTR ZONE...  REGARDLESS OF THE VIEW IN WHICH THE HOST WAS ADDED.  Basically I need to make sure all the Host records get their associated PTR component, added to the delegated PTR zone, regardless of the view in which the Forward zone is homed for a given Host Record.

"Solutions" discussed thus far-

---------------------------------------------

At first, I thought the solution might be just have BOTH views with their own copy of the zone and the Host records which fall in each (respectively), would then be served by whichever view would be hosting the corresponding Forward zone, but… THAT IS NOT THE WAY IT WORKS!?!?!?  The PTRs are delegated just like the Forwards, accept by ARIN or the Telco, rather than by a Registrar.  So, only the delegated zone would get resolved, ergo... that isn't going to work.

Perhaps delegate ALL of the server, regardless of view, with ARIN?  NOPE!  That isn't going to work either because the actual query is only going to go to one or the other set.  Who knows if the query is going to hit the correct set where (potentially) the corresponding PTR is actually mapped?!?!?!?

AND,... we can't just put a CF on recursive set, over to the non-recursives either.  There are Host records in the recursive set that would not be added where a CF was present.  The A portion of the Host would get mapped to the Forward, but the PTR portion would just get "ghosted".

I've been tinkering with the idea of an ANYCAST VIP that would send the queries to all the servers of both views, but... that seems a bit too ugly and brutal, and would probably produce more traffic than I suspect NetEng and Management would support.  AND,... it's "NEWISH", we don't do "NEW" here... so... that is probably not going to fly either.

I'm curious with regard to what suggestions (experiences) others have, that we might be able to use, in order to accomplish that with NIOS and IB Members?

Is there some way to “share” a PTR zone across DNS Views? I don’t currently see a straight forward way to do that?

My best option to date.... (i.e. the one idea we have been tinkering with at the moment)
Would be to have an MS-AD DNS server (buried behind Firewalls of course) using a peer-to-peer configuration, to act as a PTR Hidden Master (more like a “Hidden Facilitator” maybe?) for BOTH sets (Rec, Non-Rec, or any other stand-alone set that might be added in the future) to communicate with the public facing servers as MS-AD Peers?

i.e. it would not matter WHERE you added the Host Record, the relevant PTR zones in that view would be configured as MS-AD peers and then update the other "Peers" (visa-viz the "PTR hidden facilitator" described above) spreading the record to each of the views, one of which would be the delegated set.

It would be a bit easier if there was simply a way to bridge a PTR zone across views, and stick to ALL Infoblox components, but it seems like we need to have some way of peering a PTR zone where it DOES NOT MATTER… in which DNS View the Host record is added, BOTH the Views (or potentially even more stand-alone Views) get a Copy of the PTR portion of that Host record.

Any suggestions, experiences that might help to resolve the problem?

Thanks,

CJD