4

We're having an issue with DNS clients not being able to resolve certain FQDNs. Within the same domain in which the problem occurs, doing an nslookup against a host name works. However, an nslookup against the hostname.domain.parentdomain1.parentdomain2.net doesn't work. Weird, from outside that domain, the same FQDN query works. Clients in both domains are using the same DNS servers, which are in the "parentdomain1" example.

The nslookup comes back with:

Non-authoritative answer: Name: hostname.domain.parentdomain1.parentdomain2.net.parentdomain2.net Address: 209.62.20.188

So, the client is appending the "parentdomain2.net" twice.

Would appreciate any assistance.

sjw
  • 374
  • 1
  • 4
  • 9

2 Answers2

4

This is NXDOMAIN hijacking, revealing to you a harmless aspect of how DNS search suffixes work.

I'm going to guess that your DNS resolution is to a local device, which contains copies of your zones, then does recursive lookups for other zones off of an internet server (which is doing NXDOMAIN hijacking).

A client with a DNS search suffix will issue additional queries with the chunks of the suffix appended. If my system has a suffix list of, for instance, foo.domain.com then domain.com, and I do a lookup against a single-name host server, it'll execute the following queries, in order, until it finds something:

server.
server.foo.domain.com.
server.domain.com.

(the . at the end is to specify, in DNS terms, that it's relative to the root and nothing else)

Which is great, and makes perfect sense. If server doesn't exist at server., it'll be looked for at server.foo.domain.com. - if it doesn't exist, it keeps going; if it finds an answer, it'll stop.

Where it starts to look a little less normal is when you search for something that you're thinking is the FQDN - but DNS doesn't know that (unless you're doing an nslookup with the . at the end). So, if I search for server2.domain.com, it'll search like this:

server2.domain.com.
server2.domain.com.foo.domain.com.
server2.domain.com.domain.com.

Those last 2 make very little sense to you and me, but the resolver doesn't know any better, and needs to check.

Which brings us to what you're seeing. Your search suffix list probably looks something like this:

domain.parentdomain1.parentdomain2.net
parentdomain1.parentdomain2.net
parentdomain2.net

And, your recursive DNS servers probably contain a zone for parentdomain1.parentdomain2.net, but not for parentdomain2.net.

So, the query happens like this:

hostname.domain.parentdomain1.parentdomain2.net.

(NXDOMAIN response - you'll want to look into why that is happening if this is where this record is supposed to be)

hostname.domain.parentdomain1.parentdomain2.net.domain.parentdomain1.parentdomain2.net.

(Your name server likely has a zone for parentdomain1.parentdomain2.net, and throws another NXDOMAIN)

hostname.domain.parentdomain1.parentdomain2.net.parentdomain1.parentdomain2.net.

(same result as previous)

hostname.domain.parentdomain1.parentdomain2.net.parentdomain2.net.

(Now, your DNS server forwards the query to your upstream forwarders for lack of an authoritative zone. Your upstreams dutifully send back a false response, in a misguided attempt at getting some extra advertising revenue)

So! This is likely a simple issue with a record, which got a lot more confusion because of abusive practices by your ISP or whoever else runs that upstream DNS server. There's a lot of variables that I've made assumptions on above, but do some checking on how things are resolving for specific queries (with . on the end to eliminate the search suffix) and it should track pretty closely with how I've outlined it.

Shane Madden
  • 112,982
  • 12
  • 174
  • 248
  • It tracks exactly as you've outlined. With the debug=true option turned on in nslookup, the domain list is as you've described. Also, a trailing . on the fqdn does get a correct response back, bypassing the suffix searching. I'm at a loss as to where to go now though. The A record is in the correct zone, and can be looked up via a query to the hostname only, or as you've said by adding a trailing dot. What kind of issues could exist with the record itself do you think? Thanks again! – sjw Jun 29 '11 at 19:50
  • 1
    @user52692 My recommendation for the next step would be to try changing the DNS servers that you're forwarding requests to, to prevent the "bad" records from sneaking into your DNS server's cache (Google's public DNS servers are a good option), then clearing the lookup cache on your DNS server and clients - even if it does nothing to resolve the issue, it should simplify the picture to where it's a lot easier to troubleshoot. – Shane Madden Jun 29 '11 at 22:05
  • Important point, user52692: _By definition_ a (human readable form) domain name without a trailing `.` is not fully qualified, however many labels it has. **Multiple labels** _is not_ **fully qualified.** It's a commonly made error, but it is an error, and it's the error that leads to confusion in exactly this kind of situation. A human-readable form domain name is fully qualified _if it ends in a dot_. `server.` in M. Madden's answer here is a fully-qualified domain name, for example, despite having a single label. – JdeBP Jun 30 '11 at 12:46
-1

If you have windows users and they are in domains or somehow they are associated with fomain (example in wimax network nsp id or like this) when they send dns quesry they append their domain name to back of quesry. In linux /etc/resolv.conf if you have search directove this is same effect. So do not worry this is normal.

kamil babayev
  • 1