The host command doesn’t just ask a DNS server for a record; it is a DNS client that performs the entire lookup process from scratch, including finding its own authoritative nameserver.
Let’s see it in action. Imagine you want to know the IP address for google.com.
$ host google.com
google.com has address 142.250.190.14
google.com has IPv6 address 2607:f8b0:4004:831::200e
google.com mail has MX preference 10 mail.google.com.
This output shows the A record (IPv4 address), AAAA record (IPv6 address), and MX record (mail exchanger) for google.com. But host isn’t just fetching this from your local DNS resolver. It’s actually performing the full query process.
Here’s how host builds the mental model of DNS resolution. When you run host google.com, it first needs to know which DNS server to ask. It does this by querying the root DNS servers to find the authoritative nameserver for the .com top-level domain (TLD). Then, it queries the .com TLD nameserver to find the authoritative nameserver for google.com. Finally, it queries that google.com authoritative nameserver for the specific record you requested.
The primary levers you control with host are the type of DNS record you want to query and the specific DNS server you want to query.
To query for a different record type, say just the mail exchanger records, you’d use the -t flag:
$ host -t MX google.com
google.com mail has MX preference 10 mail.google.com.
If you want to skip your local resolver and query a specific DNS server, like Google’s public DNS at 8.8.8.8, you append the server’s IP address to the command:
$ host google.com 8.8.8.8
Using domain server:
Name: 8.8.8.8
Address: 8.8.8.8#53
Aliases:
google.com has address 142.250.190.14
google.com has IPv6 address 2607:f8b0:4004:831::200e
This bypasses your ISP’s DNS or any local caching. It’s the equivalent of opening a direct line to 8.8.8.8 and asking it for the information.
A common misconception is that host is just a simpler dig or nslookup. While it shares functionality, host’s default behavior of performing a full recursive query (finding the authoritative server itself) is its key differentiator. dig and nslookup by default query your configured resolver, which then performs the recursive query. host is the recursive client.
When you ask host to query for an SRV record, it’s not just looking for a simple IP address; it’s looking for information about specific services offered by a domain, including the hostname and port number where that service can be found.
$ host -t SRV _sip._tcp.google.com
_sip._tcp.google.com has SRV record 0 60 1000 sipconfig.google.com.
This tells you that the SIP (Session Initiation Protocol) service over TCP for google.com is available on sipconfig.google.com on port 1000.
The next step in understanding DNS resolution from the terminal is to explore how to interpret the output of more verbose DNS queries and how to troubleshoot DNS propagation delays.