2

I have discovered that the TTL field in an answer can vary significantly (and often increase) between subsequent queries to the same domain name (and same resolving DNS server).

$ dig stackexchange.com

; <<>> DiG 9.9.5-4.3ubuntu0.2-Ubuntu <<>> stackexchange.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 45575
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;stackexchange.com.     IN  A

;; ANSWER SECTION:
stackexchange.com.  107 IN  A   104.16.13.13
stackexchange.com.  107 IN  A   104.16.12.13

;; Query time: 12 msec
;; SERVER: 127.0.1.1#53(127.0.1.1)
;; WHEN: Thu Apr 09 14:28:45 BST 2015
;; MSG SIZE  rcvd: 78

 

$ dig stackexchange.com

; <<>> DiG 9.9.5-4.3ubuntu0.2-Ubuntu <<>> stackexchange.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 9152
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;stackexchange.com.     IN  A

;; ANSWER SECTION:
stackexchange.com.  201 IN  A   104.16.13.13
stackexchange.com.  201 IN  A   104.16.12.13

;; Query time: 13 msec
;; SERVER: 127.0.1.1#53(127.0.1.1)
;; WHEN: Thu Apr 09 14:28:46 BST 2015
;; MSG SIZE  rcvd: 78

I fired up tcpdump to inspect the packets (just to make sure there wasn't a bug in dig) where I can see that the packets are returning different TTL values.

14:28:45.011150 IP (tos 0x18, ttl 48, id 0, offset 0, flags [DF], proto UDP (17), length 106)
192.168.1.1.domain > 192.168.1.109.10403: [udp sum ok] 27042 q: A? stackexchange.com. 2/0/1 stackexchange.com. [1m47s] A 104.16.13.13, stackexchange.com. [1m47s] A 104.16.12.13 ar: . OPT UDPsize=4096 (78)
14:28:46.671406 IP (tos 0x0, ttl 64, id 39411, offset 0, flags [DF], proto UDP (17), length 74)
192.168.1.109.24817 > 192.168.1.1.domain: [udp sum ok] 57829+ [1au] A? stackexchange.com. ar: . OPT UDPsize=4096 (46)
14:28:46.682634 IP (tos 0x18, ttl 48, id 0, offset 0, flags [DF], proto UDP (17), length 106)
192.168.1.1.domain > 192.168.1.109.24817: [udp sum ok] 57829 q: A? stackexchange.com. 2/0/1 stackexchange.com. [3m21s] A 104.16.13.13, stackexchange.com. [3m21s] A 104.16.12.13 ar: . OPT UDPsize=4096 (78)

I would have thought it was due to anycasting, and potential load balancing to multiple DNS servers in a single data center. The trouble is, the queries are being resolved via my router, which I would assume caches records up to their TTL. Therefore, I should see a decreasing TTL field in each subsequent response. Could this be a bug in my router, or is it just not caching?

  • I did some testing on my end, and between a local DNS server and Google's public DNS, I only saw random changes like you pasted when querying Google's DNS. So, I'm curious: * What Brand/Model Router do you have? * Do you have more than one DNS server set on your router? Possibly try with just one DNS server configured in there, and see if this clears up? – Matthew_Sp Apr 20 '15 at 23:55
  • are you using ISP's DNS ? if so (especially in case of vzw & comcast it has highly unreliable ttl and dns in general (i personally bypass comcast in my area and use google/openDNS) – linuxdev2013 Apr 22 '15 at 05:05

1 Answers1

2

Many routers, especially cheaper ones don't actually provide DNS caching. Due to anycasting DNS servers of your provider the TTL value of the records will be different from server to server depending on when they first/last resolved this domain.

You can have a look at this by visiting a site like digwebinterface.com: http://www.digwebinterface.com/?hostnames=stackexchange.com&type=A&useresolver=8.8.4.4&ns=all&nameservers=

Manawyrm
  • 436
  • 3
  • 10