DIG Unvorhersehbare TTL in DNS

857

Ich habe herausgefunden, dass das TTL-Feld in einer Antwort zwischen aufeinanderfolgenden Abfragen an denselben Domänennamen (und denselben auflösenden DNS-Server) erheblich variieren kann (und häufig zunimmt).

$ 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?

1
Ich habe einige Tests an meinem Ende durchgeführt und zwischen einem lokalen DNS-Server und dem öffentlichen DNS von Google habe ich nur zufällige Änderungen gesehen, die Sie beim Abfragen von Googles DNS eingefügt haben. Ich bin also neugierig: * Welche Marke / Modell-Router haben Sie? * Haben Sie mehr als einen DNS-Server in Ihrem Router? Möglicherweise versuchen Sie es mit nur einem DNS-Server, der dort konfiguriert ist, und sehen Sie, ob sich das auflöst. Matthew_Sp vor 9 Jahren 0
Verwenden Sie das DNS des ISP? Wenn ja (besonders im Fall von vzw & comcast hat es im Allgemeinen sehr unzuverlässige TTLs und DNSs (ich persönlich umgehe Comcast in meiner Umgebung und verwende google / openDNS) linuxdev2013 vor 9 Jahren 0

1 Antwort auf die Frage

2
Tobias Mädel

Viele Router, vor allem günstigere, bieten eigentlich kein DNS-Caching. Aufgrund des Anycasting von DNS-Servern Ihres Providers ist der TTL-Wert der Datensätze von Server zu Server unterschiedlich, abhängig davon, wann sie diese Domain zum ersten Mal oder als letztes Mal aufgelöst haben.

Sie können dies anzeigen, indem Sie eine Website wie digwebinterface.com besuchen: http://www.digwebinterface.com/?hostnames=stackexchange.com&type=A&useresolver=8.8.4.4&ns=all&nameservers=

Verwandte Probleme