Как узнать ttl в linux
Обновлено: 02.07.2024
Команда dig(1) — это удобный инструмент для получения информации о DNS и устранения неполадок. Его можно использовать для получения значений TTL (время жизни) хоста или домена.
Эта информация может иметь решающее значение для планирования замены DNS и определения того, как долго оставить старый сервер включенным.
В большинстве случаев я бы рекомендовал установить низкое значение (5 минут или меньше) для нормальной работы, но некоторые интернет-провайдеры и провайдеры все еще стесняются уменьшать эти значения, поэтому всегда полезно проверить.
TTL для определенного хоста
Вывод Dig по умолчанию предоставляет информацию о TTL, это число, предшествующее типу записи (подчеркнуто ниже):
Примечание. Если ваш DNS-сервер по умолчанию не является полномочным сервером для зоны, которую вы копаете, dig покажет оставшееся время (до следующего обновления) вместо необработанного значения TTL в этой позиции.
TTL по умолчанию (и отрицательный TTL) для домена
Мы также можем получить параметр TTL для всего домена, который управляет отрицательным TTL (как долго сервер будет кэшировать ответ NX или "ничего там"). Это также преобразует SOA в более удобный для чтения формат:
Дополнительную информацию о множестве применений dig можно найти в DiG HOWTO Пола Хайнлайна.
Особая благодарность Джеймсу Сноу, который предоставил первоначальные факты и вдохновение для этой публикации.
3 ответа на «КАК: Использование dig(1) для поиска значений времени жизни (TTL) DNS»
Да, не всегда после кризиса, когда нам нужна быстрая смена доменного имени, мы, наконец, не забываем изменить TTL или поискать.
Параметр @8.8.8.8 может быть полезен для получения данных с DNS-серверов Google, а команда Windows ipconfig /displaydns очень хороша для локального ttl на вашем компьютере.
Резолверы Google не всегда отражают срок жизни, указанный в исходном файле зоны. Однако, как правило, это в наших интересах, так как значения TTL, которые я получил от Google, были ниже, чем значения TTL в файле зоны.
Получите только TTL с помощью:
Этот сайт использует Akismet для уменьшения количества спама. Узнайте, как обрабатываются данные ваших комментариев.
DNS TTL, или время жизни, — это элемент записи DNS, который сообщает запрашивающей стороне, как долго запись действительна.
Другими словами, если TTL для нашей DNS-записи установлен на 24 часа, после того, как браузер разрешит эту DNS-запись, он будет продолжать использовать то же значение в течение следующих 24 часов независимо от того, обновлялась ли DNS-запись. или нет.
- Почему значение TTL DNS важно?
- Выше или ниже TTL DNS?
- Можно ли установить более короткие TTL?
- Распространенные значения TTL
- Рекомендации по времени жизни DNS.
- Пример срока жизни DNS
- Когда использовать длинный TTL
Почему значение TTL DNS важно?
DNS TTL крайне важны для веб-сайтов, которые часто вносят постоянные изменения и обновления. Имея более низкий TTL, мы можем гарантировать получение самых последних обновлений в заданный период времени.
Наше время жизни имеет решающее значение для прямого управления кэшированием нашего преобразователя. Например, наш преобразователь DNS будет извлекать запись DNS со своего авторитетного сервера каждый час. Затем в течение этого часа каждый пользователь, который запрашивает этот DNS-сайт, получит кэшированную версию веб-сайта, пока преобразователь снова не получит еще одну копию обновления с авторитетного сервера. Этот процесс использования кэша преобразователя значительно улучшает общее впечатление наших конечных пользователей.
Выше или ниже TTL DNS?
Если установлено слишком большое значение TTL, новая запись DNS не может быть обновлена на стороне клиента, так как изменение вступит в силу для существующих пользователей слишком долго.
Однако установка очень низкого значения TTL приводит к дополнительным издержкам, поскольку запросы DNS должны выполняться гораздо более регулярно, что увеличивает время загрузки страницы для пользователя и увеличивает нагрузку на DNS-серверы.
Значения TTL по умолчанию традиционно составляли 24 часа, и обычно приходилось ждать более суток, чтобы изменения DNS вступили в силу.
Можем ли мы установить более короткие TTL?
Да, мы можем установить более короткие TTL. Однако это может привести к большей нагрузке на авторитетный сервер имен, но может быть полезно при изменении адреса критически важных служб, таких как веб-серверы или записи MX (указатели почтового сервера), и поэтому администратор DNS часто снижает их перед перемещением службы. , чтобы свести к минимуму сбои.
Общие значения TTL
Обычно значение TTL составляет 86 400 секунд, что составляет 24 часа. Это хорошая отправная точка для большинства записей. Однако мы можем установить более высокий TTL для записей MX или CNAME, поскольку ожидается, что они будут меняться очень редко. Если наша служба критична, рекомендуется установить TTL на 1 час (3600 секунд).
Рекомендации по времени жизни DNS
По большей части нет необходимости изменять наш TTL. Однако, если мы знаем, что скоро произведем серьезное изменение DNS, и хотим, чтобы изменения вступили в силу как можно скорее, мы можем заблаговременно изменить TTL.
Не менее чем за 24 часа до назначенного времени уменьшите значение TTL. Например, мы можем изменить его на 3600 (1 час).
Когда наша работа будет завершена, обязательно вернитесь и верните наши настройки TTL к исходным значениям. Кэширование DNS — важный способ снизить нагрузку на серверы, и лучше всего поддерживать низкий уровень этого трафика.
Проверьте срок жизни DNS с помощью команды dig
Самый простой способ посмотреть настройки TTL — воспользоваться утилитой dig, доступной в Linux, Unix и Mac OS X.
Это вернет информацию DNS (включая значения TTL) для доменного имени.
Здесь мы видим, что ttl для этих записей равен 0.
Проверьте срок жизни DNS с помощью команды nslookup
интернет-адрес = 162.159.138.9
ttl = 0
интернет-адрес = 162.159.137.9
ttl = 0
Когда использовать длинный TTL
Вот основные записи, у которых должен быть более длинный TTL:
MX-запись (указывает на почтовый сервер)
DKIM и SPF (обычно настраиваются с записями MX)
Записи, которые указывают на веб-сервер или CDN, записи A и CNAME соответственно, обычно имеют более длительный срок жизни, поскольку они редко изменяются. Для них мы хотели бы установить TTL от 12 часов до 1 дня.
Имейте в виду, что нам нужно будет снизить TTL и дождаться истечения срока действия кеша (обычно около суток), прежде чем вносить какие-либо изменения.
Примечание. Этой публикации больше года, поэтому содержащаяся здесь информация может быть устаревшей. Если вы что-то заметили, оставьте комментарий, и мы постараемся исправить это.
Частью запуска нового сайта может быть перемещение записей DNS. Перед тем, как сделать это, было бы действительно хорошей идеей разобраться со временем жизни (TTL) записи DNS, чтобы при изменении записей DNS вы не ждали целый день, пока DNS разберется сам. Большинство регистраторов DNS позволяют вам установить срок жизни до минуты или около того.
Также очень важно проверить статус ваших записей DNS, чтобы убедиться, что они имеют правильный TTL, обычно за день до (и день) перемещения.
Вы можете проверить значение TTL вашей записи A с помощью команды host. Измените значение флага -t (тип) на aaaa или cname, чтобы проверять различные типы записей.
Это приведет к следующему результату. TTL указанного ниже домена — "125".
Также можно проверить тот же результат с помощью команды dig.
Это приводит к следующему результату. Значение TTL для домена — "91".
Если вы обеспокоены тем, что ответ был закеширован в восходящем потоке (именно так работает DNS и почему вам в первую очередь нужно снизить TTL), вы можете напрямую запросить ответ у DNS-сервера имен. Это делается с помощью команды whois.
Это многое скажет вам о доменном имени. Важный бит информации называется сервером имен. Различные провайдеры TLD будут создавать разные выходные данные whois, но информация будет где-то там.
Для моего собственного сайта записи сервера имен выглядели так.
Имея эту информацию, вы можете напрямую опросить DNS-сервер, используя следующее.
Это, пожалуй, самый надежный способ проверить значения TTL вашего домена, поскольку он исключает кэширование результатов.
И наконец, не забывайте проверять все переносимые домены и поддомены. В частности, это означает проверку вариантов с www и без www для каждого переносимого адреса.
Хотите узнать больше? Нужна помощь?
Поможем! Наймите нас для обучения, советов, устранения неполадок и многого другого.
Знаете ли вы, что мы можем определить, какая операционная система работает на удаленной системе, просто проверив ее связь? Да! В этом кратком руководстве мы увидим, как определить операционную систему с помощью значения TTL и команды Ping. Этот метод должен работать в любой операционной системе, в которой есть утилита командной строки Ping.
Существует множество команд, приложений и утилит для определения операционной системы удаленной системы. Однако определить тип операционной системы с помощью TTL очень просто!
Вы можете быстро определить, работает ли система с Linux, Windows или любой другой ОС, просмотрев значение TTL в выводе команды ping. Вам не нужны никакие дополнительные приложения для определения операционной системы удаленной системы.
Значение TTL зависит от версии операционной системы и устройства.
Исходное значение TTL по умолчанию для Linux/Unix равно 64, а значение TTL для Windows равно 128.
Вот начальные значения TTL по умолчанию для популярных операционных систем, таких как Linux, FreeBSD, Mac OS, Solaris и Windows.
Значения TTL для операционных систем
Вы можете просмотреть полный список значений TTL для различных операционных систем и устройств в конце.
Определить операционную систему удаленного хоста по значению TTL
TTL (время жизни) – это значение таймера, включаемое в пакеты, отправляемые по сетям на основе TCP/IP, которое сообщает получателям, как долго следует удерживать или использовать пакет или любые содержащиеся в нем данные до истечения срока действия и отказа от пакета. или данные.
Команда Ping используется для проверки подключения и доступности системы или устройства в локальной или глобальной сети. Команда Ping предустановлена в большинстве операционных систем.
Чтобы просмотреть значение TTL хоста Linux/Windows, просто пропингуйте хост от самого себя или от других систем в сети:
Пример:
Пример вывода моего рабочего стола Fedora:
Проверка связи хоста Linux
Как вы можете видеть, я получаю 64 в качестве значения TTL в приведенном выше выводе. Потому что это система Linux.
А как насчет хостов Windows? Давайте посмотрим, что мы получим, если пропингуем систему Windows.
Я собираюсь пропинговать рабочий стол Windows 10 с моего рабочего стола Fedora. IP-адрес My Windows 10 — 192.168.122.239.
Пример вывода:
Проверка связи хоста Windows с хоста Linux
Обратите внимание на значение TTL? Оно равно 128. Значение TTL по умолчанию для ОС Windows равно 128.
Начальные значения TTL
В следующей таблице показаны начальные значения TTL по умолчанию для различных операционных систем и устройств.
| Устройство/ОС | Версия | Протокол | TTL |
| AIX | TCP | 60 | |
| AIX | UDP | 30 | |
| Android | 3.2.1 | TCP и ICMP | 64 |
| Android | 5.1.1 | TCP и ICMP | 64 |
| AIX | 3.2, 4.1 | ICMP | 255 |
| BSDI | BSD/OS 3.1 и 4.0 | ICMP | 255 |
| Compa | Tru64 v5. 0 | ICMP | 64 |
| Cisco | ICMP | 254 | |
| DEC Pathworks | V5 | TCP и UDP | 30 |
| Foundry | ICMP | 64 | |
| FreeBSD | 2.1R | < td>TCP и UDP64 | |
| FreeBSD | 3.4, 4.0 | ICMP | 255 |
| FreeBSD | 5 | ICMP | 64 |
| HP-UX | 9.0x | TCP и UDP | 30 |
| HP-UX | 10.01 | TCP и UDP | 64 |
| HP-UX | 10.2 | ICMP | 255 |
| HP-UX | 11 | ICMP | 255 |
| HP-UX | 11 | TCP | 64 |
| Irix | 5.3 | TCP и UDP | 60 |
| Irix | 6.x< /td> | TCP и UDP | 60 |
| Irix | 6.5.3, 6.5.8 | ICMP | 255 |
| juniper | ICMP | 64 | |
| MPE/IX (HP) | ICMP | 200 | |
| Linux | ядро 2.0.x | ICMP | 64 |
| Linux | ядро 2.2.14 | ICMP | 255 |
| Ядро Linux | 2.4 | ICMP | < td>255|
| Linux | Red Hat 9 | ICMP и TCP | 64 |
| MacOS/MacTCP | 2.0.x | TCP и UDP | 60 | MacOS/MacTCP | X (10.5.6) | ICMP/TCP/UDP | 64 | < tr>NetBSD | ICMP | 255 |
| Netgear FVG318 | ICMP и UDP | 64 | |
| OpenBSD | 2.6 и 2.7 | < td>ICMP255 | |
| OpenVMS | 07.01.2002 | ICMP | 255 |
| OS/2 | TCP/IP 3.0 | 64 | |
| V3.2A | TCP | 60 | |
| OSF/1 | V3.2A | UDP | 30 |
| Solaris | 2.5.1, 2.6, 2.7, 2.8 | ICMP | 255 |
| Solaris | 2.8 | TCP | 64 |
| Stratus | TCP_OS | ICMP | 255< /td> |
| Stratus | TCP_OS (14.2-) | TCP и UDP | 30 |
| Stratus | TCP_OS (14.3+) | TCP и UDP | 64 |
| Stratus | STCP | ICMP/TCP/UDP | 60 |
| SunOS | 4.1.3/4.1.4 | TCP и UDP | 60 |
| SunOS | 5.7 | ICMP и TCP | 255 |
| Ultrix | V4.1/V4.2A< /td> | TCP | 60 |
| Ultrix | V4.1/V4.2A | UDP | 30 |
| Ultrix | V4.2 — 4.5 | ICMP | 255 |
| VMS/Multinet | TCP и UDP | 64 | |
| VMS/TCPware | TCP | 60 | |
| VMS/TCPware | UDP | 64 | |
| VMS/Вуллонгонг | 1.1.1.1 | TCP | 128 |
| VMS/Вуллонгонг | 1.1.1.1 | UDP | 30 |
| VMS/UCX | TCP и UDP | 128 | < /tr>|
| Windows | для рабочих групп | TCP и UDP | 32 |
| Windows | 95 | TCP и UDP | 32 |
| Windows | 98 | ICMP | 32 |
| Windows | 98, 98 SE | ICMP | 128 |
| Windows | 98 | TCP | 128 |
| Windows | NT 3.51 | TCP и UDP | 32 |
| Windows | NT 4.0 | TCP и UDP | 128 |
| Windows | NT 4.0 SP5- | 32 | |
| Windows | NT 4.0 SP6+ | 128< /td> | |
| Windows | NT 4 WRKS SP 3, SP 6a | ICMP | 128 | < /tr>
| Windows | NT 4 Server SP4 | ICMP | 128 |
| Windows | ME | ICMP | 128 |
| Windows | 2000 pro | ICMP/TCP/UDP | 128 |
| Windows | семейство 2000 | < td>ICMP128 | |
| Windows | Server 2003 | 128 | |
| Windows | XP | ICMP/TCP/UDP | 128 |
| Windows | Vista | ICMP/TCP/UDP | 128 |
| Windows | 7 | ICMP/TCP/UDP | 128 |
| Windows | Server 2008 | ICMP/TCP/UDP | 128 |
| Windows | 10 | ICMP/TCP/ UDP | 128 |
Этот метод может не всегда быть точным. Однако это даст представление о базовой операционной системе в удаленной системе. Если вы знаете только IP-адрес удаленной системы, вы можете использовать команду Ping, чтобы получить имя ОС.
Читайте также: