Разное

Днс как расшифровать: Что такое DNS-сервер и для чего он нужен ⚛️

29.01.2021

Содержание

Что такое DNS-сервер и для чего он нужен ⚛️

Работа с доменами невозможна без знания принципов управления ими и понимания что такое DNS-сервер. Это позволит избежать возможных проблем с доступом к сайту или быстрее устранять их в случае возникновения.

Что представляет собой DNS

Для начала, следует рассмотреть понятие DNS и описание его работы. DNS — это аббревиатура от Domain Name System («Системы доменных имен»), главной задачей которой является хранение и управление информацией о доменных зонах.

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

По аналогии с телефонным справочником, можно назвать доменное имя (URL-адрес) «контактом», а IP-адрес — «номером абонента». Если дать определение простыми словами, DNS — это сама телефонная книга со всеми сохраненными в ней контактами.

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

Зачем нужны DNS-серверы

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

Назначение DNS-сервера

  • Хранение информации о доменах и предоставление ее по запросам;
  • Кэширования DNS-записей из остальных DNS-серверов.

Классификация серверов

Учитывая функции DNS-сервера, их можно поделить на несколько видов. При этом, сервер-преобразователь или «резолвер» (от англ. Resolver, «преобразователь»), непосредственно конвертирующий доменные имена в IP-адреса, может одновременно принадлежать к двум и более типам.

Ниже представлены определения основных типов DNS-серверов.

  • Авторитативный — DNS-сервер, который отвечает за определенную зону.
  • Первичный (Мастер) — сервер, уполномоченный вносить изменения в зону. Как правило, в зоне находится только один первичный сервер.
  • Вторичный (Слейв) — сервер без права применять изменения в зоны, получающий от «мастера» только уведомления об изменениях. В зоне может находиться неограниченное количество слейвов.
  • Кэширующий — отвечает за обслуживание пользователей. Он принимает рекурсивные запросы, а затем обрабатывает их с использованием нерекурсивных запросов или передает на вышестоящий сервер. Большинство серверов, работающих непосредственно с пользователями, является именно кэширующими.
  • Перенаправляющий (Прокси, Балансирующий) — кэширующий сервер, который не отдает данные напрямую, а перенаправляет запросы на связанную с ним цепь кэширующих серверов. Благодаря этому перераспределяется общая нагрузка и уменьшается вероятность даунтайма.
  • Корневой (Рут) — авторитативный сервер в корневой зоне. В мире расположено 13 таких серверов, их домены находятся в зоне root-servers.net.
  • Регистрирующий — принимает информацию об обновлениях от пользователей.

Кэширование

Чтобы понимать, как работает DNS-сервер, нужно детально рассмотреть, как в нем происходит процесс кэширования.

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

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

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

Как правило, для работы домена достаточно сохранить свои данные на двух DNS-серверах — первичном и вторичном. Хотя, гораздо лучше указывать большее их количество. Это повысит надежность работы веб-адреса, поскольку при отсутствии доступа к одному DNS-серверу, можно будет обработать запрос на следующем.

Как работает DNS-сервер

Рассмотрим более подробно принцип работы DNS-сервера на примере сайта example.com. Все доменные имена и IP-адреса здесь приведены только для примера.

  1. Пользователь вводит адрес нужного сайта (www. example.com) в адресную строку браузера и отправляет запрос.
  2. Запрос, содержащий искомое доменное имя, отправляется серверу-преобразователю имен DNS (резолверу), указанному в настройках операционной системы компьютера для поиска IP-адреса.
  3. Преобразователь выполняет перенаправление запроса на корневой DNS-сервер, который отдает в ответ сервер зоны доменов верхнего уровня (.com), ответственный за искомый домен.
  4. Преобразователь еще раз перенаправляет запрос на сервер зоны доменов верхнего уровня (.com), и получает в ответ адрес конкретного NS-сервера, к которому приписан искомый домен (ns1.eternalhost.net).
  5. Ответственный сервер получает запрос резолвера и отдает IP-адрес (192.0.2.44), соответствующий доменному имени в первоначальном запросе.
  6. После получения необходимого IP-адреса, преобразователь имен передает это значение браузеру. Вдобавок, он выполняет кэширование полученных данных о сопоставлении доменного имени с IP-адресом, чтобы при последующих аналогичных запросах быстрее на них отвечать.
  7. С браузера отправляется новый запрос уже по полученному IP-адресу. Веб-сервер example.com возвращает страницу на браузер, после чего она открывается.

Следует понимать, что информация о соответствии доменного имени IP-адресу хранится на сервере имен определенное время и обновляется с определенной периодичностью. Эти параметры могут отличаться, в зависимости от того, как настроены NS-записи и работает DNS.

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

 

Общие сведения о понятиях DNS

  • Чтение занимает 5 мин

В этой статье

Область применения. Windows Server 2016, Windows Server 2012 R2, Windows Server 2012Applies To: Windows Server 2016, Windows Server 2012 R2, Windows Server 2012

Служба доменных имен (DNS) — это распределенная база данных, представляющая пространство имен.Domain Name System (DNS) is a distributed database that represents a namespace. Пространство имен содержит все сведения, необходимые любому клиенту для поиска любого имени.The namespace contains all of the information needed for any client to look up any name. Любой DNS-сервер может отвечать на запросы о любом имени в своем пространстве имен.Any DNS server can answer queries about any name within its namespace. DNS-сервер отвечает на запросы одним из следующих способов:A DNS server answers queries in one of the following ways:

  • Если ответ находится в кэше, он отвечает на запрос из кэша. If the answer is in its cache, it answers the query from the cache.
  • Если ответ находится в зоне, размещенной на DNS-сервере, он отвечает на запрос из своей зоны.If the answer is in a zone hosted by the DNS server, it answers the query from its zone. Зона — это часть дерева DNS, хранящаяся на DNS-сервере.A zone is a portion of the DNS tree stored on a DNS server. Когда DNS-сервер размещает зону, он является полномочным для имен в этой зоне (то есть DNS-сервер может отвечать на запросы для любого имени в зоне).When a DNS server hosts a zone, it is authoritative for the names in that zone (that is, the DNS server can answer queries for any name in the zone). Например, сервер, на котором размещена зона contoso.com, может отвечать на запросы по любому имени в contoso.com.For example, a server hosting the zone contoso.com can answer queries for any name in contoso.com.
  • Если сервер не может ответить на запрос из своего кэша или зон, он запрашивает у других серверов ответ.If the server cannot answer the query from its cache or zones, it queries other servers for the answer.

Важно понимать основные возможности DNS, такие как делегирование, рекурсивное разрешение имен и интегрированные в Active Directory зоны DNS, так как они непосредственно влияют на структуру Active Directory логической структуры.It is important to understand the core features of DNS, such as delegation, recursive name resolution, and Active Directory-integrated DNS zones, because they have a direct impact on your Active Directory logical structure design.

Дополнительные сведения о DNS и службах домен Active Directory (AD DS) см. в разделе DNS и AD DS.For more information about DNS and Active Directory Domain Services (AD DS), see DNS and AD DS.

ДелегированиеDelegation

Чтобы DNS-сервер ответил на запросы о любом имени, он должен иметь прямой или косвенный путь к каждой зоне в пространстве имен.For a DNS server to answer queries about any name, it must have a direct or indirect path to every zone in the namespace. Эти пути создаются с помощью делегирования. These paths are created by means of delegation. Делегирование — это запись в родительской зоне, которая содержит сервер доменных имен, полномочный для зоны на следующем уровне иерархии.A delegation is a record in a parent zone that lists a name server that is authoritative for the zone in the next level of the hierarchy. Делегирование позволяет серверам в одной зоне ссылаться на клиентов на серверы в других зонах.Delegations make it possible for servers in one zone to refer clients to servers in other zones. На следующем рисунке показан один пример делегирования.The following illustration shows one example of delegation.

