Что такое ttl в dns настройках

What is DNS TTL + Best Practices

DNS TTL (time to live) is a setting that tells the DNS resolver how long to cache a query before requesting a new one. The information gathered is then stored in the cache of the recursive or local resolver for the TTL before it reaches back out to collect new, updated details.

For example, if the DNS TTL is set to 1800 seconds (30 mins), the resolver will have to regather the details around a website like varonis.com every 30 minutes. If 100 users visit the site in that period, they will all see the same thing, until the resolvers update their TTL. Time to live is the least understood in regards to the overall DNS strategy. In the following guide, we will learn about all the details around how DNS TTL operates and also some strategy best practices.

Get the Free Pen Testing Active Directory Environments EBook

If you would like to jump directly to the specifics, use the menu below:

DNS TTL Considerations + Basics

Some high-level considerations need to be understood regarding DNS TTL strategy. A noticeable positive is the quick turnaround time on DNS lookups, thus speeding up your internet browsing experience overall. It is much faster to check a cached version against your local resolver than it is to perform a DNS record lookup.

Now we have to point out some of the pitfalls of TTL, starting with something called DNS Propagation. DNS Propagation is essentially the time it takes for ISPs to update their caches with your new DNS changes. We will get into this in more detail later in the article.

What is a DNS TTL?

DNS TTL (time to live) represents the time each step takes for DNS to cache a record. The TTL is like a stopwatch for how long to keep a DNS record.

It is essential to understand how you are implementing your TTL. You want it to be the perfect balance between “quickly updating” and “resource savvy.” Straying too far in either direction it will cost you both time and resources to accommodate.

What is DNS TTL Used for?

DNS TTLs are vital to websites that make constant changes and updates frequently. By having a lower TTL, you can ensure that you are receiving the most recent updates in a given timeframe.

Your time to live is critical in controlling your resolver caching directly. For example, your DNS resolver will pull a DNS record from its authoritative server every hour. Then for that hour, every user that queries that DNS site will receive a cached version of the website until the resolver pulls another update copy from the authoritative server again. This process of utilizing the resolver’s cache significantly improves your end-users’ overall experience.

What is a DNS Record?

A Domain Name Server (DNS) record is ultimately a simple message that specifies which destination a request should be directed to and how long this specific destination should be cached for before being updated (TTL).

What are typical TTL times for DNS records?

TTL times are always represented in seconds; for example, 300 seconds equals 5 minutes to live. The following TTL times will give you a rough estimate of what typically is set in DNS configuration:

300 seconds = 5 minutes = “Very Short” – Websites within this timeframe use a low TTL focus to make fast changes but still can utilize some level of caching to help reduce resource consumption.

3600 seconds = 1 hour = “Short” – Websites within this timeframe use a low TTL focus to make fast changes but still can utilize some level of caching to help reduce resource consumption.

86400 seconds = 24 hours = “Long” – The opposite applies for websites using a 24 hour TTL as the focus shifts more towards a daily cache utilization.

604800 seconds = 7 days = “Very long” – Weekly TTLs are not as common, but may be used for sites that contain publish or reputable information that does not change all that often (ex. Library resources, reference sites, etc.)

Common Record Types

It is essential to understand the different record types and how they might apply to your situation. Having a good understanding of what is vital to your website will play a critical role in selecting an appropriate time to live. Below, we outline some considerations to take into account.

Why is DNS Cached?

The ultimate goal of DNS caching is to speed up internet load times and decrease the load on the DNS servers. Having a cached DNS allows for the end-user to quickly resolve DNS requests without much delay. The only downfall to caching is if your TTL is set too long for the updates required for your site, the end-users may have a delay in receiving the updated site until the TTL has expired.

Why DNS is about Network Connections, not Devices

Another complexity added is in all the different devices and network connections that happen on a corporate network. Each device on a network may need to update its records at different times or demand more depending on the job at hand. This is where TTL must be accurately set as if you are making a network-level change, but if the TTL on these devices is still on a cached copy, you could cause a panic that “the system is broken” or its “not in sync.” Ensuring that proper tuning is made to all the common records is vital to obtaining an overall network experience that is fast and timely.

How to Choose DNS TTL Values

Now that we have a general idea of what these values are responsible for, we are going to dig in to introduce ways to select values that are fitting to your environment.

What are typical TTL times for DNS TTL Values?

