Ttl что это: Вход/выход TTL-совместимый — что это такое?

Содержание

Что такое время жизни пакета (TTL)

Вероятно, многие из нас обращали внимание на параметр TTL в запущенной команде ping. Расшифровывается TTL как Time to live.

Время жизни пакета это предельное число итераций, которое пакет данных может совершить до своего исчезновения. Выражаясь не так официально, TTL — это число «прыжков» от устройства к устройству, которое может совершить пакет.

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

Возвращаясь к теме статьи, объясним предназначение времени жизни пакета. Дело в том, что данные в сети имеют свойство зацикливаться, что создаёт своего рода «мусорный» трафик. Поскольку количество «прыжков» между узлами у пакетов ограничено, они не смогут «бродить» по сети вечно.

На самом деле, изначально предполагалось, что TTL пакетов будет измеряться в секундах. Так что это должно было быть время в буквальном смысле слова. Однако позже от этой концепции отказались в пользу простого числа «прыжков» или хопов (hop). На каждом промежуточном узле это число уменьшается на единицу (по умолчанию, хотя настройки можно выставить иначе). Если число «прыжков» у пакета истекло, а адресата он так и не достиг, этот пакет уничтожается, а адресату направляется сообщение о необходимости повторной отправки данных (Time Exceeded). Учтите, что коммутаторы оставшееся число «прыжков» не изменяют, так как действуют на канальном уровне (более низком) модели OSI, а не сетевом.

Время жизни пакета задаётся в соответствующем поле в заголовке IPv4-пакета. В стандарте IPv6 используется уже другое поле Hop Limit. Максимально возможное значение TTL равно 255. В большинстве популярных операционных систем (macOS, Linux, Android, iOS и т.д.) TTL=64. В Windows по умолчанию TTL=128.

TTL и интернет-провайдеры

Достаточно интересно используют TTL пакетов интернет провайдеры для обнаружения несанкционированного подключения устройств. Способ массово стал использоваться со временем распространения мобильного интернета и устройств, которые могут этот интернет не только потреблять, но и раздавать другим (смартфоны, планшеты).

Как это выглядит на практике? Если Вы пользуетесь мобильным интернетом со смартфона, то тот отправляет TTL=64, но, если раздать с него Wi-Fi, то TTL подключенных устройств будет изменяться на единицу. Нагляднее это можно проследить на схеме ниже.

Изменение TTL при раздаче Wi-Fi со смартфона.

Таким образом, оператор видит, что TTL «прыгает» с 64 до 63, а то и до 127 (если это ноутбук с Windows), и делает вывод, что в сеть выходит не одно устройство, а больше. В зависимости от условий предоставления связи, это может привести к блокировке.

Мы не будем в этой статье рассматривать способы обхода блокировок. Скажем лишь, что значение TTL по умолчанию можно изменить. Возьмём для примера Windows. Если вы запустите ping localhost, то увидите, что, как и говорилось ранее, TTL=128.

Для изменения установленного по умолчанию значения TTL нам нужно открыть редактор реестра, пройти в ветку HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\Tcpip\Parameters и отредактировать (или создать, если его нет) параметр DefaultTTL. Если у вас 64-битная версия ОС, то тип параметра будет QWORD (64 бита), если 32-битная версия ОС, то тип DWORD (32 бита). Система исчисления — десятичная, а значение можете задать от 1 до 255. Например, 65. Тогда пакеты данных, пройдя через раздающий Wi-Fi смартфон, будут выдавать TTL=64.

Изменение значения TTL в Windows.

После этого перезагрузите компьютер. Снова запустив ping localhost, можно увидеть, что значение TTL изменилось.

Отдельно стоит упомянуть протокол IPv6. Если вы его используете, то нужная вам в реестре ветка: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\TCPIP6\Parameters.

О том, как провернуть подобную настройку в Ubuntu, читайте в статье по этой ссылке.

TTL – что это такое и зачем его менять

Раз вы сюда попали, скорее всего вам нужно поменять TTL для обхода ограничений мобильного оператора на раздачу трафика, но вы не понимаете,  что такое TTL, и зачем его менять. Постараюсь объяснить.

Понятие TTL 

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

TTL расшифровывается как Time To Live, то есть время жизни пакета данных в секундах. При прохождении пакета через очередной роутер TTL уменьшается на единицу. Нужно это для того, чтобы пакет бесконечно не гулял по сети, если не сможет дойти до адресата. Роутер, при попадании в который  пакет исчерпал свое значение TTL, посылает отправителю сообщение ICMP о том, что данный пакет  превысил максимально допустимое время своего пребывания в сети. Максимальное значение TTL=255. Причем разные операционные системы генерируют пакеты с разным TTL.

Если говорить совсем простыми словами…
Представьте себе, что вам 5 лет и вы хотите кушать (вы — пакет). Вы идете к папе и говорите: «Папа, я хочу кушать». Ваш папа смотрит телевизор, согласно таблице маршрутизации о посылает вас к маме. Вы идете к ней и просите «Мамааа, я хочу кушать». Мама болтает с подругой по телефону и согласно своей таблице маршрутизации посылает вас к папе. И так вы ходите как дурак от папы к маме и обратно, туда-сюда, туда-сюда, а все потому что криворукие админы (родители папы и мамы) неправильно настроили таблицу маршрутизации. Чтобы защититься от таких ситуаций придумали понятие TTL (Time To Live), что применительно к нашей ситуации означает количество терпения у мальчика, пока он не скажет «достало» и не упадет перед ногами мамы или папы в беспомощном состоянии. Последний, по правилам (стандарты – это «так заведено в семье»), обязан послать короткий нелестный отзыв адрес того, кто послал мальчика кушать. Это так называемый ICMP-пакет «мальчик сдох»

Ок, так при чем тут операторы? Дело в том, что по полученным от абонента TTL оператор узнает, раздается интернет или нет.

Как операторы узнают, что трафик раздается

Потому что ему от абонента начинают приходить пакеты с разными значениями TTL. На это есть две причины:

  • Во-первых, у разных устройств TTL может быть разным. А при раздаче интернета появляется ведь второе устройство – то, на которое мы раздаем интернет. Так у телефона на iOS или Android значение TTL равно 64, а у компьютера на Windows – 128. И при раздаче интернета с телефона на компьютер появится два разных значения TTL: 64 и 128. Оператору уходят пакеты и с TTL=64, и TTL=127 (при отправке пакета с компьютера через раздающий телефон-роутер значение 128 уменьшается на единицу).
  • Во-вторых, даже если TTL устройств одинаков (с телефона на телефон), раздающий телефон опять же уменьшает TTL на 1 как всякий нормальный роутер.  И оператору уходят пакеты с разными значениями TTL=64 (если это пакет с раздающего телефона) и TTL=63 (пакет с потребляющего телефона).

Итак оператор получает пакеты с разными значениями:

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

На всякий случай прикладываю картинки.

Это работа без интернета. Телефон передает оператору только пакеты с TTL=64.

А при раздаче интернета телефон передает оператору пакеты с тремя разными значениями TTL: 64 от себя, 127 от компьютера и 63 от потребляющего телефона.

 

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

  1. Либо поменять TTL на потребляющем устройстве,
  2. Либо на раздающем телефоне сделать так, чтобы пакеты к оператору шли всегда с одним значением TTL.

Приведение TTL к единому значению для обхода ограничений оператора

  • Можно привести TTL к единому значению 63, поменяв его на раздающем телефоне и на принимающем компьютере. Это изменение TTL без фиксации.
Изменение TTL раздающего телефона и принимающего устройства
  • Можно ничего не менять на принимающих устройствах, но «заставить» раздающий телефон всегда отправлять оператору пакеты с TTL=63, независимо от того, откуда они: с самого раздающего телефона или с принимающего устройства (компьютера или телефона). Это фиксация TTL.
Фиксация TTL

Вторая схема удобнее, но она пригодна не для всех телефонов.

Итак, мы рассмотрели, что такое TTL, и зачем его нужно менять. Как именно изменить TTL требует рассмотрения в отдельной статье. Как изменить TTL на Windows.

 

Автор adminОпубликовано Рубрики ПК

Что такое TTL? | Часто задаваемые вопросы о DigiCert

  1. Часто задаваемые вопросы
  2. Системы доменных имен
  3. Что такое TTL?

Что делает TTL?

Когда вы вводите доменное имя в свой браузер, вы запрашиваете IP-адрес домена у локального разрешающего сервера имен.

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

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

Как работает TTL?

TTL измеряется в секундах, а не в минутах или часах. Если, например, установить 30-минутный TTL, вы переведете 30 минут в секунды для TTL, равного 1800.

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

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

Какой TTL выбрать?

Рекомендуемый TTL зависит от типа записи.

Записи A с отработкой отказа

Для записей A с отработкой отказа рекомендуется значение TTL 180 или ниже. Поскольку IP-адрес записи изменится во время отключения основного IP-адреса, низкий TTL поможет предотвратить переход трафика на отключенный IP-адрес.

Записи A без аварийного переключения

Для записей A без аварийного переключения рекомендуется значение TTL от 1800 до 3600. Эти записи запрашиваются очень часто, поэтому более высокое значение TTL предотвратит взимание платы за большое количество запросов. Но установка значения TTL не выше 3600 позволит вносить изменения в запись в разумные сроки.

Записи A для серверов имен vanity

Для записей A для серверов имен vanity рекомендуется значение TTL 86400, поскольку, хотя запись не изменится, она будет запрашиваться при выполнении нового запроса для доменов с этими серверами имен vanity.

Записи перенаправления CNAME/ANAME/MX/HTTP

Для записей перенаправления CNAME/ANAME/MX/HTTP рекомендуется значение TTL от 1800 до 3600 с предпочтением более высокому TTL. Поскольку эти записи будут указывать на другие записи, которые будут вносить изменения, изменения для этих записей будут редкими. Но поскольку эти записи будут запрашиваться довольно часто, более высокий TTL приведет к меньшему количеству запросов.

Записи TXT (SPF)/DMARC/DKIM/CAA

Для записей TXT (SPF)/DMARC/DKIM/CAA рекомендуется значение TTL от 1800 до 3600. Если вам не нужно часто вносить изменения, выберите более высокий TTL, которого будет достаточно, поскольку эти записи в основном используются для статических проверок.

Записи NS

Для записей сервера имен рекомендуется значение TTL 86400 из-за большого объема запросов этого типа записи и низкой скорости изменения. Эти записи будут запрашиваться каждый раз, когда запрашивается запись для домена, поэтому более высокий TTL приведет к меньшему количеству запросов.

Записи PTR

Для записей указателей рекомендуется значение TTL от 1800 до 3600, поскольку эти типы записей могут меняться довольно часто, в зависимости от того, как они используются. Если вы не планируете часто менять их, рекомендуется более высокий TTL.

Остаться в живых — что такое TTL и почему это важно для настройки DNS?

Если вы знаете о DNS, вы, вероятно, слышали о поле Time-to-Live (TTL). Но ошибки с TTL встречаются чаще, чем вы думаете. Здесь мы рассмотрим особенности наборов записей DNS, родительских/дочерних доменов и способы избежать проблем с TTL.


Добро пожаловать в The Quirks of the DNS , серию коротких сообщений в блоге, в которых я освещаю некоторые необычные стороны системы доменных имен (DNS) — универсальной базы данных для всего, что связано с Интернетом. Мы увидим некоторые интересные проблемы, которые могут возникнуть с DNS, и я дам несколько рекомендаций, как избежать проблем.