Корневой DNS-сервер размещает корневую зону, представленную точкой (.The DNS root server hosts the root zone represented as a dot ( . ).). Корневая зона содержит делегирование для зоны на следующем уровне иерархии — в зоне com.The root zone contains a delegation to a zone in the next level of the hierarchy, the com zone. Делегирование в корневой зоне сообщает корневому серверу DNS, что для поиска зоны com необходимо обратиться к серверу com. The delegation in the root zone tells the DNS root server that, to find the com zone, it must contact the Com server. Аналогично, делегирование в зоне com сообщает серверу com, что для поиска зоны contoso.com необходимо обратиться к серверу Contoso.Likewise, the delegation in the com zone tells the Com server that, to find the contoso.com zone, it must contact the Contoso server.

Примечание

Делегирование использует два типа записей.A delegation uses two types of records. В записи ресурса сервера имен (NS) содержится имя полномочного сервера.The name server (NS) resource record provides the name of an authoritative server. Записи ресурсов узла (A) и узла (AAAA) предоставляют адреса IP версии 4 (IPv4) и IP версии 6 (IPv6) полномочного сервера.Host (A) and host (AAAA) resource records provide IP version 4 (IPv4) and IP version 6 (IPv6) addresses of an authoritative server.

Эта система зон и делегирования создает иерархическое дерево, представляющее пространство имен DNS. This system of zones and delegations creates a hierarchical tree that represents the DNS namespace. Каждая зона представляет слой в иерархии, и каждое делегирование представляет собой ветвь дерева.Each zone represents a layer in the hierarchy, and each delegation represents a branch of the tree.

Используя иерархию зон и делегирования, корневой сервер DNS может найти любое имя в пространстве имен DNS.By using the hierarchy of zones and delegations, a DNS root server can find any name in the DNS namespace. Корневая зона включает делегирования, которые напрямую или косвенно переводят на все другие зоны в иерархии.The root zone includes delegations that lead directly or indirectly to all other zones in the hierarchy. Любой сервер, который может запрашивать корневой DNS-сервер, может использовать сведения в делегировании для поиска любого имени в пространстве имен.Any server that can query the DNS root server can use the information in the delegations to find any name in the namespace.

Рекурсивное разрешение именRecursive name resolution

Рекурсивное разрешение имен — это процесс, с помощью которого DNS-сервер использует иерархию зон и делегирований для реагирования на запросы, для которых он не является полномочным.Recursive name resolution is the process by which a DNS server uses the hierarchy of zones and delegations to respond to queries for which it is not authoritative.

В некоторых конфигурациях DNS-серверы включают корневые ссылки (то есть список имен и IP-адресов), которые позволяют им запрашивать корневые серверы DNS.In some configurations, DNS servers include root hints (that is, a list of names and IP addresses) that enable them to query the DNS root servers. В других конфигурациях серверы пересылают все запросы, которые они не могут ответить на другой сервер.In other configurations, servers forward all queries that they cannot answer to another server. Пересылка и корневые указания являются методами, которые DNS-серверы могут использовать для разрешения запросов, для которых они не являются полномочными. Forwarding and root hints are both methods that DNS servers can use to resolve queries for which they are not authoritative.

Разрешение имен с помощью корневых ссылокResolving names by using root hints

Корневые ссылки позволяют любому DNS-серверу размещать корневые серверы DNS.Root hints enable any DNS server to locate the DNS root servers. После того как DNS-сервер обнаружит корневой сервер DNS, он может разрешить любой запрос для этого пространства имен.After a DNS server locates the DNS root server, it can resolve any query for that namespace. На следующем рисунке показано, как DNS разрешает имя с помощью корневых ссылок.The following illustration describes how DNS resolves a name by using root hints.

В этом примере происходят следующие события:In this example, the following events occur:

  1. Клиент отправляет рекурсивный запрос на DNS-сервер для запроса IP-адреса, соответствующего имени ftp.contoso.com.A client sends a recursive query to a DNS server to request the IP address that corresponds to the name ftp. contoso.com. Рекурсивный запрос указывает, что клиент хочет получить окончательный ответ на запрос.A recursive query indicates that the client wants a definitive answer to its query. Ответ на рекурсивный запрос должен быть допустимым адресом или сообщением, указывающим, что адрес не найден.The response to the recursive query must be a valid address or a message indicating that the address cannot be found.
  2. Так как DNS-сервер не является полномочным для имени и не имеет ответа в своем кэше, DNS-сервер использует корневые ссылки для поиска IP-адреса корневого сервера DNS.Because the DNS server is not authoritative for the name and does not have the answer in its cache, the DNS server uses root hints to find the IP address of the DNS root server.
  3. DNS-сервер использует итеративный запрос, чтобы запросить у корневого сервера DNS разрешение имени ftp.contoso.com.The DNS server uses an iterative query to ask the DNS root server to resolve the name ftp.contoso.com. Итеративный запрос указывает, что сервер будет принимать ссылку на другой сервер вместо определенного ответа на запрос. An iterative query indicates that the server will accept a referral to another server in place of a definitive answer to the query. Так как имя ftp.contoso.com заканчивается на метку com, корневой сервер DNS возвращает ссылку на COM-сервер, на котором размещена зона com.Because the name ftp.contoso.com ends with the label com, the DNS root server returns a referral to the Com server that hosts the com zone.
  4. DNS-сервер использует итеративный запрос, чтобы запросить у COM-сервера разрешение имени ftp.contoso.com.The DNS server uses an iterative query to ask the Com server to resolve the name ftp.contoso.com. Так как имя ftp.contoso.com заканчивается именем contoso.com, com-сервер возвращает ссылку на сервер Contoso, на котором размещена зона contoso.com.Because the name ftp.contoso.com ends with the name contoso.com, the Com server returns a referral to the Contoso server that hosts the contoso.com zone.
  5. DNS-сервер использует итеративный запрос, чтобы попросить сервера Contoso разрешить имя ftp. contoso.com.The DNS server uses an iterative query to ask the Contoso server to resolve the name ftp.contoso.com. Сервер Contoso находит ответ в данных зоны, а затем возвращает ответ на сервер.The Contoso server finds the answer in its zone data and then returns the answer to the server.
  6. Затем сервер возвращает результат клиенту.The server then returns the result to the client.

Разрешение имен с помощью пересылкиResolving names by using forwarding

Пересылка позволяет маршрутизировать разрешение имен через определенные серверы вместо использования корневых ссылок.Forwarding enables you to route name resolution through specific servers instead of using root hints. На следующем рисунке показано, как DNS разрешает имя с помощью пересылки.The following illustration describes how DNS resolves a name by using forwarding.

В этом примере происходят следующие события:In this example, the following events occur:

  1. Клиент запрашивает DNS-сервер для имени ftp. contoso.com.A client queries a DNS server for the name ftp.contoso.com.
  2. DNS-сервер перенаправляет запрос на другой DNS-сервер, который называется сервером пересылки.The DNS server forwards the query to another DNS server, known as a forwarder.
  3. Поскольку сервер пересылки не является полномочным для имени и не имеет ответа в своем кэше, он использует корневые ссылки для поиска IP-адреса корневого сервера DNS.Because the forwarder is not authoritative for the name and does not have the answer in its cache, it uses root hints to find the IP address of the DNS root server.
  4. Сервер пересылки использует итеративный запрос, чтобы запросить у корневого сервера DNS разрешение имени ftp.contoso.com.The forwarder uses an iterative query to ask the DNS root server to resolve the name ftp.contoso.com. Так как имя ftp.contoso.com заканчивается именем com, корневой сервер DNS возвращает ссылку на COM-сервер, на котором размещена зона com.Because the name ftp.contoso.com ends with the name com, the DNS root server returns a referral to the Com server that hosts the com zone.
  5. Сервер пересылки использует итеративный запрос, попросив серверу com разрешить имя ftp.contoso.com.The forwarder uses an iterative query to ask the Com server to resolve the name ftp.contoso.com. Так как имя ftp.contoso.com заканчивается именем contoso.com, com-сервер возвращает ссылку на сервер Contoso, на котором размещена зона contoso.com.Because the name ftp.contoso.com ends with the name contoso.com, the Com server returns a referral to the Contoso server that hosts the contoso.com zone.
  6. Сервер пересылки использует итеративный запрос, чтобы попросить сервера Contoso разрешить имя ftp.contoso.com.The forwarder uses an iterative query to ask the Contoso server to resolve the name ftp.contoso.com. Сервер Contoso находит ответ в файлах зоны, а затем возвращает ответ на сервер.The Contoso server finds the answer in its zone files, and then returns the answer to the server.
  7. Затем сервер пересылки возвращает результат исходному DNS-серверу.The forwarder then returns the result to the original DNS server.
  8. Затем исходный DNS-сервер возвращает результат клиенту.The original DNS server then returns the result to the client.