Knowing a baseline for implementing correct TTL for your DNS values is crucial to the overall responsiveness. The following will give you an idea of what the ranges are for the top 500 websites and their averages. Sites included on this list range from local news sites to google.com.

See Moz’s Top 500 Websites and download the CSV.

Reasons for Long & Short DNS TTLs

There are many reasons why you may consider to go long or short with your DNS TTLs. Below, we have outlined some popular reasons for each to help show you that TTLs can help benefit all different aspects of the business.

Reasons for Long:

Reasons for Short:

Recommendations for DNS TTL Values

Digging deeper, you may be curious how different TTLs are distributed across different professions. The following are some of our recommendations based on a person’s responsibility in regards to DNS availability.

DNS TTL Troubleshooting

It is imperative to understand all the ins and outs involved with troubleshooting DNS issues. Proper tuning of TTL at certain times could save your money and time.

How Long Will it Take My DNS to Update?

To honestly know that everyone is seeing an updated DNS record, it is essential to calculate how long it will “actually” take to propagate across DNS. This is accomplished by using the following formula

TTL X (number of steps) = Fully propagated

For example, if your set TTL is 1800 seconds and there are five steps (not counting the authoritative server), then your fully propagated time would be 9000 seconds or no longer than 2 hours and 30 minutes.

What Factors Affect DNS Propagation Time?

As described above, the number of steps is one key factor to consider with calculating propagation time. But the following hidden factors are also things to consider when calculation propagation.

Speeding Up DNS Propagation

There are several ways to speed up DNS propagation. The first is to ensure you switch your TTL to a short time frame to ensure the distribution happens sooner, rather than waiting for your long TTL to expire.

Next would be to ensure your DNS provider supports dynamic changes. This allows you to change your records globally.

Lastly is to test DNS propagation by utilizing several different propagation checkers to ensure the change has taken.

DNS Propagation Check and DNS Lookup

Using several different DNS propagation tools is highly recommended to ensure your changes have taken hold globally. Most of the propagation tools available are free to use and allow you to check against all record types. This check is critical to assess the timing and whether or not any problems have arisen during the rollout.

How Do DNS Lookups Work?

When a DNS request is initiated, the first action that is performed is a local cache check to see if this record has been searched before? If not, then DNS moves on to requests a record. If yes, the DNS then determines if the cache TTL is still active.

These two steps ( checking record cache and checking the TTL) are the first thing to happen with every DNS request guaranteed. If neither of these two questions can be answered with a yes, then a new request is generated to collect a new record.

How much does a DNS lookup cost?

DNS lookups are generally a free service in terms of money, but what you should be most concerned with is how much time it is going to cost you. Each request typically takes around 150 milliseconds to complete. You may be thinking, “that’s nothing,” but when you have thousands of these happening a second, it adds up pretty quickly. Every time someone loads your webpage or resource without caching enable, you are adding another 150 milliseconds to that time bill. Let’s break down an example of this time cost.

Naive DNS Cost Calculations

The following is a detailed example of loading a typical webpage with caching enabled and one without cache enabled. You will notice that the end cost is almost double that without caching. This is why it is so important to find that perfect balance with your TTL setting.

With Caching

(30 image files * 50ms to download each) + (100 ms one-time lookup of the DNS which is then cached) = 1600ms

Without Caching

(30 image files * 50ms to download each) + (30 * 100ms DNS lookups) = 3000ms

DNS TTL Best Practices

See some different DNS TTL best practices for change management listed below.

How do I know when a client will request the updated DNS record?

It is essential to understand that DNS TTL is not an instant change or an expiry date. Think of it as a rollercoaster ride. When you get on a rollercoaster, the tenets of the coaster must walk by and check that everyone’s seatbelt and bar are correctly placed. They start and one end and work their way to the end of the coaster, they can check everyone all at once on demand.

What’s the Best Practice for adding a new DNS record?

Adding a new record is much easier than modifying an existing one. Still, the same best practice is encouraged for lowering your TTL before and then raising back to normal levels shortly after the new record is created.

What’s the most common TTL setting?

Earlier in the article, we reviewed the averages for the top 500 Moz domains, comparing their TTLs. It is safe to say that a solid long TTL is around 1 hour (3600 seconds) and a short TTL of 5 minutes (300 seconds).

