:ducks My first thought was that the secondary zone on SHAREPOINT would replicate the blackery.local secondary zone automatically to PARKSERV but it hasn't done so. EDIT: It almost has to be a firewall issue relating to the VPN .I tested AD replication between the two DCs (dcdiag /test:replications) and forced a replication through AD Sites and Services. I can ping all day long from BOALSBURG (blackberry.local) to PARKSERV (copper.local) but not the other way around.However, when I attempt to create the blackberry.local forward lookup zone on Parkserv I get to the "Master DNS Server" page of the wizard and after I enter the IP address of Boalsburg (192.168.251.1) it fails.It attempts to resolve/validate the DNS server, but the FQDN just gets resolved to the Netbios name BOALSBURG and under 'Validated' it just says 'A timeout has occurred' - WINS is enabled on the 2003 server and I assume that's why I'm at least getting something under FQDN.
The only events I see are Parkserv transferring an updated zone version for copper.local to Boalsburg and then I see the Boalburg server confirming that it updated the zone information for the copper.local domain - nothing about the blackberry.local domain.
I could not get rid of the entry in DNS even after deleting every instance of it from the copper.local domain, setting the interface to not register itself in DNS, making sure it wasn't set to respond to DNS requests, flushing the DNS cacehe and it would always come back.
Traffic was originating from the wrong IP address (192.168.1.50) instead of 192.168.250.3.
I would take any errors at this point just from a troubleshooting standpoint.
Also, I need to see why a secondary NIC IP that I deleted from the copper.local forward lookup zone and set the interface to not register in DNS still shows up in the secondary copper.local zone on the Boalsburg server after a successful zone transfer. I'm sure whatever it is, I'll get bit by it some day.