It's worth noting that dig (and host) bypass the normal DNS resolution mechanism used by most programs on the host. i.e. These tools aren't using getaddrinfo/gethostbyname.
Sometimes, I want to see the results from getaddrinfo, which are impacted by caching on the host itself and/or OS-specific configuration settings that dig and host know nothing about. (scutil --dns on macOS, systemd-resolvedand nscd on Linux, etc.)
In that case, I usually use ping. e.g., waiting for a DNS change to propagate to a host, I might use:
This has confused me before when trying to lookup mDNS/avahi/.local names. You can't use dig, host etc. to look them up because the answer doesn't come from a DNS server, but you can ping them.
If you have a particularly bad ISP or are on a controlled network, dig might not use the specified DNS server because the network is intercepting outgoing DNS traffic.
Edit: It's not necessarily something to be worried about, just that "strange results" may occur if unaware. E.g. "why and how does 8.8.8.8 resolve a domain-local host?"
If you’re concerned about network interception and lack the ability to have a trusted ISP, then WireGuard your connection to a trusted endpoint (you should probably route everything over it). Normally you’d want your devices to use your pi hope so you can block malicious traffic (adverts, trackers etc) from all your devices.
Dig is great and DNS is hella underrated. It seems like not nearly enough folks know how to wield it. At both $lastco and $thisco people just used a mess of configuration to point to service IPs/URIs. I showed them how to set private zones and records for both A and SRV and suddenly everything is just using sane defaults.
Side note: does anyone know why dig's output is so...eye-bleeding? Why does it show so much info by default? +short should be the default. Why the ;; "comment" prefix?
Ahhh yup, that makes perfect sense given how zone files are formatted.
But that moves the question. Why do zone files use ; as comment? Some old assembly dialect? I've not worked much with assembly but it's always been # or //
The original DNS implementation (called JEEVES) was written by Paul Mockapetris to run on the PDP-10, which is why the zone file syntax is not very unixy. The ; comments are one example: and backslash escapes are decimal rather than octal, line continuation uses () instead of escaping.
I never really got why people use `dig`. Its interface and output is awkward, and it seems all of its functionality can be more easily performed with `host`, which doesn't feel the need to print stuff like:
Dig gives more information, such as TTL and the resolving server. If you also want that information from host, you need to use the `-v` flag, at which point the output is almost as verbose as that from dig.
I have the reverse opinion. Why do people keep insisting on using host, when dig does the same (if not more) and while being so easy to use.
Most of my co-worker prefer host, but continue to be supprised when I use dig and features like reverse lookup or dig @some-dns-server. I’m sure that host can do the same, but few seems to know how.
> host is a simple utility for performing DNS lookups. It is normally used to convert names to IP addresses and vice versa. When no arguments or options are given, host prints a short summary of its command-line arguments and options.
> dig is a flexible tool for interrogating DNS name servers. It performs DNS lookups and displays the answers that are returned from the name server(s) that were queried. Most DNS administrators use dig to troubleshoot DNS problems because of its flexibility, ease of use, and clarity of output. Other lookup tools tend to have less functionality than dig.
> all of its functionality can be more easily performed with `host`
I've seen far too many junior admins accidentally change the hostname of a server when checking a DNS record...
Dig is verbose by default, which is usually what I want. It can be made as terse as host with the +short option. host -vt SOA google.com is more typing than dig google.com SOA. Neither dig or host is very good for use by other programs.
dig allows you to control things like retries and timeouts, choice of udp or tcp, choice of opcode (if you want to synthesise a NOTIFY message, say); it shows you the flags and the authority section so you can debug referrals, and the various EDNS options in case those matter.
If you just want the answer then `host` is just fine - I use both of them a lot - but `dig` really shines when you need to get into the guts of the DNS.
What I've noticed is that people like the name of "dig". It has some advantages though (not described in this tutorial) like tracing and setting the DNS TTL but those are really edge cases. Host is indeed much more convenient!
> By the way: if you’ve ever wondered what IN means, it’s the “query class” and stands for “internet”. It’s basically just a relic from the 80s and 90s when there were other networks competing with the internet like “chaosnet”.
Reading things like this makes me feel better about the relics in my code that aren't really hurting anything but would take work to remove.
> dog is a command-line DNS client, like dig. It has colourful output, understands normal command-line argument syntax, supports the DNS-over-TLS and DNS-over-HTTPS protocols, and can emit JSON.
I wish the DNS RFC had included a MUST support for ANY requests on the server side, and wildcard domain support (e.g. ANY for label *.domain.tld).
That would have made life so much easier. The state now is that clients cannot even rely on multiple request questions to be answered correctly...and is the reason why every Browser sends out separate DNS questions for A and AAAA and TXT etc.
All the overhead for parsing message compression is also kinda useless when you have only one record with the same labels answered all the time.
QTYPE=ANY has very tricky interaction with caches. The standard semantics are that ANY means whatever the server has, not all the types at the qname. So, if you have a mixture of v4-only and dual stack clients, you can’t predict whether the cache will have just A or both A and AAAA, so ANY will be worse than just making both queries concurrently.
And because ANY interacts badly with UDP fragmentation and certain backend database design, and because it has been abused for DDoS attacks, it is increasingly common for it to return a subset of the records that the server has.
So I am afraid there is no realistic way to make ANY mean ALL.
Multiple questions don’t work because DNS packets only have one RCODE so there is no way to signal a mixture of success and failure. I don’t know why the DNS message format has a QDCOUNT field for multiple questions.
Yeah DNS compression is problematic in many ways, but in many cases it allows the answer name(s) to be represented by 0x000C. In another context, the root-servers.net domain looks unnecessarily verbose but having all the servers in the same domain makes good use of compression.
Multiple questions inside the same packet are quite common in DNS-SD based multicast queries.
The idea there is to save DNS packets so that you only ask for a pointer (PTR) to a service identifier and get as a response all information that you need (address via A/AAAA, hostname and port via SRV, API version and necessary parameters via TXT etc).
My point was exactly about the QDCOUNT field because its intent clearly was to be able to save unnecessary packets, but in practice, nobody uses it and wastes a lot of bandwidth. Note that technically, servers have to support TCP via port 53, too...but they never actually do :)
As a sidenote: 0x0c is only appearing because it's the start of the label identifier of the first question. This can be a byte pointer to anything, and, if labels of records are crafted maliciously, even lead to an infinite loop or buffer overflow on clients/resolvers with naive implementations (see NAMEWRECK vulnerability [1]).
Regarding the ANY problem and why it's disabled: I think this is the wrong point in the architecture to fix DDoS or amplification attacks and the abuse of a public resolver. ISPs or ASNs could simply block UDP traffic which has a different source/target network. That alone would reduce most of the DDoS traffic and probably fix most of the abuse.
I mean, at some point you have to wonder: What happens when hackers start to use TXT queries to DDoS a target because their buffer size is larger, too? Just disable TXT? I hope you understand my point.
A DNS server could also always block via a throttling mechanism or increase the TTL to limit the bandwidth to a specific target, additionally to the comparison of source/target addresses. If someone with a different origin keeps requesting DNS queries, you can likely assume that it's an amplification attack...there are literally dozens of ways to fix this in a better way than disabling ANY completely.
Sounds similar to AXFR queries, which it is best practice to disable. It's not advisable in general to provide information about hosts that the querier didn't request specifically and individually.
"A remote unauthenticated user may observe internal network structure, learning information useful for other directed attacks."
Maybe she just edited it, but actually it's 30 DNS queries. 26 of them are to the 13 root nameservers.
> So it’ll make about 30 DNS queries. (I checked using tcpdump, it seems to make 2 queries to get A/AAAA records for each of the root nameservers so that’s already 26 queries. I’m not really sure why it does this because it should already have those IPs hardcoded, but it does.)
Not related to the post, but the owner of this blog also makes small CS zines that act as cheat sheets for common tools: https://wizardzines.com/ . They're small and cute and make good tech stocking stuffers.
Is there a simple way to list all A, CNAME, TXT etc. records for all subdomains of a domain from the terminal? Like what you would see in the web interface for your domain registrar? There's lots of free and simple web services that do this to check if your DNS settings have propagated worldwide. I usually just use one of those because DNS changes and checks aren't something I do often enough to remember the terminal commands for.
Some resolvers will respond to the ANY type query, e.g., dig any …. This may not work with your default name server though, so look up some different servers to test. It’s common to disable this feature due to avoid it being abused as an amplifier for DDoS attacks (spoof a small query, get a large response sent to victim).
Apparently not obvious, or they wouldn't be asking.
DNS is public data, what harm can come from asking for all of it? It doesn't leak any secrets, it doesn't take a lot of bandwidth or server load, it doesn't give you any power to imitate the domain, and it's nothing you couldn't find by brute-force eventually.
It might speed up some recon "what does this company have?" but DNS caches the world over will know what the company has as soon as users reference it. For all anyone knows they could be malicious DNS caches selling the information behind the scenes. Don't put secrets in public DNS records.
Dynamic responses make transfers difficult to implement in some server architectures. Which is not to take away from your point - trying to hide things in the DNS is a fairly pointless exercise.
IXFR is for incremental transfers in which the client asks for a series of diffs between a particular serial and the current one. AXFR requests a transfer of the full zone. dig supports supports both.
It's been a long time, but ~10ish years ago, I was doing something DNS-heavy in C, and ldns was a pleasure to use after being spoiled by Perl's Net::DNS. I think the ldns API was in fact built to resemble Net::DNS.
Either way, it was a pleasure to use. And if you know dig, drill will feel very familiar.
Shameless plug:
I love dig but never liked that I couldn't easily use it to monitor DNS propagation. To a single host sure, but to actually see changes propagate over regions its not easy.
To solve this I wrote dug. It's similar to dig, albeit less powerful for info about single hosts, but is specifically designed to monitor large numbers of servers and to 'watch' DNS propagation.
What about the good old nslookup? Or it is no longer good, just old?
P.S. apparently, nslookup uses its internal resolver, instead of the system's (as dig does). Thus it has been deprecated for some time to avoid confusion [1]. Not sure if anything has changed since.
That's super useful. Every time I'm setting up subdomains or playing with Cloudflare settings, I'm always so confused. This will help when I need to use dig.
In one sense, No. This question is effectively equivalent to questions like "Is there a way to find out everybody who likes cheese?". You're going to need to ask everybody, which is not practical.
However, you can get fairly close, at some expense. You need "passive DNS" which is a product aggregated from large DNS services containing the set of DNS questions and answers they saw over some period (but not who asked the question)
If you can afford to buy this, you can process that data (or your service provider might offer a neat database query that can do it) to find all the A questions whose answer was some particular dotted quad in some period (e.g. last 7 days). Since it's apparently a market research question you likely have a budget and will find this affordable. If it's "market research" only in the sense that somebody in your sales department was idly wondering, well, the answer is they need to pay $$$ to somebody.
I have to do something similar to this at work to find out if people are still using thousands of AWS ELBs. The only way I found was to find the DNS guy and ask him for a CNAME extract from our external DNS provider.
There was a time I would have suggested not using nslookup due to its maintainers saying it would be deprecated. They have since rolled back that decision. [1]
Sometimes, I want to see the results from getaddrinfo, which are impacted by caching on the host itself and/or OS-specific configuration settings that dig and host know nothing about. (scutil --dns on macOS, systemd-resolvedand nscd on Linux, etc.)
In that case, I usually use ping. e.g., waiting for a DNS change to propagate to a host, I might use: