# Introduction Diagnostics using dig ## Goals * Become familiar with the use of dig * Interpret dig's output and identify some common DNS problems * Use dig to retrieve and examine DNSSEC resource records ## Notes * Commands preceded with "$" imply that you should execute the command as a general user - not as root. * Commands preceded with "#" imply that you should be working as root. * Commands with more specific command lines (e.g. "rtrX>" or "mysql>") imply that you are executing commands on remote equipment, or within another program. ## The dig Tool The tool "dig" was originally shipped with BIND and is commonly found on many Unix-like platforms. Other DNS implementations also include similar tools, often with similar names (e.g. [kdig](https://www.knot-dns.cz/docs/2.6/html/man_kdig.html)). Older tools used for DNS troubleshooting include [nslookup](https://man.openbsd.org/nslookup) and [host](https://man.openbsd.org/host). A manual page for dig [can be found here](https://bind9.readthedocs.io/en/latest/manpages.html#dig-dns-lookup-utility) or from the command-line. There are a lot of available parameters. You can ignore most of them while you are getting started. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ $ man dig ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ## Sending DNS Queries Using dig Try using dig to look up the address corresponding to the DNS name www.pir.org. Here are various ways of doing that; what differences do you see in the output from each of them? ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ $ dig www.pir.org A $ dig www.pir.org $ dig @8.8.8.8 www.pir.org A $ dig @1.1.1.1 www.pir.org A ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ## Requesting Authenticated Data How can you tell whether an answer has been validated using DNSSEC and is authentic? For example, what do the following tell you? ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ $ dig @8.8.8.8 www.pir.org A +dnssec $ dig te-labs.training A +dnssec $ dig @1.1.1.1 servfail.nl A +dnssec $ dig @1.1.1.1 servfail.nl A +dnssec +cd $ dig @8.8.8.8 servfail.nl A +dnssec $ dig @8.8.8.8 servfail.nl A +dnssec +cd ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ## Looking at DNSSEC Resource Records Remember that DNSKEY, DS, RRSIG, NSEC and NSEC3 are all regular DNS resource records and you can request them using the corresponding query types, e.g. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ $ dig . DNSKEY $ dig ORG DS $ dig PIR.ORG RRSIG ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Normal applications don't look for RRSIG or DS records that way, however. Signatures and delegation signer records are returned alongside the normal queries that are triggered by (e.g.) applications looking up addresses corresponding to names. You can simulate the kinds of queries that would be sent in response to an application trying to find an address for the name WWW.PIR.ORG. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ $ dig @F.ROOT-SERVERS.NET www.pir.org A +dnssec +norec $ dig @A0.ORG.AFILIAS-NST.INFO www.pir.org A +dnssec +norec $ dig @NS1.SEA1.AFILIAS-NST.INFO. www.pir.org A +dnssec +norec ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ What DNSSEC records did these queries obtain in the course of these three queries? Are they sufficient to validate the final response? If not, what is missing?