Понимание работы DNS – это вам не Косынку мышкой раскладывать. Как гласит одна из сетевых истин – всё сложнее, чем кажется на первый взгляд, всегда можно копнуть глубже.
Ниже представлен перевод статьи для «самых маленьких» администраторов https://blog.varonis.com/definitive-guide-to-dns-ttl-settings/. А после статьи моё послесловие и несколько полезных ссылок.
Примечание к переводу: (DNS) lookup и request должны переводится по разному, но в русском варианте обычно используется только слово запрос. Слово resolve, имеющее перевод разрешать выглядит дико (разрешить ребёнку взять пирожок с полки? при этом «разрешающая способность» звучит вполне привычно), поэтому перевожу как возвращать или обрабатывать, хотя большинство инженеров использует прямое прочтение резолвить.
Введение
DNS является основополагающей частью [любой] технологии. Почти каждый сетевой запрос на уровне приложений, весь интернет трафик, веб поиск, электронная почта и т.д. полагаются на способность [службы] DNS возвращать ответы на запросы (переводить имена, такие как some.domain.org, в IP адреса или другие домены).
Мы хотели написать о Time To Live (TTL), так как большинство системных администраторов ежедневно не взаимодействуют с конфигурациями DNS, и большая часть информации, которая там есть, основана на полузабытых холиварах, полученных в наследство от предыдущих поколений системных администраторов.
Мы спросили в Твиттере, и некоторые системные администраторы даже не были точно уверены в том, что означает TTL (хотя большинство, к счастью, знали).
Чтобы помочь в этой ситуации, мы рассмотрим:
- Основы DNS и TTL
- Траблшутинг DNS TTL
- Лучшие практики для изменения DNS записей
- Инструменты DNS
- Следующие шаги
1. Основы DNS
Что такое DNS запись?
Записи сервера доменных имен (DNS) определяют две важные вещи:
Куда должны указывать (где обрабатываться) запросы к записи.
Как долго запись может быть кэширована до ее повторного запроса – это зловеще называется Time To Live (TTL) записи.
Почему DNS кэшируется?
Большинство организаций настраивают DNS записи, а затем не меняют их в течение многих лет. Поскольку DNS записи часто запрашиваются, но редко обновляются, кэширование очень эффективно для повышения производительности сети за счет повышения сложности рассуждений [о причинах] и устранения неполадок DNS.
Что такое TTL?
Время жизни показывает, как долго каждый шаг цепочки DNS запросов будет кэшировать запись. TTL отслеживается в секундах (подождите, это будет важно чуть позже).
Этот термин действительно не отражает нюансов: несмотря на то, что это определенно «время жизни», это может иметь больше смысла, если вы думаете об этом как о «времени выполнения запроса» или о том, «как долго хранить эту DNS запись в кэше».
Каковы типичные интервалы TTL для DNS записей?
Значения TTL всегда представлены в секундах. Большинство служб настройки конфигурации DNS предоставляют вам предварительно заданный список значений для использования в записях.
300 секунд = 5 минут = «Очень короткий»
3600 секунд = 1 час = «Короткий»
86400 секунд = 24 часа = «Длинный»
604800 секунд = 7 дней = «Безумие»
Как работают DNS запросы?
Когда вы вводите URL адрес в своём браузере, создается целая серия запросов:
На каждом этапе этого процесса задаются следующие вопросы: (часто шагов больше, чем перечислено здесь)
- У нас есть эта запись в кэше?
- Если она кэширована, остается ли TTL действительным?
Если ответ на любой из этих вопросов «нет», то запрос перемещается на следующий шаг вверх по цепочке.
Почему DNS относится к сетевым подключениям, а не к устройствам
Устранение неполадок DNS сложно не только потому, что TTL и система кэширования вносят сложности, а потому, что многие современные устройства подключаются через разные сети и цепочки DNS серверов.
Рассмотрим обычный портативный компьютер. Мой более или менее «приклеен» к столу, и хотя он не двигался неделями, я подключился к:
- Моей обычной домашней Wi-Fi / кабельной сети;
- Моему сотовому телефону, когда кабельная сеть не работала;
- Оба вышеуказанных способа, но с подключенным VPN.
Каждый раз при переключении между сетями создается новая цепочка DNS. Если вы находитесь в процессе внесения изменений, серверы и кэши в цепочке DNS могут иметь или не иметь правильную информацию.
Это часто происходит в корпоративных сетях, где домен Active Directory совпадает с веб сайтом компании. Внешний DNS сервер (на уровне ISP) имеет DNS запись, которая указывает «www.example.com» на правильный IP адрес веб сервера / CNAME, но на внутреннем сервере DNS, используемом Active Directory, записи не были зеркалированы.
Так что вы получите паникующих людей. «Веб сервер не работает!», «Небо падает», «Где мои штаны?»… и когда вы начнете устранять неполадки, вы обнаружите, что на самом деле произошло то, что они оставили свою VPN сеть подключенной (прим. пер.: “The webserver is down!” – посмотрите это видео, “the sky is falling” – своего рода «игра», когда вы говорите своему другу «небо падает», и тут же ударяете его кулаком по голове, “where are my pants?” – фобия остаться без штанов в публичном месте и приколы и игры основанные на ней).
Прим. пер.: почитайте про утечку DNS в Windows https://habrahabr.ru/post/264503/
2. Траблшутинг DNS TTL
Траблшутинг – поиск и устранение неполадок.
Сколько времени займет обновление моего DNS?
Чтобы рассчитать максимальный (наихудший) период времени, который потребуется между обновлением DNS записи и уверенностью в том, что каждый клиент теперь ссылается на новое значение, умножьте количество шагов (не считая авторитетного сервера) на значение TTL (авторитетный или авторитативный сервер – это сервер который хранит оригинальную DNS запись, т.е. ответственный за запрашиваемую зону).
Так что, если ваш TTL составляет 3600 секунд (1 час), и есть 5 шагов, он не должен занимать более 18 000 секунд (5 часов), чтобы изменения полностью распространились.
Постойте, любезный!
Сколько стоит DNS запрос?
Когда вы спрашиваете, сколько DNS запрос «стоит», вы обычно не беспокоитесь о деньгах. Вы беспокоитесь о времени. В зависимости от остального зоопарка сетевых уродцев, запрос DNS обычно занимает от 100 до 200 миллисекунд.
Хотя это очень небольшое количество времени, рассмотрим веб страницу. Для каждого изображения, файла css и файла ресурсов javascript, на которые ссылается страница, необходимо вернуть их DNS записи. Без кэширования вы бы значительно увеличили время загрузки.
Наивные вычисления стоимости DNS
Это «наивно», поскольку маловероятно, что каждый ресурс на вашем веб сайте будет обслуживаться из другого домена, и у браузеров есть много хороших уловок и стратегий кэширования, чтобы сделать вещи быстрее, чем эта упрощенная модель того, как они работают.
С кэшированием
(30 файлов изображений * 50 мс для загрузки каждого из них) + (100 мс одно время запроса DNS, который затем кэшируются) = 1600 мс
Без кэширования
(30 файлов изображений * 50 мс для загрузки каждого из них) + (30 * 100 мс время запроса DNS) = 3000 мс
Почему мое обновление DNS не выполняется?
Кроме того, могут быть дополнительные факторы, которые увеличивают время распространения сверх базового расчета. Некоторые примеры включают в себя:
- Веб браузеры внутренне кэшируют DNS записи для периодов времени, не контролируемых TTL, чтобы казаться «быстрее». Например, современные версии Internet Explorer кэшируют DNS на 30 минут по умолчанию (до IE 4 это было 24 часа) и будут игнорировать TTL ниже этого значения.
- Мобильные интернет провайдеры могут стремиться уменьшить общий трафик за счет увеличения времени TTL, уменьшая частоту выполнения запросов.
- Сложные внутренние сети с бóльшим количеством DNS серверов, чем вы ожидали, естественно, потребуют больше времени для обновления.
Вышеупомянутое является причиной, по которой большинство служб содержат что-то вроде: «Для того, чтобы изменения DNS полностью распространились, может потребоваться несколько дней, планируйте соответственно».
Есть ли способ заставить клиента обновлять свои DNS записи удаленно?
Обычно этот вопрос задают в контексте: «Я обновил мои DNS записи, и теперь клиент не может связаться с каким-либо сайтом, как я могу принудительно выполнить обновление?»
К сожалению, ответ «нет». Не существует команды конфигурации DNS, которую вы можете ввести для принудительного досрочного обновления у нижестоящих клиентов.
Есть команды, которые вы можете запустить для удаления DNS записи из локального кэша, но обычно они работают не так эффективно, как можно было бы надеяться, поскольку у вас все еще есть вышестоящие кэши (кэширующие DNS серверы провайдера) и нижестоящие (кэширование DNS в браузере).
Ваш лучший выбор – изменить TTL для ваших записей заранее.
3. Лучшие практики для изменения DNS записей
Что лучше: короткий или длинный TTL?
Разработчики долгое время ведут холивары по поводу того, должны ли отступы в коде быть табуляторами или пробелами. Я обнаружил, что сетевые администраторы испытывают нечто похожее по отношению к величине TTL.
Обычно мнение людей как бы намекает, какие атаки или фиаско с конфигурацией испытывали их сети.
DDOS атака, которая нарушает работу DNS серверов на корневом / ISP серверах в течение 12 часов, будет иметь меньшее влияние на сайты с очень длинным TTL. Длинный TTL позволяет клиентам продолжать работать, даже когда DNS сервер находится в оффлайне или перегружен.
Но если вы надумали переключить веб узел или сервер электронной почты, и изменили DNS запись, то последнее, что вы хотите, это получить ситуацию, когда изменения заморозятся на 12 часов. И потому есть люди, которые отстаивают TTL со значением в минуту.
Мое личное предпочтение – иметь короткие (менее 1 часа / 3600 секунд) интервалы TTL.
Как узнать, когда клиент запросит обновленную DNS запись?
Очень сложно оценить когда все клиенты будут обновлены.
Смотрите, TTL – это не «дата свежести». Не рассматривайте DNS TTL как дату «годен до» на несвежей буханке хлеба – это не исключительное время, когда запись превращается из хорошей в плохую и нуждается в замене.
DNS намного больше похож на организационную диаграмму, где по мере внесения изменений, изменения медленно распространяются на всю сеть по прошествии времени, а у нижестоящих клиентов (вы ведь помните что промежуточный DNS сервер является клиентом для вышестоящего сервера?) в диаграмме их кэши истекают и запрашивают запись с вышестоящего DNS сервера.
Прим. пер.: утрируя, ситуацию можно проиллюстрировать такой диаграммой, где по горизонтали будет время, а точнее периоды нахождения DNS записи в различных кэшах.
Затем в момент, отмеченный ярко-красным цветом, у нас обновляется DNS запись, записи в остальных кэшах становятся неактуальными и обновление начинает распространяться вниз по цепочке в сторону клиента.
Какова наилучшая практика для изменения DNS записи?
Для чего-то относительно простого, например, для изменения одной записи в домене, может показаться излишним иметь «план» или «стратегию», но, учитывая очень серьезную критичность DNS, необходимо проявлять осторожность. Это как старая поговорка: «щепотка загодя стоит пуда после» (прим. пер.: русский аналог – «предотвратить легче, чем лечить», или «дорого яичко ко христову дню»).
Есть простой способ ограничить свои ошибки: никогда не обновляйте одновременно DNS запись и TTL для этой записи. В идеале у вас будет следующий процесс:
- Уменьшите TTL для DNS записи до очень низкого значения за пару дней до того, как вам действительно нужно будет сделать переключение. Например: 300 секунд;
- Измените фактическую запись в день переключения;
- Через несколько дней после того, как вы сделали переключение, увеличьте TTL до более высокого значения.
Какова лучшая практика для добавления новой DNS записи?
Добавление новых записей проще, чем изменение существующих.
- Добавьте запись с низким TTL.
- После того, как вы убедитесь, что все работает, увеличьте значение TTL.
Какое значение TTL самое распространенное?
Так много споров вокруг того, какими должны быть ваши настройки TTL, что мы подумали, что попытаемся сформировать какие-то жесткие данные. Сайты Moz Top 500 представляют собой отличное сечение веб сайтов, и они уже проделали большую работу, поместив их все в CSV файл.
Я написал быстрый скрипт для перебора списка и поиска текущего TTL первичной записи для каждого домена. Как и любой тип проекта данных, в зависимости от того, как вы задаете вопрос, эти данные дико неактуальны. Это недостаточно широкая выборка, он вытягивает текущие (кэшированные) результаты и т.д. и т.п. При таком отказе от ответственности все же есть некоторые отличные идеи для получения результатов.
Анализ TTL Top 500 Moz доменов
Посмотреть / изменить сценарий или загрузить и запустить его самостоятельно: https://gist.github.com/mbuckbee/79b2e76bd9271bea38487defd8a9138b
Посмотреть список и загрузить CSV: https://moz.com/top500
| Самый низкий TTL: | 1 |
| Самый высокий TTL: | 129 540 |
| Количество доменов: | 485 |
| Средний TTL: | 6468 |
| Медиана TTL: | 300 |
Самые низкие значения поступают от доменов, которые выполняют очень быстрые изменения DNS для целей балансировки нагрузки. Самые высокие от доменов, которые не обновлялись в течение длительного времени (python.org, я смотрю на вас).
С точки зрения необходимости отстаивать решение о том, чтобы иметь короткий (менее 1 часа, 3600 секунд) TTL, вы можете указать на среднее значение 300 секунд (5 минут) и уверенно заявить, что у вас есть эмпирические данные о том, каким должно быть значение.
4. Инструменты платформы DNS
Как проверить TTL DNS записи в Windows?
Утилита nslookup https://technet.microsoft.com/ru-ru/library/bb490950.aspx это самый простой способ проверки DNS записей в Windows
Пример: nslookup -type=cname -debug www.varonis.com
TTL указан в нижней части вывода. «Non-authoritative answer» (не авторитетный ответ) указывает, что это TTL, как его видно от клиента (у нас есть 2 минуты и 11 секунд, пока локальный клиент не проверит следующий уровень в DNS).
Как проверить TTL DNS-записи на Unix / Linux / Mac?
В Unix (и производных) систем для поиска неисправностей используется команда dig (хотя nslookup обычно тоже в наличии).
Пример: dig www.varonis.com
Значение TTL выделено красным цветом.
Как проверить DNS запись из Интернета?
Вы не всегда имеете доступ к своему компьютеру когда вам нужно проверить DNS запись. Удобная (и бесплатная) версия dig доступна в Интернете с помощью Google по адресу: https://toolbox.googleapps.com/apps/dig/
Значение TTL выделено красным цветом.
Прим. пер.: гугл почему-то убрал возможность выбора сервера для запросов, хотя во всплывающей подсказке упоминание об этом осталось, поэтому используйте альтернативные сервисы, например: http://www.kloth.net/services/dig.php или http://www.logicalpackets.com/NSLookup/Nslookup.asp
Как проверить распространение DNS TTL?
Если вы пытаетесь выяснить, произошло ли обновление ваших настроек DNS на определенном сервере, все перечисленные инструменты (dig, nslookup и др.) позволяют указать, к какому DNS серверу вы хотите выполнять запросы вместо локальных настроек по умолчанию.
Для того, чтобы получить более полную картину ваших изменений, я рекомендую whatsmydns.net, который будет проверять многие из верхних (уровня ISP) DNS серверов, которые позволят вам узнать, если что-то пошло совсем не так, как планировалось.
5. Следующие шаги
Настройка DNS TTL может быть сложной задачей, но если вы установите короткие (менее часа) значения интервалов, то сохраните себе нервы и лучше подготовите сеть для прохождения изменений.
Послесловие
Что меня бесило в начале знакомства с DNS:
- В статьях тема DNS (S = system) обычно неразрывно связана с DNS server, причем эти темы переплетаются и люди сходу начинают рассказывать как настроить сервак, вместо рассказа про систему доменных имён.
- DNS сервер это в 99% BIND (он же Named). По нему много документации, и как следствие, есть очень много противоречивых интерпретаций и мнений, поэтому советую читать оригинальную документацию http://www.zytrax.com/books/dns/ или наиболее близкие к ней переводы, например http://www.bog.pp.ru/work/dns_info.html и http://www.bog.pp.ru/work/bind.html.
- Огромное количество вариаций конфигов для разных видов DNS серверов (Master, Slave, Cache, Stealth, Root http://info.nic.ru/st/8/out_256.shtml). Суть – разные виды серверов являются одним сервером с разными кейсами (сценариями) использования и как следствием – конфигом. Понимание сценария ведёт к пониманию того, что нужно подкрутить/добавить/убавить. Что если у вас нет понимания где брать типовые конфиги для данного сценария? Сложно сказать на счет русскоязычных источников, я обычно редко смотрю в закладки и каждый раз гуглю с чистого листа, но всё же рекомендую http://www.zytrax.com/books/dns/ch4/.
- Люто, бешено бесило бесконечное описание различий параметров в разных версиях BIND в http://www.bog.pp.ru/work/bind.html. Даже не заморачивайтесь, открывайте документацию ТОЛЬКО к своей версии, а сомнительные опции либо игнорируйте, либо вычитывайте в оригинальных доках.
Типичная схема работы DNS из гуглокартинок:
Советы:
- Используйте этот классный пост Лучшие практики DNS для телекома, большинство пунктов не теряют свою актуальность.
- Да и других интересных вещей там много: «Ультимативный DNS-дайджест»
- Повторяя мысли из поста, добавлю, сначала добейтесь работоспособности вашего решения в самом общем виде, потом прикручивайте опции для защиты сервиса, а потом уже тюнингуйте.
- Дизайн вашего решения, как взаимодействия нескольких серверов, так и содержания их конфигов должен быть достаточно прозрачен и логичен.
- Никогда не применяйте изменения в нескольких разделах конфига сразу, быстро оценить изменения в работе сервиса довольно сложно. А неработающий DNS это автоматически неработающий интернет для 99% пользователей, или как минимум какой-нибудь сервис для части пользователей. Можно легко получить ситуацию, когда не будет работать какая-то отдельная комбинация из внешних/внутренних клиентов и типов запросов.
- Используйте с осторожностью опции, относящиеся к безопасности, включайте логирование, следите за ресурсами сервера, прикрутите мониторинг к физическом серверу и DNS серверу (в смысле сервису). Кстати, у Fail2Ban есть шаблоны для DNS серверов.
- Есть много статей по поводу тюнинга DNS серверов, сравнений между различными серверами и т.п. Имейте в виду что:
- Серверы отличные от BIND/Named часто хуже документированы и менее надёжны в долгосрочной перспективе, либо узкоспециализированы.
- Если у вас есть или планируется веб хостинг с панелью или DNS сервер используется внутри провайдера – ответ тот же, не надо пытаться использовать неправильный инструмент. А вот если у вас тестовый стенд, домашний сервак или маленькая конторка, то ради б-га.
