[Okta Webinar] Learn how to a build a cloud-first strategyRegister Now

  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 688
  • Last Modified:

DNS Resolution Failing on Certain Domains

Unable to resolve some rather well known web sites (e.g. tigerdirect.com) and this is rather amusing given the facts below.   Those that aren’t resolving is very limited thus far (only a handful).

We use Microsoft’s DNS service on a Windows Server 2008 R2 machine with Active Directory.  So to try and fix this, I first checked the DNS event log and didn’t see anything out of the ordinary.  I then tried simply restarting the DNS service without any improvement.  I then fired up nslookup on the AD/DNS machine and couldn’t resolve TigerDirect (TD) (request timed out).   I did this with a trace running on my Cisco PIX firewall and it showed a response coming back from a name server with a Format Error.  What’s interesting is that the query displayed by nslookup has no “additional record” part of the query.  However, the PIX trace shows an additional OPT-EDNS0 option added record.  It appears that the PIX is inserting this?!?!  And is this the reason the query is failing?  If I bypass my internal name server on nslookup and point to some external server, I can get TD to resolve and there’s no added record to the query in the PIX trace.

I then turned on DNS tracing and the event log said pretty much what nslookup said (no added record to the query).  However, it showed the query response as ServFail and it also had event codes 5504 in the event log (invalid domain name in the DNS packet was returned).  

What I also noticed is that the name servers being consulted were not the ones in the root list.  And what’s “amusing” (actually frustrating and bewildering) is that the name servers being consulted belong to an IP range owned by TigerDirect.  So why aren’t my root servers being consulted or has my DNS been hijacked or polluted? (or is my DNS understanding skewed?)
  • 2
  • 2
1 Solution
Paul MacDonaldDirector, Information SystemsCommented:
Is there a proxy server involved somewhere?  Specifically: Is there domain name filtering going on somewhere?
ejefferson213Author Commented:
Thanks for the rapid response.  

No proxy is in use or has ever been used and no domain filtering.
Paul MacDonaldDirector, Information SystemsCommented:
There's no evidence of poisoning?  You don't have a (fake) zone configured for Tiger Direct?
Chris DentPowerShell DeveloperCommented:
> However, the PIX trace shows an additional OPT-EDNS0 option added record

Outbound query? If so, your server will be adding it (EDNS is enabled by default).

> So why aren’t my root servers being consulted

They are, to get information about .com, but the root servers know nothing about the content of .com, and nothing at all about tigerdirect.com. As long as you use Root Hints you'll end up querying individual name servers for individual domains. If you don't want that behaviour, use Forwarders.

The most likely problem is that the response packet is too large and your PIX is dropping it (DNS packet inspection). Two ways you can test / prove that:

1. Disable EDNS:

dnscmd /Config /EnableEDnsProbes 0

2. Modify your PIX to allow larger packets:

You can either do this using the FixUp command (PIX IOS version 6.3.2 and below):

fixup protocol dns maximum-length 4096

Or by modifying the inspection policy on later versions:

policy-map type inspect dns preset_dns_map
  message-length maximum 4096

The value I've used here, 4096, is a reasonable one in a post-DNSSEC time.

ejefferson213Author Commented:
That was it!!! As soon as I disabled edns as you suggested, the problem disappeared.  BTW, I had previously set my firewall to accept larger packets (actually at 4096 as you suggested).  

I'll look into and the fowarders vs root hints a bit more.

Thanks so much for your help!!!!!

Featured Post

New Tabletop Appliances Blow Competitors Away!

WatchGuard’s new T15, T35 and T55 tabletop UTMs provide the highest-performing security inspection in their class, allowing users at small offices, home offices and distributed enterprises to experience blazing-fast Internet speeds without sacrificing enterprise-grade security.

  • 2
  • 2
Tackle projects and never again get stuck behind a technical roadblock.
Join Now