Reply
Highlighted
Accepted Solution

Architecting a solution for DNS views

Adviser
Posts: 60
14994     2

I have an unusual set of challenges in trying to implement dns views for my organization.  Our Infoblox grid hosts not only my organization’s zones but the zones of many other “related” organizations.  We are primary for all of our zones but we could be primary or secondary for those zones that are “owned” by external organizations.  I want to implement an internal and external dns view for my organization but I need to do it in such a way that I don’t disrupt the other organizations.  Fortunately, my organization is responsible for managing the grid which gives me great freedom in architecting a solution.

 

Right now everything is in the “Default” view.  I was considering creating a new view and naming it “Internal.”  I would then copy ALL of the records from the Default view into the Internal view.  Then I would go back to the Default view and delete our zones/records that we don’t want visible to the public.  The problem with this is that now, whenever any of these external organizations log in to the web GUI to make dns changes for their respective organization, they will have to make changes to the default view and our new internal view.  They aren’t going to be happy about that. 

 

How do people handle maintaining records in multiple views without having to manually make changes to all views to keep them in sync?  I can see how implementing dns views could double or triple the amount of work necessary to keep records updated in the various views.  Are there programatic solutions that will detect changes to records in one view and copy them to another view?  Is there a way to cascade dns views so that you don’t have to maintain records in every view?  I found a forum post on cascading views but it was vague and I couldn’t find any other references to it.  We have about 2,000 zones and I don’t think shared resource records would be an appropriate option.

 

I’m starting to think that instead of implementing dns views, I should consider a completely different grid for our internal dns.  The problem with that is we don’t have the money to purchase new equipment/licenses for that.  Our current equipment is running at less than 25% capacity so I’d sure hate to have to buy more equipment.   I’m still looking for a solution where we can continue to host all organization’s zones yet allow us to have in internal and external view for my organization - and not double the workload on the external org admins.

 

Maybe I’ve missed something in the admin guide but I sure don’t see any way to come up with a clean solution.  Any ideas would be appreciated.

Re: Architecting a solution for DNS views

Adviser
Posts: 213
14995     2
Let’s start with getting a little more information.

When you say that these other organizations must modify both the default view AND the internal view, why do you think that? If the internal view is NOT authoritative for their data, there shouldn’t be any need for you to require that they access both views. They should be able to just update their data and any of your internal clients that need their services will just resolve through the Internet (even if that means coming back to your same appliance).

Your biggest challenge will be to ensure that you get the view ordering and match list(s) correctly configured. Usually, the internal view is all of your own private addressing and the “external” view (default in this case) would match everything (and be at the bottom of the ordering).

Do the other companies come in only through the Internet to resolve names on your DNS appliances or do they come through some VPN or other connectivity? This could be relevant depending on what address spaces they are coming in from. You just need to understand and plan accordingly.

Yes, having multiple views can complicate matters and when you put them on the same appliance, that adds additional complications. Sometimes it’s fairly straight forward but it does mean you have to think more logically about where the target data is and where the client is coming from to determine what the likely result will be. If you stick to only two views, you’re likely to keep the configuration from getting too complex. Just be careful if you feel that you need to start creating more…that adds to your complexity in many ways.

Re: Architecting a solution for DNS views

Adviser
Posts: 60
14995     2

Of the 2,000 zones we host on our grid, about 25% of them are are under our organization's control.   The other 75% are "owned" and maintained by other organizations.  All admins have a GUI login so they can maintain (add/remove/modify) their own records and zones.  Concerning the zones we do not own, most of them we are authoritative for and some we are not.  In some cases, we may be acting as a secondary for their authoritative server.

 

My organization wants to hide some of our reverse lookup zones and the associated host records in the forward lookup zones.  We'll probably want to hide about 20% of our records.  No other organizations will ever be setting up dns views.  

 

My organization owns the Infoblox appliances, licenses, maintenance contracts and maintains the grid. 

 

Point 1 - After reading the admin guide I can see that any particular client can access only one dns view.  Once the match client list finds a match, it uses that dns view and no others.

 

