browse
Overview
Using nslookup to check DNS query responses is commonly used in troubleshooting DNS issues. In some scenarios, queries may appear to return an extra level of a domain. For example, looking up sub.domain.com yields a query and answer for sub.domain.com.domain.com. What does this mean? Read on and find out.
Nslookup: Resolution algorithm differences
When querying DNS, one utility is ubiquitous across all modern operating systems: nslookup. While older and less capable than dig, Windows users are limited by default to nslookup. It is important to note that nslookup handles DNS differently than dig or the local system.
For a public query with no public wildcard:
nslookup:
- Query made for domain.com (nslookup domain.com)
- nslookup sends "domain.com.suffix" and checks for a response - NXDOMAIN
- nslookup sends "domain.com.secondsuffix" and checks for a response - NXDOMAIN
- nslookup sends "domain.com" and returns the response
System DNS or Dig
- Query made for domain.com (dig domain.com)
- dig or the system sends a DNS packet lookup up "domain.com" and returns the response
- If the above is non-existing, a DNS packet will be generated for "domain.com.suffix"
- If the above is non-existing, a DNS packet will be generated for "domain.com.secondsuffix"
Now, in a scenario where there is no local answer and only a public answer exists, this acts exactly the same. The only difference in the above scenario is if packets are captured, the nslookup scenario will be sending strange looking suffix appended queries.
For a public query where a DNS suffix has a public wildcard.
nslookup:
- Query made for domain.com (nslookup domain.com)
- nslookup sends "domain.com.suffix" and checks for a response - response is returned (suffix is a public wildcard domain). An answer is found for domain.com.suffix, no further queries are made.
System DNS or Dig
- Query made for domain.com (dig domain.com)
- dig or the system sends a DNS packet lookup up "domain.com" and returns the response for domain.com
As a result, nslookup may return a completely different DNS answer than users utilizing a computer's web browser, and may lead to perceived incorrect DNS responses. This may also lead to "double" appearances of domains should the queried DNS record match the computer's suffix list.
Working solution to use nslookup for public wildcard DNS search suffix domain
When querying DNS, apply a "." at the end of the query unless using nslookup to query a hostname. This will look up the exact query requested. "nslookup domain.com." will request only domain.com without suffixes first.
Appearance in Umbrella reporting
In certain scenarios, this behavior may be observable in Umbrella reports. Entries may appear such as "facebook.com.domain.local" or "google.com.domain.local" when this is occurring. In most cases, this is nslookup performing those local queries first. If your suffixes are not authoritative on the DNS zone, they may be forwarded to Umbrella rather than being returned NXDOMAIN by the local DNS server on network.
Special case: Umbrella roaming client
If your applied DNS search suffix domain is a public wildcard and also used internally, you may also observe the suffix-doubled behavior noted above. Queries for host.domain.com may appear as host.domain.com.domain.com in your reports (despite being on the internal domains list). If domain.com is a public wildcard, add "domain.com.domain.com" to your internal domains list to resolve any observed user impact.