Одминский блог
Изменение значений TTL в сервере DNS/BIND при миграции
На той неделе помогал перевозить клиентов со всеми их серваками и прочим мусором, и вот очень хотелось сделать так, чтобы время разброда и шатания почты по инету, в поиске обновления доменных записей, было минимальным. Основная причина того, что некоторые развеселые клиенты не могут прислать письмо неделями- это устаревание кэша DNS серверов, т.е. вы уже две недели как переехали, а чужой сервер до сих пор полагает, что вы хоститесь под старым IP адресом. Лечится это изменением в меньшую сторону параметра $TTL в SOA записи.
DNS TTL это параметр по аналогии с параметром жизни сетевого пакета (Time To Live) отвечающий за существование записи DNS зоны в кеше DNS сервера, без дополнительных изменений. По достижении установленного времени, кеширующий сервер запрашивает DNS сервер, содержащий доменную зону, информацию о зоне.
В стандартной настройке $TTL равно 86400 секунды, т.ч. если минимальный параметр TTL на вашем доменном сервере DNS и кэширующем сервере удаленного хоста установлен по умолчанию в значение 86400, то обновление произойдет на сервере через день.
Типичная SOA запись выглядит таким образом:
$TTL 3600
@ IN SOA ns.domain.com. abuse.ns.domain.com. (
2009120200 ; Serial
3600 ; Refresh
900 ; Retry
3600000 ; Expire
3600 ) ; Minimum
Перед запланированными процедурами, первую строку SOA записи следует изменить на значение $TTL 600 , или меньше, после чего изменить serial number и перегрузить зоны, т.е. рестартовать DNS сервер и спокойно идти за чаем в ожидании истечения времени указанного для TTL первоначально. После того как эти данные обновятся, что можно проверить с помощью команды dig, можно начинать производить необходимые процедуры по миграции серверов. Изменение IP адресов произойдет в течении указанного времени.
После того как все процедуры по переезду и миграции будут произведены, значение TTL можно перевести в большее значение с тем, чтобы снизить нагрузку на DNS сервер и избежать слишком большого сетевого трафика при обновлении зон.
Understanding TTL Values In DNS Records
In an ideal world, the DNS would be like one of those As-Seen-On-TV rotisserie ovens — set it and forget it. However, the Internet is a dynamically changing place and what may be relevant in one moment may not be the next.
To cope with this, the DNS was designed with a mechanism to refresh records and ensure that users were always given the most pertinent answer when they requested it.
The Basics
Time To Live, or TTL for short, is the sort of expiration date that is put on a DNS record. The TTL serves to tell the recursive server or local resolver how long it should keep said record in its cache. The longer the TTL, the longer the resolver holds that information in its cache. The shorter the TTL, the shorter amount of time the resolver holds that information in its cache.
For example, we’ve got example.com. Example.com has an A-record at the apex of the zone to point us to a server. With a TTL of 3600 seconds, or 1 hour, that means that as a recursive server learns about example.com, it will store that information about the A-record at example.com for one hour. Anyone else who uses that same resolver will get the same answer, and on the authoritative side, there will be no query to the server unless the TTL runs out.
Best Practices
TTLs are nothing to take lightly — they can directly affect the amount of query volume that is attributable to your authoritative service, and in the event of needing to quickly change the record, can result in longer than expected change propagation to all users.
For records that leverage a sort of advanced traffic management scenario, such as NS1’s Filter Chain, it’s best to keep the TTL as short as possible. This way, when a change is enacted by the system, users on the other end requesting the name are given the most recent information. It’s worth noting that most recursive servers do not actually understand a TTL shorter than 30 seconds — while we won’t stop you from going lower than that, the results may not be favorable in the long run.
For records that rarely change, such as TXT or MX records, it’s best to keep those somewhere between an hour (3600s) and a day (86400s). When it does come time to enact changes with regard to these types of records, it may behoove you to change the TTL down to a shorter interval before enacting any changes to ensure that the changes are propagated quickly.
The SOA TTLs
At the top of every DNS zone, in the Start of Authority (SOA), there are five TTL values that serve a higher purpose in the DNS.
SOA TTL — The interval at which the SOA record itself is refreshed.
Refresh TTL — The interval at which secondary servers (secondary DNS) are set to refresh the primary zone file from the primary server.
Retry TTL — The rate at which a secondary server will retry to refresh the primary zone file if the initial refresh failed.
Expiry TTL — If Refresh and Retry fail repeatedly, this is the time period after which the primary should be considered gone and no longer authoritative for the given zone.
NX TTL — In the event that requesting the domain results in a non-existent query (NXDOMAIN), this is the amount of time that is respected by the recursor to return the NXDOMAIN response.
It is recommended to not modify these TTLs unless you have a very specific need to do so, which is often a very rare case.
DNS TTL
DNS TTL на сервере — time to live или время жизни записей зон DNS. Задается в секундах. Это время через которое клиент будет должен вновь запросить информацию с сервера и время, по истечении которого значения записей обновятся после внесения изменений .
Задание DNS TTL на сервере
Для неавторитативного ответа фактически запрос разрешается следующим образом (это самый частый случай):
- Клиент обращается к домену example.com, запрашивая при этом IP адрес сервера, на котором размещается сайт. Запрос уходит на NS сервера, прописанные на компьютере для резолвинга
- Если этим серверам про домен ничего не известно идет обращение на root сервера NS, которых в мире 30. Ответ представляет собой информацию об ответственных за резолвинг example.com NS
- Происходит обращение к ним и возвращается ответ и IP адресом к которому и нужно обращаться чтобы получить контент сайта
В случае с авторитативным ответом исключается второй шаг, в остальном процесс тот же.
Вместе с ответом клиенту передается информация о времени жизни записи, по его истечению и при повторном обращении клиента процесс должен будет выполнен вновь. Это время и есть TTL.
Описанный процесс с точки зрения сети довольно ресурсоемкий и означает передачу трафика и временные задержки.
TTL определяется в настройках DNS сервера, в частности за него отвечает SOA запись для домена. В ней прописывается нужное значение считываемое клиентом при первом обращении.
Стоит иметь в виду, что SOA записью определяется time to live только для одного первичного DNS сервера. Фактически информация обновится через указанное количество секунд в случае если домен делегирован на NS сервер, для которого добавлена запись. Если нет — какое-то время также займет распространение информации на вторичные DNS.
Значение Refresh SOA записи (в секундах) на вторичном DNS сервере определяет как часто информация синхронизируется с первичного сервера (изменения вносятся только на первичном).
Основное правило заключается в том, что значение TTL стоит подбирать с учетом специфики проекта для которого используется домен, но лучше всего ставить 300-600 секунд.
Маленькие значения обеспечат минимальное время простоя в случае если с сервером, обслуживающим сайт, что-то случится и запись потребуется поменять. 300 секунд обычно устанавливают провайдеры, предлагающие защиту от сетевых атак DDOS.
Если приходит атака адрес автоматически меняется и прописывается адрес специальной мощной машины, которая фильтрует трафик и перенаправляет на основной сервер только запросы пользователей, исключая ботов.
В то же время, при маленьких значениях возрастает нагрузка на DNS и, поскольку, обращения происходят гораздо чаще, чаще требуется разрешение запросов к домену, что несколько уменьшает скорость загрузки сайта.
Лучшим решением почти всегда является то, которое учитывает оба обозначенных фактора. Должна быть возможность достаточно быстро изменить записи при необходимости, при этом не генерируя постоянного ненужного трафика.