есть ли разница — МирДоступа

В чем разница между торговой сетью ДНС и магазинами Технопоинт? Постараемся ответить на этот вопрос максимально доступно.

Итак, если говорить простым языком Технопоинт является дискаунтером сети ДНС. (Примечание редактора: дискаунтер — магазин, который реализует товар по оптовым ценам или близко к ним).

Таким образом, магазин Технопоинт отличается от ДНС в первую очередь стоимостью товаров, но в 2019 году ДНС и Технопоинт сравнялись по ценам и сейчас разница между ними стерта, разве что в последнем нет менеджеров по продажам.

Ниже приводим отзыв о дискаунтере, который недавно упал к нам на электронную почту:

Заказал 2 клавиатуры в Технопоинт и решил сравнить цены с ДНС. Оказалось, что цена одинаковая. Получается столько лет покупал в ДНС ничего не потерял. Разницы в цене вообще не заметил ни на какие товар. Хотя говорят, что несколько лет назад Технопоинт оправдывал свое звание дискаунтера и можно было купить товар со скидкой больше 30%

Продолжаем отвечать на вопрос чем отличается ДНС от ДНС Технопоинт. В ДНС есть традиционные торговые витрины, в Технопоинт — нет. В последнем есть электронный прайс, который позволяет заказать любой товар со склада прямо на точку выдачи.

Если Вы пришли в ДНС, то априори можете пощупать, понюхать, посмотреть любой товар и решить нравится ли он Вам или нет. С Технопоинт такое не пройдет — там можно что-то пощупать только после оплаты. Зато на выбор не будут влиять посторонний факторы — продавец, помещение и другие субъективные вещи. Таким образом, классический магазин ДНС позволяет покупать тем кто ориентируется скорее на внешний вид товара, чем на его технические характеристики.

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

Таким образом, понять чем же всё таки отличается ДНС от ДНС Технопоинт несложно — Технопоинт является дочкой ДНС, который реализует товар по оптовой стоимости, но в 2019 году данное определение уже не актуально, так как цены в обоих магазинах практически сравнялись.

Facebook

Twitter

Мой мир

Вконтакте

Одноклассники

Битва за данные пользователей: зачем нужно шифровать DNS-запросы


Специалисты по обеспечению конфиденциальности и безопасности находятся в центре публичной борьбы за будущее шифрования трафика в интернете. В сентябре кабельные компании и другие представители телекоммуникационной отрасли в США направили в Конгресс письмо с протестом против планов Google по шифрованию трафика системы доменных имен (DNS) в браузере.  В этом месяце Mozilla отправила в Конгресс собственное письмо, в котором просила законодателей не рассматривать этот протест, поскольку он основан на «фактических неточностях».

Речь идет о том, как следует шифровать DNS-трафик — сетевые запросы, которые преобразуют понятные людям доменные имена (адреса сайтов) в IP-адреса серверов. Когда пользователь вводит доменное имя в браузере, тот запрашивает у ближайшего указанного в настройках DNS-сервера IP-адрес, связанный с этим доменным именем.

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

Шифрование DNS гарантирует, что «браузер общается с тем, с чем вы хотите взаимодействовать, а не с тем, куда вас зовут вредоносные программы», — говорит Тим Эйприл, главный архитектор сетевой компании Akamai.

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

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

Два способа шифрования

Современные сети полагаются на протокол защиты транспортного уровня (TLS) для безопасного обмена данными, например, для просмотра веб-страниц, передачи файлов, VPN-подключений, сеансов удаленного рабочего стола и передачи голоса по IP-телефонии. Одна сторона соединения, обычно сервер, имеет сертификат с цифровой подписью, выданный доверенным центром сертификации.  Другая сторона соединения, обычно клиент, использует сертификаты для проверки того, с кем он обменивается данными.

Поскольку протокол TLS уже широко используется для обеспечения конфиденциальности, аутентификации и целостности данных, расширение протокола для работы с DNS является вполне логичным. DNS поверх TLS (IETF RFC 7858) определяет, как DNS-пакеты будут шифроваться с помощью TLS и передаваться по широко используемому протоколу управления передачей (TCP).

По умолчанию DNS проходит через порт 53 по протоколу TCP или UDP. При использовании DNS поверх TLS все зашифрованные пакеты отправляются через порт 853. Большинство общедоступных DNS-серверов, включая Cloudflare, Quad9 и Google, уже поддерживают DNS поверх TLS, и компании, использующие собственную DNS-инфраструктуру, также могут использовать такое шифрование. 

Google включил поддержку DNS поверх TLS в Android Pie (Android 9), чтобы пользователи могли настраивать шифрование DNS как для Wi-Fi, так и для мобильной сети, и многие приложения и устройства уже умеют работать с этой опцией.

«Мы решили проблему, добавив DNS к TLS», — сказал Пол Викси, изобретатель DNS и генеральный директор Farsight Security. Он также признает, что такое решение не является «веб-дружественным» в том смысле, что нет простого пользовательского интерфейса для включения этой функции.

DNS поверх HTTPS (IETF RFC8484) в значительной степени разработан с оглядкой на принципы работы современного интернета, поскольку он вбрасывает все пакеты данных в поток HTTPS вместе с другим зашифрованным веб-трафиком. В отличие от своего конкурента, DNS поверх HTTPS не шифрует отдельные запросы, а вместо этого пропускает их через зашифрованный туннель между клиентом и сервером. 

Поскольку соединение использует HTTPS и HTTP/2, все пакеты выглядят одинаково. Любой, кто отслеживает порт 443 — стандартный порт HTTPS — не сможет идентифицировать DNS-запросы из всего остального веб-трафика.

Плюсы и минусы каждого подхода

Для сторонников конфиденциальности DNS через TLS недостаточно хорош, потому что любой, кто контролирует сеть, будет знать, что любая активность на 853-ем порту связана с этим DNS.  Хотя наблюдатель не будет знать фактическое содержание запроса, поскольку и ответ, и запрос зашифрованы, тот факт, что сетевой администратор или провайдер будут знать, что есть такая активность, уже может привести к последствиям для пользователя (в худшем случае этот порт может быть вообще закрыт). Хотя DNS поверх TLS безопасен, он не так удобен с точки зрения конфиденциальности, как DNS поверх HTTPS.

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

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

Конфиденциальность против безопасности

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

Mozilla объявила, что DNS поверх HTTPS будет использоваться по умолчанию для пользователей Firefox в Соединенных Штатах, и это изменение в настоящее время активно внедряется. Firefox автоматически передает весь DNS-трафик популярному серверу Cloudflare 1.1.1.1 и игнорирует существующие настройки DNS пользователя. Это обходит все связанные с DNS сетевые правила фильтрации, в том числе позволяет попасть на сайты, доступ к которым блокируется по DNS.

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

Microsoft, как обычно, хочет усидеть на двух стульях одновременно: с одной стороны, компания планирует поддерживать DNS поверх HTTPS в Windows, с другой — хочет дать системным администраторам некоторый контроль.

Эйприл считает, что шифрование DNS — это «разумное ограничения доступа» к плохим ресурсам, но с ним нужно быть осторожнее. Провайдеры частенько блокируют имена хостов, используемые Wannacry и другими вредоносными программами, и временами перенаправляют пользователей, пытающихся получить доступ к вредоносным или заблокированным сайтам. Администраторы общедоступных сетей Wi-Fi модифицируют DNS-запросы, чтобы сначала загружалась страница авторизации для новых пользователей. DNS поверх HTTPS ломает все эти настройки.

