[HN Gopher] How to Use Dig
___________________________________________________________________
How to Use Dig
Author : mfrw
Score : 215 points
Date : 2021-12-04 15:17 UTC (7 hours ago)
(HTM) web link (jvns.ca)
(TXT) w3m dump (jvns.ca)
| cookiengineer wrote:
| 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.
| LinuxBender wrote:
| Those requests are most often used in combination with spoofed
| packets to DDoS others. Many of us block those requests.
| addingnumbers wrote:
| 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
| fanf2 wrote:
| 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.
| cookiengineer wrote:
| 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...
| tmsbrg wrote:
| 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.
| mrweasel wrote:
| 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.
| bspammer wrote:
| 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>
| dmarinus wrote:
| 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!
| fanf2 wrote:
| 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.
| colechristensen wrote:
| 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?
| johnchristopher wrote:
| Well, today I learned of `host`. Thanks !
| e12e wrote:
| 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...
| Denvercoder9 wrote:
| 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.
| ducktective wrote:
| Anyone knows how to get the public IP and geolocation with `dig`?
| Is there a free service that works with DNS resolvers via `dig`?
| brian_cunnie wrote:
| > 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]
| delta1 wrote:
| dog is a nice modern take on dig
|
| https://github.com/ogham/dog
| disintegrator wrote:
| Quite like using dog too
|
| https://github.com/ogham/dog
| FPGAhacker wrote:
| Missed an opportunity to call it dug [1]. Well, maybe not
| "missed."
|
| [1] https://en.m.wikipedia.org/wiki/Dig_Dug
| InvaderFizz wrote:
| > 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.
| kbrazil wrote:
| 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
| azundo wrote:
| > 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.
| emmelaich wrote:
| 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*?"
| kortex wrote:
| 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?
| kalev wrote:
| A blog post of what you describe would be greatly appreciated,
| i'll probably learn a thing or two from it.
| kortex wrote:
| Great idea, I'll take a stab at it!
| jvolkman wrote:
| I always assumed its output was supposed to resemble a zone
| file.
| kortex wrote:
| 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 //
| jvolkman wrote:
| Maybe the original creator was an Emacs fan? Lisp also uses
| semicolons for comments.
| detaro wrote:
| ; 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.
| fanf2 wrote:
| 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.
| silisili wrote:
| 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.
| istjohn wrote:
| 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.)_
| silisili wrote:
| 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.
| maximedupre wrote:
| 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.
| er4hn wrote:
| 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.
| js2 wrote:
| 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
| 1vuio0pswjnm7 wrote:
| http://cdn.netbsd.org/pub/NetBSD/NetBSD-release-9/src/usr.bi...
| formerly_proven wrote:
| 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?"
| da_chicken wrote:
| That's not really a dig problem.
| midasuni wrote:
| 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.
| nonsequitur wrote:
| You can directly query `getaddrinfo` with
| getent ahosts myhost
| indigodaddy wrote:
| Thanks for this. I've always wanted to know how to replicate
| how the OS is resolving.
| jamespwilliams wrote:
| TIL .digrc
| fanf2 wrote:
| Be warned that if you have any scripts using `dig` they might
| not be robust against changes in behaviour due to .digrc!
| sigjuice wrote:
| dig can also be used to make mDNS queries. dig -p
| 5353 @224.0.0.251 raspberrypi.local
| jodrellblank wrote:
| 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 https://www.isc.org/download/
| pdenton wrote:
| drill is a nice replacement for dig and it's packaged in most
| distros. Look for ldns
| krylon wrote:
| 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.
| amtamt wrote:
| also, drill helps with dnssec resolution, which I don't know if
| any recent dig version supports.
| ignoramous wrote:
| dig supports doh natively, now. dig +https
| @dns10.quad9.net fb.com MX
|
| https://www.isc.org/blogs/bind-doh-update-2021/
| jeffrallen wrote:
| Nslookup is better. Fight me.
| krylon wrote:
| Booo! _throws crumbled paper_
|
| (SCNR)
| LinuxBender wrote:
| 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...
| tptacek wrote:
| nslookup has the distinction of being perhaps the worst command
| line / terminal experience the Unix environment has to offer.
| indigodaddy wrote:
| 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?
| brian_cunnie wrote:
| 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.
| seanwilson wrote:
| 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.
| cjcampbell wrote:
| 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).
| toxik wrote:
| 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.
| jodrellblank wrote:
| 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.
| bityard wrote:
| Good security practices dictate that you don't reveal any
| information that you don't have to.
| monkaiju wrote:
| 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: https://github.com/unfrl/dug https://dug.unfrl.com
___________________________________________________________________
(page generated 2021-12-04 23:00 UTC)