TTL IP-пакетов
В IPv4 TTL представляет собой восьмиразрядное поле IP-заголовка. Параметр TTL считается верхней границей времени существования IP-дейтаграммы в сети. Поле TTL устанавливается отправителем пакета и уменьшается в течение всего процесса передачи данных, в соответствии со временем пребывания в данном устройстве, согласно протоколу обработки.
Основное назначение – не допустить длительной задержки, когда, например, в процессе передачи данных маршрутизатор отключился или была потеряна связь между двумя узлами.
В каждой промежуточной точке (маршрутизаторе) значение поля TTL уменьшается на 1 (данный параметр изменяется) до тех пор, пока пакет данных не достигнет точки назначения.
При условии, что значение на каком-либо из задействованных узлов достигнет 1, пакет данных уничтожается, а на исходный сервер посылается сообщение о необходимости повторить передачу пакета. В этом случае отправителю отправляется ICMP-пакет с кодом 11 — «Превышение временного интервала». При слишком маленьком значении пакет может просто не дойти, при слишком большом, в случае задержки, ожидание может занять много времени (при значении TTL 255 оно достигает 4 минут и 10 секунд).
Маршрутизатор не пропускает пакеты с нулевым значением TTL. Это делается для того, чтобы в случае ошибочной маршрутизации пакет не «гулял» бесконечно по сети, а уничтожался через некоторое время.
Как работает технология?
Когда пакет информации создается и отправляется через интернет, существует риск того, что он будет продолжать переходить с маршрутизатора на маршрутизатор на неопределенный срок. Чтобы уменьшить эту возможность, пакеты создаются с истечением срока действия, называемым пределом времени жизни. Пакет TTL также может быть полезен при определении того, как долго он находился в обращении, и позволяет отправителю получать информацию о пути пакета через интернет. Каждый пакет имеет место, где он хранит числовое значение, определяющее, насколько долго он должен продолжать перемещаться по сети. Каждый раз, когда маршрутизатор получает пакет, он вычитает одно значение из счета TTL и затем передает его в следующее место в сети. Если в любой момент счетчик TTL равен нулю после вычитания, маршрутизатор отбросит пакет и отправит сообщение ICMP обратно на исходный узел.
TTL у DNS
DNS в TTL – это параметр, отвечающий за использование записей DNS-зоны в памяти сервера без дополнительных изменений. По достижении установленного времени, кеширующий сервер запрашивает DNS-сервер, содержащий доменную зону и информацию о ней.
При использовании стандартных настроек TTL обновление произойдет на сервере через день. Перед запланированными процедурами первую строку записи следует изменить на значение 550 или меньше, после чего ввести serial number и перегрузить зоны, обновив DNS-сервер. После обновления данных можно начинать производить необходимые процедуры по миграции серверов. Проверку произвести с помощью команды dig. После этого произойдет обновление IP-адресов в течение указанного времени.
После выполнения всех процедур по передаче данных, значение TTL можно увеличить, чтобы снизить нагрузку на DNS-сервер и избежать использования большого трафика для обновления зон.
TTL — что такое и как это работает?
В HTTP время жизни отображает количество секунд, для которых может быть возвращен кэшированный веб-контент до запроса сервера. Значение по умолчанию определяется настройками на веб-сервере, но может быть переопределено тегами управления кэшем, которые определяют, какие типы серверов могут кэшировать данные.
Пакет является фундаментальной единицей информационного транспорта во всех современных компьютерных сетях и в других сетях связи. Маршрутизатор представляет собой электронное устройство или программное обеспечение сетевого уровня, которое соединяет локальные или глобальные сети и пересылает пакеты между ними.
Типы DNS-записей
A и AAAA
Запись A связывает домен или субдомен с IP-адресом, что позволяет трафику достигать сайта. Это основная функция DNS. Типичная запись A выглядит следующим образом:
example.com A 12.34.56.78 hello.example.com A 12.34.56.78
Вы можете указать разные субдомены на разных IP-адресах. Если нужно указать каждый субдомен example.com на IP, то можете использовать для субдомена звездочку (*):
*.example.com A 12.34.56.78
Проверка домена на доступность — как ее провести?
Запись AAAA аналогична записи A, но она используется для IP-адресов IPv6. Типичная запись AAAA выглядит следующим образом:
Запись AAAA аналогична записи A, но она используется для IP-адресов IPv6. Типичная запись AAAA выглядит следующим образом:
AXFR
Запись AXFR используется для репликации DNS. Хотя существуют более современные способы.
Записи AXFR не используются в обычных файлах зон. Чаще всего они применяются на подчиненном DNS-сервере для репликации файла зоны с главного DNS-сервера.
CAA
DNS Certification Authority Authorization (CAA) использует DNS, чтобы владелец домена мог указать, каким центрам сертификации разрешено выдавать сертификаты для этого домена.
CNAME
Запись CNAME (запись канонического имени) соответствует домену или поддомену. При записи CNAME используются разрешения DNS целевого домена в качестве разрешения псевдонима. Например:
alias.com CNAME example.com. example.com A 12.34.56.78
При запросе alias.com начальный поиск DNS найдет запись CNAME с целью example.com. Будет запущен новый поиск DNS example.com, который найдет IP-адрес 12.34.56.78. Посетители alias.com будут направлены к IP-адресу 12.34.56.78.
Записи CNAME применяются, чтобы домены могли иметь псевдонимы. Некоторые почтовые серверы странным образом обрабатывают почту для доменов с записями CNAME. Поэтому не следует использовать запись CNAME для домена, который принимает электронную почту.
Записи MX не могут ссылаться на имена хостов, определенные CNAME. Целевой домен для записи CNAME также должен иметь нормальное разрешение A-записи.
Примечание
CNAME-запись может быть эффективным способом перенаправления трафика от одного домена к другому, сохраняя тот же URL-адрес. Но она не работает так же, как редирект URL-адресов. CNAME-запись направляет трафик для определенного домена на IP-адрес целевого домена. Как только пользователь достигнет этого IP-адреса, конфигурация сервера будет определять способ обработки домена. Если этот домен не настроен, сервер отобразит веб-страницу по умолчанию. Она может быть веб-страницей целевого домена в записи CNAME, в зависимости от того, как настроен сервер.
DKIM
Запись DKIM она же запись DomainKeys Identified Mail отображает открытый ключ для аутентификации сообщений, которые подписаны с помощью протокола DKIM. Это расширяет возможности проверки подлинности электронной почты. Типичная запись DKIM выглядит следующим образом:
selector1._domainkey.example.com TXT k=rsa;p=J8eTBu224i086iK
Как создать гмаил почту для своего домена?
DKIM-записи представлены в виде текстовых записей. Запись должна быть создана для субдомена, который имеет уникальный селектор для этого ключа, затем указывается точка (.) и _domainkey.example.com. Тип -TXT, значение включает в себя тип ключа, за которым следует фактический ключ.
MX
Запись MX устанавливает адресат доставки почты для домена или субдомена. Типичная MX-запись выглядит следующим образом:
example.com MX 10 mail.example.com. mail.example.com A 12.34.56.78
Приведенные выше записи направляют почту для example.com на сервер mail.example.com. В идеале MX-запись должна указывать на домен, который также является именем хоста его сервера. Если вы используете стороннюю почтовую службу, такую как Google Apps, то следует применять предоставленные ими MX-записи.
Приоритет является еще одним компонентом MX-записей. Это число, записанное между типом записи и целевым сервером. В примере, приведенном выше, использован приоритет 10.
Приоритет позволяет назначить резервный почтовый сервер (или серверы) для определенного домена. Меньшие числа имеют более высокий приоритет. Пример домена, который имеет два резервных почтовых сервера:
example.com MX 10 mail_1.example.com example.com MX 20 mail_2.example.com example.com MX 30 mail_3.example.com
Если mail_1.example.com не работает, электронная почта будет доставлена на mail_2.example.com. Если mail_2.example.com также не работает, почта будет доставлена на mail_3.example.com.
NS
NS-записи устанавливают серверы имен для домена. Они задаются для домена у регистратора и в файле зоны. Типичные записи сервера имен выглядят следующим образом:
example.com NS ns1.linode.com. example.com NS ns2.linode.com. example.com NS ns3.linode.com. example.com NS ns4.linode.com. example.com NS ns5.linode.com.
Серверы имен, которые вы назначаете у своего регистратора, содержат файл зоны для домена.
Также можно настроить различные серверы имен для любого из поддоменов. Они задаются в файле зоны вашего основного домена:
mail.example.com NS ns1.nameserver.com mail.example.com NS ns2.nameserver.com
Первичные серверы имен настраиваются у регистратора, а вторичные — в файле зоны основного домена. Порядок NS- записей не имеет значения. DNS-запросы отправляются случайным образом на разные серверы. Если один хост не отвечает, будет запрошен другой.
PTR
История whois домена — 4 онлайн-сервиса для поиска архивной информации
Запись PTR или запись указателя сопоставляет IP-адрес с доменом или поддоменом, позволяя функционировать обратным DNS-запросам. Она работает противоположно записи A, в том смысле, что позволяет искать домен, связанный с конкретным IP-адресом, а не наоборот.
Записи PTR обычно устанавливаются на хостинге. Они не являются частью файла зоны домена.
Для добавления записи PTR необходимо создать действительную запись A или AAAA, которая указывает IP-адрес для нужного домена.
Примечание
Можно использовать разные IP-адреса (включая адреса IPv4 и IPv6), на которых один и тот же домен установлен для обратного DNS. Для этого необходимо настроить несколько записей A или AAAA для этого домена, которые указывают на различные IP-адреса.
SOA
Запись SOA обозначает файл зоны с именем хоста, на котором он был создан. Далее в нем указывается контактный адрес электронной почты администратора домена. Типичная запись SOA:
@ IN SOA ns1.linode.com. admin.example.com. 2013062147 14400 14400 1209600 86400
Примечание
Адрес электронной почты администратора пишется с точкой (.) вместо символа @.
Вот что означают эти цифры:
- Серийный номер: номер редакции файла зоны этого домена. Он изменяется, когда файл обновляется.
- Время обновления: количество времени (в секундах), в течение которого вторичный DNS-сервер будет хранить файл зоны, прежде чем проверит изменения.
- Время повтора: время, которое вторичный DNS-сервер будет ожидать, прежде чем повторить передачу файла зоны.
- Время истечения: время, в течение которого вторичный DNS-сервер будет ожидать, прежде чем истечет срок действия текущей копии файла зоны, если он не сможет обновить себя.
- Минимальный TTL: минимальный период времени, в течение которого другие серверы должны хранить в кэше данные из файла зоны.
Сервер имен, упомянутый в записи SOA, считается основным для динамического DNS. На нем изменения файла зоны производятся до того, как они распространяются на другие серверы имен.
SPF
Запись Sender Policy Framework (SPF) содержит список почтовых серверов, назначенных для домена или субдомена. Это помогает подтвердить легитимность почтового сервера и снижает вероятность подделки заголовков писем. Спамеры часто пытаются сделать это, чтобы обойти фильтры.
SPF- запись домена сообщает другим почтовым серверам, какие исходящие серверы являются допустимыми источниками электронной почты. Поэтому они могут отклонять поддельную почту с вашего домена, отправленную с неавторизованных серверов. Простая SPF-запись выглядит следующим образом:
example.com TXT «v=spf1 a ~all»
В SPF-записи необходимо перечислить почтовые серверы, с которых вы отправляете почту, а затем исключить остальные. Ваша SPF- запись будет содержать домен или поддомен, тип (TXT или SPF, если ваш сервер имен поддерживает его) и текст (который начинается с «v = spf1» и содержит настройки SPF- записи).
С помощью этой SPF-записи принимающий сервер проверит и IP-адрес отправляющего сервера, и IP-адрес example.com.
Примечание
Убедитесь, что SPF- записи не слишком строгие. Если вы случайно исключите легитимный почтовый сервер, полученные от него письма могут быть помечены как спам.
Рекомендуем посетить ресурс openspf.org, чтобы узнать, как работают SPF- записи и как создать запись, которая подходит для вашей настройки.
SRV
Запись SRV сопоставляет конкретную службу, работающую на домене или поддомене, с целевым доменом. Это позволяет направлять трафик, предназначенный для определенных служб, на другой сервер. Типичная запись SRV:
_service._protocol.example.com SRV 10 0 5060 service.example.com
Описание элементов, которые используются в SRV-записи:
- Служба: названию службы должно предшествовать подчеркивание ( _ ) и точка ( . ). Служба может быть чем-то вроде _xmpp.
- Протокол: имя протокола должно начинаться с подчеркивания ( _ ) и заканчиваться точкой ( . ). Протокол может быть чем-то вроде _tcp.
- Домен: имя домена, который будет получать исходный трафик для службы.
- Приоритет: первое число (10 в приведенном выше примере) позволяет установить приоритет для целевого сервера. Можно установить цели с разными приоритетами, что позволит иметь резервный сервер (или серверы) для этой службы. Меньшие числа имеют более высокий приоритет.
- Вес: Если две записи имеют одинаковый приоритет, вместо него учитывается вес.
- Порт: порт TCP или UDP, на котором работает служба.
- Цель: целевой домен или поддомен. Он должен иметь запись A или AAAA, которая разрешается в IP-адресе.
Примером использования SRV-записей является настройка федеративной VoIP .
TXT
Запись TXT (текстовая запись) предоставляет информацию о домене другим интернет-ресурсам. Одно из распространенных применений TXT-записи — создание SPF- записи на серверах имен, которые изначально не поддерживают SPF. Другой вариант использования — создание записи DKIM для почты.
Дайте знать, что вы думаете по этой теме статьи в комментариях. За комментарии, отклики, дизлайки, лайки, подписки огромное вам спасибо!
Пожалуйста, оставляйте ваши мнения по текущей теме материала. За комментарии, дизлайки, лайки, подписки, отклики низкий вам поклон!
Вадим Дворниковавтор-переводчик статьи «DNS Records: An Introduction»
Обход блокировок
Обходится блокировка достаточно просто – нужно на подключенных устройствах выставить TTL, который будет ровен на 1 больше чем у раздающего телефона. Например, вы раздаете интернет на ноутбук, тогда нужно установить у этого устройства ТТЛ со значение на 1 больше чем у раздающего устройства (то есть 65). В итоге пакет от компьютера, попадая на телефон будет принимать значение 64. Оператор будет видеть, что все пакеты одинаковые, и никого блокировать не будет.
ПРИМЕЧАНИЕ! Можно, конечно, не уменьшать ТТЛ на принимающем устройстве, а уменьшить его на раздающем, но для этого понадобятся ROOT права и программа TTL Master. Поэтому проще всего изменить значение на второстепенных аппаратах – об этом поподробнее чуть ниже.
Но есть ещё одна загвоздка, про которую нигде почему-то не написано. Дело в том, что операторы начали также по-другому вычислять раздачу. У провайдера есть список серверов, к которым можно обратиться только с компьютера.
Например, если на подключенном компьютере начнется обновление Windows, то оператор это сразу поймет. Потому что с телефона никто в здравом уме не будет обращаться к серверам обновления от Microsoft. Список таких серверов постоянно пополняется. Но и эта проблема достаточно легко решается. По этому поводу у нас на портале есть подробные инструкции для всех операторов:
- МТС
- Билайн
- YOTA
Там расписаны все шаги с картинками и пояснениями. Также вы сможете определить и проверить свой ТТЛ, но на деле они имеют одинаковые значения для всех типов устройств, о которых я написал в самом начале.
Ответы DNS сервера
Ответы DNS бывают следующего типа:
- Авторитативный ответ (authoritative response) приходит от серверов, являющихся ответственными за зону.
- Неавторитативный ответ (non authoritative response) приходит от серверов, которые не отвечают за зону (от кэширующих).
Ответ DNS обычно содержит следующую информацию:
- Запись заголовка — служебную информацию о запросе.
- Запись запроса — повторяет отправленный запрос.
- Запись ответа — собственно, сам ответ.
- Записи авторитетных серверов — информацию об авторитетных серверах, хранящих информацию по текущему запросу.
- Дополнительную информацию — дополнительные записи, например адреса NS-серверов.
Вышенаписанное наглядно подтверждается утилитой dig:
[email protected]:~# dig ya.ru ; <<>> DiG 9.7.3 <<>> ya.ru (раздел заголовка) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 53499 ;; flags: qr rd ra; QUERY: 1, ANSWER: 7, AUTHORITY: 2, ADDITIONAL: 3 ;; QUESTION SECTION: (раздел запроса) ;ya.ru. IN A ;; ANSWER SECTION: (раздел ответа) ya.ru. 4813 IN A 87.250.250.203 ya.ru. 4813 IN A 87.250.251.3 ya.ru. 4813 IN A 93.158.134.3 ya.ru. 4813 IN A 93.158.134.203 ya.ru. 4813 IN A 213.180.204.3 ya.ru. 4813 IN A 77.88.21.3 ya.ru. 4813 IN A 87.250.250.3 ;; AUTHORITY SECTION: (авторитативные сервера) ya.ru. 4813 IN NS ns1.yandex.ru. ya.ru. 4813 IN NS ns5.yandex.ru. ;; ADDITIONAL SECTION: (дополнительная информация — адреса авторитативных name servers) ns5.yandex.ru. 345565 IN A 213.180.204.1 ns1.yandex.ru. имя главного DNS (Primary Name Server) 345565 IN A 213.180.193.1 ns1.yandex.ru. 3565 IN AAAA 2a0ua.em2:6emb8::1 ;; Query time: 7 msec ;; SERVER: 192.168.1.1#53(192.168.1.1) ;; WHEN: Sat Jul 2 23:02:45 2011 ;; MSG SIZE rcvd: 238