Отчасти поэтому Mozilla не включает DNS поверх HTTPS для пользователей Firefox в Соединенном Королевстве, так как там закон требует от интернет-провайдеров блокировать доступ к нелегальным веб-сайтам, таким как те, которые связаны с детской порнографией.

DNS поверх HTTPS против DNS поверх TLS — это еще одна разновидность борьбы за данные о просмотре веб-страниц пользователем и за то, кто получит доступ к ним. DNS-запросы от Firefox будут отправляться в Cloudflare, что означает, что Cloudflare будет иметь доступ к огромному количеству данных DNS. По словам Викси, технологические компании, которые управляют централизованными DNS-серверами, такие как Cloudflare и Google, в конечном итоге получат выгоду от DNS поверх HTTPS, поскольку именно они будут получать информацию о том, что люди просматривают в интернете.

Сторонники конфиденциальности считают, что не провайдеры, а сами пользователи должны отвечать за то, как они попадают на сайты в интернете. Но решение Mozilla заставляет пользователей Firefox использовать Cloudflare независимо от их собственных предпочтений.

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

Реальность современного интернета заключается в том, что интернет-провайдеры и компании играют определенную роль в предотвращении угроз для пользователей. В идеале веб-браузеры должны позволять пользователям выбирать, следует ли использовать DNS поверх TLS или DNS поверх HTTPS, а также предоставлять пользователям возможность контролировать, какого поставщика DNS использовать.


iGuides в Telegram — t. me/igmedia
iGuides в Яндекс.Дзен — zen.yandex.ru/iguides.ru

DNS Безопасность с DNSCrypt | OpenDNS

Представляем DNSCrypt

Предыстория: потребность в лучшей безопасности DNS

DNS - один из фундаментальных строительных блоков Интернета. Он используется каждый раз, когда вы посещаете веб-сайт, отправляете электронное письмо, общаетесь в чате или делаете что-то еще в Интернете. Хотя OpenDNS уже много лет обеспечивает безопасность мирового класса с использованием DNS, и OpenDNS - самый безопасный из доступных DNS-сервисов, основной протокол DNS не был достаточно безопасным для нашего удобства.Многие помнят уязвимость Каминского, которая повлиял почти на все реализации DNS в мире (но не на OpenDNS).

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

Было множество примеров взлома, атак типа «злоумышленник в середине» и отслеживания DNS-трафика на «последней миле», и это представляет серьезную угрозу безопасности, которую мы всегда хотели исправить. Сегодня мы можем.

Почему DNSCrypt так важен

Точно так же, как SSL превращает веб-трафик HTTP в зашифрованный веб-трафик HTTPS, DNSCrypt превращает обычный DNS-трафик в зашифрованный DNS-трафик, защищенный от перехвата и атак типа «злоумышленник в середине».Не требует изменения домена имен или того, как они работают, он просто предоставляет метод безопасного шифрования связи между нашими клиентами и нашими DNS-серверами в наших центрах обработки данных. Однако мы знаем, что одни только заявления не работают в сфере безопасности, поэтому мы открыли загрузите исходный код в нашу базу кода DNSCrypt, и он доступен на GitHub.

DNSCrypt потенциально может стать самым значительным достижением в области Интернет-безопасности после SSL, значительно улучшая онлайн-безопасность и конфиденциальность каждого отдельного пользователя Интернета.

Примечание. Ищете защиту от вредоносных программ, бот-сетей и фишинга для ноутбуков или устройств iOS? Проверьте мобильность Umbrella от OpenDNS.

Загрузить сейчас:

Загрузить DNSCrypt для Mac
Загрузить DNSCrypt для Windows

Часто задаваемые вопросы (FAQ):

1. Говоря простым языком, что такое DNSCrypt?

DNSCrypt - это легкое программное обеспечение, которое каждый должен использовать для повышения конфиденциальности и безопасности в Интернете. Он работает, шифруя весь DNS-трафик между пользователем и OpenDNS, предотвращая любые шпионские, спуфинговые или атаки типа «злоумышленник в середине».

2. Как я могу использовать DNSCrypt сегодня?

Мы открыли исходный код нашей базы кода DNSCrypt, и он доступен на GitHub. Графические интерфейсы больше не разрабатываются; однако сообщество с открытым исходным кодом по-прежнему предоставляет неофициальные обновления к техническому превью.

Советы:
Если у вас есть брандмауэр или другое промежуточное программное обеспечение, обрабатывающее ваши пакеты, вам следует попробовать включить DNSCrypt с TCP через порт 443.Это заставит большинство брандмауэров думать, что это HTTPS-трафик, и оставить его в покое.

Если вы предпочитаете надежность безопасности, включите откат на небезопасный DNS. Если вы не можете связаться с нами, мы попытаемся использовать ваши назначенные DHCP или ранее настроенные DNS-серверы. Однако это угроза безопасности.

3. Что насчет DNSSEC? Устраняет ли это необходимость в DNSCrypt?

Нет. DNSCrypt и DNSSEC дополняют друг друга. DNSSEC выполняет ряд функций.Во-первых, он обеспечивает аутентификацию. (Это запись DNS, о которой я получаю ответ от владельца доменного имени, о котором я спрашиваю, или она была подделана с?) Во-вторых, DNSSEC обеспечивает цепочку доверия, которая помогает установить уверенность в том, что ответы, которые вы получаете, поддаются проверке. Но, к сожалению, DNSSEC на самом деле не обеспечивает шифрование записей DNS, даже если они подписаны DNSSEC. Четный если бы все в мире использовали DNSSEC, необходимость в шифровании всего DNS-трафика не исчезла бы.Более того, DNSSEC сегодня представляет собой почти нулевой процент от общего числа доменных имен и все меньший процент записей DNS каждый день по мере того, как Интернет растет.

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

4. Используется ли SSL? Что такое криптовалюта и каков дизайн?

Мы не используем SSL. Мы проводим аналогию с тем, что DNSCrypt похож на SSL в том смысле, что он обертывает весь трафик DNS с помощью шифрования так же, как SSL обертывает весь трафик HTTP, но это не криптографическая библиотека. Мы используем криптографию с эллиптическими кривыми, в частности, эллиптическая кривая Curve25519.Цели разработки аналогичны целям, описанным в конструкции сервера пересылки DNSCurve.

Как зашифровать свой DNS с помощью DNSCrypt в Ubuntu и Debian

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

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

В этом руководстве вы узнаете:

  • Как установить DNSCrypt в Ubuntu и Debian.
  • Как настроить DNS-сервер.
  • Как установить DNSCrypt в качестве системного DNS с помощью NetworkManager и Resolvconf.

Конфигурация DNS NetworkManager.

Используемые требования к программному обеспечению и условные обозначения

11 11
Требования к программному обеспечению и условные обозначения командной строки Linux
Категория Используемые требования, условные обозначения или версия программного обеспечения
Система Текущая версия Debian10 или Ubuntu
Программное обеспечение DNSCrypt
Другое Рабочая установка поддерживаемого дистрибутива с привилегиями root.
Условные обозначения # - требует, чтобы данные команды Linux выполнялись с привилегиями root либо непосредственно как пользователь root, либо с помощью команды sudo $ - требует, чтобы данные команды linux выполнялись как обычные -privileged user

Установить DNSCrypt

dnscrypt-proxy - ArchWiki

Эту статью или раздел необходимо расширить.

dnscrypt-proxy - это DNS-прокси с поддержкой зашифрованных DNS-протоколов DNS over HTTPS и DNSCrypt, которые можно использовать для предотвращения атак типа «злоумышленник в середине» и перехвата. dnscrypt-proxy также совместим с DNSSEC.

Установка

Установите пакет dnscrypt-proxy.

Конфигурация

Запуск

Примечание: Несмотря на то, что есть два способа запустить прокси, восходящий поток рекомендует службу , . [1] [2]