В этом посте мы рассмотрим Time-to-Live (TTL), поле в каждой записи DNS, которое сообщает DNS-клиентам, как долго информация в этой записи действительна и, следовательно, как долго она может храниться в DNS. кэш клиента. Вы можете думать о TTL как о сроке годности на упаковке молока. Как только эта дата истечет, тайник знает, что он должен выбросить этот пакет молока и получить новый!

TTL и родительские/дочерние записи DNS

В DNS «хендовер» с сервера, обслуживающего более короткое имя ( с. ) к одному, обслуживающему более длинное имя ( netnod.se. ), выражается с помощью записей типа NS (nameserver). Клиент просит se. для имени, оканчивающегося на netnod.se.

будет получать только NS-записи, говорящие клиенту «пойти в другое место» для поиска, а именно на серверы, на которых хранится информация для netnod.se .

Записи, выданные se. Сервер («родительский») будет выглядеть примерно так:

 netnod.se. 86400 В НС nna.netnod.se.
netnod.se. 86400 IN NS nnb.netnod.se.
netnod.se. 86400 IN NS nnp.netnod. se.
netnod.se. 86400 IN NS nnu.netnod.se.
 

Строка netnod.se. слева (называемое «имя владельца») говорит нам, какой поддомен («дочерний») делегирован; IN («класс») говорит нам, что мы имеем дело с информацией, связанной с Интернетом; NS («тип записи») сообщает нам, что мы смотрим информацию о сервере имен для дочернего элемента; а имена справа («данные записи») сообщают нам имена серверов, которые содержат информацию DNS о

netnod.se. и имена «ниже» его.

Последнее поле здесь, число 86400 , называется временем жизни (TTL). Он информирует получателя данных о том, что он может полагаться на данные в течение (в данном случае) 86 400 секунд (= 24 часа) без необходимости возвращаться для повторной проверки. Данные могут храниться локально («кешироваться») на клиенте в течение этого периода времени.

ПРИЧИНА 1: Все TTL в наборе записей должны иметь одинаковое значение

«Набор записей» (RRSET) — это полный набор всех записей с одним и тем же именем владельца, классом и типом. В приведенном выше примере есть одна запись, установленная для [ netnod.se. , IN , NS ] и состоит из четырех записей. DNS рассматривает наборы записей как «склеенные», и они всегда должны передаваться и интерпретироваться как группа. Если разрешить разделение набора записей, разные «игроки» в мире DNS будут видеть разные представления данных DNS, и база данных больше не будет согласованной и согласованной.

Требование согласованности представлений базы данных приводит к требованию, чтобы значение TTL должен быть одинаковым для всех членов набора записей. Для этого есть две причины:

  1. Клиенты получают RRSET и сохраняют его в своих кэшах. Затем все значения TTL для всех записей в кэше постоянно уменьшаются, и когда TTL для записи достигает 0, запись будет удалена из кэша. Если члены RRSET имеют разные TTL, они будут удалены в разное время, что «заставит» систему кэширования разделить набор записей на части, и требование когерентности больше не будет выполняться.
    Кэш будет содержать только около штук. Изображение базы данных уже не соответствует действительности. Поэтому важно, чтобы все записи в RRSET удалялись из кэша одновременно. Отсутствие записей в кеше заставит клиента запросить у источника «свежий» RRSET, а в кеше снова будут согласованные данные.
  2. Когда используется безопасный DNS (DNSSEC), это становится еще более важным. В DNSSEC криптографические подписи используются клиентом в качестве инструмента для проверки того, что полученные данные DNS не были изменены во время их перемещения по сети. DNSSEC подписывает наборы записей, а не отдельные записи. Важной частью подписи является «исходный TTL» (т. е. то, каким был TTL в начале, до того, как кеш начал его уменьшать). Этот исходный TTL представляет собой единое значение, которое охватывает весь RRSET, и если записи в наборе изначально имели разные значения, подпись была бы неверной, и проверка данных была бы невозможной.

РЕКОМЕНДАЦИЯ: Убедитесь, что все записи в наборе записей имеют одинаковый TTL.

ПРИЧИНА 2: Записи NS для родительского и дочернего элементов должны быть синхронизированы

Записи NS должны присутствовать как в родительском (который «выдает полномочия»), так и в дочернем элементе («который получает полномочия»). Записи выглядят одинаково в обоих местах, но не синхронизируются автоматически (если только не используются очень последние дополнения к протоколу DNS). Это нужно делать вручную. Как мы все знаем, люди не очень хорошо умеют синхронизировать вещи, так что это дает достаточно возможностей для расхождения систем. Обычно происходят две вещи:

  1. Администраторы дочерних данных меняют набор серверов имен и забывают сообщить родительскому о своем желании это сделать. Если дочерние администраторы изменят все серверы, все перестанет работать. Если они изменят лишь некоторые из них, все может продолжать работать деградировавшим образом.
  2. Записи в родительском объекте имеют другой TTL, чем в дочернем. Это менее проблематично, но может привести к ненужному DNS-трафику, если TTL для записей в дочерней базе данных имеют более низкий TTL, чем в родительской базе данных. Поскольку записи NS в дочерней базе данных считаются «авторитетными» (т. е. имеющими более высокий «приоритет»), чем записи в родительской базе данных, у дочерней базы данных есть возможность «возиться» с TTL без ведома или согласия родителя. Если родительская система проектирует свои DNS-системы для определенного шаблона трафика, который является ожидаемым результатом установки значений TTL для его дочерних элементов на определенное значение, они могут быть удивлены, если дочерние элементы установят
    их значения TTL
    для записей NS на что-то совершенно другое.

РЕКОМЕНДАЦИЯ: как администратор дочерних данных, выровняйте значения TTL для записей NS с теми, которые появляются в базе данных вашего родителя.

Надеюсь, этот пост был вам полезен. Следите за дальнейшими публикациями, пока мы углубляемся в особенности DNS! Тем временем, если у вас есть какие-либо вопросы о настройке DNS и о том, как может помочь служба Netnod DNS anycast, вы можете связаться с нами здесь.


Этот пост изначально был опубликован в блоге Netnod.

DNS вариант использования

Еще от этого автора

Вам также может понравиться

Посмотреть больше

Празднование 30-летия первого в Европе корневого сервера имен

Ларс-Йохан Лиман

Ларс-Йохан Лиман

Базируется в Стокгольме, Швеция.

Ларс-Йохан Лиман работает старшим специалистом по системам в Netnod Internet Exchange в Стокгольме, Швеция. Он отвечает за службу корневых имен Netnod для системы доменных имен (DNS) и провел более 30 лет, разрабатывая и возясь с DNS. Со временем он работал практически со всеми аспектами, которые вы можете себе представить, — эксплуатацией, настройкой, предоставлением, проектированием, тестированием, отладкой, документацией, проектированием и развитием, международным сотрудничеством и управлением, обучением и даже шутками над этим. В настоящее время он является председателем Постоянного комитета клиентов ICANN, а также членом Консультативного комитета по системе корневых серверов и Рабочей группы по управлению системой корневых серверов.

Об авторе

Ларс-Йохан Лиман Базируется в Стокгольме, Швеция.

Ларс-Йохан Лиман работает старшим системным специалистом в Netnod Internet Exchange в Стокгольме, Швеция. Он отвечает за службу корневых имен Netnod для системы доменных имен (DNS) и провел более 30 лет, разрабатывая и возясь с DNS.

Ttl что это: Вход/выход TTL-совместимый — что это такое?

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *

Пролистать наверх