💾 Archived View for dioskouroi.xyz › thread › 29441333 captured on 2021-12-04 at 18:04:22. Gemini links have been rewritten to link to archived content
➡️ Next capture (2021-12-05)
-=-=-=-=-=-=-
________________________________________________________________________________
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:
while :; do ping -c 1 hostname; sleep 1; done
You can directly query `getaddrinfo` with
getent ahosts myhost
Thanks for this. I’ve always wanted to know how to replicate how the OS is resolving.
http://cdn.netbsd.org/pub/NetBSD/NetBSD-release-9/src/usr.bi...
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.
That's not really a dig problem.
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.
Related, CNAME is used casually in the opposite sense to it's expansion, "canonical name".
Also, in a hundred years there'll be people making up retronyms for .arpa.
"Uhm maybe it stands for *address reverse protocol association*?"
Not related to the post, but the owner of this blog also makes small CS zines that act as cheat sheets for common tools:
. They're small and cute and make good tech stocking stuffers.
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 9.16.20 <<>> -r jvns.ca
;; global options: +cmd
;; Got answer:
just try `host goo.gl 1.1.1.1` or `host -t ns google.com` -- it's the output you'd expect without all the verbosity.
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.
The comment you're replying to has an example of using a specific DNS server.
As for reverse lookups, it's as simple as host <ip-address>
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.
Dig is/was part of bind - and I believe it output is conformant with textual representation from the rfc(s):
https://datatracker.ietf.org/doc/html/rfc1035.html#section-5...
If you want dig to be less verbose add +short
It’s mostly just habit mixed with the difference in inconvenience being quite small
Also doesn’t host use the local nss stack while dig exclusively queries dns?
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.
Well, today I learned of `host`. Thanks !
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!
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?
I always assumed its output was supposed to resemble a zone file.
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.
Maybe the original creator was an Emacs fan? Lisp also uses semicolons for comments.
; is quite common in assembly as the comment marker. And zone files are old, so the // or # were not as standard as they are today.
A blog post of what you describe would be greatly appreciated, i’ll probably learn a thing or two from it.
Great idea, I'll take a stab at it!
Quite like using dog too
> 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 especially like that last part.
You can also convert dig output to JSON with jc. (I’m the author)
$ jc dig example.com | jq -r '.[].answer[].data'
93.184.216.34
https://github.com/kellyjonbrazil/jc
Missed an opportunity to call it dug [1]. Well, maybe not “missed.”
[1]
https://en.m.wikipedia.org/wiki/Dig_Dug
dig supports doh natively, now.
dig +https @dns10.quad9.net fb.com MX
https://www.isc.org/blogs/bind-doh-update-2021/
Nice article, I wish everyone, especially my devops guys, would learn to use dig. It's a lifesaver.
On tracing
So it’ll make about 20 DNS queries
Not sure about this part. Most domains will hit root, tld, x.tlds nameservers, and maybe one more. Most traces should only be 3 to 5 queries.
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.)_
Interesting! Just tested and saw the same. I had no idea it did that, and to be honest, also have no idea why it does. Thanks for the update.
Comparable PowerShell Resolve-DnsName commands, though it's not overall as capable:
Basic lookup against specific DNS server:
# dig @8.8.8.8 jvns.ca
PS C:\> Resolve-DnsName -Server 8.8.8.8 -Name jvns.ca
Name Type TTL Section IPAddress
---- ---- --- ------- ---------
jvns.ca AAAA 300 Answer 2606:4700:3031::ac43:b35a
jvns.ca AAAA 300 Answer 2606:4700:3033::6815:5bce
jvns.ca A 300 Answer 104.21.91.206
jvns.ca A 300 Answer 172.67.179.90
Lookup NS type only:
# dig ns jvns.ca
PS C:\> Resolve-DnsName -Name jvns.ca -Type NS
Name Type TTL Section NameHost
---- ---- --- ------- --------
jvns.ca NS 20944 Answer art.ns.cloudflare.com
jvns.ca NS 20944 Answer roxy.ns.cloudflare.com
or
PS C:\> Resolve-DnsName jvns.ca NS
Reverse lookup:
# dig -x 172.217.13.174
PS C:\> Resolve-DnsName -Server 8.8.8.8 -Name 172.217.13.174
Name Type TTL Section NameHost
---- ---- --- ------- --------
174.13.217.172.in-addr.arpa PTR 21600 Answer yul03s04-in-f14.1e100.net
Reverse lookup using PTR type (it will tab-complete through the available -Type options):
PS C:\> Resolve-DnsName -server 8.8.8.8 -Name 174.13.217.172.in-addr.arpa -Type PTR
Name Type TTL Section NameHost
---- ---- --- ------- --------
174.13.217.172.in-addr.arpa PTR 21131 Answer yul03s04-in-f14.1e100.net
The output isn't actually a text table, it's an array of objects, so it's easy to filter and extract data without text parsing:
PS C:\> resolve-dnsname google.com ns |% namehost
ns3.google.com
ns1.google.com
ns4.google.com
ns2.google.com
There's also `-TCPOnly`, `-NoRecursion`, `-NoHostsFile` and other options.
NB. you can get BIND for Windows, and therefore dig.exe for Windows, at
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.
[1]
https://www.forescout.com/blog/forescout-and-jsof-disclose-n...
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."
https://us-cert.cisa.gov/ncas/alerts/TA15-103A
Those requests are most often used in combination with spoofed packets to DDoS others. Many of us block those requests.
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).
This is called zone transfer and is generally not enabled for obvious reasons.
The protocol to look for is IXFR and I’m pretty sure dig does it.
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.
Good security practices dictate that you don't reveal any information that you don't have to.
dog is a nice modern take on dig
drill is a nice replacement for dig and it's packaged in most distros. Look for ldns
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.
also, drill helps with dnssec resolution, which I don't know if any recent dig version supports.
dig can also be used to make mDNS queries.
dig -p 5353 @224.0.0.251 raspberrypi.local
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.
Anyone knows how to get the public IP and geolocation with `dig`? Is there a free service that works with DNS resolvers via `dig`?
> how to get the public IP and geolocation with `dig`
Yup, I wrote a DNS server that does just that. So, to find your public IP, you'd type the following:
`dig @ns.sslip.io ip.sslip.io txt +short`
It'll return your public IP.
[removed comments about unrelated services]
TIL .digrc
Be warned that if you have any scripts using `dig` they might not be robust against changes in behaviour due to .digrc!
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.
Check it out:
Nslookup is better. Fight me.
I have a personal preference for `nslookup`, too. But I don't want to fight about it--different strokes for different folks.
My favorite thing about nslookup is it's clear which server it's querying to get its information.
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]
[1] -
https://unix.stackexchange.com/questions/93808/dig-vs-nslook...
nslookup has the distinction of being perhaps the worst command line / terminal experience the Unix environment has to offer.
So many old school SAs still use it though (it always astounds me).. even the old school Unix guys seem to.. I guess it’s been around the longest?
Booo! _throws crumbled paper_
(SCNR)