locked
Server 2008 R2 RTM dns.exe high memory utilization

    Question

  • Dns.exe is consuming very large amounts of RAM. Built a couple of test virtual 2008 R2 servers and noticed a trend. The more logical cores the system has the more RAM dns.exe uses.  Single-core and dual-core both use about 80MB, quad-core uses around 157MB, and my physical server with 16 logical cores uses a whopping 606MB.  Any thoughts on what could be causing this?
    Monday, August 17, 2009 4:28 PM

Answers

  • I'm getting the exact same thing as HEQ.  This is R2 (the released build), upgraded on a stable build of 2008 RTM.  After the upgrade I've been having DNS issues.

    Only some domains are failing.  For example, google.com and a bunch of other sites work, but bing.com and microsoft.com don't.  Can't blame Microsoft for blocking the competition this time.  ;)

    If I change my DNS server (that the NIC uses) to another DNS server, it works perfectly.  I'm using 127.0.0.1 since this is a domain controller.

    What's even more odd is that if I ping from the command prompt, it resolves to the correct IP.  But, it fails in both IE and Chrome.  Event Viewer doesn't give any good clues except to give this message: "Name resolution for the name support.microsoft.com timed out after none of the configured DNS servers responded."

    I'm not using forwarders.  In fact, after the upgrade a forwarder appeared to have been added, but it said that it couldn't be resolved.  (Though I'm not positive what it was before the upgrade).  A test showed the recursive lookups are failing.  I removed the forwarder address and recursive lookups work in the DNS Monitoring tab.

    Any ideas?
    Friday, August 21, 2009 4:22 AM

All replies

  • I see the same issue, 8 proc using 305MB. Also noticed that some domains will not resolve while others will. Using DNS in Server 2008R2 AD does not seem to have any issues.

    Feature or Memory Leak?

    Even if it is a feature it does not explain why some domains do not resolve. When I check the DNS cache it appears it resolved the host but is not sending that on to the DNS clients.
    Tuesday, August 18, 2009 4:49 PM
  • Quick update - it appears when in a root hints configuration without any forwarders DNS still does not resolve some hosts in a AD DNS config or a stand alone config.
    • Edited by HEQ Tuesday, August 18, 2009 6:10 PM
    Tuesday, August 18, 2009 6:07 PM
  • I haven't had any resolution problems but I am using forwarders.  Strange thing about the memory utilization is that sometimes it doesn't happen only to reappear on the next reboot but more often than not dns.exe is using over 600MB of memory on my 16 core server.   When my 16 core server doesn't use over 600MB it only uses around 5MB like many 2003 and 2008 R1 servers.  The one single core DC running 2008 R2 uses over 80MB and it has never changed.  Any explanation to this behavior would be welcome.
    Tuesday, August 18, 2009 8:09 PM
  • I'm getting the exact same thing as HEQ.  This is R2 (the released build), upgraded on a stable build of 2008 RTM.  After the upgrade I've been having DNS issues.

    Only some domains are failing.  For example, google.com and a bunch of other sites work, but bing.com and microsoft.com don't.  Can't blame Microsoft for blocking the competition this time.  ;)

    If I change my DNS server (that the NIC uses) to another DNS server, it works perfectly.  I'm using 127.0.0.1 since this is a domain controller.

    What's even more odd is that if I ping from the command prompt, it resolves to the correct IP.  But, it fails in both IE and Chrome.  Event Viewer doesn't give any good clues except to give this message: "Name resolution for the name support.microsoft.com timed out after none of the configured DNS servers responded."

    I'm not using forwarders.  In fact, after the upgrade a forwarder appeared to have been added, but it said that it couldn't be resolved.  (Though I'm not positive what it was before the upgrade).  A test showed the recursive lookups are failing.  I removed the forwarder address and recursive lookups work in the DNS Monitoring tab.

    Any ideas?
    Friday, August 21, 2009 4:22 AM
  • Why was this OWScott's reply posted as an answer?

    Still pending a proper answer/resolution.
    Tuesday, September 01, 2009 3:59 PM
  • Yeah, I have not resolved this yet.  I spent another hour on it a couple nights ago but no luck so far.  It's really odd.  Why would the browser get a different DNS answer than a ping from the command prompt.  Some sites still don't work, while others work perfectly.
    Tuesday, September 01, 2009 5:14 PM
  • Ok, I finally sat down to figure this out.  From a network trace I was able to see that the DNS results returned from the Akamai DNS servers said "Response - Format error".  I then compared the DNS request to what it looked like on a working computer and noticed extra information made by the DNS server: "AdditionalRecord:  of type OPT on class Unknown DNSClass"

    After some searching I found that the OPT is tied with EDns which is a relatively new DNS protocol extension that is still coming of age.

    I'll save the long explanation and simply say that with R2 (fresh install or upgrade), EDns is enabled by default.  It wasn't enabled by default with WS08 RTM.  Additionally, it appears that many of the Akamai DNS servers get confused with EDns and completely fail.

    This shows that the web isn't ready for EDns yet.  More DNS providers will need to catch up and make sure they support it.  In theory, DNS providers are supposed to ignore the extra extensions, but apparently that isn't the case.

    The fix is easy, which is to disable EDns and wait another year or two until the rest of the Internet catches up and support EDns.

    Now that I know what search terms to use, I've found a couple other posts about this now too.  (search for 'EnableEDnsProbes')  Some people are starting to run into this, but I suspect that a more people will be affected in the coming months.

    The reason it appears to work with a ping but not in the browser is that the browser does a redirect in the background, so it did successfully find the original domain name, it just didn't follow it like the browser did.

    To disable EDns, you can do it from the command prompt, or by editing the registry.

    From the command prompt, no restart of DNS is required.  If from the registry, make sure to restart the DNS Server service.

    Command prompt:  dnscmd /config /EnableEDnsProbes 0

    Registry: HKLM\SYSTEM\CurrentControlSet\services\DNS\Parameters Create a DWORD called EnableEDnsProbes and set to 0
    • Proposed as answer by Jeff McLuckie Tuesday, September 15, 2009 9:33 PM
    Tuesday, September 15, 2009 8:44 PM
  • Thanks for the info. I will give this a try.

    Does anyone have an answer to the high memory utilization yet?
    Tuesday, September 15, 2009 9:35 PM
  • I can confirm that it also happens on as low as 4 cores Xeon Quad, memory consumption around 100MB which is crazy - it was nothing like that on the same machine with Windows Server 2008. R2 obviously changed it for worse. I am using forwarders.

    I can confirm OWSCott's solution works perfectly.
    Friday, October 16, 2009 10:13 AM
  • Has anyone been able to solve this?  My servers dns is using 605MB  this is just way to much
    Wednesday, October 21, 2009 2:21 AM
  • Has anyone been able to solve this?  My servers dns is using 605MB  this is just way to much

    I've been able to partly solve the problem by disabling EDNS probes like mentioned above.
    Wednesday, October 21, 2009 11:38 AM
  • I just checked 2 DNS servers I have running.  One is part of our core DNS for our network and it does recursive lookups. It hasn't been upgraded to R2 yet.  It's using 800MB.  So, even prior to R2 it seems like 600 - 800 is normal.  There is a lot of caching that DNS needs to do to perform well. 

    I can't say I've looked into seeing if you can increase the frequency that DNS cleans stale records and such.

    On another DNS server, also pre-R2, it only uses 70MB, but it doesn't support forwards.  It's used for authorative DNS zones only.  So from this small sample, it appears that the forward lookups are what use the memory, and this is pre-R2.
    Wednesday, October 21, 2009 1:02 PM
  • I'm having the same exact problems with my DNS server. I've got a little home server that I've put together using an Atom 330 dual core processor. The server is only setup as a DC/DHCP/file server and provides DNS for the entire network of maybe about 10 devices.

    It's currently using 158MB of RAM, whereas I have another server running Server 2008 SP2 that's only using 25MB of RAM at the moment. They're both using forwarders, too. It's crazy how much memory it's taking up.

    I've had a few issues where DNS will not resolve in IE as well. It seems to happen mostly on Facebook and only for intervals of a couple of minutes...I've disabled EDns per OWScott's suggestion as well.
    Tuesday, October 27, 2009 6:30 AM
  • Hi,

    I have exactly the same Problem. I´m also running Windows 2008 R2 x64 Standard and my DNS-Server Process uses about 320 MB Memory.

    My Server is configured as an AD DC and the DNS-Server is also used as a forwarder for my internet connection.

    On all my other W2k3 Servers, the DNS-Process only uses about 25-30 MB Memory.

    So what sould I do?

    Thx Sebi

    P.S.:
    My Server:
    Windows 2008 R2 Standard German
    Intel Core i7 860 (4 Cores, each with Hyperthreading, 8 Cores in Taskmanager)
    Intel Board DP55WG
    8GB Memory
    3Ware 9650 SATA-Controller (8 Ports with 8x WD 1.5TB Hdd RAID 6)
    Tuesday, November 17, 2009 9:25 AM
  • I believe what everyone is seeing with DNS memory is due to the reserved UDP ports the DNS cache vulnerability update (originally released in July, 2008) is causing. This is by default to protect DNS cache poisoning.

    I put together a blog explaining the update and the consequences of memory  utilization. My blog can be found in the following link.

    The DNS Cache Poisoning Vulnerability, Microsoft KB953230 Patch, and Ports Reservation Explained
    http://msmvps.com/blogs/acefekay/archive/2009/09/03/the-dns-cache-poisoning-vulnerability-microsoft-kb953230-patch-and-ports-reservation-explained.aspx

    Also, regarding EDNS0, you don't have to disable EDNS0 on the DNS server. The EDNS0 extensions have been around since 1998, and first implemented in Windows 2003. So it's been around for quite some time. The problem is not Windows supporting EDNS0, is the network edge firewall does not support it, possibly either because it is an older firewall that hasn't been updated, or a newer one that EDNS0 has not been enabled.

    The *fix* is simply to update the edge router/firewall with the vendor's latest IOS to handle EDNS0. Consult your vendor's firewall documentation on how to do that.

    The workaround is also to simply use a forwarder to an ISP's DNS server that does support EDNS0. I saw one poster earlier explain that forwarding didn't work. Apparently the forwarder used in that scenario doesn't support EDNS0.

    Also, I suggest to not use the loopback for a DNS address on a DC. Use the actual IP.

    I hope this helps.

    Ace


    Ace Fekay, MVP, MCT, MCITP EA, MCTS Windows 2008 & Exchange 2007, MCSE & MCSA 2003/2000, MCSA Messaging 2003 Microsoft Certified Trainer Microsoft MVP - Directory Services This posting is provided AS-IS with no warranties or guarantees and confers no rights.
    Wednesday, January 20, 2010 1:39 PM
  • Also, I suggest to not use the loopback for a DNS address on a DC. Use the actual IP.

    Any particular reason for this, Ace?
    Brian Day, Overall Exchange & AD Geek
    MCSA 2000/2003, CCNA
    MCTS: Microsoft Exchange Server 2010 Configuration
    LMNOP
    Wednesday, January 20, 2010 4:57 PM
  • Hi Brian,

    Actually, it's not really a big deal. It can cause DNS tests, dcdiags and netdiags to fail, as well as nslookup to get that annoying 'can't find server..." message. Some look at it as an error, but it's just a message stating that it cannot find a PTR entry for the DNS server nslookup is using, which in this case is the loopback.

    However, seeing the loopback tells me that the adminstrator ran dcpromo on this server and allowed the promotion process create the DNS entry and never changed it. If going by the best practices guidelines that you should have a minimal of two DCs per domain (no matter if one domain or a multi-domain forest, as well as what many engineers recommend when it comes to DNS settings in NIC properties, is to point the first entry to the DC itself, and to a partner DC either in the same site, or at another AD site with a fast link.

    Other than the annoying nslookup message that scares many, there is no 'right" or "wrong" with using the loopback. I like to look at it as following administrative followup after a DC promotion to properly set itself to its own IP instead of the loopback. As I said, it just tells me the admin prmoted the machine and didn't follow through with other tasks after the promotion, which involves insuring all SRV and the LdapIpAddress records are properly registered in the zone, etc.
    This also stems back to the Windows 2000 days when dcpromo will do the same, but when RRAS was installed on the DC (not a recommended configuration anyway because a multihomed DC is extremely problematic), it will give RRAS clients the loopback as their DNS address. There was a KB that addressed this:

    RAS Clients Receive 127.0.0.1 for DNS Server Address
    http://support.microsoft.com/kb/254715

    Back in the Windows 2000 days as well, dcpromo will configure a Root zone in DNS if the DC was not connected to the internet. This caused much concern because a Root zone causes the DC to not recurse outside requests and grayed out the Forwarders tab. Something else that needed following up after a promotion.

    These are just little things that I look for to correct or straighten out. Like I said, no big deal, it's just a recommendation to point it to itself and a replica DC as the second entry. If you leave it, that's fine too, but be aware that when you run tests against your DCs and domains, it will generate numerous errors.

    I hope that helps.

    Ace


    Ace Fekay, MVP, MCT, MCITP EA, MCTS Windows 2008 & Exchange 2007, MCSE & MCSA 2003/2000, MCSA Messaging 2003 Microsoft Certified Trainer Microsoft MVP - Directory Services This posting is provided AS-IS with no warranties or guarantees and confers no rights.
    Wednesday, January 20, 2010 6:29 PM
  • Thanks for going into detail, Ace. We've actually changed a lot of DCs from their IP as the 1st entry (with other DCs as 2nd/3rd) to their loopback address, hah! :) Perhaps we'll rethink this and consider going back to the normal DC IP address after seeing what you have brought up.


    -brian
    Brian Day, Overall Exchange & AD Geek
    MCSA 2000/2003, CCNA
    MCTS: Microsoft Exchange Server 2010 Configuration
    LMNOP
    Wednesday, January 20, 2010 6:32 PM
  • Hi Brian,

    Yea, the general consensus among engineers is to have its own IP as first, and a replica DC as second. No use putting a third one in. Due to the client side resolver algorithm works, it may never ever see the third entry. If the first response is NULL (meaning no response), will it go the next. If the first responds with an NXDOMAIN, meaning it doesn't have an answer, well to the resolver, that is an answer and won't go further. Kind of crazy, some would say, but it's based on RFC2308.

    I have a blog on how the resolver algorithm works that goes into detail. Check it out. I hope you find it useful.

    DNS, WINS & the Client Side Resolver, NetBIOS, Browser Service, Disabling NetBIOS, Direct Hosted SMB (DirectSMB), If One DC is Down, Does a Client logon to Another DC, and DNS Forwarders Algorithm:
    http://msmvps.com/blogs/acefekay/archive/2009/11/29/dns-wins-netbios-amp-the-client-side-resolver-browser-service-disabling-netbios-direct-hosted-smb-directsmb-if-one-dc-is-down-does-a-client-logon-to-another-dc-and-dns-forwarders-algorithm.aspx

    Ace


    Ace Fekay, MVP, MCT, MCITP EA, MCTS Windows 2008 & Exchange 2007, MCSE & MCSA 2003/2000, MCSA Messaging 2003 Microsoft Certified Trainer Microsoft MVP - Directory Services This posting is provided AS-IS with no warranties or guarantees and confers no rights.
    Wednesday, January 20, 2010 7:20 PM