DNS and the importance of SoA?

Bleek

Bleek

Bleek

Soldato
Joined
7 May 2004
Posts
5,503
Location
Naked and afraid
Hi guys, we've got a long standing DNS issue whereby our records appear to out of date or delayed in their update. This is especially the case of remote workers who lose drive mappings and have issues connecting, our desktop and security team often have issues remoting the wrong computers etc.

Our setup is a single AD integrated domain and 42 domain controllers, all of which run DNS, WINS and DHCP.

We have 4 central DCs at our head office, the rest are remote offices/sites all connected through a Cisco WAN.

The problem I believe stems from the SoA on each DC, I was under the impression the SoA should be the SAME on ALL DNS servers i.e. the primary DNS server?

So for example if our primary DNS server was "server01" each and every other DNS server should reference "server01.domain.com" in their SoA, in their msdcs.

Is this correct?

As it stands, each of our DNS servers references itself in the SoA.
 
That says hardware though. :D

TBH I was in a little quandry where I should place this subject.
 
Edleake said:
Hi guys, we've got a long standing DNS issue whereby our records appear to out of date or delayed in their update. This is especially the case of remote workers who lose drive mappings and have issues connecting, our desktop and security team often have issues remoting the wrong computers etc.

Our setup is a single AD integrated domain and 42 domain controllers, all of which run DNS, WINS and DHCP.

We have 4 central DCs at our head office, the rest are remote offices/sites all connected through a Cisco WAN.

The problem I believe stems from the SoA on each DC, I was under the impression the SoA should be the SAME on ALL DNS servers i.e. the primary DNS server?

So for example if our primary DNS server was "server01" each and every other DNS server should reference "server01.domain.com" in their SoA, in their msdcs.

Is this correct?

As it stands, each of our DNS servers references itself in the SoA.
Click to expand...

Showing themselves in SoA when integrated in Active Directory is normal.

In Active Directory all DCs have a writeable copy of the domain information and replicate it between themselves.

In Primary/Secondary you have *one* Primary (SOA) and any number of secondaries.

The Primary (SOA) has a writeable master copy of the zone information, secondariess has a readable copy of the zone information.

In Active Directory Integrated all DNS servers have a writeable copy of the zone information and replicate it between themselves, make sure that your DNS severs are "ad integrated".... also make sure that EVERY DNS client is pointed to more than one DNS server for DNS name resolution. remember that a DNS server is also a DNS client.

In essence, shouldn't be a problem I don't think. Although you might want to investigate further, that's the extent of what I know/searched.
 
As mentioned above the best approach is to configure all DNS servers to use Active Directory integrated zones.


DNS servers running on domain controllers can store their zones in Active Directory. In this way, it is not necessary to configure a separate DNS replication topology that uses ordinary DNS zone transfers, because all zone data is replicated automatically by means of Active Directory replication. This simplifies the process of deploying DNS and provides the following advantages:

Multiple masters are created for DNS replication. Therefore:

Any domain controller in the domain running the DNS server service can write updates to the Active Directory–integrated zones for the domain name for which they are authoritative. A separate DNS zone transfer topology is not needed.

Secure dynamic updates are supported. Secure dynamic updates allow an administrator to control which computers update which names, and prevent unauthorized computers from overwriting existing names in DNS.

Windows Server 2003 DNS Active Directory stores zone data in application directory partitions. The domain partition was the only Active Directory storage option in Windows 2000 Server, and it is available in Windows Server 2003 DNS for backward compatibility. The following DNS-specific application directory partitions are created during Active Directory installation:

* A forest-wide application directory partition, called ForestDnsZones.
* Domain-wide application directory partitions for each domain in the forest, named DomainDnsZones.
 
WINS

I see you said WINS in your op.

Your main WINS hub should be the one that holds the PDC Emu fsmo role.
Also re wins all spoke replication partners should be set to replicate ONLY to the main hub WINS server.
Did i mention WINS ;) each WINS server should only have itself in the WINS tcpip properties if a WINS server cannot register its own services in WINS then you have bigger issues.

I only mention wins because i had exaclty the same issue across 7 regional offices and 300 branch sites whereby wins was replicating all over the place and name resolution was returning false values so had to rebuild the WINS databases properly this time.
 
I'll take a look at WINS, I didn't set it up myself so don't know how it's currently operating.

We currently don't have aging/scavenging set which I guess isn't a good thing? I was looking to turn this on or perhaps run a scheduled batch file running the 'dnscmd' on my FSMO master overnight, good/bad idea?
 
Ok that article was very helpful and it's clear we need to setup proper scavenging, however after taking an extract of DNS I have found a lot of our server entries are 'dynamic' and are time stamped.

With these servers never changing their address and therefore not updating DNS if we were to enable scavenging these servers would be wiped out including many DCs!

The problem is we can't work out why some are static and some are dynamic, a couple of new member servers that joined the domain recently are static (they have no time stamp and won't be aged/scavenged), how does AD/DNS distinguish between what needs to be static and never gets updated and what needs a timestamp to be eligable for scavenging?

Obviously when we're adding servers in the future we don't want to come across the problem of their DNS being wiped out after a week.
 
Rangler said:
I see you said WINS in your op.

Your main WINS hub should be the one that holds the PDC Emu fsmo role.
Also re wins all spoke replication partners should be set to replicate ONLY to the main hub WINS server.
Did i mention WINS ;) each WINS server should only have itself in the WINS tcpip properties if a WINS server cannot register its own services in WINS then you have bigger issues.

I only mention wins because i had exaclty the same issue across 7 regional offices and 300 branch sites whereby wins was replicating all over the place and name resolution was returning false values so had to rebuild the WINS databases properly this time.
Click to expand...

In our instance we have 4 WINS servers but they are ALL push/pull, should I change the 3 none fsmo servers to pull only?
 
WINS PUSH PULL

EDLEAKE you should have your main HUB wins server on the same box that holds the PDC Emu FSMO role.
Every other WINS server should ONLY replicate with the hub server and no-one else in PUSH/PULL.

Also in tspip entry for each wins server the primary wins address should be itself just like in DNS. Otherwise the wrong wins servers will be responsible for addresses they shouldnt hold.
 
You must log in or register to reply here.
Back
Top Bottom