Служба может быть запущена двумя взаимоисключающими способами (т. Е. Может быть включен только один из двух):

  1. Со службой systemd dnscrypt-proxy.Сервис .
    • Параметр listen_addresses должен быть настроен (например, listen_addresses = ['127.0.0.1:53', '[:: 1]: 53'] ) в файле конфигурации при использовании службы.
  2. Активация через сокет с использованием dnscrypt-proxy. socket .
    • Параметр listen_addresses должен быть пустым (т.е. listen_addresses = [] ) в файле конфигурации, поскольку systemd заботится о конфигурации сокета.

Выбрать преобразователь

Если оставить server_names закомментированным в файле конфигурации /etc/dnscrypt-proxy/dnscrypt-proxy.toml , dnscrypt-proxy выберет самый быстрый сервер из источников, уже настроенных в [источники] [3 ]. Списки будут загружены, проверены и автоматически обновлены [4]. Таким образом, настройка определенного набора серверов не является обязательной.

Чтобы вручную указать, какой сервер используется, отредактируйте / etc / dnscrypt-proxy / dnscrypt-proxy.toml и раскомментируйте переменную server_names , выбрав один или несколько серверов. Например, чтобы использовать серверы Cloudflare:

 server_names = ['cloudflare', 'cloudflare-ipv6']
 

Полный список преобразователей находится на странице апстрима или Github. Если dnscrypt-proxy успешно работал в системе раньше, /var/cache/dnscrypt-proxy/public-resolvers.md также будет содержать список. Посмотрите описание серверов, которые проверяют DNSSEC, не регистрируют и не подвергаются цензуре.Эти требования можно настроить глобально с помощью параметров require_dnssec , require_nolog , require_nofilter .

Отключить любые службы, привязанные к порту 53

Совет: При использовании #Unbound в качестве локального DNS-кеша этот раздел можно игнорировать, так как unbound по умолчанию работает на порте 53.

Чтобы узнать, используют ли какие-либо программы порт 53, запустите:

 $ ss -lp 'sport =: domain'
 

Фактическая точность данной статьи или раздела оспаривается.

