45

Can anyone tell me why this is happening? I can resolve a hostname using host and/or nslookup but forward lookups do not work with dig; reverse lookups do:

musashixxx@box:~$ host someserver someserver.somenet.internal has address 192.168.0.252 musashixxx@box:~$ host 192.168.0.252 252.0.168.192.in-addr.arpa domain name pointer someserver.somenet.internal. musashixxx@box:~$ nslookup someserver Server: 192.168.0.253 Address: 192.168.0.253#53 Name: someserver.somenet.internal Address: 192.168.0.252 musashixxx@box:~$ nslookup 192.168.0.252 Server: 192.168.0.253 Address: 192.168.0.253#53 252.0.168.192.in-addr.arpa name = someserver.somenet.internal. musashixxx@box:~$ dig someserver ; <<>> DiG 9.8.1-P1 <<>> someserver ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 55306 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;someserver. IN A ;; Query time: 0 msec ;; SERVER: 192.168.0.253#53(192.168.0.253) ;; WHEN: Wed Oct 3 15:47:38 2012 ;; MSG SIZE rcvd: 27 musashixxx@box:~$ dig -x 192.168.0.252 ; <<>> DiG 9.8.1-P1 <<>> -x 192.168.0.252 ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 28126 ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;252.0.168.192.in-addr.arpa. IN PTR ;; ANSWER SECTION: 252.0.168.192.in-addr.arpa. 3600 IN PTR someserver.somenet.internal. ;; Query time: 0 msec ;; SERVER: 192.168.0.253#53(192.168.0.253) ;; WHEN: Wed Oct 3 15:49:11 2012 ;; MSG SIZE rcvd: 86 

Here's what my resolv.conf looks like:

nameserver 192.168.0.253 search somenet.internal 

Is this behavior normal? Any thoughts?

7 Answers 7

69

It's the default behaviour of dig not to use the search-option.

From the manual page:

 +[no]search Use [do not use] the search list defined by the searchlist or domain directive in resolv.conf (if any). The search list is not used by default. 

Edit: Just add +search to make it work, like dig +search myhost.

2
  • 4
    Am I the only one who sees that as being a little counter-intuitive? :-) Anyway, thanks a lot! Commented Oct 3, 2012 at 22:03
  • 7
    @musashiXXX Well, it depends :-) Most people use dig for debugging DNS and in this case it's quite a good idea to disable everything which might mess up the answers from DNS. I think it's a pretty good idea; most people use host and nslookup after all. :-) Commented Oct 3, 2012 at 22:06
13

In my case, it is a bug in Microsoft DNS Server, where it returns FORMERR response (request format error) for requests with EDNS Cookie option set. Newer versions of dig (9.11 and up) use dns-cookies by default. This can be prevented by +nocookie or +noedns flag to dig:

$ dig +nocookie DOMAIN @SERVER 

Source: https://kevinlocke.name/bits/2017/01/20/formerr-from-microsoft-dns-server-for-dig/

7

I was having the same problem. After inspecting packets sent from both nslookup and dig with wireshark, I found the problem.

dig was setting the authentic data bit in the query. According to the man page, "This requests the server to return whether all of the answer and authority sections have all been validated as secure according to the security policy of the server." By running dig with +noadflag, it returned the same results as nslookup.

1
  • 3
    Had same issue, but different result was caused by edns extension. When I made query with +noends dig returned same result as host. Commented Nov 4, 2017 at 20:55
2

You can use a .digrc file in your home directory with the line

+search

to chance the default behaviour

0

Had the same issue on my Mac, Adding the ~/.digrc file as suggested by Slava Bacherikov fixed the issue

❯ cat ~/.digrc +noedns 
 rancher-desktop /tmp ❯ dig github.com +short 20.207.73.82 rancher-desktop /tmp ❯ mv ~/.digrc /tmp/ rancher-desktop /tmp ❯ dig github.com +short ; <<>> DiG 9.10.6 <<>> github.com +short ;; global options: +cmd ;; connection timed out; no servers could be reached rancher-desktop /tmp took 18s ❯ mv /tmp/.digrc ~/.digrc rancher-desktop /tmp ❯ dig github.com +short 20.207.73.82 rancher-desktop /tmp ❯ 
-1

I experienced this issue on my home wi-fi network trying to resolve good ol' google.com from within an Ubuntu VM running on a Windows 7 host, with dig, which timed out, but nslookup instantly returned the result.

The solution for me was to add +noedns: $ dig +noedns google.com.

-1

https://www.mankier.com/1/dig

+[no]search This option uses [or does not use] the search list defined by the searchlist or domain directive in resolv.conf, if any. The search list is not used by default. ndots from resolv.conf (default 1), which may be overridden by +ndots, determines whether the name is treated as relative and hence whether a search is eventually performed. 

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.