У нас есть домен с Route 53 в качестве DNS-провайдера. У нас много запросов к записям, которых больше нет. Я подумал, что будет хорошей идеей установить все записи с высоким TTL, например: *.example.com -> 1.1.1.1. Это означает, что все запросы DNS без существующей записи будут иметь длительный TTL. Проблема в том, что теперь, когда я создаю новую запись и проверяю распространение с помощью https://www.whatsmydns.net/ некоторые из серверов возвращаются 1.1.1.1 а некоторые возвращают реальный IP-адрес. Это хорошая практика?
Спасибо
Никогда не рекомендуется указывать свои записи DNS на чужие IP-адреса без какого-либо соглашения с владельцем этих адресов.
Кроме того, имея * запись часто не является хорошей идеей. Когда-нибудь вы можете столкнуться со сценариями, в которых вам действительно нужны ответы NXDOMAIN для некоторых имен, что становится немного сложнее, если * запись присутствует. Дополнительно наличие * запись в вашей зоне означает, что вы можете легко потерять из виду, на какие настоящие имена вы полагались * запись для. В конечном итоге это означает, что заменить * запись с отдельными записями имен, поэтому вы можете застрять с неоптимальной конфигурацией.
Кроме того, как вы заметили, высокий TTL означает, что внесенные вами изменения вступят в силу через много времени. Вот почему TTL для ответов NXDOMAIN (указанных в записи SOA) обычно довольно низок.
Также * запись может не так сильно уменьшить количество запросов, как вы думаете. Зона без * Запись имеет астрономическое количество несуществующих имен. Ни один рекурсор никогда не будет кэшировать отдельную запись для каждого возможного субдомена из 63 символов. Таким образом, запросы на несуществующие имена могут создать бесконечный поток запросов, который кэширование отдельных имен никогда не сможет уменьшить.
Другой вариант - подписать свою зону с помощью DNSSEC. С введением RFC 8198 DNSSEC позволяет рекурсорам отвечать NXDOMAIN на основе кэшированных записей, охватывающих весь диапазон имен, а не только одно имя, охватываемое каждой кэшированной записью.
Если вы получаете много запросов на несуществующие имена от рекурсора, который поддерживает RFC 8198, то вы можете уменьшить количество таких запросов, подписав свою зону.
В частности, RFC говорит следующее:
Если отрицательный кэш проверяющего преобразователя содержит достаточно информации для проверки запроса, преобразователь ДОЛЖЕН использовать записи NSEC, NSEC3 и подстановочные знаки для синтеза ответов, как описано в этом документе. В противном случае он ДОЛЖЕН вернуться к отправке запроса на полномочные DNS-серверы.
теперь, когда я создаю новую запись и проверяю распространение
DNS работает не так. Каждая рекурсивная система, работающая по всему Интернету, должна узнавать об отдельных записях (за исключением доказательства отсутствия, предоставляемого зонами, подписанными DNSSEC - см. Ответ Касперда), и многие из них имеют ограничения, определенные для максимального TTL, который они готовы честь. Серверы также забывают эту кэшированную информацию при перезапуске. Это беспроигрышная война против рекурсивных систем Интернета, которые, по всей вероятности, превосходят по численности фактические устройства, запрашивающие ваши записи DNS.
Это хорошая практика?
Даже если мы исходим из предположения, что вы можете использовать кэшированные данные, чтобы существенно повлиять на запросы удаленных систем по всему Интернету, ответ все равно отрицательный. Многие люди не знают, что большинство рекурсивных реализаций DNS кэшируют небытие записей в дополнение к их существованию. Вместо подачи ложных данных DNS-серверов, которые просто займут больше места в DNS-кешах и сбивают с толку людей, которые пытаются запросить ресурс (потому что вы говорите им разговаривать с IP-адресом вместо того, чтобы сказать им, что его не существует) , вы должны просто сказать этим серверам, чтобы они дольше запоминали ваши несуществующие записи. Как справедливо отмечает касперд, вмешательство в NXDOMAIN на самом деле предотвращает рекурсивные системы от определения несуществования без отправки дополнительных запросов.
Отрицательный TTL контролируется ОТРИЦАТЕЛЬНЫЙ поле TTL и TTL самой записи SOA. Преобладает минимальное (меньшее) из двух значений. Слава Хокану за напоминание!
example.com. IN SOA ns.example.com. hostmaster.example.com. (
2003080800 ; sn = serial number
172800 ; ref = refresh = 2d
900 ; ret = update retry = 15m
1209600 ; ex = expiry = 2w
3600 ; nx = nxdomain ttl = 1h
)
(образец записи SOA заимствован из DNS для ученых-ракетчиков)
Ваш эффективный отрицательный TTL сообщает удаленным рекурсивным серверам, сколько секунд им следует подождать, прежде чем снова спросить, не существует ли записи. Недостатком является (что неудивительно) то, что вы стреляете себе в ногу, если ваша компания преждевременно начинает направлять клиентов к записи DNS, прежде чем она действительно будет запущена. К счастью, вы не можете слишком сильно выстрелить себе в ногу, поскольку большинство программного обеспечения DNS-серверов игнорируют очень высокие значения TTL (включая отрицательные), которые превышают максимум, который они определили в своей локальной конфигурации.
Короче говоря, почти всегда лучше честно сказать, что записи не существует. Рекламируйте меньший отрицательный TTL, если вы хотите, чтобы удаленные серверы дольше запоминали отсутствие ваших данных или идентифицировали Зачем вы получаете так много устаревших запросов на данные и решаете проблему в ее источнике. (устаревшие ссылки и т. д.)