17

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
jhabbott
  • 291
  • 1
  • 3
  • 8
  • both commands should work the same way in this case. Can you show the complete output of each command? – Renan Apr 21 '13 at 01: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

2 Answers2

15

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.

Celada
  • 6,060
  • 1
  • 20
  • 17
  • 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 05: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](http://serverfault.com/users/108127/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 06 '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 09 '14 at 21:50
  • FYI to fellow non-DNS admins: `dig`’s output is based on the [zone file format](https://en.wikipedia.org/wiki/Zone_file). `;` starts a comment, and record columns are `name`, `ttl`, `record class`, `record type`, and [`record data`](https://tools.ietf.org/html/rfc1035#section-3.3). [BIND](https://www.isc.org/downloads/bind/), of which `dig` is a part, documents [zone files](http://ftp.isc.org/isc/bind9/9.10.2/doc/arm/Bv9ARM.ch06.html#id2598276) elsewhere and omits this info from `dig`’s [man page](http://ftp.isc.org/isc/bind9/9.10.2/doc/arm/man.dig.html). – duozmo Feb 18 '16 at 19:48
  • I'm getting much more info with `host`, like IPv6 records I couldn't get with `dig -6`: `dig @4.2.2.2 ehow.com; host -v ehow.com 4.2.2.2` – Pablo A Apr 07 '22 at 11:50
10

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
wisbucky
  • 969
  • 9
  • 9