DIG непредсказуемый TTL в DNS

645

Я обнаружил, что поле TTL в ответе может значительно различаться (и часто увеличиваться) между последующими запросами к одному и тому же доменному имени (и тому же разрешающему DNS-серверу).

$ 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

Я запустил tcpdump для проверки пакетов (просто чтобы убедиться, что в dig нет ошибок), где я вижу, что пакеты возвращают разные значения TTL.

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)

Я бы подумал, что это связано с произвольным вещанием и потенциальной балансировкой нагрузки на несколько DNS-серверов в одном центре обработки данных. Проблема в том, что запросы разрешаются через мой маршрутизатор, который, как я предполагаю, кэширует записи вплоть до их TTL. Поэтому я должен видеть уменьшающееся поле TTL в каждом последующем ответе. Может ли это быть ошибкой в ​​моем роутере, или это просто не кеширование?

1
Я провел некоторое тестирование с моей стороны, и между локальным DNS-сервером и общедоступным DNS от Google я видел только случайные изменения, которые вы вставляли при запросе DNS от Google. Итак, мне любопытно: * Какой у вас бренд / модель роутера? * На вашем маршрутизаторе установлено несколько DNS-серверов? Возможно, попробуйте только один DNS-сервер, настроенный там, и посмотрите, все ли прояснилось? Matthew_Sp 9 лет назад 0
Вы используете DNS провайдера? если это так (особенно в случае vzw & comcast, он имеет очень ненадежные ttl и dns в целом (я лично обхожу comcast в своей области и использую google / openDNS) linuxdev2013 9 лет назад 0

1 ответ на вопрос

2
Tobias Mädel

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=

Похожие вопросы