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.
 
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?
 
I've configured one replication partner on each server (that being the fsmo primary) and set them to push/pull, so they replicate both ways with the 'hub' and the hub replicates back out to all partners - correct?

WINS IP configuration sorted, own server address in the config as suggested (they were all in before).
 
Thanks for all your help thus far, much appreciatted!

This weekend I've reconfigured the WINS to have the fsmo primary push/pull to all other 4 WINS servers and each of those to only push/pull with the fsmo primary, the 'hub'. In addition I've removed all other IPs from the TCPIP settings on each WINS server.

I've setup scavenging on the entire DNS domain of No-refresh 5 + refresh 7 (12 days cycle) but the primary server is NOT enabled to scavenge. I've removed all other servers with the dnscmd to stop servers scavenging.

So in effect I should be doing the process of aging entries to then 'sanity check' the extract after 12 days looking for tombstoned entires etc as per the earlier article posted - I believe this is correct?

Now I have a problem, we have a reverse lookup zone for our remote users who dial-in via secure ID on our 'AppGate' appliance. The scavenge period was actually enabled and set to 1+1 days (not sure who did this) and the TTL is 45 minutes.

Yet last night I logged on remotely, obtained an IP in this range and the DNS entry never updated, it still listed 'my' IP under another machines name...

This is the problem I'm actually trying to fix and avoid, is my understanding of DNS wrong here because I expected DNS to update with my laptops information?
 
You must log in or register to reply here.
Back
Top Bottom