Currently we only seem to have two choices in BlueCat:

1. Separate “Configurations”, but that leads to duplicate zones and duplicate records and confusion.
2. Don’t track the overlapping space.  We do this for some private address space that we designate as non-routable internally, any group can use it behind their own firewall or gateway.  But of course they later decide they want DNS entries, and we have to say no.

A better solution would be nice, but still there will be complexity.  If some networks and zones could be ‘common’ across DNS views, and others separate, that might work.

Hey ​@rharolde very well outlined. I passed this on to the team and they mentioned it was really helpful for them. A suggestion → What about using UDLs to help mark relationships in overlapping space? There is some basic documentation and some best practices here: UDL

UDLs might help.  I have not had time to work with them.

​@rharolde If you end up using them - keep me posted. Would like to hear if they help and what you’ve done with them. 

​@rharolde here is a demo to assist 

We used to do #2 and stipulate that we would not provide DNS entries at those IPs, however one can provide DNS at those IPs and not have the records tied back to the IP Address objects in BAM by using Generic A records.

True, you can set up forward DNS records.  Then there were some users that wanted reverse records, and those would conflict with others, so we had to say ‘no’.