1

When running dig you can specify a "server" (the DNS server you make query against), "domain" and "host". Since "host" is not optional, I'm guessing this is what you are trying to resolve. But you also can specify a "domain". I thought that may be if we take unix.stackexchange.com as an example, the "host" could be unix and the "domain" could be stackexchange.com, however dig stackexchange.com unix did not seem to retreive the dns records for unix.stackexchange.com.

The "host" and "domain" I'm referring to are what is listed in the help lines below.

(To clarify, I know that dig unix.stackexchange.com works, I'm asking about the meaning of "host" and "domain" in dig help lines)

$ dig -v DiG 9.16.44-Debian $ dig -h Usage: dig [@global-server] [domain] [q-type] [q-class] {q-opt} {global-d-opt} host [@local-server] {local-d-opt} [ host [@local-server] {local-d-opt} [...]] Where: domain is in the Domain Name System q-class is one of (in,hs,ch,...) [default: in] q-type is one of (a,any,mx,ns,soa,hinfo,axfr,txt,...) [default:a] (Use ixfr=version for type ixfr) q-opt is one of: -4 (use IPv4 query transport only) -6 (use IPv6 query transport only) -b address[#port] (bind to source address/port) -c class (specify query class) -f filename (batch mode) -k keyfile (specify tsig key file) -m (enable memory usage debugging) -p port (specify port number) -q name (specify query name) -r (do not read ~/.digrc) -t type (specify query type) -u (display times in usec instead of msec) -x dot-notation (shortcut for reverse lookups) -y [hmac:]name:key (specify named base64 tsig key) d-opt is of the form +keyword[=value], where keyword is: +[no]aaflag (Set AA flag in query (+[no]aaflag)) +[no]aaonly (Set AA flag in query (+[no]aaflag)) ... global d-opts and servers (before host name) affect all queries. local d-opts and servers (after host name) affect only that lookup. -h (print help and exit) -v (print version and exit)
Improve this question
2
  • Please put your full not-working command for debugging. dig stackexchange.com unix <my local DNS IP address> works just fine for me. Commented Dec 12, 2023 at 0:07
  • @davolfman I created a chat room to discuss further Commented Dec 12, 2023 at 1:15

2 Answers 2

Reset to default
1

I think this is just a bug in the description introduced by a refactoring done 23 years ago. The help text went from the grammatically correct:

"Usage: dig [@server] [domain] [q-type] [q-class] {q-opt} {d-opt}\n" "where: server,\n" " domain are in the Domain Name System\n"

to this (note how it still says "are in the Domain Name System", but now the subject is the singular "domain"):

"Usage: dig [@global-server] [domain] [q-type] [q-class] {q-opt}\n" " {global-d-opt} host [@local-server] {local-d-opt}\n" " [ host [@local-server] {local-d-opt} [...]]\n" "Where: domain are in the Domain Name System\n"

If you inspect the changes, you'll see that they are all almost entirely for changing how options are assigned (globally vs per-lookup), and the code for selecting the host/domain/name/whatever-you-call-it to be looked up is itself unchanged. It did not add any new domain vs host distinction in the parsing itself. I suppose the author of the commit got the terms mixed up as it seems they were also working on host at around the same time (and host used "hostname").

This change predates the dig(1) manpage itself, which came a few months later. The manpage avoids the "domain", "host" and "hostname" labels in favour of a fourth label "name", using the simpler [@server] ... [name] [type] [class] [queryopt...] format still seen there.

Improve this answer
1
  • I think you are spot on Commented Dec 12, 2023 at 8:19
-1

Dig's optional host argument is the name of a local computer you want to send the query to. It is not the "host" portion of a fully-qualified domain name. (I.e., not unix from unix.stackexchange.com). The domain argument is the name you want to look up. (I.e., unix.stackexchange.com)

So if your local DNS resolver computer is named "mydns", then a dig query for the addresses for the name unix.stackexchange.com would be:

dig unix.stackexchange.com mydns

although it's usually more like:

dig @mydns unix.stackexchange.com

Or, if you want dig to ask your computer's default resolver (which could be a process on the same computer), it can be as simple as:

dig unix.stackexchange.com

which for me returned:

% dig unix.stackexchange.com ; <<>> DiG 9.10.6 <<>> unix.stackexchange.com ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 34418 ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 512 ;; QUESTION SECTION: ;unix.stackexchange.com. IN A ;; ANSWER SECTION: unix.stackexchange.com. 300 IN A 172.64.144.30 unix.stackexchange.com. 300 IN A 104.18.43.226 ;; Query time: 25 msec ;; SERVER: 2001:558:feed::1#53(2001:558:feed::1) ;; WHEN: Mon Dec 11 23:17:58 PST 2023 ;; MSG SIZE rcvd: 83
Improve this answer
6
  • 1
    Do you have an example output for dig unix.stackexchange.com mydns? That's how nslookup does things and something like nslookup unix.stackexchange.com resolver1.opendns.com works fine, but I can't get dig unix.stackexchange.com resolver1.opendns.com to work like that (it just resolves both domains using my system's configured DNS server). Commented Dec 12, 2023 at 7:45
  • I just invoked dig @8.8.8.8 unix.stackexchange.com and it gave me pretty much the same output as the last part of my answer. The syntax with mydns as the last argument is non-standard and I don't know when/why you would use that syntax instead of the standard dig @server fqdn syntax. Commented Dec 12, 2023 at 7:49
  • I want to verify that this non-standard syntax works at all. Commented Dec 12, 2023 at 7:52
  • Notably dig unix.stackexchange.com mydns never worked and is not working for me as you describe it. It executes a query for unix.stackexchange.com and another one for mydns and is exactly what I'd expect it do. I think this answer is wrong, at least for dig based on <github.com/isc-projects/bind9>. You may have mixed it up with nslookup, which does work the way you described. Commented Dec 12, 2023 at 8:45
  • 1
    @SottoVoce the text from the question is not from the manpage, but from dig itself (with the -h option, for example). The relevant part of the text hasn't changed for 23 years, and for all of those 23 years, the manpage has had a different description which didn't mention such an argument. Commented Dec 12, 2023 at 16:28

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.