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

dns: разница между ЛЮБОЙ и А запросом на измененную запись DNS?

Я недавно сменил IP-адрес для определенного домена, назовите его example.com. Я знаю, что для распространения изменения DNS требуется время, и еще достаточно рано, чтобы распространение не было завершено.

Я заметил, что выполнение ЛЮБОГО запроса дает разные результаты от выполнения запроса A-записи. Например ...

% host -t a example.com
example.com has address THE.OLD.IP.ADDRESS
% host -t any example.com
example.com has address THE.NEW.IP.ADDRESS

Я знаю, что в конечном итоге DNS будет полностью распространяться, и запрос A-записи затем вернет THE.NEW.IP.ADDRESS. Но мне интересно, может ли кто-нибудь объяснить, почему ЛЮБОЙ запрос возвращает новый IP-адрес, в то время как запрос A-записи по-прежнему возвращает старый IP-адрес, пока распространение не будет завершено.

Это важно для меня, потому что прикладное программное обеспечение, которое разрешает доменные имена, похоже, выполняет эквивалент запроса A-записи, а не ЛЮБОГО запроса, и поэтому эти приложения по-прежнему разрешают IP-адрес до старого значения, пока распространение DNS не будет завершено.

Я просто ищу объяснение, почему ЛЮБЫЕ результаты, кажется, распространяются быстрее, чем результаты A-record ... это для моего собственного понимания и назидания.

Большое спасибо.

domain-name-system query

Назовите истинное имя вовлеченного, иначе устранить вашу проблему будет невозможно. И использовать dig не host для отладки. И всегда явно указывайте, какой сервер имен вы запрашиваете
ANY не является истинной записью, он просто просит преобразователь отправить обратно все, что есть в его кэше для данного имени; таким образом, это очень плохой инструмент для отладки, поскольку результат будет полностью зависеть от запрашиваемого преобразователя; по какой-то причине некоторые люди хотят полностью отказаться от него
Так что НИКАКИЕ записи не "размножаются"
На самом деле никакие записи не передаются вообще, поскольку DNS не работает сверху вниз. Этот термин используется повсеместно, но он плохо отражает действительность.

И теперь как минимум с 10.01.2019 с RFC 8482 «Обеспечение минимального размера ответов на запросы DNS, у которых QTYPE = ANY», серверы имен могут "обезвредить" ANY запросы и ответы с минимальным количеством данных (либо любое подмножество записей, которые они сочтут подходящими, либо только с одной записью HINFO).

Посмотрите этот прекрасный пример от Cloudflare:

$ dig @ns7.cloudflare.com cloudflare.com ANY +noall +ans
cloudflare.com.     1h3m9s IN HINFO "RFC8482" ""

Похоже, что на запрос записи 'ANY' отвечает полномочный DNS-сервер, у которого есть новый IP-адрес, в то время как на запрос 'A' записи отвечают другие рекурсивные DNS-серверы, где распространение нового IP-адреса все еще ожидает и следовательно, возвращает старый IP-адрес, потому что это информация, которая есть в его кеше.

Вывод dig помогает в подобных обстоятельствах, поскольку нам не хватает других деталей, таких как TTL, связанных с обоими запросами.

Я считаю маловероятным, что ANY приводит к другому поведению. Независимо от используемого типа запроса, отдельные записи в кэше будут иметь разные TTL, связанные с ними, и нет никакой разницы в двух запросах, которые будут предлагать серверу обновить свое кэшированное значение. Если что-нибудь, ANY обычно приводит к тому, что ответы на конкретные типы записей опущено если в данный момент их нет в кеше. (т.е. истекший срок)

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