Lazy Diary @ Hatena Blog

PowerShell / Java / miscellaneous things about software development, Tips & Gochas. CC BY-SA 4.0/Apache License 2.0

How long does an old DNS A record live in stub resolver according to TTL?

Question

A cached DNS A record in a full resolver expires after the TTL has elapsed. A timer for TTL starts when the full resolve gets an answer from an authoritative name server.

So, how about stub resolvers? How about a full resolver that gets an answer from an upstream full resolver? If a full resolver returns the TTL value of the authoritative answer, a stub resolver will access an old server after the TTL of the authoritative answer (e.g. server relocation).

Result

  • Full resolvers return TTL lower than the one in authoritative answer, according to the elapsed time from when the full resolver got an authoritative answer.
  • Some full resolvers start TTL count irrelevantly to the TTL of the authoritative answer, but it's relatively small (60-300 seconds).

Examples

For example, the TTL of www.tut.ac.jp on ns1.tut.ac.jp (authoritative name server) is 43200.

satob@K690XN:/tmp$ dig www.tut.ac.jp a @ns1.tut.ac.jp

; <<>> DiG 9.16.48-Ubuntu <<>> www.tut.ac.jp a @ns1.tut.ac.jp
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 45864
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 3, ADDITIONAL: 3
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
; COOKIE: 945070fcdf30040054d73dfd66097241d24c3e11ae55afa3 (good)
;; QUESTION SECTION:
;www.tut.ac.jp.                 IN      A

;; ANSWER SECTION:
www.tut.ac.jp.          43200   IN      A       52.156.43.168

;; AUTHORITY SECTION:
tut.ac.jp.              43200   IN      NS      dns-x.sinet.ad.jp.
tut.ac.jp.              43200   IN      NS      ns0a.tut.ac.jp.
tut.ac.jp.              43200   IN      NS      ns1.tut.ac.jp.

;; ADDITIONAL SECTION:
ns1.tut.ac.jp.          43200   IN      A       133.15.20.16
ns0a.tut.ac.jp.         43200   IN      A       52.156.46.44

;; Query time: 10 msec
;; SERVER: 133.15.20.16#53(133.15.20.16)
;; WHEN: Sun Mar 31 23:25:05 JST 2024
;; MSG SIZE  rcvd: 184

But when you get an answer from a full resolver, the value of TTL is lower than 43200. (Note that 192.168.233.1 is my full resolver)

satob@K690XN:/tmp$ dig www.tut.ac.jp @192.168.233.1

; <<>> DiG 9.16.48-Ubuntu <<>> www.tut.ac.jp @192.168.233.1
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 22876
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;www.tut.ac.jp.                 IN      A

;; ANSWER SECTION:
www.tut.ac.jp.          42992   IN      A       52.156.43.168

;; Query time: 0 msec
;; SERVER: 192.168.233.1#53(192.168.233.1)
;; WHEN: Sun Mar 31 23:26:07 JST 2024
;; MSG SIZE  rcvd: 58

Some full resolvers, for example, Google Public DNS (8.8.8.8), start TTL count from a smaller value (half of the original TTL?)

[cloudshell-user@ip-xx-xx-xx-xx ~]$ dig www.tut.ac.jp a @8.8.8.8

; <<>> DiG 9.16.48-RH <<>> www.tut.ac.jp a @8.8.8.8
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 42917
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;www.tut.ac.jp.                 IN      A

;; ANSWER SECTION:
www.tut.ac.jp.          21600   IN      A       52.156.43.168

;; Query time: 159 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Sun Mar 31 10:22:49 UTC 2024
;; MSG SIZE  rcvd: 58

AWS's full resolver used in CloudShell (10.0.0.2) returns TTL 300 for most of the queries.

[cloudshell-user@ip-xx-xx-xx-xx ~]$ dig www.tut.ac.jp

