...
For example, as shown in Figure 35.1, the A record for printer1.corpxyz.com is on both the Microsoft and Infoblox Grid member. On the Grid, the A record has extensible attributes and a comment. A Microsoft server admin changes the IP address of the A1 resource record from 10.1.1.2 to 10.1.1.3. On the Microsoft server, this is equivalent to deleting the A1 resource record with the IP address 10.1.1.2 and then adding a new A1 resource record with the IP address 10.1.1.3. When the data is synchronized, the Grid member deletes the original record with its extensible attributes and comments and creates a new A record with IP address 10.1.1.3.
Figure 35.1 | Drawio |
|---|
| border | true1 |
|---|
| viewerToolbar | true |
|---|
| fitWindow | falsebaseUrl | https://infoblox-docs.atlassian.net/wiki |
|---|
| diagramName | 35.1 |
|---|
| zoom | 1 |
|---|
| simpleViewer | false |
|---|
| widthpageId | 22252425 |
|---|
| custContentId | 7083505 |
|---|
| lbox | 1 |
|---|
| contentVer | 1 |
|---|
| revision | 1 |
|---|
|
- If a Microsoft server admin changes the IP address of a resource record and a Grid Manager admin changes the IP address of the same resource record, they are effectively deleting the record and each creating a new one.
For example, as shown in Figure 35.2, a Microsoft server admin changes the IP address of the A resource record for printer1.corpxyz.com from 10.1.1.2 to 10.1.1.3, and a Grid Manager admin changes the IP address of the same resource record to 10.1.1.4. When the data is synchronized, the Grid member deletes the A1 resource record with IP address 10.1.1.2 and creates an A resource record with IP address 10.1.1.3 and another A1 resource record with IP address 10.1.1.4.
Figure 35.2 | Drawio |
|---|
| border | true1 |
|---|
| viewerToolbar | true |
|---|
| fitWindow | falsebaseUrl | https://infoblox-docs.atlassian.net/wiki |
|---|
| diagramName | 35.2 |
|---|
| simpleViewer | false |
|---|
width | | zoom | 1 |
|---|
| pageId | 22252425 |
|---|
| custContentId | 7935738 |
|---|
| lbox | 1 |
|---|
| contentVer | 1 |
|---|
| revision | 1 |
|---|
|
- The Microsoft server does not allow the creation of arpa subzones as forward-mapping zones, similarly, the appliance restricts assigning arpa subzones (zone names ending with .arpa) to the Microsoft server.
- NIOS does not synchronize the top-level reverse-mapping zones (in-addr.arpa and ip6.arpa) created on the Microsoft server and the top-level reverse-mapping zones (in-addr.arpa and ip6.arpa) created on the NIOS appliance cannot be assigned to the Microsoft server.
- Grid members can synchronize classless IPv4 reverse-mapping zones from the Microsoft server to the Grid only if the zone prefix is in one of the following formats: <subnet>/<subnet mask bit count> or <subnet>-<subnet mask bit count> . For example, 128/26.2.0.192.in-addr.arpa. If the zone prefix is not in the specified format, the Grid member skips the zone and logs an error message. For information, see http://technet.microsoft.com/en-us/library/cc961414.aspx.
Likewise, Grid Manager admins can add a classless IPv4 reverse-mapping authoritative or stub zone to a Microsoft server only if its prefix is in the specified format.For information about configuring classless IPv4 reverse-mapping zones in Grid Manager, see Specifying an RFC 2317 Prefix.
...
