Re: DNS Cache corruption?
- From: "infinitiguy" <derek@xxxxxxxx>
- Date: Mon, 2 Jun 2008 22:41:12 -0400
Sorry, You're right, after reading through.. it is a bit vague.
Currently in production we're using incognito DNS commander(dns and dhcp). It runs on solaris. There's two servers.. one here (10.65.6.2) and one in dublin (10.2.2.49). They work in pri/sec zones.
The plan is to remove those, and implement MSDNS, which we already have in place for our ionaglobal.com zone(for exchange). We just consolidated all of our NT4 domains to ionaglobal, so the next logical step is to get all of our workstations/servers that are using the old DNS to use the new DNS.
The plan will be to have two stub zones. One here(10.65.6.2 eventually) and one in dublin(10.2.2.49). These stub zones will point to the various DC's(4 in waltham, and 2 in dublin) for DNS. Overall there'll be 8 dns servers(2 stubs, and 6 DC's/DNS).
The reason that amer-dns1 is using secondary zones is I'm not cutting the entire company over to MSDNS in one swoop. I'm going to do waltham first, then dublin a few weeks later. I'd rather only break half the company if something goes wrong. The need for the secondaries will be to do local name resolution for the zones Dublin hosts, rather than setting up a bunch of zone forwards.. eventually all of the zones will be ADI zones, and the only zones that amer-dns1(stub server) will host.. will be stub zones.
We will have a single forest/single domain.
The use of the stub servers will be to allow the DNS server to be re-iped when it's time to go into production without having to promote/create a new DC that will inherit that IP.. none of the clients will be pointing to the other DNS servers so I figure the stub will be a constant, always on central point to distribute the load.
There will be a DNS/DC at each major location. That I'm not worried about yet.
re: firewall. We use a checkpoint firewall. I don't know if it supports EDNS0.. I know that there was a bug within our current DNS system where when dns caching was enabled dns would eventually crash, so that DNS admin just turned off caching... the product is full of bugs which is why we're moving off of it.
I guess the thing I just don't understand is what causes the behavior to happen. Why cnn.com? Why aol.com in my experience a month ago, and why when the cache is cleared does it work fine, and continue to work fine with the new cached record? Unfortunately I don't have details of the ttl's or anything for the buggy records since I had to clear the cache earlier today. Maybe the firewall thing is something to look into but I'm not sure if that's what's causing the woes.
Your DNS infrastructure description is a bit confusing and doesn't provide enough specific info.
Can you elaborate on what the following sentence means?"I've gotten internal IT on to my
DNS server, "
Are the "other" DNS servers, such as Amer-DNS1, domain controllers? If so, be careful to manually create a zone that is AD Integrated, especially if the zone is in the same Replication Scope the domain controller is part of.
Do you have one domain in one forest or a multi-domain forest?
Not sure why you are using stubs and secondaries, that is if these other DNS servers are truly domain controllers? It can lead to DNS issues.
Is there a DC at each location? If so, it would be beneficial for them to be DNS servers.
What type of firewall do you have? Maybe it doesn't support EDNS0. Check your documentation on how to enable it. Lack of EDNS0 support will lead to failed resolution of zone with large data, that is above 512 bytes. You can check if your firewall supports EDNS0. Use nslookup. Query for the sites you say you cannot resolve. Then change it to TCP (by using the set vc command). If it resolves, then it's an EDNS0 issue.
By legacy methods, DNS query traffic uses UDP. Now on the response side, if it is larger than 512 bytes, legacy method (non-EDNS0) will revert the response to TCP. If DNS supports EDNS0, which WIndows 2003 does, it believes there is no reason to revert, but then what happens is the firewall will block the traffic if it cannot support a DNS UDP response packet larger than 512 bytes.
If you have a PIX, the command is:
protocol fixup dns 1280
--
Regards,
Ace
This posting is provided "AS-IS" with no warranties or guarantees and
confers no rights.
Ace Fekay, MCSE 2003 & 2000, MCSA 2003 & 2000, MCSE+I, MCT,
MVP Microsoft MVP - Directory Services
Microsoft Certified Trainer
For urgent issues, you may want to contact Microsoft PSS directly. Please
check http://support.microsoft.com for regional support phone numbers.
Infinite Diversities in Infinite Combinations
.
- Follow-Ups:
- Re: DNS Cache corruption?
- From: Herb Martin
- Re: DNS Cache corruption?
- From: Ace Fekay [MVP]
- Re: DNS Cache corruption?
- References:
- DNS Cache corruption?
- From: infinitiguy
- Re: DNS Cache corruption?
- From: Ace Fekay [MVP]
- DNS Cache corruption?
- Prev by Date: Re: DNS Cache corruption?
- Next by Date: Re: DNS Cache corruption?
- Previous by thread: Re: DNS Cache corruption?
- Next by thread: Re: DNS Cache corruption?
- Index(es):
Relevant Pages
|