Назад | Перейти на главную страницу

Понимание поля TTL записи PTR, возвращаемой клиентом dig

У меня есть некоторые сомнения по поводу работы DNS в целом - даже с учетом того, что у меня есть теоретическая база. рассмотрим следующий вывод: 

[user@host ~]$ dig google.com
[...]
;; ANSWER SECTION:
google.com.     102 IN  A   172.217.3.174

[user@host ~]$ dig -x 172.217.3.174
[...]
;; ANSWER SECTION:
174.3.217.172.in-addr.arpa. 17514 IN    PTR sea15s11-in-f14.1e100.net.
174.3.217.172.in-addr.arpa. 17514 IN    PTR sea15s11-in-f174.1e100.net.

[user@host ~]$ dig -x 172.217.3.174
[...]
;; ANSWER SECTION:
174.3.217.172.in-addr.arpa. 299 IN  PTR sea15s11-in-f14.1e100.net.
174.3.217.172.in-addr.arpa. 299 IN  PTR sea15s11-in-f174.1e100.net.

[user@host ~]$ dig -x 172.217.3.174
[...]
;; ANSWER SECTION:
174.3.217.172.in-addr.arpa. 299 IN  PTR sea15s11-in-f14.1e100.net.
174.3.217.172.in-addr.arpa. 299 IN  PTR sea15s11-in-f174.1e100.net.

[user@host ~]$ dig -x 172.217.3.174
[...]
;; ANSWER SECTION:
174.3.217.172.in-addr.arpa. 298 IN  PTR sea15s11-in-f14.1e100.net.
174.3.217.172.in-addr.arpa. 298 IN  PTR sea15s11-in-f174.1e100.net.

[user@host ~]$ dig -x 172.217.3.174
[...]
;; ANSWER SECTION:
174.3.217.172.in-addr.arpa. 297 IN  PTR sea15s11-in-f14.1e100.net.
174.3.217.172.in-addr.arpa. 297 IN  PTR sea15s11-in-f174.1e100.net.

Что именно означает поле TTL?
В первом ответе это: 17514, далее 299, 298 ...
Я знаю определение, это что-то вроде: Как долго клиент должен хранить ответ в кеше (ограничить запросы DNS)

Тем не мение,
1. Относится ли это только к клиентам приложений? В конце концов, Linux не кэширует ответы DNS, поэтому это поле не имеет значения.
2. Относится ли это также к вторичным DNS-серверам (другими словами, как долго хранить информацию от главного DNS-сервера в течение этот конкретный запись?)? А как насчет поля Refresh SOA в мастере?
3. Как получается, что он все меньше и меньше? Кто за это отвечает? Мой клиент (копайся на RHat) или DNS сервер? Авторитетный или рабский? /etc/resolv.conf?

Кстати: я считаю, что мастер и Authorative одинаковы, а также slave = secondary = non-Authorative

  1. Большинство клиентов кэшируют ответы DNS, большинство дистрибутивов Linux этого не делают по умолчанию, но также могут установить программное обеспечение для этого.
  2. Да, большинство DNS-серверов кэшируют ответы для доменов, для которых они не являются полномочными. Это делается для каждой записи. Интервал обновления Start Of Authority (SOA), с другой стороны, предназначен для DNS-кластеров, где главный сервер хранит главную копию зоны, а интервал обновления записи SOA устанавливает, как часто подчиненные серверы должны запрашивать копию всей зоны. с главного сервера.
  3. Обычно это клиент, который хранит кеш уже полученных записей и очищает их по мере истечения срока действия записей. Все неавторизованные серверы в цепочке делают то же самое для кешированных ответов. Linux не делает этого по умолчанию, поэтому ответы, которые вы видите, исходят от неавторизованного DNS-сервера.

Авторитетный / неавторизованный не означает то же самое, что и главный / подчиненный в DNS. Полномочный DNS-сервер - это сервер, который публикует определенную зону для остальной части глобального DNS. Неавторизованный DNS-сервер - это сервер, который не отвечает за определенную зону, но имеет копию записей из этой зоны. DNS-сервер может быть авторитетным для одной зоны, назовем ее abc.com, но также неавторизованным для другой зоны, например bcd.com.

Главный и подчиненный DNS-серверы относятся к кластерам. В кластере DNS-серверов один сервер является главным и хранит главную копию всех зон, для которых этот кластер является полномочным. Подчиненные серверы затем опрашивают ведущего на предмет копии зон, а затем отвечают как полномочные DNS-серверы для этой зоны. Это сделано для того, чтобы все изменения выполнялись только на главном сервере и реплицировались на подчиненные серверы. Обычно подчиненные серверы - единственные, кто отвечает на внешние запросы DNS, а главный просто разговаривает с подчиненными серверами.