; <<>> DiG 9.16.48-RH <<>> www.tut.ac.jp
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 44459
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;www.tut.ac.jp.                 IN      A

;; ANSWER SECTION:
www.tut.ac.jp.          300     IN      A       52.156.43.168

;; Query time: 129 msec
;; SERVER: 10.0.0.2#53(10.0.0.2)
;; WHEN: Sun Mar 31 10:21:22 UTC 2024
;; MSG SIZE  rcvd: 58

Query for some domains served by CDN returns TTL 0. For example, a query for www.ipa.go.jp returns TTL 0.

satob@K690XN:/tmp$ dig www.ipa.go.jp

; <<>> DiG 9.16.48-Ubuntu <<>> www.ipa.go.jp
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 19943
;; flags: qr rd ad; QUERY: 1, ANSWER: 9, AUTHORITY: 0, ADDITIONAL: 0
;; WARNING: recursion requested but not available

;; QUESTION SECTION:
;www.ipa.go.jp.                 IN      A

;; ANSWER SECTION:
www.ipa.go.jp.          0       IN      CNAME   d2aiu9f88m0xez.cloudfront.net.
d2aiu9f88m0xez.cloudfront.net. 0 IN     A       13.33.174.6
d2aiu9f88m0xez.cloudfront.net. 0 IN     A       13.33.174.90
d2aiu9f88m0xez.cloudfront.net. 0 IN     A       13.33.174.89
d2aiu9f88m0xez.cloudfront.net. 0 IN     A       13.33.174.31
ns-130.awsdns-16.com.   0       IN      A       205.251.192.130
ns-1012.awsdns-62.net.  0       IN      A       205.251.195.244
ns-1045.awsdns-02.org.  0       IN      A       205.251.196.21
ns-1632.awsdns-12.co.uk. 0      IN      A       205.251.198.96

;; Query time: 0 msec
;; SERVER: 172.30.176.1#53(172.30.176.1)
;; WHEN: Mon Apr 01 00:05:29 JST 2024
;; MSG SIZE  rcvd: 329

In the authoritative server, TTL is set to 60. So it looks like some of the resolvers upstream from me rewrite TTL.

satob@K690XN:/tmp$ dig d2aiu9f88m0xez.cloudfront.net a @ns-1012.awsdns-62.net

; <<>> DiG 9.16.48-Ubuntu <<>> d2aiu9f88m0xez.cloudfront.net a @ns-1012.awsdns-62.net
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 8904
;; flags: qr aa rd; QUERY: 1, ANSWER: 4, AUTHORITY: 4, ADDITIONAL: 1
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;d2aiu9f88m0xez.cloudfront.net. IN      A

;; ANSWER SECTION:
d2aiu9f88m0xez.cloudfront.net. 60 IN    A       13.33.174.6
d2aiu9f88m0xez.cloudfront.net. 60 IN    A       13.33.174.90
d2aiu9f88m0xez.cloudfront.net. 60 IN    A       13.33.174.89
d2aiu9f88m0xez.cloudfront.net. 60 IN    A       13.33.174.31

;; AUTHORITY SECTION:
d2aiu9f88m0xez.cloudfront.net. 172800 IN NS     ns-1012.awsdns-62.net.
d2aiu9f88m0xez.cloudfront.net. 172800 IN NS     ns-1045.awsdns-02.org.
d2aiu9f88m0xez.cloudfront.net. 172800 IN NS     ns-130.awsdns-16.com.
d2aiu9f88m0xez.cloudfront.net. 172800 IN NS     ns-1632.awsdns-12.co.uk.

;; Query time: 59 msec
;; SERVER: 205.251.195.244#53(205.251.195.244)
;; WHEN: Mon Apr 01 00:08:22 JST 2024
;; MSG SIZE  rcvd: 260

satob@K690XN:/tmp$ dig d2aiu9f88m0xez.cloudfront.net a @ns-1012.awsdns-62.net