Dig for dummies
Explaining an highly useful network tool
When you're building websites, apps or email services you may run into domain names and their configurations. When everything is working as it should, most of this is invisible. But when troubleshooting a domain name configuration, it may be necessary to dig a little deeper... read along to learn how!
Domain Name System (DNS)
The internet works using numerical internet protocol (IP) addresses as means to locate and to identify online computers, (cloud)services and devices. Instead of memorising all these IP-addresses, the domain name system has become the essential world wide directory service, linking names to numbers.
You're reading this on willem.com, but in reality this domain name is simply a pointer for a physical machine, connected to the internet (with wires, really!). One of those wires is linked to IP-address 188.8.131.52. It's the responsibility of the DNS server to keep the correct (IP-address) numbers matching to the (domain) names.
Distributed and decentralised
When the Americans designed their ARPANET in the early seventies, one of their military design requirements was that the network would survive attacks (by enemies). They accomplished this by implementing packet switching, a way to share and reuse network cables by multiple people in multiple ways. If one part of the network gets damaged, packets of information are rerouted over other parts of the network.
To achieve maximum survivability, there is no single root DNS server. Instead, the domain name system delegates responsibility of assigning domain names and mappings to those names by designating an authoritative name server for each domain name.
This is why there are many different DNS-servers and configurations. With so many ways and places that things can go wrong, you need a tool to dig around.
dig (domain information groper)
The 'dig'-command is a tool for questioning DNS nameservers for information about IP-addresses, hostnames, mail servers and other kinds of network settings. The dig-command is available on Unix, macOS, GNU/Linux and Windows.
Using dig to query domain name servers
You can use dig to get information about a given domain name by simply typing: 'dig willem.com'. See the following screenshot with explanation:
- 1) dig willem.com will return all information about the question, answer, authority (the one that answered the question) and statistics of the actual query (like how long it took to get an answer).
- 2) dig +short willem.com omits all the extra information and only returns the answer. Here you can see that willem.com points to IP-address 184.108.40.206.
- 3) dig +short willem.com MX will show you the mailer exchange (MX) records. MX-records are crucial for email to arrive at the right server. Basically it's the designation of the post office responsible for email linked to the domain name. For willem.com this is a mail services called online.lemmid.com. Other popular mail services are Office365 and Google Gmail. Using dig you can find out what mail service somebody is using.
- 4) dig +short willem.com NS will show you the name servers that are responsible for handling queries for this domain name. Usually these are the servers operated by the domain name registry, your domain name provider. Using dig you can find what kind of domain name provider somebody is using (in the case of willem.com, that's Lemmid).
- 5) dig +short willem.com TXT will return the text record linked to the domain name, this is where you'll find the so called SPF-record. The SPF-record is another crucial part of email, its useful to dig a little deeper into SPF.
Sender Policy Framework (SPF)
To detected forged sender addresses in emails (so called email spoofing), the SPF standard was defined in 2004. Originally called "Sender Permitted From", SPF is a way to check if somebody is allowed to send email on behalf of a given domain name. SPF allows the owner of a domain name to specify which computers are authorised to send email with FROM addresses of that domain.
If a domain name owner publishes a SPF-record, spammers and phishers are less likely to (ab)use the domain name to send forged emails, pretending to be from that domain. An SPF-protected domain is therefore less likely to be blacklisted by spam filters, making it more likely to allow legitimate email from the domain to get through. A misconfigured SPF-record can however disrupt email delivery.
Using dig to query SPF-records
Using the dig-command you can query a SPF-record and see what the exact sender policy is. See the following screenshot with explanation:
- 1) dig +short TXT google.com will show us the TXT-record linked configured for google.com, the place where you can find the SPF-record (among other things). The SPF-record for google.com is "v=spf1 include:_spf.google.com ~all". The include:-part means that for this domain name external SPF values should be loaded, too.
- 2) dig +short TXT _spf.google.com shows what those external SPF values for google.com actually are. In this case it reveals another three includes: "_netblocks.google.com", "_netblocks2.google.com" and (how original..) "_netblocks3.google.com".
- 3) dig +short TXT _netblocks.google.com (and the 2 + 3 variants) specify the actual IP-addresses that are allowed to send email on behalf of google.com. As Google is a big internet company there are many IP-addresses in these lists. If you look carefully, you'll notice that some of these addresses have a "/"-suffix, like "/24". This is the way to notate an entire block (e.g. street) of IP-addresses.
IP blocks explained
The easiest way to understand IP-address block notation is by the following examples:
- /8 = 255.0.0.0
- /16 = 255.255.0.0
- /24 = 255.255.255.0
- /32 = 255.255.255.255
Where you'll see '0' in the addresses above, other values are included. So, for instance, the 220.127.116.11/16 actually means "all the addresses starting with '173.194' ". Given 255 possible positions on each octet, that is 255x255=65025 different addresses!
To solve problems you need to know where the problem is. Using the dig-command you can learn about a given network and domain configuration.
Answers from one command to another, enable you to dig deep into the innards of the amazing interwebs. Good luck!