TTL при запросе любой записи с копанием

4066
whitenoisedb

Этот вопрос приходит из этой темы . Когда я делаю это, я получаю оставшиеся секунды до истечения срока действия записи A в запрашиваемом сервере имен:

dig stackexchange.com 

Однако, если я сделаю это, я получу значения TTL:

dig any stackexchange.com 

Итак, я не понимаю, почему, когда я делаю, dig any stackexchange.comя получаю все значения TTL, как если бы я задал авторский вопрос, когда я фактически сделал рекурсивный запрос.

4
@ Каннан Мохан, теперь это в новом вопросе. whitenoisedb 9 лет назад 0

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

6
Kannan Mohan

Короче говоря, оба запроса, которые вы упомянули в вопросе, являются неавторизованными.

Записи DNS для домена могут быть запрошены с кэширующего DNS-сервера или с официального DNS-сервера. Таким образом, если вы хотите запросить DNS-сервер с кэшированием, вы можете указать IP-адрес DNS-сервера или, если он не указан, будет выбран DNS-сервер по умолчанию, который был настроен /etc/resolv.conf.

Неавторизованный запрос

$ dig stackexchange.com 

или же

$ dig stackexchange.com @8.8.8.8 

В обоих случаях запрос возвращает неавторизованный ответ, поскольку DNS вашего интернет-провайдера или общедоступный DNS Google (8.8.8.8) не являются полномочными для stackexchange.comдомена. Когда вы запросили неавторизованный сервер имен, значение TTL, которое он предоставляет, будет уменьшаться при каждом запросе. Как только значение TTL истечет, кэширующий сервер имен будет запрашивать полномочный DNS-сервер.

Авторитетный запрос

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

$ dig ns stackexchange.com ... ;; ANSWER SECTION: stackexchange.com. 84894 IN NS cf-dns02.stackexchange.com. stackexchange.com. 84894 IN NS cf-dns01.stackexchange.com. ... 

ОТВЕТ Раздел предоставляет полномочные сервера для домена stackexchange.comи поэтому, если нам нужно, чтобы получить авторитетный ответ, то

$ dig stackexchange.com @cf-dns01.stackexchange.com. 

Хотя мы запрашиваем авторитетный DNS-сервер, значения TTL не изменятся, поскольку эти серверы имен являются основным источником информации, и срок их действия не истекает до тех пор, пока администратор не изменит их.

Как работает ЛЮБАЯ запись

ЛЮБАЯ запись похожа на шаблон, вы можете использовать ее для получения всех записей, которые кэшируются / хранятся на DNS-сервере. Например, я запросил stackexchange.comЛЮБУЮ запись, и мой DNS-сервер по умолчанию отвечает, как показано ниже.

$ dig any stackexchange.com .... ;; ANSWER SECTION: stackexchange.com. 86350 IN SOA cf-dns01.stackexchange.com. dns.cloudflare.com. 2017456480 10000 2400 604800 3600 stackexchange.com. 176 IN A 198.252.206.140 stackexchange.com. 84338 IN NS cf-dns01.stackexchange.com. stackexchange.com. 84338 IN NS cf-dns02.stackexchange.com. .... 

Здесь вы можете увидеть, что ответ содержит только информацию о SOA, Aи NSзапись. Но на самом деле есть еще записи, stackexchange.comкоторые не кэшируются на моем DNS-сервере по умолчанию, поскольку я не запрашивал их.

Теперь я запрашиваю MXзапись на мой DNS-сервер по умолчанию, и ответ

$ dig MX stackexchange.com .... ;; ANSWER SECTION: stackexchange.com. 300 IN MX 10 aspmx3.googlemail.com. stackexchange.com. 300 IN MX 5 alt2.aspmx.l.google.com. stackexchange.com. 300 IN MX 5 alt1.aspmx.l.google.com. stackexchange.com. 300 IN MX 10 aspmx2.googlemail.com. stackexchange.com. 300 IN MX 1 aspmx.l.google.com. .... 

Теперь я снова запрашиваю ANYзапись, и теперь вы можете видеть, что запрос ANYтакже вернул MXзаписи. И поэтому ANYзапись будет просто предоставлять записи, которые кэшируются только на вашем сервере имен по умолчанию.