Point 2 - Any internal clients in my organization need to be able to access any and all dns records in any zone hosted in our grid.

 

Point 3 - Any external client needs to be able to access any and all dns records in any zone hosted in our grid MINUS the internal records we want to hide.  Over all, the stuff we want to hide is a small percentage of the total number of records we host.

 

After reading the admin guide, it looks like I will need a minimum of two views, internal and external, or public and private, however you want to word it.  The internal view will contain everything on the entire grid.  The external public view will contain everything in the entire grid too - except for the zones/records our organization wants to hide.  The public view will be a subset of the private view.

 

To summarize, any external dns client (anywhere on the internet) may need to resolve from any zone no matter which organization "owns" it.  The only exception is that we don't want external clients trying to resolve stuff on our private networks.  Since this is the case, both dns views will contain the bulk of everything we are hosting on our grid.  Since both dns views contain the bulk of everything (both dns views will contain 95% the same data), every admin that has an account on our system will have to keep both views updated.  Even though our “internal” dns view does not benefit them, they will still have to keep it updated or our internal users will not have current data.

 

These are all conclusions I have come to after reading the admin guide.  Maybe I didn't interpret it properly.  The admin guide is not he best place to get a high level overview of some concepts and features.  If there is some other way to do this without duplicating almost 2,000 zones I would like to hear it.  I’m hoping there is some other way to do this.

Re: Architecting a solution for DNS views

Adviser
Posts: 213
14995     2

Point 1 - After reading the admin guide I can see that any particular client can access only one dns view.  Once the match client list finds a match, it uses that dns view and no others.

This is correct.  The ACL acts as a filter and you "enter" one view and one view only.


Point 2 - Any internal clients in my organization need to be able to access any and all dns records in any zone hosted in our grid.

 


You could "forward" from the "internal" view to the "default" view.  Any lookups for your zone would only match out of the "internal" view but ALL other zones could be serviced out of the "default" view.


Point 3 - Any external client needs to be able to access any and all dns records in any zone hosted in our grid MINUS the internal records we want to hide.  Over all, the stuff we want to hide is a small percentage of the total number of records we host.


Yes, this would be the easiest and most "normal" reason to implement multiple views.


To summarize, any external dns client (anywhere on the internet) may need to resolve from any zone no matter which organization "owns" it.  The only exception is that we don't want external clients trying to resolve stuff on our private networks.  Since this is the case, both dns views will contain the bulk of everything we are hosting on our grid.  Since both dns views contain the bulk of everything (both dns views will contain 95% the same data), every admin that has an account on our system will have to keep both views updated.  Even though our “internal” dns view does not benefit them, they will still have to keep it updated or our internal users will not have current data.

No, this would complicate things and would not be necessary.  You would move ONLY those zones which differ from the "external (default)" data to the "internal" view.  ALL other zones which would have identical data would exist in only the "external" view.  You would then configure the "internal" view to FORWARD to the IP of the member itself to resolve the "external" data or just let the appliance use normal Internet-based recursion.  You just have to make sure the member's IP address does NOT match the "internal" view during resolution.  Thus only you and your team would need access to manage anything in the "internal" view and everyone else would continue to do exactly what they do today...only touch records in the default view.

 

 

 

 

 

 

 

 

Re: Architecting a solution for DNS views

Adviser
Posts: 60
14995     2

Thanks for the information DSmith, this information is encouraging.  The only problem I have to solve is related to the IP addresses.  The way we architected our grid is to use a hidden master with multiple grid members.  Each of the grid members are configured exactly the same, obviously the physical interfaces and the grid member names are unique, but there is nothing unique in function to any grid member.  

 

There are two anyacst addresses configured on each grid member.  Those two anycast addresses are the addresses we advertise as our dns servers.  The physical addresses are configured as "stealth" so they never show up in any soa or ns records.  We never allow people to use the physical IP address of an interface as their resolver.  It looks like we might need to allocate some unique IP addresses for our internal view.  I have to research what you are saying to see if I can accomplish this with an additional anycast address.  I'm thinking it wont work.   Need to research.  Thank you for the info.  I might need to get Professional Services involved.

Re: Architecting a solution for DNS views

Adviser
Posts: 213
14995     2
Glad I could help.

Regarding your stealth master configuration and “hidden” IP addresses…no changes or special handling required here for any of the “users” of the system. Only you, as the admin, need to worry about those and there shouldn’t be any need to change “much” beyond making sure that the IP used by the appliances for resolution match the “clients” or “destination” based on how you’re planning to do the view forwarding or resolution.

I would definitely recommend getting PS to help at least review the configuration and walk you through the pros and cons of either configuration. They will be able to offer more specific insight than what I can using the public forum.

Good luck to you and have a Happy Thanksgiving!

Re: Architecting a solution for DNS views

VObelic
Techie
Posts: 3
14995     2

May I just steal the topic for a bit?

How would you setup forwarding between e.g. external and default view?

I want to achieve exactly this, have a specific zone in a view and then forward the rest of the queries to the default view.

 

Thanks!

Re: Architecting a solution for DNS views

Adviser
Posts: 213
14995     2

Configure the view and set the fowarders list and use the IP address of the same member (point it to itself).  If it's an HA pair, use the VIP.

Re: Architecting a solution for DNS views

TTiscareno Community Manager
Community Manager
Posts: 242
14995     2

If all administrators have their own logins and your main intention is to hide certain zones from different administrators, would setting the permissions to deny read/write access to these zones for all administrators other than those which should have access accomplish what you are looking for? You can also use ACL's in the Query properties at the zone levels to restrict who can actually query for those zones and records.

 

If so, this would allow you to avoid having to re-architect your DNS infrastructure and would be much simpler than implementing this through the use of DNS Views.


@Clark wrote:

Of the 2,000 zones we host on our grid, about 25% of them are are under our organization's control.   The other 75% are "owned" and maintained by other organizations.  All admins have a GUI login so they can maintain (add/remove/modify) their own records and zones.  Concerning the zones we do not own, most of them we are authoritative for and some we are not.  In some cases, we may be acting as a secondary for their authoritative server.

 

My organization wants to hide some of our reverse lookup zones and the associated host records in the forward lookup zones.  We'll probably want to hide about 20% of our records.  No other organizations will ever be setting up dns views.  

 

My organization owns the Infoblox appliances, licenses, maintenance contracts and maintains the grid. 

 

Point 1 - After reading the admin guide I can see that any particular client can access only one dns view.  Once the match client list finds a match, it uses that dns view and no others.

 

Point 2 - Any internal clients in my organization need to be able to access any and all dns records in any zone hosted in our grid.

 

Point 3 - Any external client needs to be able to access any and all dns records in any zone hosted in our grid MINUS the internal records we want to hide.  Over all, the stuff we want to hide is a small percentage of the total number of records we host.

 

After reading the admin guide, it looks like I will need a minimum of two views, internal and external, or public and private, however you want to word it.  The internal view will contain everything on the entire grid.  The external public view will contain everything in the entire grid too - except for the zones/records our organization wants to hide.  The public view will be a subset of the private view.

 

To summarize, any external dns client (anywhere on the internet) may need to resolve from any zone no matter which organization "owns" it.  The only exception is that we don't want external clients trying to resolve stuff on our private networks.  Since this is the case, both dns views will contain the bulk of everything we are hosting on our grid.  Since both dns views contain the bulk of everything (both dns views will contain 95% the same data), every admin that has an account on our system will have to keep both views updated.  Even though our “internal” dns view does not benefit them, they will still have to keep it updated or our internal users will not have current data.

 

These are all conclusions I have come to after reading the admin guide.  Maybe I didn't interpret it properly.  The admin guide is not he best place to get a high level overview of some concepts and features.  If there is some other way to do this without duplicating almost 2,000 zones I would like to hear it.  I’m hoping there is some other way to do this.


Re: Architecting a solution for DNS views

Adviser
Posts: 60
14995     2

All those admins already have permissions set so they can't see or modify zones which they don't own.  I am implementing internal and external DNS views because we have zones/records that are public that should not be public.  When we started running our own DNS we were small and had no need for public and private views.  Now we have lots of 10. private networks and other internal hosts that everyone can see.  We only have one "default" DNS view.   I am implementing a private view to hide our internal nets.  Long overdue.

Re: Architecting a solution for DNS views

Adviser
Posts: 60
14995     2

Thanks to the info I received here, I have my lab environment configured and working with a new private "internal" DNS view.  I set up a forwarder at the DNS View level and it works great.   Now I don't have to copy all those unnecessary zones to the private view.   

 

I have one last question:  Is it possible to configure a zone in an internal DNS view to only contain the records that are considered “internal?”  If an internal client unsuccessfully queries the internal zone, can the query will be forwarded to the same zone in the external view?  If this can be done it will eliminate having to update records in both views.  I couldn’t figure out how to do it.  I’m just trying to avoid having to maintain records for the same zone in two views.

Re: Architecting a solution for DNS views

TTiscareno Community Manager
Community Manager
Posts: 242
14995     2

@Clark wrote:

Thanks to the info I received here, I have my lab environment configured and working with a new private "internal" DNS view.  I set up a forwarder at the DNS View level and it works great.   Now I don't have to copy all those unnecessary zones to the private view.   

 

I have one last question:  Is it possible to configure a zone in an internal DNS view to only contain the records that are considered “internal?”  If an internal client unsuccessfully queries the internal zone, can the query will be forwarded to the same zone in the external view?  If this can be done it will eliminate having to update records in both views.  I couldn’t figure out how to do it.  I’m just trying to avoid having to maintain records for the same zone in two views.


 

The challenge here is that with DNS, nxdomain (does not exist) is a completely valid answer so the server has no way of knowing if it should say that the name does not exist or follow the recursion path. If you are OK with returning both the internal and external IP's, you can control the ordering of these IP's using the Sort Lists feature. Clients generally connect to the IP which is ordered first and only use any additional IP's if the connection times out, trying each one in order.

 

However, I imagine that most likely you will want to take an CSV export of the zone which contains all of your records, modify the IP's and then import that to the zone in the other view.

 

Hope this helps.

Re: Architecting a solution for DNS views

Adviser
Posts: 60
14995     2

I only have two zones that will be in multiple views.  For these two zones, I had planned on exporting a csv file and importing to the new internal dns view.  Then go back and remove the "private" records from the external dns view.  The internal and external view of these two zones will contain a lot of the same records.  Our admins will have to remember to possibly update records in both dns views.

 

I will never have a case where a host will have a different IP address based on the dns view it is in.  It either will or will not be visible in the external dns view.   Therefore, I started thinking about configuring the internal zones with ONLY the records that we want to keep private.  The external zones will contain ONLY the records we want public.  There would be no overlap in the dns records in the two views.  This would require the internal zones to be configuured to forward to the external zone if a record is not found.  If not found in the external zone, it would return nxdomain.

 

This is the specific scenario I was thinking about.

 

 

Re: Architecting a solution for DNS views

Authority
Posts: 20
14995     2

Not sure if this will help but I had a similar scenario in which I need to create a separate view for our guest wireless networks and allow a specific subdomain to be resolved so that people on the guest wireless network could use our conference room collaboration equipment wirelessly.

 

Essentially what I did was create a new view call guest-wireless and set the match client list to only the subnets for the guest wireless devices. Then I moved it to the top of the view order. After that, I created a shared record group for the subdomain they needed and included my internal view zone and the guest wireless view zone in the shared record group. 

 

Now if I need to make a record update for a record in that subdomain I just add it in the shared record group and it writes the record to both zones. This also allowed me to deny resolution for any of my other internal records so guest wireless only gets the subdomain records that I give them.

 

I also had a scenario in which I had two different views for locations (now defunct) but the two different views had to be able to resolve records between each other so we did as suggested above which is to forward the queries to the other views rather than manually manage records in two different views.

Re: Architecting a solution for DNS views

[ Edited ]
Adviser
Posts: 60
14995     2

How did you "forward the queries to the other views" ???   This would solve my problems!

Re: Architecting a solution for DNS views

Authority
Posts: 20
14995     2

We just set up a forward zone in the first view in the view order and pointed it to the ip of the infoblox and it would forward it back to itself and hit the second view and resolve.

Re: Architecting a solution for DNS views

[ Edited ]
Adviser
Posts: 60
14995     2

I'm already doing that - setting up a forward at the dns view level.  This type of forward only works at the zone level.  If an internal user hits the internal dns view, and the zone does not exist, the query gets forwarded to the external dns view where that zone exists.  This works really well.  My internal dns view contains 52 zones and my external dns view contains 2,000 zones.   

 

The problem I am trying to solve is this:  If an internal user hits the internal dns view (and the zone exists there) but the host record in the query does not exist . . . I do not want an NXDOMAIN to be returned to the client.  I want the query to be redirected to the same zone but in the external view.  If, for whatever reason, the record does not exist in the external dns view, only then do I want the response to be NXDOMAIN.

 

Setting up a forwarder does not work at the record level.  I'm still searching to see if the forward can be done at the record level.   I have found some documentation concerning bind 9.10 where new functionality was introduced so users can modify the behavior of the NXDOMAIN response.  But i still haven't figured out how to apply this to Infoblox NIOS.   

 

Google search "NXDOMAIN Redirection Using DLZ in BIND 9.10"  This sounds like exactly what I need.  However, I don't believe the Infoblox NIOS has any way for the end user to configure this.  Unless the end user can get the behavior using a custom RPZ.

Re: Architecting a solution for DNS views

Adviser
Posts: 213
14995     2

You can forward at a view level which allows any query not handled authoritatively (or from cache) to go to another "server" (could be another view on the same server).  You can also define a "forward" zone which means queries only for that zone go to another target server.  If you want to do a "record" level redirect, you can leverage RPZ for that.

 

All three options are available in NIOS but you must have a license for RPZ to enable the feature.

 

Re: Architecting a solution for DNS views

Adviser
Posts: 60
14995     2

Sounds like I need RPZ.   I do have a license.   The reason I couldn't find the NXDOMAIN Redirect tab is because I didn't realize it requires a license.   Off to read about RPZ now.

Re: Architecting a solution for DNS views

verne
Techie
Posts: 12
14995     2

I am thinking of a similar view setup but am concerned about the overhead of the one view falling thru to the forward statements to then hit the other view ...

 

... will this double processing impact NIOS ... my lab environment shows it works ... does make interesting query log entries

 

... what are the downside, if any, to have one view falling thru and forwarding to another ... I am testing using a loopback address as part of migrating/duplicating/integrating another agency's DNS servers into my appliance while keeping (hijacking) their IP addresses

 

... so their end users will not have to make any config changes .... their queries will come in on the hijacked IP and hit their view and get direct answers ... but if the query is for one of my zones, the forward statement will throw them over to my authoritative (public) zone for an answer (all on the same single appliance).

 

I am at a point of considering not using views and have the appliance simply give authoritative answers for all of the new zones as well as all of my older zones regardless of what incoming IP connection is used.

 

I am hoping my situation is close to yours ... don't mean to hijack this thread ...

 

 

Re: Architecting a solution for DNS views

Adviser
Posts: 60
14995     2

I know that in my case, the only queries that will forward to a different view are queries from my internal clients.  I am calling my views "public" and "private"  

 

My internal clients will hit the private view first and possibly forward to the public view.  The total number of queries from my internal clients are relatively low compared to the total number of queries my grid receives.  So only my internal clients could possibly forward to a different view.  My appliances are over spec'd anyway so I'm not concerned about the performance hit.

 

I'll say it in a different way:  Most of our queries are from external sources.  Our internal clients are the only clients that would ever forward to a different view.  There will be in minimal performance impact because if this.  You might want to get some idea of the % of your total traffic that *might* forward to to a different view.  We have reporting enabled so it was easy to get an idea how this might affect us.

Showing results for 
Search instead for 
Do you mean 

Recommended for You