Причина: systemd-resolved слушает 127.0.0.53:53, это не должно влиять на dnscrypt-proxy, который слушает 127.0.0.1:53. (Обсудить в Обсуждении: Dnscrypt-proxy #)

Если вывод содержит больше, чем первая строка имен столбцов, вам необходимо отключить любую службу, использующую порт 53. Одна из распространенных причин - systemd-resolved.service (NetworkManager # Unit dbus-org.freedesktop.resolve1.service not найдено), но другие сетевые менеджеры могут иметь аналогичные компоненты. Вы будете готовы продолжить, как только приведенная выше команда выведет не более чем следующую строку:

 Netid State Recv-Q Send-Q Local Address: Port Peer Address: Порт
 

Изменить файл resolv.conf

Эту статью или раздел необходимо расширить.

Измените файл resolv.conf и замените текущий набор адресов резолвера адресом для localhost и опциями [5]:

 сервер имен :: 1
сервер имен 127.0.0.1
опции edns0 однократное открытие-повторное открытие
 

Другие программы могут перезаписывать этот параметр; см. resolv.conf # Перезапись /etc/resolv.conf для подробностей.

Запустить службу systemd

Наконец, запустите / включите dnscrypt-proxy.service unit или dnscrypt-proxy. socket , в зависимости от того, какой метод вы выбрали выше.

Советы и хитрости

Конфигурация локального кэша DNS

Совет: dnscrypt-proxy может кэшировать записи, не полагаясь на другую программу. Эта функция включена по умолчанию в строке cache = true в вашем файле конфигурации dnscrypt-proxy

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

Изменить порт

Чтобы пересылать запросы из локального кеша DNS, dnscrypt-proxy должен прослушивать порт, отличный от порта по умолчанию 53 , поскольку сам DNS-кеш должен прослушивать 53 и запрашивать dnscrypt-proxy на другой порт. Номер порта 53000 используется в качестве примера в этом разделе.В этом примере номер порта больше 1024, поэтому dnscrypt-proxy не требуется для запуска от имени root.

Есть два метода изменения порта по умолчанию:

Метод розетки

Отредактируйте dnscrypt-proxy.socket со следующим содержимым:

 [розетка]
ListenStream =
ListenDatagram =
ListenStream = 127.0.0.1: 53000
ListenStream = [:: 1]: 53000
ListenDatagram = 127.0.0.1: 53000
ListenDatagram = [:: 1]: 53000
 

Когда запросы перенаправляются из локального кэша DNS на 53000 , dnscrypt-proxy.socket запустит dnscrypt-proxy.service .

Метод обслуживания

Измените параметр listen_addresses в файле /etc/dnscrypt-proxy/dnscrypt-proxy.toml следующим образом:

 listen_addresses = ['127.0.0.1:53000', '[:: 1]: 53000']
 
Пример конфигурации локального кэша DNS

Следующие конфигурации должны работать с dnscrypt-proxy и предполагать, что он прослушивает порт 53000 .

Несвязанный

Настройте Unbound по своему вкусу (в частности, см. Unbound # Local DNS server) и добавьте следующие строки в конец раздела server в файле /etc/unbound/unbound.conf :

 do-not-query-localhost: нет
форвард-зона:
  имя: "."
  прямой-адрес: :: 1 @ 53000
  прямой адрес: [email protected]
 

Совет: Если вы настраиваете сервер, добавьте interface: [email protected] и access-control: your-network / subnet-mask allow inside the server: section so что другие компьютеры могут подключаться к серверу.Клиент должен быть настроен с использованием nameserver address-of your-server в /etc/resolv.conf .

Перезапустите unbound.service , чтобы изменения вступили в силу.

dnsmasq

Настройте dnsmasq как локальный кеш DNS. Базовая конфигурация для работы с dnscrypt-proxy :

 /etc/dnsmasq. conf 
 без разрешения
сервер = :: 1 # 53000
сервер = 127.0.0.1 # 53000
адрес-прослушивания = :: 1,127.0.0.1 

Если вы настроили dnscrypt-proxy для использования резолвера с включенной проверкой DNSSEC, не забудьте включить его также в dnsmasq:

 / и т. Д. / Dnsmasq.conf 
 conf-файл = / usr / share / dnsmasq / trust-anchors.conf
dnssec 

Перезапустите службу dnsmasq.service , чтобы изменения вступили в силу.

pdnsd

Установите pdnsd. Базовая конфигурация для работы с dnscrypt-proxy :

 /etc/pdnsd.conf 
 global {
    perm_cache = 1024;
    cache_dir = "/ var / cache / pdnsd";
    run_as = "pdnsd";
    server_ip = 127.0.0.1;
    status_ctl = on;
    query_method = udp_tcp;
    min_ttl = 15м; # Сохранять кешированные записи не менее 15 минут.max_ttl = 1w; # Одна неделя.
    таймаут = 10; # Глобальная опция тайм-аута (10 секунд).
    neg_domain_pol = on;
    udpbufsize = 1024; # Верхний предел размера сообщений UDP. 
}

server {
    метка = "dnscrypt-proxy";
    ip = 127.0.0.1;
    порт = 53000;
    таймаут = 4;
    proxy_only = on;
}

источник {
    владелец = localhost;
    файл = "/ etc / hosts";
} 

Перезапустите pdnsd.service , чтобы изменения вступили в силу.

Включить EDNS0

Эту статью или раздел необходимо расширить.

Механизмы расширения для DNS, которые, помимо прочего, позволяют клиенту указывать размер ответа по UDP.

Добавьте следующую строку в ваш /etc/resolv.conf :

 опции edns0
 

Эта статья или раздел устарели.

Вы также можете добавить следующее в файл /etc/dnscrypt-proxy.conf :

 EDNSPayloadSize  <байтов> 
 

Где <байты> - число, размер по умолчанию - 1252 , со значениями до 4096 байта, которые предположительно безопасны.Значение, меньшее или равное 512 байта, отключит этот механизм, если клиент не отправит пакет с разделом OPT, предоставляющим размер полезной нагрузки.

Тест EDNS0

Воспользуйтесь сервером проверки размера ответа DNS, используйте инструмент командной строки Drill для выполнения запроса TXT для имени rs.dns-oarc.net :

 $ дрель rs.dns-oarc.net TXT
 

Если поддерживается EDNS0 , «раздел ответов» вывода должен выглядеть примерно так:

 первый.x3827.rs.dns-oarc.net.
rst.x4049.x3827.rs.dns-oarc.net.
rst.x4055.x4049.x3827.rs.dns-oarc.net.
«2a00: d880: 3: 1 :: a6c1: 2e89 Ограничение размера ответа DNS составляет не менее 4055 байт»
"2a00: d880: 3: 1 :: a6c1: 2e89 отправил EDNS размер буфера 4096"
 

Как утечки DNS могут разрушить анонимность при использовании VPN и как их остановить

Когда вы пытаетесь оставаться анонимным в сети, VPN - самое простое решение: одним или двумя щелчками мыши ваш IP-адрес, поставщик услуг и местоположение будут замаскированы от любого сайта, на который вы заходите, и от всех, кто пытается шпионить за вашим соединением. .Но утечка DNS может полностью подорвать назначение VPN. Вот как этого не допустить.

(Небольшое примечание перед тем, как мы продолжим: утечка DNS - это проблема конфиденциальности, только если вы беспокоитесь о том, что ваш интернет-провайдер отслеживает ваш просмотр. Это не имеет ничего общего с слежкой АНБ или другими формами цифрового слежения.)

Что такое утечка DNS?

Система доменных имен (DNS) - это система для связывания URL-адресов (например, www. makeuseof.com) и IP-адреса (54.221.192.241). Когда вы используете свой браузер для перехода на веб-сайт, он отправляет запрос на DNS-сервер с URL-адресом, который вы ввели, и указывает на правильный IP-адрес. Это важнейшая часть того, как работает Интернет; см. наше введение в DNS-серверы для получения дополнительной информации.

Обычно DNS-серверы назначаются вашим интернет-провайдером (ISP), что означает, что они могут отслеживать и записывать ваши действия в сети всякий раз, когда вы отправляете запрос на сервер. Когда вы используете виртуальную частную сеть (VPN), DNS-запрос должен быть направлен на анонимный DNS-сервер через вашу VPN, а не напрямую из вашего браузера; это не позволяет вашему интернет-провайдеру контролировать ваше соединение.

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

Очевидно, это нехорошо.Итак, давайте посмотрим, как его диагностировать и остановить.

Диагностика утечки

Если ваш компьютер использует настройки по умолчанию и не маршрутизирует DNS-запросы через DNS-сервер VPN, это не будет очевидным; вам нужно будет использовать тест на герметичность. К счастью, есть один простой способ запомнить: www.dnsleaktest.com.

Просто зайдите на сайт и нажмите кнопку «Стандартный тест» (если вас действительно беспокоит слежка, вы можете нажать «Расширенный тест» - он немного более подробный, но занимает немного больше времени). Если вы видите свою страну и интернет-провайдера в списке на странице результатов, вы знаете, что ваш интернет-провайдер может контролировать ваше соединение. Это не хорошо.

Остановка утечки

Итак, мы диагностировали утечку. Что теперь? Есть несколько шагов, которые вы можете предпринять, чтобы остановить утечку DNS и предотвратить утечку в будущем. Начнем с самого простого.

Изменить DNS-серверы

Если ваш DNS-сервер по умолчанию - это тот, который был назначен вашим интернет-провайдером, один из самых простых способов не дать им увидеть, что вы делаете в Интернете, - это изменить свой DNS-сервер. Даже если вы не беспокоитесь об утечках DNS, изменение DNS-сервера по умолчанию может быть хорошей идеей, поскольку это может привести к более высокой скорости Интернета.

Следующие DNS-серверы находятся в хорошем состоянии и обеспечат вам высокую производительность и безопасность:

  • Открытый DNS (предпочтительно: 208. 67.222.222, запасной: 208.67.222.220)
  • Comodo Secure DNS (предпочтительно: 8.26.56.26, альтернативный: 8.20.247.20)
  • Google Public DNS (предпочтительно: 8.8.8.8, альтернативный: 8.8.4.4)

Чтобы узнать, как изменить настройки DNS на вашем компьютере, ознакомьтесь со статьей Дэнни «Как изменить DNS-серверы и повысить безопасность в Интернете»."

Использование VPN с защитой от утечки DNS

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

Итак, какие VPN включают защиту от утечки DNS? По данным BestVPNz. com, Private Internet Access, TorGuard (оба вошли в наш список лучших VPN), VPNArea, PureVPN, ExpressVPN, VPN.AC и LiquidVPN - все они обеспечивают защиту. Если вы используете одну из этих VPN, убедитесь, что ваши настройки установлены правильно. Если это не так и вас беспокоит слежка интернет-провайдера, возможно, вам стоит подумать о переходе.

Использование программного обеспечения для мониторинга VPN

Некоторое программное обеспечение для мониторинга VPN также включает поддержку для устранения утечек DNS. Профессиональная версия VPNCheck сделает это за вас, как и OpenVPN Watchdog (если вы используете OpenVPN).

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

Отключить Teredo

Teredo - это технология на базе Windows, которая, по сути, обеспечивает связь по двум IP-протоколам: IPv4 и IPv6. Оба присутствуют в Интернете, и в некоторых случаях вам нужно будет использовать что-то вроде Teredo, чтобы позволить им общаться (детали довольно сложны, но вы можете узнать больше на странице в Википедии о туннелировании Teredo). Однако Teredo иногда может вызывать утечку DNS, поэтому вы можете отключить его.

Чтобы отключить Teredo, откройте командную строку и введите следующую команду:

  netsh interface teredo set state disabled  

Если вам нужно снова включить Teredo в какой-то момент, вы можете использовать эту команду:

  netsh interface teredo set state type = default  

Заткни те утечки

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

Использовали ли вы какую-либо из вышеперечисленных стратегий для диагностики или остановки утечек DNS? Есть ли у вас другие рекомендации? Поделитесь своими лучшими советами ниже!

Изображение предоставлено: Дырявый кран (отредактированный), Ночная карта сети США, Различные соединения, подразумевающие карту мира, Деловая женщина с увеличительным стеклом через Shutterstock.

4 простых способа доступа и редактирования iPhone Apple Notes в Windows

Если вы используете Apple Notes на своем iPhone и хотите получить к ним доступ на ПК с Windows, вот несколько способов сделать это.

Об авторе Данн Олбрайт (Опубликовано 519 статей)

Данн - консультант по контент-стратегии и маркетингу, который помогает компаниям генерировать спрос и потенциальных клиентов. Он также ведет блог о стратегии и контент-маркетинге в dannalbright.com.

Больше От Данна Олбрайта
Подпишитесь на нашу рассылку новостей

Подпишитесь на нашу рассылку, чтобы получать технические советы, обзоры, бесплатные электронные книги и эксклюзивные предложения!

Еще один шаг…!

Подтвердите свой адрес электронной почты в только что отправленном вам электронном письме.

DNS01 | сертификат-менеджер

Настройка DNS01 Challenge Provider

Эта страница содержит подробную информацию о различных опциях, доступных на Issuer конфигурация решателя задач DNS01 ресурса.

Для получения дополнительной информации о настройке ACME Issuers и их формате API прочтите Документация ACME Issuers.

Конфигурация провайдера DNS01 должна быть указана на ресурсе Issuer , аналогично к примерам в документации по настройке.

Вы можете прочитать о том, как работает тип запроса DNS01 на Let's Encrypt типы задач страница.

  apiVersion: cert-manager.io/v1
вид: Эмитент
метаданные:
  имя: пример-эмитент
спецификации:
  акме:
    электронная почта: [email protected]
    сервер: https://acme-staging-v02.api.letsencrypt.org/directory
    privateKeySecretRef:
      имя: пример-эмитент-ключ-счета
    решатели:
    - dns01:
        cloudDNS:
          проект: мой-проект
          serviceAccountSecretRef:
            имя: prod-clouddns-svc-acct-secret
            ключ: сервис-аккаунт. json  

Каждый эмитент может указать несколько разных поставщиков запросов DNS01, и также возможно иметь несколько экземпляров одного и того же поставщика DNS на один Эмитент (например, можно настроить две учетные записи CloudDNS, каждая со своим имя).

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

Настройка серверов имен для самопроверки DNS01

cert-manager проверит наличие правильных записей DNS перед попыткой DNS01 вызов.По умолчанию cert-manager будет использовать взятые рекурсивные серверы имен. из /etc/resolv.conf для запроса авторитетных серверов имен, которые он будет затем запросите напрямую, чтобы убедиться, что записи DNS существуют.

Если это нежелательно (например, с несколькими официальными серверами имен или split-horizon DNS) контроллер cert-manager предоставляет два флага, которые позволяют вы меняете это поведение:

--dns01-recursive-nameservers Строка, разделенная запятыми, с указанием хоста и порта рекурсивные серверы имен должен запросить Cert-Manager.

--dns01-recursive-nameservers-only Заставляет диспетчер сертификатов использовать только рекурсивные серверы имен для проверки. Включение этой опции могло вызвать DNS01 Самопроверка занимает больше времени из-за кэширования, выполняемого рекурсивными серверами имен.

Пример использования:

  --dns01-recursive-nameservers-only --dns01-recursive-nameservers = "8.8.8.8:53,1.1.1.1:53"  

Если вы используете Helm-диаграмму cert-manager , вы можете установить рекурсивные серверы имен через .Values.extraArgs или по команде во время установки / обновления Helm с - установить :

  --set 'extraArgs = {- dns01-recursive-nameservers-only, - dns01-recursive-nameservers = 8.8.8.8: 53 \, 1.1.1.1: 53}'  

Делегированных доменов для DNS01

По умолчанию cert-manager не отслеживает записи CNAME, указывающие на поддомены.

Если предоставление доступа cert-manager к корневой зоне DNS нежелательно, то _acme-challenge.example.com субдомен можно вместо этого делегировать другому, менее привилегированный домен ( менее привилегированный.example.org ). Этого можно было добиться следующим образом. Скажем, у одного две зоны:

  • example.com
  • less-privileged.example.org
  1. Создайте запись CNAME, указывающую на этот менее привилегированный домен:

      _acme-challenge.example.com В CNAME _acme-challenge.less-privileged.example.org.
      
  2. Предоставить диспетчеру сертификатов права на обновление менее привилегированных менее привилегированных.example.org зона

  3. Укажите конфигурацию / учетные данные для обновления этой менее привилегированной зоны и добавьте дополнительное поле в соответствующий решатель dns01 . Обратите внимание, что селектор поле все еще работает для исходного example. com , в то время как учетные данные предоставляются для less-privileged.example.org

      apiVersion: cert-manager.io/v1
    вид: Эмитент
    метаданные:
    ...
    спецификации:
    акме:
    ...
    решатели:
    - селектор:
        dnsZones:
        - 'пример.com '
    - dns01:
        # Допустимые значения: None и Follow
        cnameStrategy: Подписаться
        route53:
          регион: eu-central-1
          accessKeyID: <здесь ID доступа для less-privileged.example.org>
          hostedZoneID: <здесь ID зоны для less-privileged.example.org>
          secretAccessKeySecretRef:
            ...  

Если у вас есть множество (под) доменов, требующих отдельных сертификатов, можно совместно использовать псевдоним менее привилегированный домен. Для этого нужно создайте запись CNAME для каждого (под) домена следующим образом:

  _acme-challenge.example.com В CNAME _acme-challenge.less-privileged.example.org.
_acme-challenge.www.example.com В CNAME _acme-challenge. less-privileged.example.org.
_acme-challenge.foo.example.com В CNAME _acme-challenge.less-privileged.example.org.
_acme-challenge.bar.example.com В CNAME _acme-challenge.less-privileged.example.org.  

С этой конфигурацией cert-manager будет рекурсивно следить за записями CNAME, чтобы определить какую зону DNS обновлять во время запросов DNS01.

Поддерживаемые провайдеры DNS01

ACME Issuer поддерживает ряд различных DNS-провайдеров.Ниже это список доступных провайдеров, их конфигурации .yaml , а также дополнительные примечания относительно Kubernetes и провайдера относительно их использования.

Вебхук

cert-manager также поддерживает поставщиков DNS вне дерева с помощью внешнего веб-перехватчика. Ссылки на этих поддерживаемых поставщиков вместе с их документацией приведены ниже:

Вы можете найти дополнительную информацию о том, как настроить поставщиков веб-перехватчиков. Вот.

Чтобы создать нового неподдерживаемого поставщика DNS, следуйте документации для разработчиков. Вот.

Последнее изменение: 18 декабря 2020 г .: Добавление IBM Cloud Internet Service (ibmcis) в список веб-перехватчиков (3b4bbee)

Что такое обратный DNS? Как выполнить обратный поиск в DNS?

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

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

Что такое обратный DNS (rDNS)?

Все мы знаем, что такое DNS и как он работает. Но даже некоторые ИТ-специалисты иногда забывают о rDNS, а некоторые, только что вступившие в клуб, даже не слышали о нем.

Говоря простым языком, обратный DNS, или rDNS, работает противоположно традиционному DNS. То есть вместо преобразования имени домена в IP-адрес он преобразует IP в имя хоста.

Разрешение rDNS - это полностью отдельный механизм от обычного разрешения DNS.Например, если домен yourcompany.com указывает на IP 1.2.3.4 (фиктивный IP-адрес), это не обязательно означает, что обратное разрешение для IP равно 1.2.3.4.

Для хранения записей rDNS существует особый тип записи DNS, называемый записью PTR. Эта запись также известна как «запись ресурса» (RR) и определяет IP-адреса всех систем с использованием инвертированной записи.

Эта конфигурация rDNS позволяет вам искать IP-адрес в DNS, поскольку домен inaddr.arpa добавляется к инвертированной нотации IP, превращая IP в доменное имя.

Например: чтобы преобразовать IP-адрес 1.2.3.4 в запись PTR, нам нужно инвертировать IP и добавить домен inaddr.arpa, в результате чего получится следующая запись: 4.3.2.1.in-addr.arpa.

Классическая работа системы DNS заключается в преобразовании или преобразовании IP-адресов в имена, но в некоторых сценариях требуется обратное, а это означает перевод имен подключенных к Интернету устройств с их IP-адресов. Это то, что называется rDNS, или обратное разрешение.

Все типы IP-адресов поддерживают rDNS? Безусловно, и IPv4, и IPv6 поддерживают поиск по rDNS.В случае адресов на основе IPv4 поиск использует специальный домен in-addr.arpa, а для поиска IPv6 rDNS используется специальный домен ip6.arpa.

Нужен ли мне rDNS? Текущее использование обратного DNS

Насколько тогда важен rDNS? Может ли мой онлайн-бизнес жить без этого?

Ответ - да… и нет. В то же время.

Если у вас нет настройки rDNS для вашей ИТ-инфраструктуры, он все равно будет работать. Это не строгое требование. Однако некоторые вещи могут работать не так, как ожидалось, или могут вызвать трудности.Продолжай читать.

Когда полезен rDNS?

  • Если вы хотите предотвратить проблемы с электронной почтой. Если у вас есть собственный почтовый сервер, rDNS станет очень полезным для исходящих писем. Запись rDNS позволяет отследить источник электронной почты, повысить надежность почтового сервера и стать надежным источником для многих популярных поставщиков услуг электронной почты, таких как Gmail, Yahoo, Hotmail и других. Некоторые серверы входящей электронной почты даже не позволяют вашей электронной почте приходить в их почтовые ящики, если у вас нет настройки записи rDNS.Так что, если вы используете свой собственный почтовый сервер, вы должны помнить об этом.
  • Когда вы проводите расследование киберпреступности. Еще одно популярное использование обратных DNS-записей - выявление потенциальных угроз и массовое сканирование в Интернете. Используя как конечные точки API безопасности, так и веб-продукты, такие как SurfaceBrowser, вы или ваша команда можете легко идентифицировать авторов и сети, стоящие за массовым сканированием, распространением вредоносных программ или другими типами вредоносных действий - так же, как Трой Мурш показал в нашем сообщении блога обратные записи DNS для идентификации массовых сканеров.

Как я могу выполнить обратный поиск в DNS?

Выполнение обратного поиска в DNS не является ракетной наукой, но существует множество методов и инструментов поиска rDNS. используются для выполнения противоположной обычной проверки DNS: разрешения заданного IP-адреса на хост.

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

Копать

Мощная команда dig приходит на помощь, когда нам нужно выполнить обратный поиск в DNS.Используя параметр -x, вы можете выполнить простой обратный поиск для сопоставления адреса с именами за считанные секунды.

Этот параметр dig автоматически выполняет поиск традиционного имени IP-адреса, такого как 94.2.0.192.in-addr.arpa, и устанавливает тип и класс запроса на PTR и IN соответственно для адресов IPv6. Поиск rDNS выполняется с использованием формата полубайтов в домене IP6.ARPA.

Пример вывода:

  [исследование @ securitytrails ~] $ dig -x 1.1.1.1
; << >> Рис.9.11.10-RedHat-9.11.10-1.fc30 << >> -x 1. 1.1.1
;; глобальные параметры: + cmd
;; Получил ответ:
;; - >> HEADER << - код операции: QUERY, статус: NOERROR, id: 56773
;; флаги: qr rd ra; ЗАПРОС: 1, ОТВЕТ: 1, АВТОРИТЕТ: 2, ДОПОЛНИТЕЛЬНО: 7
;; ОПТИЧЕСКАЯ ПСЕВДОЗЕКЦИЯ:
; EDNS: версия: 0, флаги :; UDP: 512
;; РАЗДЕЛ ВОПРОСА:
; 1.1.1.1.in-addr.arpa. В PTR
;; РАЗДЕЛ ОТВЕТА:
1.1.1.1.in-addr.arpa. 1096 В PTR one.one.one.one.
;; РАЗДЕЛ ВЛАСТИ:
1.1.1.in-addr.arpa. 69422 IN NS ns3.cloudflare.com.
1.1.1.in-addr.арпа. 69422 IN NS ns7.cloudflare.com.
;; ДОПОЛНИТЕЛЬНЫЙ РАЗДЕЛ:
ns3.cloudflare.com. 86027 IN A 162.159.7.226
ns3.cloudflare.com. 86027 IN A 162.159.0.33
ns3.cloudflare.com. 86027 В AAAA 2400: cb00: 2049: 1 :: a29f: 21
ns3.cloudflare.com. 86027 В AAAA 2400: cb00: 2049: 1 :: a29f: 7e2
ns7.cloudflare.com. 203 IN A 162.159.6.6
ns7.cloudflare.com. 203 IN A 162.159.4.8
;; Время запроса: 13 мсек.
;; СЕРВЕР: 192.168.1.1 # 53 (192.168.1.1)
;; КОГДА: среда, 18 сентября, 11:20:01 -03 2019
;; РАЗМЕР MSG rcvd: 248
[исследование @ securitytrails ~]  

Интересная часть:

  1. 1.1.1.in-addr.arpa. 1096 В PTR one.one.one.one.  

Для более четкого результата можно выполнить вывод с помощью grep.

Хост

Команда host, вероятно, является самой популярной командой для выполнения быстрого разрешения rDNS с терминала. Синтаксис довольно прост:

  хост XX.XX.XX.XX  

Где XX.XX.XX.XX - настоящий IP-адрес. Давайте посмотрим на несколько примеров.

Cloudflare идет первым с запросом обратного разрешения DNS для 1.1.1.1:

  [исследование @ securitytrails ~] $ host 1.1.1.1
1.1.1.1.in-addr.arpa указатель доменного имени 1.1.1.1.in-addr.arpa.
[исследование @ securitytrails ~] $  

То же самое относится к любому другому IP-адресу, например DNS-серверу Google:

  [исследование @ securitytrails ~] $ host 8.8.8.8
8.8.8.8.in-addr.arpa указатель доменного имени dns.google.  

Или наш собственный IP-адрес securitytrails.com:

  [исследование @ securitytrails ~] $ host 151. 139.243,5
Хост 5.243.139.151.in-addr.arpa. не найдено: 3 (NXDOMAIN)
[исследование @ securitytrails ~]  

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

Набор инструментов G-Suite Dig

Некоторое время назад Google выпустил очень полезный ресурс под названием G-Suite dig, онлайн-утилиту, которая позволяет выполнять любой тип DNS-запросов с помощью простого, но сложного веб-интерфейса.

В этом случае выберите запись «PTR», введите свой IP-адрес и получите полный результат rDNS за секунды.

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

Конечная точка API обратного DNS

Использование нашего мощного API - еще один отличный источник для запроса нашей пассивной базы данных DNS для любых записей PTR компании.

Конечная точка «/ v1 / ips / list» позволяет запрашивать домен вершины (в данном случае cloudflare.com), поэтому вы можете легко обнаружить все известные IP-адреса, связанные с Cloudflare.com доменное имя.

Давайте воспользуемся быстрым скриптом Python, чтобы увидеть, как это выглядит:

  запросов на импорт
url = "https://api.securitytrails.com/v1/ips/list"
querystring = {"apikey": "your_api_key_here", "page": "1"}
payload = "{\" запрос \ ": \" ptr_part = 'cloudflare.com' \ "}"
response = requests.request ("POST", url, data = payload, params = querystring)
печать (response.text)  

Пример вывода:

Помимо записей PTR, вы также найдете открытые порты для каждого хоста, возвращенные нашей службой API.

Благодаря нашему API, полностью основанному на HTTP, вы также можете выполнить простой запрос CURL из командной строки или использовать любые другие популярные языки, включая Node.js, JavaScript, Ruby, Go и PHP.

SurfaceBrowser Massive rDNS Исследование

Когда мы говорим, что SurfaceBrower - идеальный универсальный инструмент для исследования поверхности атаки, мы действительно имеем в виду именно это. Помимо всех данных о зоне DNS, доменных именах, SSL и открытых портах, SurfaceBrowser может использоваться как мощный инструмент обратного поиска DNS.

Чтобы изучить данные rDNS от любой компании, просто запустите SurfaceBrowser из консоли своей учетной записи по адресу: https://securitytrails.com/app/sb/

Выберите любое доменное имя, которое вы хотите изучить, затем нажмите на опцию «Reverse DNS», как показано ниже:

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

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

В данном случае при изучении доменного имени fbi.gov было обнаружено 289 записей. Каждый из них можно просмотреть в области результатов, что позволяет исследовать по записи PTR, открытым портам и количеству связанных IP-адресов. Взгляните:

Если вам нужно найти связанные IP-адреса, указывающие на любую запись PTR, просто щелкните число + для немедленных результатов:

Второй экран данных PTR показывает общее количество IP-адресов, а также их размещение и текущие открытые порты, найденные для каждого из них.

fbi.gov - это «маленькая» организация, когда дело касается записей PTR, хотя мы нашли много полезной информации. Но вот что происходит, когда вы изучаете такую ​​крупную онлайн-компанию, как Google:

Для cache.google.com мы обнаружили около 94 тысяч IP-адресов, связанных с этой записью PTR. Представьте себе выполнение этого поиска с использованием традиционных инструментов обратного DNS. Это может занять у вас вечность!

Заключительные мысли

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

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


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

ЭСТЕБАН БОРДЖ

Эстебан - опытный исследователь и специалист по кибербезопасности с более чем 15-летним опытом. С момента присоединения к SecurityTrails в 2017 году он был нашим специалистом по технической безопасности серверов и информации об источниках.

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

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