$ dig any stackexchange.com .... ;; ANSWER SECTION: stackexchange.com. 298 IN MX 5 alt1.aspmx.l.google.com. stackexchange.com. 298 IN MX 10 aspmx2.googlemail.com. stackexchange.com. 86084 IN NS cf-dns01.stackexchange.com. stackexchange.com. 298 IN MX 10 aspmx3.googlemail.com. stackexchange.com. 298 IN MX 1 aspmx.l.google.com. stackexchange.com. 298 IN MX 5 alt2.aspmx.l.google.com. stackexchange.com. 86084 IN NS cf-dns02.stackexchange.com. stackexchange.com. 243 IN A 198.252.206.140 stackexchange.com. 86343 IN SOA cf-dns01.stackexchange.com. dns.cloudflare.com. 2017456480 10000 2400 604800 3600 .... 

И, как вы можете видеть, значения TTL меняются для неавторизованных ответов.

1
TheCompWiz

Вы не понимаете поле TTL в DNS-запросах. TTL является для клиента показателем того, как долго он должен кэшировать результаты, прежде чем повторно запрашивать сервер имен. Если вы не обновите свой DNS-сервер другим значением для TTL, ответ всегда будет одинаковым. Это очень плохая практика - перезапрашивать серверы имен каждый раз, когда вам нужно преобразовать имя хоста в IP.

Я понимаю, что только при запросе к серверу авторизации TTL указывает, как долго он должен кешировать результаты. Однако при выполнении рекурсивного запроса вы получаете фактическое оставшееся время на этом DNS-сервере до его перезапуска. whitenoisedb 9 лет назад 0
Так почему, когда я выполняю `dig somedomain.com`, я получаю, например, 1645? который на самом деле не TTL. Если я задаю такой вопрос, я получу правильное значение TTL 14400. whitenoisedb 9 лет назад 0
Не могли бы вы указать конкретную команду, которую вы используете? Я подозреваю, что некоторые параметры переключаются на итеративный запрос, а не разрешают рекурсивный запрос. (+ norec + nssearch или + trace?) TheCompWiz 9 лет назад 0
Скажем, например, я только что сделал `dig stackexchange.com` и TTL равнялся 15. Тогда, если я сделал` dig + norecurse stackexchange.com @ cf-dns01.stackexchange.com`, я получаю значение TTL 300. whitenoisedb 9 лет назад 0
Правильный. + norecurse форсирует запросы к авторитетным серверам напрямую. + norecurse по определению делает итеративный запрос. TheCompWiz 9 лет назад 0
Так почему, когда я выполняю dig `dig any stackexchange`, я получаю все значения TTL, как если бы я делал итеративный запрос? Это был мой первый вопрос. whitenoisedb 9 лет назад 0
`dig any stackexchange` будет пытаться найти` any` типа `stackexchange`. (что у вас, вероятно, назад) Итак, во второй раз, что было * EXACT * запросом, который вы выполнили, и что было неожиданным? TheCompWiz 9 лет назад 0
Я не понимаю, почему, когда я «копаю любой стек-обмен», я получаю все значения TTL, как будто я сделал итеративный запрос, когда я фактически сделал рекурсивный запрос! whitenoisedb 9 лет назад 0
Во-первых, я не знаю, почему вы получили бы какой-нибудь интеллектуальный ответ от `dig any stackexchange`, потому что ваши параметры обратные. Нет такого понятия, как тип записи `stackexchange`. Во всяком случае, вы можете получить случайные некэшированные данные, потому что вы запрашиваете тип записи, который не может быть кэширован ... или ваш запрос обработан не так, как вы хотите. TheCompWiz 9 лет назад 0
О, чувак, я скучаю по `.com`! whitenoisedb 9 лет назад 0
Синтаксис для dig - `dig`` name` `type`. Не существует типа записи `stackexchange.com`. Когда-либо. TheCompWiz 9 лет назад 0
`dig` понимает это в обоих направлениях. `dig`` name` `type` и` dig` `type`` name` whitenoisedb 9 лет назад 0

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