Узнай, как расшифровывается магазин
Обновлено: 03.07.2024
Зона DNS — это часть группы компонентов, составляющих DNS. Эти объекты детально управляются администратором или организацией. Зоны DNS могут содержать различную информацию о домене и поддоменах. Несколько зон также могут существовать на одном сервере. Информация DNS хранится в текстовом файле, называемом файлом зоны DNS.
Что такое файл зоны DNS?
Файл зоны DNS — это обычный текстовый файл, хранящийся на сервере DNS, который содержит все записи для каждого домена в данной зоне. Файлы зон могут включать более 44 различных типов записей, но всегда должны начинаться с записи SOA (или начала полномочий).
Типы записей
Как уже упоминалось, в зоне DNS используется множество типов записей DNS, каждый из которых служит уникальной цели. Ниже приведены некоторые примеры наиболее часто используемых типов записей и краткое описание каждого из них.
Начало полномочий (SOA)
Первая запись в любом файле зоны — это запись ресурса SOA. Эта запись является неотъемлемой частью файла зоны DNS. Он указывает зону домена и основные свойства сервера доменных имен. Каждый файл зоны может содержать только одну запись SOA.
Сервер имен (NS)
Записи NS сообщают рекурсивным серверам имен, какие серверы имен являются авторитетными для зоны. Рекурсивные серверы имен просматривают авторитетные записи NS, чтобы облегчить запрос следующего сервера при разрешении имени.
Единственный файл зоны, который имеет значение, — это тот, который находится на полномочном сервере имен для домена. Вы можете узнать, какие серверы имен будут просматриваться в Интернете, с помощью поиска whois в домене.
Обмен почтой (MX)
Обычно две записи MX отвечают за указание того, какой почтовый сервер получает сообщения электронной почты для домена. Почтовый клиент устанавливает SMTP-подключение к основному почтовому серверу, указанному в файле зоны. Записи ранжируются по приоритету от низшего к высшему. Самый низкий приоритет имеет основной почтовый сервер, а более высокие значения имеют более низкий приоритет. Если первичный сервер недоступен, следующий почтовый сервер попытается направить соединение. Записи MX должны указывать на домен, а не на IP-адрес.
Адрес (А)
Запись A используется для поиска IP-адреса, связанного с доменным именем. Эта запись направляет информацию с сервера в веб-браузер клиента.
Четверная запись A имеет ту же функцию, что и запись A, но используется специально для протокола IPv6.
Каноническое имя (CNAME)
Эта запись будет псевдонимом одного имени сайта для другого. Затем поиск DNS направит запросы доменного имени на новое имя, которое содержит запись A. Эти записи должны указывать на полное доменное имя (FQDN).
Псевдоним записи (псевдоним)
Текст (TXT)
Записи TXT содержат текст любого типа в произвольной форме. Первоначально они предназначались для удобочитаемой информации о сервере, такой как местоположение или центр обработки данных. В настоящее время наиболее распространенными видами использования записей TXT являются SPF и Domain_Keys (DKIM).
Поиск службы (SRV)
Записи SRV – это обобщенная запись местоположения службы. Он используется для более новых протоколов вместо создания записей для конкретных протоколов, таких как MX. Этот тип записи хоть и полезен, но редко используется.
Указатель (PTR)
Запись PTR указывает IP на каноническое имя и явно используется в обратных записях DNS. Важно отметить, что обратные записи DNS устанавливаются на полномочных серверах имен лицом, которому принадлежит IP, а не лицом, которому принадлежит каноническое имя.
Заключение
DNS — это основа Интернета. Это позволяет нам легко подключаться к нашим любимым сайтам. Изучение компонентов этой системы гарантирует, что ваш сайт
всегда будет найден.
Наша группа поддержки состоит из опытных технических специалистов по Linux и талантливых системных администраторов, хорошо разбирающихся в различных технологиях веб-хостинга, особенно в тех, которые обсуждаются в этой статье.
Если у вас возникнут какие-либо вопросы относительно этой информации, мы всегда готовы ответить на любые вопросы, связанные с этой статьей, 24 часа в сутки, 7 дней в неделю, 365 дней в году.
Если вы являетесь владельцем полностью управляемого VPS-сервера, выделенного облака, частного облака VMWare, частного родительского сервера, управляемых облачных серверов или выделенного сервера и вам неудобно выполнять какой-либо из описанных шагов, с нами можно связаться по телефону. @800.580.4985, чат или запрос в службу поддержки, чтобы помочь вам в этом процессе.
Традиционные DNS-запросы и ответы отправляются по протоколу UDP или TCP без шифрования. Это уязвимо для прослушивания и спуфинга (включая интернет-фильтрацию на основе DNS). Ответы рекурсивных распознавателей клиентам наиболее уязвимы для нежелательных или злонамеренных изменений, в то время как обмен данными между рекурсивными распознавателями и авторитетными серверами имен часто включает дополнительную защиту.
Чтобы решить эти проблемы, Google Public DNS предлагает разрешение DNS через TCP-подключения с шифрованием TLS, как указано в RFC 7858. DNS-over-TLS повышает конфиденциальность и безопасность между клиентами и преобразователями. Это дополняет DNSSEC и защищает проверенные DNSSEC результаты от модификации или подделки на пути к клиенту.
Как это работает
Клиентская система может использовать DNS-over-TLS с одним из двух профилей: строгая или гибкая конфиденциальность. В профиле строгой конфиденциальности пользователь настраивает имя DNS-сервера (имя домена аутентификации в RFC 8310) для службы DNS-over-TLS, и клиент должен иметь возможность создавать безопасное соединение TLS на порту. 853 на DNS-сервер. Неспособность установить безопасное соединение является серьезной ошибкой и приведет к отключению службы DNS для клиента.
При использовании оппортунистического профиля конфиденциальности IP-адрес DNS-сервера может быть настроен непосредственно пользователем или получен из локальной сети (с использованием DHCP или каким-либо другим способом). Преобразователь клиента пытается установить безопасное соединение через порт 853 с указанным DNS-сервером. Если установлено безопасное соединение, это обеспечивает конфиденциальность запросов пользователя от пассивных наблюдателей на пути. Поскольку клиент не проверяет подлинность сервера, он не защищен от активного злоумышленника. Если клиент не может установить безопасное соединение через порт 853, он возвращается к обмену данными с DNS-сервером через стандартный порт DNS 53 через UDP или TCP без какой-либо безопасности или конфиденциальности. Использование Opportunistic Privacy предназначено для поддержки поэтапного развертывания повышенной конфиденциальности с целью повсеместного внедрения строгого профиля конфиденциальности.
При использовании строгого профиля конфиденциальности резолверы-заглушки устанавливают соединение DNS-over-TLS, выполнив следующие действия.
- Преобразователю-заглушке настраивается имя преобразователя DNS-over-TLS dns.google .
- Резолвер-заглушка получает IP-адрес(а) для dns.google с помощью локального резолвера DNS.
- Преобразователь-заглушка устанавливает TCP-соединение с портом 853 по тому же IP-адресу.
- Резолвер-заглушка инициирует рукопожатие TLS с резолвером Google Public DNS.
- Общедоступный DNS-сервер Google возвращает свой сертификат TLS вместе с полной цепочкой сертификатов TLS вплоть до доверенного корневого сертификата.
- Преобразователь-заглушка проверяет подлинность сервера на основе представленных сертификатов.
- Если удостоверение не может быть проверено, разрешение DNS-имени завершается сбоем, и тупиковый преобразователь возвращает ошибку.
- После того, как TLS-соединение установлено, тупиковый преобразователь получает безопасный путь связи между общедоступным DNS-сервером Google.
- Теперь резолвер-заглушка может отправлять DNS-запросы и получать ответы по соединению.
При использовании гибкого профиля конфиденциальности клиент сначала пытается создать безопасное TLS-соединение с сервером. Это делается аналогично предыдущему с одним важным отличием — клиент не выполняет проверку сертификата. Это означает, что личности сервера нельзя доверять. Если не удается установить TLS-подключение к серверу через порт 853, тупиковый преобразователь возвращается к обращению к DNS-серверу через порт 53.
Конфиденциальность
Наша политика конфиденциальности распространяется на службу DNS-over-TLS.
27 июня 2019 г. мы повторно включили клиентскую подсеть EDNS (ECS) для службы DNS-over-TLS. ECS был отключен при запуске службы.
Поддержка стандартов
Google Public DNS реализует DNS-over-TLS на основе RFC 7858. Кроме того, мы поддерживаем следующие рекомендации по предоставлению высококачественной службы DNS с малой задержкой.
Начать использовать
См. инструкции по настройке на устройстве с Android 9 (Pie) или более поздней версии.
DNS-over-TLS также поддерживается для службы Google Public DNS64 только для IPv6. Обратите внимание, что настраивать DNS64 для мобильного устройства, которое будет подключаться к нескольким сетям, не рекомендуется, поскольку DNS64 работает только при наличии IPv6.
Если не указано иное, содержимое этой страницы предоставляется по лицензии Creative Commons Attribution 4.0, а образцы кода — по лицензии Apache 2.0. Подробнее см. в Правилах сайта Google Developers. Java является зарегистрированным товарным знаком Oracle и/или ее дочерних компаний.
Используя Cloudflare 1.1.1.1, другие службы DNS по-прежнему требуют некоторых ноу-хау в командной строке.
Шон Галлахер – 8 апреля 2018 г., 16:00 UTC
Шифрование DNS-трафика между вашим устройством и провайдером, ориентированным на конфиденциальность, может помешать кому-либо шпионить за тем, куда направлен ваш браузер, или использовать DNS-атаки, чтобы перенаправить вас куда-то еще.
комментарии читателей
Поделиться этой историей
Смерть сетевого нейтралитета и ослабление правил обработки интернет-провайдерами сетевого трафика клиентов вызвали множество опасений по поводу конфиденциальности. Интернет-провайдеры (и другие, наблюдающие за трафиком, проходящим через Интернет) уже давно имеют инструмент, который позволяет им с легкостью отслеживать привычки людей в Интернете: их серверы системы доменных имен (DNS). И если они еще не извлекли выгоду из этих данных (или не использовали их, чтобы изменить ваше отношение к Интернету), скорее всего, они скоро это сделают.
Дополнительная литература
"Открытые" DNS-сервисы позволяют обойти услуги интернет-провайдеров по соображениям конфиденциальности и безопасности, а в некоторых случаях и для обхода фильтрации контента, слежки и цензуры. А 1 апреля (не шутка) Cloudflare запустила собственный новый бесплатный высокопроизводительный авторитетный DNS-сервис, предназначенный для повышения конфиденциальности пользователей в Интернете. Это новое предложение также обещало способ полностью скрыть DNS-трафик — шифрование.
Названный по адресу интернет-протокола, 1.1.1.1 является результатом сотрудничества с исследовательской группой APNIC, интернет-реестра Азиатско-Тихоокеанского региона. Хотя он также доступен как «открытый» обычный преобразователь DNS (и очень быстрый), Cloudflare поддерживает два зашифрованных протокола DNS.
Несмотря на то, что версия 1.1.1.1 выполняется с помощью уникальной технологии Cloudflare, она никоим образом не является первой зашифрованной службой DNS: Quad9, Cisco OpenDNS, служба Google 8.8.8.8 и множество более мелких провайдеров поддерживают различные схемы шифрования DNS-запросов. полностью. Но шифрование не обязательно означает, что ваш трафик невидим; некоторые зашифрованные службы DNS регистрируют ваши запросы для различных целей.
Cloudflare пообещала не регистрировать DNS-трафик отдельных лиц и наняла стороннюю фирму для проверки этого обещания. По словам Джеффа Хьюстона из APNIC, APNIC хочет использовать данные о трафике, чтобы указать на IP-адрес, который, к сожалению, является свалкой для «мусорного» интернет-трафика, в исследовательских целях. Но и в этом случае у APNIC не будет доступа к зашифрованному DNS-трафику.
Дополнительная литература
Для пользователей воспользоваться преимуществами зашифрованных служб DNS от Cloudflare или любых других служб DNS, ориентированных на конфиденциальность, не так просто, как изменить номер в настройках сети. В настоящее время ни одна операционная система напрямую не поддерживает ни одну из зашифрованных служб DNS без добавления какого-либо менее удобного для пользователя программного обеспечения. И не все сервисы одинаковы с точки зрения поддержки программного обеспечения и производительности.
Почему мы опять это делаем?
Существует множество причин для повышения безопасности трафика DNS. Хотя веб-трафик и другие коммуникации могут быть защищены криптографическими протоколами, такими как безопасность транспортного уровня (TLS), почти весь трафик DNS передается в незашифрованном виде. Это означает, что ваш интернет-провайдер (или кто-либо еще между вами и остальной частью Интернета) может регистрировать посещаемые вами сайты, даже если вы используете другую службу DNS, и использовать эти данные для ряда целей, включая фильтрацию доступа к контенту и сбор данных для в рекламных целях.
"У нас есть проблема "последней мили" в DNS, – – сказал Крикет Лю, главный архитектор DNS в компании Infoblox, занимающейся сетевой безопасностью. – «Большинство механизмов безопасности мы имели дело с межсерверными проблемами. Но у нас есть проблема, когда у нас есть тупиковые резолверы в различных операционных системах, и у нас нет никакого способа их защитить». По словам Лю, это особенно проблема в странах с более враждебным отношением к Интернету.
В какой-то степени помогает простое использование службы DNS без ведения журнала. Но это не мешает кому-то фильтровать эти запросы на основе контента или захватывать адреса внутри них с помощью захвата пакетов или механизма глубокой проверки пакетов. И в дополнение к простым пассивным атакам с прослушиванием существует также угроза более активных атак на ваш DNS-трафик — попытки интернет-провайдера или правительства «подделать» личность DNS-сервера, направляя трафик на свой собственный сервер. регистрировать или блокировать трафик. Что-то похожее (хотя, по-видимому, не злонамеренно), по-видимому, происходит с (случайной) неправильной маршрутизацией трафика AT&T на адрес Cloudflare 1.1.1.1, судя по наблюдениям форумчан на DSLReports.
Самый очевидный способ избежать мониторинга — использовать виртуальную частную сеть. Но хотя виртуальные частные сети скрывают содержимое вашего интернет-трафика, для подключения к виртуальной частной сети может потребоваться сначала запрос DNS.После того как вы запустили сеанс VPN, DNS-запросы могут время от времени направляться за пределы вашего VPN-подключения веб-браузерами или другим программным обеспечением, создавая «утечки DNS», раскрывающие, какие сайты вы посещаете.
Дополнительная литература
Именно здесь на помощь приходят зашифрованные протоколы DNS: протокол DNSCrypt (поддерживается, среди прочего, Cisco OpenDNS), разрешение DNS по TLS (поддерживается Cloudflare, Google, Quad9 и OpenDNS) и разрешение DNS по HTTPS (в настоящее время поддерживается Cloudflare, Google и служба блокировки контента для взрослых CleanBrowsing). Зашифрованный трафик гарантирует, что трафик не может быть перехвачен или изменен, а также что запросы не могут быть прочитаны кем-то, маскирующимся под службу DNS, что исключает атаки посредников и шпионаж. Использование прокси-сервера DNS для одной из этих служб (непосредственно на вашем устройстве или на «сервере» внутри вашей локальной сети) поможет предотвратить утечку DNS через VPN, поскольку прокси-сервер всегда будет самым быстро реагирующим DNS-сервером.
Однако эта конфиденциальность не предназначена для массового потребления. Ни один из этих протоколов в настоящее время изначально не поддерживается каким-либо распознавателем DNS, предварительно упакованным с операционной системой. Все они требуют установки (и, возможно, компиляции) клиентского приложения, которое действует как локальный DNS-сервер, ретранслируя запросы, сделанные браузерами и другими приложениями вверх по течению, к защищенному DNS-провайдеру по вашему выбору. И хотя две из трех технологий являются предлагаемыми стандартами, ни один из протестированных нами вариантов не обязательно находится в окончательной форме.
Поэтому, если вы решите погрузиться в зашифрованный DNS, вы, вероятно, захотите использовать Raspberry Pi или другое выделенное оборудование для запуска его в качестве DNS-сервера для вашей домашней сети. Это потому, что вы обнаружите, что настройка одного из этих клиентов является более чем достаточным хакерством. Зачем повторять процесс несколько раз, если вы можете просто запросить настройки протокола динамической конфигурации хоста (DHCP) вашей локальной сети, чтобы указать все на одну успешную установку в качестве DNS-сервера? Я неоднократно задавал себе этот вопрос, наблюдая, как во время тестирования клиенты вылетают на Windows и засыпают на MacOS.
Как работает DNS?
Интернет – это гигантская сеть компьютеров. Каждому устройству, подключенному к Интернету, назначается уникальный IP-адрес, который помогает другим компьютерам идентифицировать его.
Этот IP-адрес представляет собой строку чисел с точками, которая выглядит следующим образом: 192.124.249.166
А теперь представьте, если бы вам приходилось запоминать такие длинные цепочки цифр, чтобы посещать любимые веб-сайты. Их трудно запомнить, и они ничего не говорят вам о веб-сайте, который вы увидите, если введете их в браузере.
Для решения этой проблемы были придуманы доменные имена: они используют алфавиты и позволяют пользователям выбирать легко запоминающиеся имена для своих веб-сайтов.
DNS или система доменных имен в основном преобразует эти доменные имена в IP-адреса и указывает вашему устройству правильное направление.
Доменное имя и соответствующий ему IP-адрес называются DNS-записью.
Вот простой способ понять, как работает DNS, за четыре шага.
<р>2. Если записи DNS не найдены, запрос отправляется на ваш локальный DNS-сервер. Обычно это сервер вашего интернет-провайдера, и его часто называют «сервером разрешений имен». <р>3. Если записи не кэшируются на разрешающем сервере имен, то запрос перенаправляется на так называемый «корневой сервер имен» для поиска записей DNS. Корневые серверы имен — это назначенные серверы по всему миру, которые отвечают за хранение данных DNS и обеспечение бесперебойной работы системы. Как только запись DNS будет найдена на корневом сервере имен, она кэшируется вашим компьютером.
Подробнее см. в нашем руководстве для начинающих о том, как работают доменные имена.
Что такое сервер имен?
Интернет возможен благодаря сети компьютеров, называемых серверами. Сервер – это компьютер, предназначенный для хранения и доставки веб-сайтов на другие компьютеры по всему миру.
Сервер имен, иногда называемый «сервер имен», представляет собой особый тип сервера, на котором хранятся все записи DNS вашего доменного имени. Его задача — предоставить вашу информацию DNS всем, кто ее запрашивает.
Серверами имен обычно управляет ваш регистратор доменных имен или хостинг-провайдер.
Каждый сервер имен имеет собственный адрес и может хранить записи многих веб-сайтов. Например, если ваш веб-сайт размещен на Bluehost, сервер имен, используемый для управления вашими записями DNS, будет находиться на серверах имен с адресами, которые выглядят следующим образом:
У каждого доменного имени должно быть как минимум два сервера имен. Первый сервер имен является основным сервером.Если первичный сервер не отвечает, для разрешения доменного имени используется вторичный сервер имен.
Некоторые хостинг-провайдеры WordPress также позволяют пользователям получать собственные частные серверы имен. Например, в WPBeginner мы используем собственный сервер имён.
Как изменить серверы имен
Самое лучшее в системе DNS — это то, что она позволяет владельцам веб-сайтов перемещать свои веб-сайты без изменения их доменных имен.
Лучшие регистраторы доменов обычно предоставляют владельцам доменов простые инструменты для управления своими серверами имен.
В идеале было бы лучше, если бы вы зарегистрировали свой домен у своего хостинг-провайдера. Использование собственного хостинг-провайдера избавляет от необходимости переноса доменного имени или смены серверов имен.
Если ваше доменное имя зарегистрировано у одного провайдера, а ваш веб-сайт размещен в другом месте, вы можете просто изменить DNS-серверы имен и указать на свой веб-хост.
Далее выберите DNS и серверы имен в меню слева.
Затем выберите доменное имя и нажмите на 3 точки в правой части экрана.
Теперь отредактируйте серверы имен, нажав «Изменить».
Затем введите свой сервер имен в соответствующее поле.
Наконец, нажмите Отправить изменения, и все готово.
Что такое запись CNAME?
CNAME означает каноническое имя. Запись CNAME — это тип записи DNS, который используется для указания доменного имени на другое доменное имя, а не на IP-адрес.
Как добавить запись CNAME
Затем отредактируйте запись CNAME, нажав на три точки рядом с записью, которую вы хотите изменить, и нажмите "Изменить".
Затем выберите CNAME в раскрывающемся меню справа. Введите информацию в соответствующие поля.
После ввода необходимой информации нажмите кнопку "Добавить DNS", и все готово.
Если вы не видите настройки изменения записи CNAME в своей учетной записи хостинга, обратитесь к своему хостинг-провайдеру, и он сможет вам помочь.
Что такое запись MX?
Запись MX — это сокращение от записи почтового обменника. Это еще один тип записи DNS, который определяет почтовый сервер для обработки электронной почты для определенного доменного имени.
Как добавить запись MX
Далее нажмите синюю кнопку "Добавить запись DNS".
Затем выберите из списка запись MX, которую хотите изменить, и нажмите на три точки справа.
Теперь внесите изменения в запись MX и нажмите «Обновить DNS». Готово.
Если вы не видите настройки изменения записей MX в своей учетной записи хостинга, попросите своего хостинг-провайдера показать вам, как добавить запись MX.
Что такое запись TXT?
Запись TXT — это еще один тип записи ресурса DNS. Записи TXT могут содержать записи SPF (Sender Policy Framework) и DKIM (Domain Key Identified Mail), которые добавляют зашифрованный ключ в исходящую почту.
Эта информация повышает эффективность доставки электронной почты за счет добавления уровня доверия к вашему почтовому серверу.
Как добавить запись TXT
Далее нажмите синюю кнопку "Добавить запись DNS".
Затем прокрутите вниз, пока не увидите записи TXT, и нажмите на 3 точки справа.
Наконец, внесите изменения в запись TXT и нажмите «Обновить DNS».
Бесплатный DNS и платный DNS: в чем разница?
Обычно, когда пользователь посещает ваш веб-сайт из определенного региона мира, записи DNS вашего веб-сайта кэшируются ближайшими серверами имен, управляемыми местными интернет-провайдерами.
Это поможет другим пользователям из этого региона быстро попасть на ваш сайт.
Однако разрешение DNS-запросов по-прежнему требует времени. Обычно это миллисекунды, и это не имеет большого значения для небольших компаний и блогов.
Вот почему большинство веб-сайтов просто используют DNS-серверы, предоставленные их хостинговой компанией или регистратором доменных имен.
Вы также можете использовать бесплатных поставщиков услуг DNS, таких как Cloudflare, которые предлагают более быстрый бесплатный DNS с ограниченной защитой брандмауэра.
Большие компании обычно выбирают платный DNS, чтобы получить интеллектуальные функции, такие как 100% время безотказной работы, более высокая скорость поиска, перенаправление геотрафика, вторичный DNS, повышенная безопасность и многое другое.
В WPBeginner мы используем DNSMadeEasy в качестве поставщика DNS, потому что они являются одними из самых быстрых в отрасли.
Мы надеемся, что эта статья помогла вам узнать все о DNS и о том, как он работает. Ознакомьтесь с дополнительной литературой ниже, чтобы узнать больше.
Вы также можете подписаться на наш канал YouTube, чтобы получать пошаговые видеоруководства по WordPress, и подписываться на нас в Twitter и Facebook, чтобы быть в курсе последних обновлений.
Ваша информация будет храниться в тайне.
Это архивная запись из блога Netsparker (теперь Invicti). Обратите внимание, что содержимое может не отражать текущие названия продуктов и функции в предложении Invicti.
В мире информационной безопасности и конфиденциальности запросы системы доменных имен (DNS) представляют собой особую проблему. Мало того, что они не зашифрованы по умолчанию, что позволяет любому легко перехватить и изменить их, но злоумышленники также использовали их для усиления атак распределенного отказа в обслуживании (DDoS).
Злоумышленники могут сделать это, поскольку DNS использует протокол пользовательских дейтаграмм (UDP) для пакетов размером до 4096 байт, а отсутствие трехэтапного рукопожатия TCP позволяет легко подделать исходный IP-адрес. Это означает, что злоумышленники могут отправлять относительно небольшие запросы на DNS-сервер, который, в свою очередь, отправляет гораздо более объемные ответы на поддельный IP-адрес. Но это не единственная проблема с DNS.
Вы не можете просто заблокировать исходящие DNS-запросы?
Если вы серьезно относитесь к онлайн-безопасности, вам необходимо использовать надежный брандмауэр, чтобы блокировать определенные входящие и исходящие запросы. Это означает, что если вы используете веб-сайт в VPN, нет необходимости предоставлять доступ к его службе Secure Shell (SSH) всем, кто к нему подключается.
Эксфильтрация данных через DNS
Во-первых, whoami преобразуется в текущего пользователя. В случае веб-серверов Apache этим пользователем, скорее всего, является www-data. После расширения команда будет выглядеть следующим образом:
Что приходит на ум, когда вы читаете, как невероятно неудобно отправлять большие объемы данных с помощью DNS-запросов? Конечно! Хранение файлов в кэшах DNS-серверов! Смущенный? Позвольте мне объяснить.
Действительно ли DNSFS является файловой системой на основе DNS?
Некоторое время назад Бен Кокс проверял, как долго некоторые преобразователи DNS фактически хранят записи DNS в своем кэше. Выяснилось, что некоторые из них хранили данные до одной недели. С тех пор, как он написал сообщение в блоге о своих выводах, ему было любопытно, может ли он использовать это поведение для хранения файлов в кешах преобразователей DNS.
- Сначала ему пришлось просканировать Интернет в поисках открытых преобразователей DNS. Когда он закончил, у него был довольно большой список. После десяти дней ожидания, чтобы отсеять резолверы, работающие на динамических IP-адресах, у него все еще оставалось много открытых резолверов.
- Затем он написал DNSFS (файловую систему DNS) — инструмент, который позволяет ему хранить файлы в записях DNS. Вот как это работает. Предположим, ему принадлежит имя хоста dnsfs.ns, на котором он запускает инструмент DNSFS. Если он хочет сохранить файл name.txt, он может использовать открытый преобразователь для запроса some-subdomain.dnsfs.ns. Инструмент DNSFS затем, в свою очередь, вернет версию файла в кодировке base64 в записи .txt с TTL, установленным на 68 лет. После этого файл удаляется из памяти DNSFS.
- Теперь пользователь может использовать DNSFS для повторного запроса преобразователя и извлечения файла из кэшированной записи TXT. Однако если пользователь хочет хранить файлы большего размера, они разбиваются на части по 180 байт каждая и сохраняются в разных записях TXT.
Если вам интересно, работает ли это на самом деле, ознакомьтесь с записью в его блоге (ссылка выше), где вы можете увидеть этот инструмент в действии. Он смог использовать эту технику для хранения одной из своих предыдущих записей в блоге на разных DNS-серверах. Но, как бы заманчиво это ни звучало, пожалуйста, не храните свои налоговые записи на открытых преобразователях DNS, так как этот метод хранения крайне ненадежен!
Читайте также: