DDNS, Forwarding, Grid Replication...Admin Guide Confusion

[#1]

I'm testing a scenario where I have five NSGs in theoretically separate geographical locations, GM & GMC configured as hidden stealth primaries for each NSG and a pair of secondary Grid members per NSG.

I'm a bit confused as to how Grid Replication comes into play as far as DDNS and Zone Transfers or Forwarding are concerned.  My primary questions are:

1) What is the proper way to configure DDNS updates allowing the DHCP server to update DNS in this scenario?

2) How are DNS requests handled in a standard Grid configuration...no external primaries or secondaries.  Is there a need to configure forwarding to other Grid members?

Let's tackle DDNS first.  Within the 8.4 Admin Guide under the "Configuring a Grid" section, there's a map on page 328 that details an example site layout that's similar to my test scenario.  On page 335, the section labeled "Infoblox Grid Master - DDNS Updates", it recommends adding the IPs of the Grid Members to the Updates tab of the GM.  Does Grid Replication provide that info to the Grid Master?  If not, and if the Members are supplying both DNS & DHCP, which IP am I adding to the Grid Master's Update tab...the DNS IP or the DHCP IP?

My DNS Forwarding question also relates to Grid Replication.  Is it even required to configure forwarding on the Grid Members & Master if Grid Replication is in use?  For example, If the clients served by NSG1 send a query to NSG3 for resolution, does Forwarding need to be configured between these two entities?  Or does Grid Replication handle that request

The Admin Guide has a note stating the following under the DDNS Updates procedure:

When all DNS servers are members in the same Grid, the members use database replication to synchronize all their data—including DNS zone data. You can change the default behavior so that Grid members use zone transfers instead. In this example, Grid members use database replication.

If the data is synchronized, is there a need for Update or Forward configuration at all??

[#2]

Hi,

1) What is the proper way to configure DDNS updates allowing the DHCP server to update DNS in this scenario?

--> on DHCP side, need to enable the DDNS (by default is disabled), need to enable the option 81, need to configure DDNS which zone that DHCP need to be updated.

--> On DNS side, need to allow update for the DHCP servers IP.

2) How are DNS requests handled in a standard Grid configuration...no external primaries or secondaries.  Is there a need to configure forwarding to other Grid members?

--> i think this is protocol wise, when you configure DHCP servers to update the DNS the flow will be, DHCP server will look at the MNAME of the SOA record and ask for its IP, then it will update to that master IP. i think there's no different whether if its on the grid or we have external ns to update.

--> no forwarding configuration needed, it will look at ddns configuration (you can find this option in Data Management -> DHCP -> tools bar -> configure DDNS)

Hope this can help

Thanks

[#3]

I think you're getting forwarding and grid replication mixed up, they are two different things. All the grid replication does is replace the zone transfer mechanism, so if there is an update on the primary DNS server then it will transfer the data to the secondaries via grid replication instead of zone transfer.

As for forwarding, if the DHCP servers can resolve the DDNS domain directly via their configured DNS resolver then you don't need to configure any forwarding. If they can't resolve the domain locally, then you may need to configure forwarding so that the domain can be resolved by whichever servers are authoritative. The DHCP server will send the update to whatever server is listed in the SOA mname field, which could be an Infoblox member or non-Infoblox device (unless you have altered this via the DDNS configuration settings).

If you are using Infoblox DHCP servers then the grid will automatically add them to the "allow-update" configuration on the Infoblox primary DNS server(s), you don't need to add them to the "allow-updates" list, it'll do it automatically, you can see it by viewing the DNS configuration on the primary DNS server.

[#4]

---

@paulr wrote:

I think you're getting forwarding and grid replication mixed up, they are two different things. All the grid replication does is replace the zone transfer mechanism, so if there is an update on the primary DNS server then it will transfer the data to the secondaries via grid replication instead of zone transfer.

So, if I have a single Grid and a client in zone corp.com behind NSG1 (GM/GMC stealth primaries & Grid Member secondaries) that needs to query zone example.net behind NSG2 (same GM/GMC stealth primaries but different Grid Member secondaries), would I need either:

1) A stub zone of example.net on NSG1?

2) Configure a forwarder to the servers of NSG2?

3) Do nothing as the Grid inter-communication would handle this request?

In BIND, I would just create a slave zone of example.net on the NSG1 servers.  Unsure how the request would be handled in Infoblox.

[#5 · Accepted solution]

Infoblox doesn't automagically configure the resolution paths just because they are in the same grid, you still have to set up all the secondary/stub zones or forwarding, the name servers in NSG2 won't automatically resolve names in NSG1 unless you set up the relationships between them like you would in BIND. Remember this is all BIND under the hood, just with a nice UI on top.