Hopefully, this article will be insightful in helping organizations fine-tune their DNS TTL to optimize performance and availability across its resources.

If you are concerned about your network perimeter now with everyone working from home due to the COVID-19 crisis, check out what the professionals are using to ensure data exfiltration is not happening on their watch.

DNS TTL FAQs

Below we’ve included commonly asked questions around using DNS platform tools.

How do I check the TTL of a DNS record on Windows?

Simple, you probably have run this command before and didn’t even realize it. From your command prompt (CMD) run “nslookup” then the name of your URL to resolve. You can get specific and check things like the CNAME or even produce different levels of information straight from this one-line command. Below is an example of performing a nslookup in Windows:

The TTL is shown outlined in red.

How do I check a DNS record from the Web?

There are tons of DNS record checking websites and tools available for on the go DNS checking. Google has a free version of its DNS checker that is very lightweight and effective.

Is there any way to force a client to update their DNS record remotely?

Unfortunately, there is not a way to “force” a DNS record update remotely. The best advice is to plan ahead of time and change your TTL to a short time before making a significant change.

Jeff has been working on computers since his Dad brought home an IBM PC 8086 with dual disk drives. Researching and writing about data security is his dream job.

Источник

TTL значения записи в DNS

DNS система является одной из фундаментальных технологических решений, на которых базируется интернет. Практически весь спектр сетевых запросов верхнего уровня функционирует посредством использования возможности выполнения поиска DNS (поиску таких имен как yournet.kz и преобразованию их в IP-адрес). Среди них HTTP запросы, пересылка писем, и много других механизмов, которые продолжают работать уже значительное время по всему интернету, а также в локальных сетях.

В данном посту мы поговорим о таком параметре как TTL-записи. Каждый домен в настройках DNS-сервера содержит некоторый набор ресурсных записей (Resource Records), которые служат для того, чтобы домен мог полноценно функционировать в сети. Среди таких параметров обычно присутствуют A, MX, NS, TXT, CNAME-записи, и другие. Для каждой такой записи указывается параметр TTL, который указывает время жизни (Time To Live). Данный параметр довольно часто остаётся незамеченным, т.к. в большинстве случаев оставляется по умолчанию при настройке записей доменов.

Для чего используется TTL записи

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

Время жизни TTL

Таким образом мы пришли к самому определению времени жизни TTL. Время жизни (TTL) указывает длительность кэширования записи для участников системы. В качестве базовой единицы величины TTL используются секунды. В этом случае, если запись, найденная при поиске данных, содержит величину TTL равной 3600, то длительность хранения записи в DNS кэше будет 1 час. После этого запись будет удалена.
Стоит понимать, что изменение значения TTL не влияет на скорость обновления данных в системе DNS, при внесении изменений в записи доменного имени. Данный параметр сообщает другим серверам через сколько времени запись теряет свою актуальность, после чего, кэширующий сервер должен будет отправлять повторный запрос.

Конфигурации записей DNS могут содержать величины TTL указанные в таком виде:

Как работает поиск в DNS
Условно поиск записей по всей системе можно разделить на звенья. При вводе URL в адресе вашего браузера запускается целая серия поисков. Логика поиска сводится к тому что происходит проверка вида:
1) Есть ли данные по записи в кэше?
2) После нахождения записи проверяется не превысил ли срок TTL с момента её добавления?
3) Если запись не актуальная (согласно TTL), то запрос перемещается на следующее звено цепочки поиска.

Практически все современные веб-браузеры выполняют самостоятельное кэширование данных о сайте. Подобным образом браузера хранят кэш и записей DNS. Браузер может некоторое время хранить данные, а каком-либо сайте без учёта TTL. Всё это так же делается для того, чтобы максимально ускорить отрисовку сайта в браузере, и сократить время на поиски. Аналогично происходит и с другими программами вроде FTP-клиентов, и мессенджеров.

Как принудительно обновить все DNS-записи для домена?

Вопрос может стать актуальным при работе с действующим проектом. К примеру, если проект мигрировал на другой сервер, и есть необходимость сократить время ожидания обновления данных на промежуточных звеньях. И к сожалению, из-за архитектурной особенности системы сделать это принудительно невозможно. По этой причине хостинг провайдеры всегда просят подождать около 24 часов с момента обновления записей в DNS.
На этом у меня всё, надеюсь информация была для вас полезной, всего доброго!

Источник

