none
DNS not resolving some web addresses

    Question

  • Hi,

    This seems similar to an issue I had a couple months back where mx records were not resolving.  The fix for that was to change the way my firewall handled EDNS0, added a fixup protocol line to increase the dns max to 4096.

    Now I've found a web site, bls.gov, that I can't resolve.  Nothing seems to work, ping, tracert or nslookup.  However, if I change the DNS servers on my workstation to point directly to our ISP everything works fine.  So far this is the only web site I've found that I can't resolve.

    I'm running Windows 2008 R2 as my domain controller with DNS installed.  Any suggestions on how to troubleshoot this or what the problem might be?  My firewall is a Cisco PIX 515e.

    Thanks in advance,

    Linn

    Monday, October 18, 2010 2:38 PM

Answers

  • Hi Linn,

    I haven't tried Google's forwarders because Google does things a little differently than others with their nameservers and have read numerous complaints regarding them, so with all due respect to MrX's suggestions to use them, I shy away from them.

    I don't know how reliable your ISP's forwarders are. I'm assuming when you used nslookup setting the server to your ISP's, I assume you set that to one of the Forwarders you're using. If it works directly, then I can't see that EDNS0 being an issue.

    Although I wouldn't have set the PIX fixup to 4096, since the max it uses is 1280, but I don't think that setting it that high should be a factor. Besides, if using a Forwarder, the EDNS0 issue is a non-factor, since the query is not being resovled using the Hints, rather it's sending it to the Forwarder for resolution, bypassing any EDNS0 limitation, if there are any, if you know what I mean.

    If you want to try a different forwarder, many in the industry use the GTE nameservers, which are highly reliable. They are 4.2.2.2, 4.2.2.3, 4.2.2.4, etc. Try 4.2.2.2 and see if that helps. Don;t forget to clear the DNS server cache, as well as the workstation cache prior to testing it. If using nslookup, exit and open it again to clear its own internal cache (nslookup uses its own resolver service and not the local machine's).

    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.

    • Marked as answer by Tiger Li Tuesday, October 19, 2010 6:33 AM
    Monday, October 18, 2010 3:09 PM

All replies

  • Please make sure that your DNS server is forwarding unresolved DNS requests to your ISP DNS server (You may try to forward unresolved DNS resquests to 8.8.8.8 instead of your ISP DNS server).

     

     


    This posting is provided "AS IS" with no warranties or guarantees , and confers no rights.
    Monday, October 18, 2010 2:47 PM
  • Thanks for the quick response, Mr. X. 

    I do have two DNS IP Addresses configured as forwarders and use root hints is checked.  Both of these addresses are DNS servers at my ISP.  Is 8.8.8.8 the Google DNS?

    Linn

     

    Monday, October 18, 2010 2:53 PM
  • Hi Linn,

    I haven't tried Google's forwarders because Google does things a little differently than others with their nameservers and have read numerous complaints regarding them, so with all due respect to MrX's suggestions to use them, I shy away from them.

    I don't know how reliable your ISP's forwarders are. I'm assuming when you used nslookup setting the server to your ISP's, I assume you set that to one of the Forwarders you're using. If it works directly, then I can't see that EDNS0 being an issue.

    Although I wouldn't have set the PIX fixup to 4096, since the max it uses is 1280, but I don't think that setting it that high should be a factor. Besides, if using a Forwarder, the EDNS0 issue is a non-factor, since the query is not being resovled using the Hints, rather it's sending it to the Forwarder for resolution, bypassing any EDNS0 limitation, if there are any, if you know what I mean.

    If you want to try a different forwarder, many in the industry use the GTE nameservers, which are highly reliable. They are 4.2.2.2, 4.2.2.3, 4.2.2.4, etc. Try 4.2.2.2 and see if that helps. Don;t forget to clear the DNS server cache, as well as the workstation cache prior to testing it. If using nslookup, exit and open it again to clear its own internal cache (nslookup uses its own resolver service and not the local machine's).

    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.

    • Marked as answer by Tiger Li Tuesday, October 19, 2010 6:33 AM
    Monday, October 18, 2010 3:09 PM
  • Hi Ace,

    It's funny but I had 4.2.2.2 in my forwarders previously but removed it while resolving and testing the mx lookup issue before.  I added it back to the list, left it third in the list, cleared the server cache and my workstation cache and it now resolves the address and the web site. 

    Does this mean my ISPs DNS servers are not reliable?  How can I collect the necessary data to convince them that they have an issue?

    The PIX fixup setting of 4096 came from a Cisco KB article about the issue.  I was just following their suggestion.  That did seem to be the cure for the mx lookup issue.

    Yeah, I recall being told that Google tracks the useage of it's DNS servers and that just bothers me somehow.

    Thanks,

    Linn

    Monday, October 18, 2010 4:34 PM
  • Hi Linn,

    Possibly. You would have to test your ISP's DNS with nslookup using the -2d option while running a query. Sometimes if I find that simply changing the forwarder to a reliable one works, I won't bother testing. I would put it at the first of the list and simply remove the ISP's.

    Also, you have it as 3rd on the list? It may never get to the third unless the first two provide NULL (not NXDOMAIN) response. Read more on the Forwarder's algorithm and how it works with the clientside resolver, and how the timeouts (Forwarders and client side resolver waiting for a resolution) affect this and how it may never reach the third forwarder in my blog:

    DNS, WINS NetBIOS & 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 if you have multiple forwarders.
    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 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.

    Monday, October 18, 2010 5:08 PM