11

I was using this command to verify if I'd set things up correctly with a DNS provider:

host hostname.example.com ns1.example-nameserver.com

As far as I can tell, this asks ns1.example-nameserver.com to look up hostname.example.com and reports the answer. I was getting a host-not-found response so I thought I'd done it wrong. However, without specifying their name-server (thus allowing my ISP's name-server to look it up) I got the correct response (hostname is a CNAME if it matters). I couldn't fathom this so I searched around and found the dig command:

dig @ns1.example-nameserver.com hostname.example.com

As far as I can tell this does the same thing as the host command - asks a specific name-server to look up a host. I therefore conclude that they must do it differently somehow, and that caching name-servers must use the same method as dig.

My conclusion is either right or wrong, if it is right:

What is the difference between these two look-up methods?

If it is wrong:

What are my misunderstandings about DNS and the host and dig commands that have led me to this conclusion?

Example output:

$ host cardiff.tzmchapters.org ns1.livedns.co.uk
Using domain server:
Name: ns1.livedns.co.uk
Address: 213.171.192.250#53
Aliases: 

Host cardiff.tzmchapters.org not found: 3(NXDOMAIN)

$ dig @ns1.livedns.co.uk cardiff.tzmchapters.org

; <<>> DiG 9.8.3-P1 <<>> @ns1.livedns.co.uk cardiff.tzmchapters.org
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 23620
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 0
;; WARNING: recursion requested but not available

;; QUESTION SECTION:
;cardiff.tzmchapters.org.   IN  A

;; ANSWER SECTION:
cardiff.tzmchapters.org. 3600   IN  CNAME   ghs.google.com.

;; AUTHORITY SECTION:
google.com.     3600    IN  SOA ns1.livedns.co.uk. admin.google.com. 1354213742 10800 3600 604800 3600

;; Query time: 27 msec
;; SERVER: 213.171.192.250#53(213.171.192.250)
;; WHEN: Mon Apr 22 23:47:05 2013
;; MSG SIZE  rcvd: 128
|improve this question|||||
  • both commands should work the same way in this case. Can you show the complete output of each command? – Renan Apr 21 '13 at 1:01
  • Notice how both dig and host report NXDOMAIN. With dig you can see it in the header (5th non-blank line of the output) and with host it's more obvious. NXDOMAIN means the domain does not exist. Yet a CNAME is returned in the answer section! I do believe that's a bug in the DNS server! – Celada Apr 22 '13 at 23:03
  • So in that case, do dig and host both send the exact same query packet, get the exact same response packet (aside from any timestamps), but interpret it differently? Does host bail out as soon as it sees NXDOMAIN? – jhabbott Apr 23 '13 at 11:37
  • FWIW I have the exact opposite problem on a specific subdomain. Using host on this specific subdomain provides the expected record showing that this particular subdomain resolves to an expected canonical hostname. However, when using dig on this particular subdomain - I receive a response that the record does not exist. Additionally navigating to this subdomain with a browser does not work. I've tried multiple times, checking for spelling mistakes, etc. The commands are clearly NOT working in the same way. – user12345 Jun 17 '15 at 19:48
13

host, dig, and nslookup all share most of the same functionality. In the case you are asking about (asking a particular DNS question to a particular nameserver), dig and host (and indeed nslookup) behave exactly the same.

For DNS troubleshooting, dig is preferred because its output format is more "raw": in its output it directly shows the contents of all 4 fields in the DNS response: question, answer, authority, and additional sections (plus the flags in the header), and also it has more options. host, on the other hand, has a more user-friendly output format.

If you don't happen to need an option that one of the commands has and the others don't, or a piece of information that one of them outputs and the others don't, then it comes down to a matter of preference.

|improve this answer|||||
  • 2
    If they do the same thing on the network side (the actual query) how can I be getting host not found when using host but the correct answer when using dig? Even if the server is configured using a particular setting (either by choice or accident) to cause this, it must be able to differentiate the requests. – jhabbott Apr 22 '13 at 5:23
  • Nope! The two commands you give in your question are equivalent and they should produce the same answer! Are you sure that dig gave you an actual answer and not a record in the additional or authority section? As Renan suggests, it might help to show the output. – Celada Apr 22 '13 at 13:18
  • Ok, I've added some example output. I get the same result at home and at work. When I don't specify a name server to use and my ISP handles the query, host works fine. Please try it yourself and let me know the results. – jhabbott Apr 22 '13 at 22:53
  • Just reviewing this - The ISP eventually told me that their server was configured not to respond to direct client queries, only to other nameservers asking for information transfers - does dig query in a different way, like a nameserver would? – jhabbott Mar 6 '14 at 21:38
  • 1
    dig can do both regular questions (all types except AXFR) and zone transfers (type AXFR) but DNS operators usually restrict zone transfers to authorized slaves so you most probably want to use regular questions – Celada Mar 9 '14 at 21:50
0

If you're using the non-FQDN hostname, the results can be different because host will use the search domains in resolv.conf, whereas dig does not by default.

You have to use the +search option if you want dig to use resolv.conf (or add it to ~/.digrc).

For example:

$ host foo
foo.myfqdn.com has address 10.1.2.3

$ dig +short foo
# (no result)

$ dig +short +search foo
10.1.2.3
|improve this answer|||||

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.