DNS server updates and removes 2nd Host record of itself (it's Hamachi, software VPN, IP address)
Posted on 2008-06-23
I have a domain that has an SBS 2003 server as the PDC, we'll call this server "Server A" at "Site A". DNS server is running on Server A, as well as DHCP. Server A is also the Exchange server for the domain. The local area connection on Server A has a static IP and the only DNS server for the connection is itself. Everything DNS related for the workstations at Site A is working fine.
There is a 2003 Standard server, "Server B" on the domain at another location "Site B" hundreds of miles away from Site A. I was able to use Hamachi (software VPN connection) to connect the two sites. After many many hours of struggling, I was able to run dcpromo on Server B with it at Site B in order to make it an additional domain controller on the domain. In order to do so I had to manually create and populate the _msdcs.domain.local forward lookup zone in the DNS server on Server B. Before doing so the dcpromo wizard would fail because it could not find the Domain controller.
So I got that fixed up and got Server B promoted to domain controller. Active Directory and DNS both replicated to Server B successfully. I was then able to join the 2 workstations at Site B to the domain. Both of those workstations are also running Hamachi and are joined to the same Hamachi network as the domain controllers. One of the workstation's Outlook client keeps losing its connection to the Exchange server (Server A at Site A). When it does, I check the DNS server (on either server) and the Hamachi IP address of Server A (the Exchange server) is missing from the Forward Lookup Zone. I can manually add the Host Record of the Hamachi IP address of Server A and then the workstation is once again able to connect to the Exchange server.
Everything would be fine if the DNS server would quit removing the Host Record for Server A conatining the Hamachi IP address. It seems that it is now removing that record every 15 minutes or so. This is causing a lot of email downtime and a lot of frustration (for the user and myself).
Addditional info... When running properly the DNS server should have 2 Host Record for Server A, it's local IP and it's Hamachi IP. Server B has two Host Records, its local IP and its Hamachi IP and neither record has ever disappeared. All necessary Reverse Lookup Zones are created and PTRs are created. I've opened the LDAP port in the firewall at Site A. DNS event viewer shows the following 2 events just before the Host Record goes missing:
Event ID 4521
The DNS server encountered error 32 attempting to load zone 255.162.5.in-addr.arpa from Active Directory. The DNS server will attempt to load this zone again on the next timeout cycle. This can be caused by high Active Directory load and may be a transient condition.
Event ID 6702
DNS server has updated its own host (A) records. In order to ensure that its DS-integrated peer DNS servers are able to replicate with this server, an attempt was made to update them with the new records through dynamic update. An error was encountered during this update, the record data is the error code.
If this DNS server does not have any DS-integrated peers, then this error
should be ignored.
If this DNS server's Active Directory replication partners do not have the correct IP address(es) for this server, they will be unable to replicate with it.
To ensure proper replication:
1) Find this server's Active Directory replication partners that run the DNS server.
2) Open DnsManager and connect in turn to each of the replication partners.
3) On each server, check the host (A record) registration for THIS server.
4) Delete any A records that do NOT correspond to IP addresses of this server.
5) If there are no A records for this server, add at least one A record corresponding to an address on this server, that the replication partner can contact. (In other words, if there multiple IP addresses for this DNS server, add at least one that is on the same network as the Active Directory DNS server you are updating.)
6) Note, that is not necessary to update EVERY replication partner. It is only necessary that the records are fixed up on enough replication partners so that every server that replicates with this server will receive (through replication) the new data.