How to check DNS caching

A DNS cache is a temporary database, containing records of all the recent and attempted visits for requested domains names, each sequence of a DNS query from Browser to the recursive resolver looks like this.

What is DNS caching?

The purpose of caching is to temporarily stored data in a location that results in improvements in performance and reliability for data requests. DNS caching involves storing data closer to the requesting client so that the DNS query can be resolved earlier and additional queries further down the DNS lookup chain can be avoided, thereby improving load times and reducing bandwidth/CPU consumption. DNS data can be cached in a variety of locations, each of which will store DNS records for a set amount of time determined by a time-to-live (TTL).

Browser level DNS caching

Modern web browsers are designed by default to cache DNS records for a set amount of time. The purpose here is obvious; the closer the DNS caching occurs to the web browser, the fewer processing steps must be taken in order to check the cache and make the correct requests to an IP address. When a request is made for a DNS record, the browser cache is the first location checked for the requested record.

In Chrome, you can see the status of your DNS cache by going to chrome://net-internals/#dns

this also applies to Microsoft Edge since it rendering on chromium.

Mozilla Firefox lists entries in DNS cache with this URL
about:networking#dns

OS level DNS caching

The operating system level DNS resolver is the second and last local stop before a DNS query leaves your machine. The process inside your operating system that is designed to handle this query is commonly called a “stub resolver” or DNS client. When a stub resolver gets a request from an application, it first checks its own cache to see if it has the record. If it does not, it then sends a DNS query (with a recursive flag set), outside the local network to a DNS recursive resolver inside the Internet service provider (ISP).

When the recursive resolver inside the ISP receives a DNS query, like all previous steps, it will also check to see if the requested host-to-IP-address translation is already stored inside its local persistence layer.

How to check and query local DNS Cache

In some situations, the content of the DNS cache needs to be checked, such as when several instances of different level caching do not match, or to update the cache immediately if there are changes in the DNS.

When using Windows, the ipconfig command can be used to view the DNS cache content, To do this, open a command prompt with press Win+Rcmd Enter to paste and run the following command.

C:\> ipconfig /displaydns

If you want to reset the DNS cache, for example because the cache is to be updated immediately, the flushdns option can be used.

C:\> ipconfig /flushdns

To retrieve the content of the DNS client cache can also get in the Windows PowerShell they give the Get-DnsClientCache cmdlet.

PS C:\> Get-DnsClientCache

The cmdlet is preferable, this output comes very nice and comfortable.

With Linux it is quite different, if using Linux Mint or another Ubuntu based OS, then resolvectl can help to show the cache content.

$ resolvectl query 217.27.98.76

The resolve query output appears something like this.

217.27.98.76: apache2.a-enterprise.ch          -- link: ens160

-- Information acquired via protocol DNS in 24.9ms.
-- Data is authenticated: no

DNS caching is not guaranteed to be present on every Linux system. In the traditional configuration (i.e. without systemd), apps would send DNS queries directly to the servers found in /etc/resolv.conf, so there’s no “system” DNS cache to be seen in the first place. Linux Distributions do often enable DNS caching by default, but the exact mechanism varies.

To show link and server status, try perform the status command.

$ resolvectl status

systemd-resolved as DNS cache

If you are using systemd-resolved as the DNS cache (which these days is indeed the closest thing to a “system DNS cache”), run systemctl kill -s USR1 systemd-resolved and it will dump all cache contents to the system journal (journalctl -b -u systemd-resolved) upon receiving the SIGUSR1.

Note. that the ‘systemd-resolved‘ tool is named resolvectl query in recent versions, which additionally has the --cache=no option to bypass caching done by systemd-resolved.

Testing this out, we can run journalctl for all DNS records in the cache, with launch the script will perform grep for IN records.

time=$(date +%s)
systemctl kill -s USR1 systemd-resolved
journalctl -b -u systemd-resolved -S "@$time" -o cat | grep " IN "

If there is a DNS caching on your Linux? you can verify this on your system with perform the ‘systemctl is-active‘ command.

$ systemctl is-active systemd-resolved

More usefull resolvectl query commands! this retrieve the MX record of the “icloud.com” domain.

$ resolvectl -t MX query icloud.com

To retrieve any TXT record of a domain.

$ resolvectl --legend=no -t TXT query outlook.com

Because we usually want to query the SPF record these days.

$ resolvectl -t TXT query gmail.com | grep "spf1"

this query looks something like this.

gmail.com IN TXT "v=spf1 redirect=_spf.google.com" - link: ens160

Resolve an SRV service type using resolvectl service option.

$ resolvectl service _xmpp-server._tcp gmail.com

To retrieve SRV entries of a domain, i.e. preferred for SCP by Outlook Anywhere.

$ resolvectl service _autodiscover._tcp hosttech.net

If you want to flush all local DNS caches, i.e. the cache is to be updated immediately, then the flush-caches option can be appended.

$ resolvectl flush-caches

Further help is given with hitting –help.

$ resolvectl --help
resolvectl [OPTIONS...] COMMAND ...

Send control commands to the network name resolution manager, or
resolve domain names, IPv4 and IPv6 addresses, DNS records, and services.

Commands:
  query HOSTNAME|ADDRESS...    Resolve domain names, IPv4 and IPv6 addresses
  service [[NAME] TYPE] DOMAIN Resolve service (SRV)
  openpgp EMAIL@DOMAIN...      Query OpenPGP public key
  tlsa DOMAIN[:PORT]...        Query TLS public key
  status [LINK...]             Show link and server status
  statistics                   Show resolver statistics
  reset-statistics             Reset resolver statistics
  flush-caches                 Flush all local DNS caches
  reset-server-features        Forget learnt DNS server feature levels
  dns [LINK [SERVER...]]       Get/set per-interface DNS server address
  domain [LINK [DOMAIN...]]    Get/set per-interface search domain
  default-route [LINK [BOOL]]  Get/set per-interface default route flag
  llmnr [LINK [MODE]]          Get/set per-interface LLMNR mode
  mdns [LINK [MODE]]           Get/set per-interface MulticastDNS mode
  dnsovertls [LINK [MODE]]     Get/set per-interface DNS-over-TLS mode
  dnssec [LINK [MODE]]         Get/set per-interface DNSSEC mode
  nta [LINK [DOMAIN...]]       Get/set per-interface DNSSEC NTA
  revert LINK                  Revert per-interface configuration

Options:
  -h --help                    Show this help
     --version                 Show package version
     --no-pager                Do not pipe output into a pager
  -4                           Resolve IPv4 addresses
  -6                           Resolve IPv6 addresses
  -i --interface=INTERFACE     Look on interface
  -p --protocol=PROTO|help     Look via protocol
  -t --type=TYPE|help          Query RR with DNS type
  -c --class=CLASS|help        Query RR with DNS class
     --service-address=BOOL    Resolve address for services (default: yes)
     --service-txt=BOOL        Resolve TXT records for services (default: yes)
     --cname=BOOL              Follow CNAME redirects (default: yes)
     --search=BOOL             Use search domains for single-label names
                                                              (default: yes)
     --raw[=payload|packet]    Dump the answer as binary data
     --legend=BOOL             Print headers and additional info (default: yes)

See the resolvectl(1) man page for details.

UNBLOG Tutorials