1. Introduction
When we modify the DNS records of a domain, it often takes some time before the changes propagate. This happens because the DNS resolver caches the records.
The TTL (Time-To-Live) values for each DNS record determine how long the resolver is allowed to cache that particular record. Once the TTL expires, the resolver requests for a fresh value of the record.
Since we’d need to wait till the resolver invalidates the cache, we’d often prefer to know how much of the TTL is remaining for a given DNS record.
In this tutorial, we’ll look at different ways to check the TTL for a DNS record using the Linux command line.
2. TTL Check Using the dig Command
The dig command stands for “Domain Information Groper” and is often used for obtaining DNS-related information for a given domain. Most Linux distributions include it by default, so we can use it straight away.
2.1. Querying the Default Local Resolver
To check the TTL value for the A record of a given domain, say baeldung.com, we type the dig command followed by the domain name:
$ dig baeldung.com
; <<>> DiG 9.18.1-1ubuntu1.2-Ubuntu <<>> baeldung.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 43362
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 2, ADDITIONAL: 7
...
;; ANSWER SECTION:
baeldung.com. 300 IN A 172.66.43.8
baeldung.com. 300 IN A 172.66.40.248
;; AUTHORITY SECTION:
baeldung.com. 166164 IN NS lakas.ns.cloudflare.com.
baeldung.com. 166164 IN NS meera.ns.cloudflare.com.
...
In the flags line of the header section, we see ra, which indicates the query was answered from the cache by the default local resolver on our system. For a non-cached answer by the authoritative nameserver, we’d see an aa flag.
In the “ANSWER SECTION” of the output, we can see the A record pointing to the IP, with 300 as the TTL value. Assuming we didn’t have any cache to start with, and this was a fresh request, 300 is the initial TTL value for this record. Therefore, our resolver now caches the DNS record for 300 seconds, starting from the time we ran this command.
When we run the command again, say 10 seconds later, we’ll see the TTL that’s remaining:
$ dig baeldung.com
...
;; ANSWER SECTION:
baeldung.com. 290 IN A 172.66.43.8
baeldung.com. 290 IN A 172.66.40.248
...
Above, we can see that the TTL value shown is 290, which is 10 seconds less than the initial 300. Once this value counts down to zero, we can make a request again and check that the value is reset to 300.
2.2. Querying the Authoritative Nameserver
When we ran dig for the first time, the output also contained an “AUTHORITY SECTION“. From this section, we can infer that the authoritative nameservers for baeldung.com are lakas.ns.cloudflare.com and meera.ns.cloudflare.com.
Now, let’s bypass the local resolver cache and query either of these authoritative nameservers by specifying the nameserver in the command:
$ dig baeldung.com @lakas.ns.cloudflare.com
; <<>> DiG 9.18.1-1ubuntu1.2-Ubuntu <<>> baeldung.com @lakas.ns.cloudflare.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 44978
;; flags: qr aa rd; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
;; WARNING: recursion requested but not available
...
;; ANSWER SECTION:
baeldung.com. 300 IN A 172.66.40.248
baeldung.com. 300 IN A 172.66.43.8
...
In the above example, we queried the A record for the domain baeldung.com using the authoritative nameserver lakas.ns.cloudflare.com. In the flags section, we can see that the aa flag is present and the TTL value is 300. Since this is an authoritative answer, we’d continue to see the value 300 on subsequent queries regardless of the time elapsed.
3. TTL Check Using the nslookup Command
nslookup is another DNS lookup tool that we can use instead of dig. It normally doesn’t show the TTL values, but we can run the command with the -debug option to see the verbose output which contains the TTL values.
3.1. Querying the Default Local Resolver
To query the default local resolver, we’ll run the command with just the -debug option and the domain name:
$ nslookup -debug baeldung.com
Server: 127.0.0.53
Address: 127.0.0.53#53
------------
QUESTIONS:
baeldung.com, type = A, class = IN
ANSWERS:
-> baeldung.com
internet address = 172.66.43.8
ttl = 300
-> baeldung.com
internet address = 172.66.40.248
ttl = 300
AUTHORITY RECORDS:
-> baeldung.com
nameserver = lakas.ns.cloudflare.com.
ttl = 165640
-> baeldung.com
nameserver = meera.ns.cloudflare.com.
ttl = 165640
As we observed with dig, we can see that the TTL on the first run is 300. We can also see the authoritative nameservers under the “AUTHORITY RECORDS” section.
Let’s run the command again:
$ nslookup -debug baeldung.com
Server: 127.0.0.53
Address: 127.0.0.53#53
------------
QUESTIONS:
baeldung.com, type = A, class = IN
ANSWERS:
-> baeldung.com
internet address = 172.66.40.248
ttl = 181
-> baeldung.com
internet address = 172.66.43.8
ttl = 181
...
As expected, we see that the TTL has reduced to 181 seconds.
3.2. Querying the Authoritative Nameserver
To query the authoritative nameserver, we have to include the nameserver address as an additional argument to the command:
$ nslookup -debug baeldung.com lakas.ns.cloudflare.com
Server: lakas.ns.cloudflare.com
Address: 173.245.59.194#53
------------
QUESTIONS:
baeldung.com, type = A, class = IN
ANSWERS:
-> baeldung.com
internet address = 172.66.40.248
ttl = 300
-> baeldung.com
internet address = 172.66.43.8
ttl = 300
...
From the above output, we can see that the TTL value is 300. This value won’t change upon subsequent queries.
4. Conclusion
In this article, we looked at two different methods to check the TTL value of DNS records using the Linux command line. Both commands work well for our purpose and there’s no significant difference in the functionalities they offer for this purpose. So, we can use the one we feel more comfortable with.