Что такое TTL

Time to live (TTL) – это время жизни пакета. TTL показывает максимальный период времени существования набора данных (пакета).

TTL IP-пакетов

В IPv4 TTL представляет собой восьмиразрядное поле IP-заголовка. Параметр TTL считается верхней границей времени существования IP-дейтаграммы в сети. Поле TTL устанавливается отправителем пакета и уменьшается в течение всего процесса передачи данных, в соответствии со временем пребывания в данном устройстве, согласно протоколу обработки.

Основное назначение – не допустить длительной задержки, когда, например, в процессе передачи данных маршрутизатор отключился или была потеряна связь между двумя узлами.

В каждой промежуточной точке (маршрутизаторе) значение поля TTL уменьшается на 1 (данный параметр изменяется) до тех пор, пока пакет данных не достигнет точки назначения.

При условии, что значение на каком-либо из задействованных узлов достигнет 1, пакет данных уничтожается, а на исходный сервер посылается сообщение о необходимости повторить передачу пакета. В этом случае отправителю отправляется ICMP-пакет с кодом 11 — «Превышение временного интервала». При слишком маленьком значении пакет может просто не дойти, при слишком большом, в случае задержки, ожидание может занять много времени (при значении TTL 255 оно достигает 4 минут и 10 секунд).

Маршрутизатор не пропускает пакеты с нулевым значением TTL. Это делается для того, чтобы в случае ошибочной маршрутизации пакет не «гулял» бесконечно по сети, а уничтожался через некоторое время.

TTL у DNS

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

При использовании стандартных настроек TTL обновление произойдет на сервере через день. Перед запланированными процедурами первую строку записи следует изменить на значение 550 или меньше, после чего ввести serial number и перегрузить зоны, обновив DNS-сервер. После обновления данных можно начинать производить необходимые процедуры по миграции серверов. Проверку произвести с помощью команды dig. После этого произойдет обновление IP-адресов в течение указанного времени.

После выполнения всех процедур по передаче данных, значение TTL можно увеличить, чтобы снизить нагрузку на DNS-сервер и избежать использования большого трафика для обновления зон.

Источник

Полное руководство по настройке DNS TTL (Перевод)

Понимание работы 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 (хотя большинство, к счастью, знали).

Riddle me this! With respect to DNS, what does TTL stand for?

Чтобы помочь в этой ситуации, мы рассмотрим:

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 адрес в своём браузере, создается целая серия запросов:

На каждом этапе этого процесса задаются следующие вопросы: (часто шагов больше, чем перечислено здесь)

Если ответ на любой из этих вопросов «нет», то запрос перемещается на следующий шаг вверх по цепочке.

Почему DNS относится к сетевым подключениям, а не к устройствам

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

Рассмотрим обычный портативный компьютер. Мой более или менее «приклеен» к столу, и хотя он не двигался неделями, я подключился к:

Каждый раз при переключении между сетями создается новая цепочка 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 полностью распространились, может потребоваться несколько дней, планируйте соответственно».

Есть ли способ заставить клиента обновлять свои 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 для этой записи. В идеале у вас будет следующий процесс:

Какова лучшая практика для добавления новой DNS записи?

Добавление новых записей проще, чем изменение существующих.

Какое значение TTL самое распространенное?

Так много споров вокруг того, какими должны быть ваши настройки TTL, что мы подумали, что попытаемся сформировать какие-то жесткие данные. Сайты Moz Top 500 представляют собой отличное сечение веб сайтов, и они уже проделали большую работу, поместив их все в CSV файл.

Я написал быстрый скрипт для перебора списка и поиска текущего TTL первичной записи для каждого домена. Как и любой тип проекта данных, в зависимости от того, как вы задаете вопрос, эти данные дико неактуальны. Это недостаточно широкая выборка, он вытягивает текущие (кэшированные) результаты и т.д. и т.п. При таком отказе от ответственности все же есть некоторые отличные идеи для получения результатов.

Анализ TTL Top 500 Moz доменов

Посмотреть / изменить сценарий или загрузить и запустить его самостоятельно: https://gist.github.com/mbuckbee/79b2e76bd9271bea38487defd8a9138b

Посмотреть список и загрузить CSV: https://moz.com/top500

Самые низкие значения поступают от доменов, которые выполняют очень быстрые изменения 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

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 из гуглокартинок:

Источник