Настройки dns – Яндекс.DNS

26.12.2019 alexxlab

Содержание

Как изменить настройки DNS на ПК с Windows 10

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

Что такое DNS

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

Все компьютеры, подключенные к интернету, имеют IP-адреса, которые позволяют им общаться друг с другом. Однако, мы не компьютеры, и IP-адрес (вида 193.109.246.68) трудно запомнить. DNS обеспечивает способ для перевода дружественных доменных имен (windows-school.ru) в IP-адрес, что могут понять компьютеры.

Хотя большинство из нас попадают на наши любимые веб-сайты, просто набирая URL-адреса, например https://windows-school.ru, ваш браузер должен знать IP-адрес сайта, к которому вы пытаетесь получить доступ. Для этого при вводе нового доменного имени ваш браузер отправляет запрос на DNS-сервер, чтобы преобразовать доменное имя в IP-адрес, а когда совпадение найдено, оно возвращается в браузер и страница загружается.

Как правило, этот процесс довольно быстрый, измеряется в миллисекундах, но если DNS-серверы, предоставляемые вашим интернет-провайдером, ненадежны или по какой-либо причине вам нужно использовать пользовательские настройки, Windows 10 позволяет вам быстро изменять настройки DNS на вашем компьютере

В этом уроке по Windows 10 мы расскажем, как изменить настройки DNS на вашем компьютере с помощью панели управления и командной строки.

Как изменить настройки DNS в панели управления

Чтобы изменить настройки DNS на устройстве Windows 10 с помощью панели управления, выполните следующие действия:

Откройте Панель управления.
Нажмите на Сеть и Интернет → Центр управления сетями и общим доступом.
На левой панели нажмите Изменить настройки адаптера.
Щелкните правой кнопкой мыши сетевой интерфейс, подключенный к Интернету, и выберите Свойства.
В открывшемся окне свойств выберите IP версии 4 (TCP / IPv4) из списка.
Нажмите кнопку Свойства.
Выберите параметр Использовать следующие адреса DNS-серверов.
Введите предпочитаемые и альтернативные адреса DNS-серверов. Здесь вы можете ввести любые DNS-серверы, в том числе и бесплатные, такие как Яндекс.DNS, Google Public DNS или OpenDNS.
- Яндекс.DNS:
  - Базовый: 77.88.8.8 и 77.88.8.1 – быстрый и надежный DNS
  - Безопасный: 77.88.8.88 и 77.88.8.2 – без мошеннических сайтов и вирусов
  - Семейный: 77.88.8.7 и 77.88.8.3 – без сайтов для взрослых
- Публичные DNS-адреса Google: 8.8.8.8 и 8.8.4.4
- Адреса OpenDNS: 208.67.222.222 и 208.67.220.220
Нажмите ОК. и Закрыть, чтобы применить новые настройки DNS к адаптеру.

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

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

У вас даже есть кнопки сбоку, чтобы установить их приоритет.

Как изменить настройки DNS в командной строке

В зависимости от того, как вы используете ОС, иногда у вас не будет доступа к панели управления, но вы все равно можете изменить настройки DNS, запустив несколько команд, как показано здесь:

Откройте командную строку от имени администратора.
Введите следующую команду, чтобы отобразить имена ваших сетевых адаптеров, и нажмите Enter:
```
wmic nic get NetConnectionID
```
Введите следующую команду, чтобы изменить настройки сети, и нажмите Enter:
```
netsh
```
Введите следующую команду для установки основного IP-адреса DNS и нажмите Enter:
```
interface ip set dns name="ADAPTER-NAME" source="static" address="X.X.X.X"
```
В этой команде не забудьте изменить ADAPTER-NAME на имя сетевого адаптера, которое вы получили на шаге 2, и измените XXXX на адрес DNS-сервера, который вы хотите использовать.
Введите следующую команду, чтобы добавить альтернативный IP-адрес DNS, и нажмите Enter:
```
interface ip add dns name="ADAPTER-NAME" addr="X.X.X.X" index=2
```
В этой команде не забудьте изменить ADAPTER-NAME на имя сетевого адаптера, которое вы получили на шаге 2, и измените XXXX на адрес дополнительного DNS-сервера, который вы хотите использовать.

После выполнения команд ваше устройство сразу же начнет использовать новые настройки DNS.

Если вам нужно настроить более одного альтернативного адреса, вы можете повторить

шаг 5, но увеличить номер индекса на 1.

Вот пример использования команды для добавления третьего IP-адреса DNS в Windows 10:

interface ip add dns name="Ethernet 2" addr="8.8.8.8" index=3

Хотя Windows 10 предоставляет вам несколько способов изменить настройки DNS на вашем устройстве, есть много других подходов для достижения той же цели, таких как использование стороннего приложения или настройка маршрутизатора.

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

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

windows-school.ru

Яндекс.DNS

Настройка в маршрутизаторах D-Link

Разработчики российского R&D-подразделения компании D-Link сделали использование сервиса контентной фильтрации Яндекс.DNS максимально простым и доступным пользователю любого уровня. Адреса DNS-серверов Яндекса уже заданы в программном обеспечении маршрутизаторов, и пользователю не нужно выполнять сложные манипуляции по настройке DNS. Вы сможете задать единый режим фильтрации сразу для всех клиентов домашней сети или назначить персональный режим каждому устройству, например, выбрать детский режим для ноутбука, с которым работает ребенок. Изменить настройки Яндекс.DNS может только пользователь, у которого есть пароль для доступа к маршрутизатору.

В настоящее время поддержка Яндекс.DNS реализована в следующих моделях маршрутизаторов D-Link:

DIR-320/A/D1A: начиная с версии ПО 2.5.15,
DIR-620/A/E1A: начиная с версии ПО 2.5.11,
DIR-620/D/F1A: начиная с версии ПО 2.5.15,
DIR-815/A/C1A: начиная с версии ПО 2.5.16,

DIR-825/A/D1A: начиная с версии ПО 2.5.31,
DIR-825/AC/E1A: начиная с версии ПО 2.5.23,
DSL-2640U/RA/U1A: начиная с версии ПО 2.5.2,
DSL-2650U/RA/U1A: начиная с версии ПО 2.5.1,
DSL-2740U/RA/U1A: начиная с версии ПО 2.5.1,
DSL-2750U/RA/U2A: начиная с версии ПО 2.5.1.

Полный список устройств с поддержкой Яндекс.DNS доступен на официальном сайте компании D-Link.

Как настроить Яндекс.DNS?

Обратитесь к Web-интерфейсу маршрутизатора:
— если у вас маршрутизатор линейки DIR, в адресной строке введите 192.168.0.1 ( IP-адрес, заданный по умолчанию) или http://dlink-router и нажмите клавишу Enter.
— если у вас маршрутизатор линейки DSL, в адресной строке введите адрес

192.168.1.1 и нажмите клавишу Enter.
Введите имя пользователя и пароль.
Убедитесь, что у вас установлена последняя версия программного обеспечения (ПО). При необходимости обновите прошивку. Узнать подробнее про обновление ПО можно на официальном сайте D-Link здесь и здесь (в зависимости от интерфейса) или посмотреть видеоинструкцию на канале D-Link на YouTube.
Чтобы настроить сервис Яндекс.DNS, перейдите к разделу Яндекс.DNS, используя меню в левой части страницы.
На странице Яндекс.DNS / Настройка безопасности / Настройки установите флажок Включено. В разделе Выбор режима по умолчанию
вы можете настроить режим фильтрации сразу для всех пользователей Вашей сети.
Выберите Безопасный режим, чтобы заблокировать доступ к вредоносным и мошенническим сайтам.
Детский режим позволит заблокировать доступ не только к вредоносным сайтам, но и к ресурсам, нежелательным для просмотра детьми.
Режим без защиты обеспечит работу DNS-сервера, но не ограничит доступ к опасным сайтам.
Выбранный режим фильтрации также будет действовать для всех вновь подключённых к сети маршрутизатора устройств.
При необходимости Вы можете задать персональный режим фильтрации для любого устройства домашней сети, например, выбрать детский режим для ноутбука ребенка. Для этого перейдите на страницу Яндекс.DNS / Настройки безопасности / Устройства.
На открывшейся странице в разделе Клиенты вне правил отображаются устройства, режим фильтрации для которых определен на странице Яндекс.DNS / Настройка безопасности / Настройки. Название режима отображается в разделе Режим по умолчанию.
Чтобы создать новое правило фильтрации, нажмите кнопку Добавить в разделе Правила и введите MAC- /IP-адрес устройства, которому необходимо назначить персональный режим. Чтобы заполнить поля MAC-адрес и IP-адрес автоматически, выберите необходимое устройство в раскрывающемся списке Известные IP/MAC-адреса.
Для удобной идентификации устройства задайте название правила в поле Назначенное имя.
Выберите режим работы сервиса Яндекс.DNS для данного правила.
После задания необходимых параметров нажмите кнопку Применить.
Сохраните настройки, нажав на уведомление Конфигурация устройства была изменена в правом верхнем углу страницы.

Более подробные инструкции по настройке Яндекс.DNS Вы сможете найти на канале D-Link на YouTube.

dns.yandex.ru

Поднимаем свой DNS сервер на VDS / Sandbox / Habr

В данной статье я опишу, как поднять свой DNS сервер на арендованном VDS/VPS с помощью пакета BIND.

Причины, по которым нам нужен свой DNS сервер, могут быть самые разнообразные, но в большинстве случаев, это просто облегчает работу со множеством доменов. И согласитесь, приятно видеть в сервисе Whois свои нейм сервера.

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

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

Сервер для DNS → 91.197.130.49 (ns1.mydomain.com)
→ 91.197.130.63 (ns2.mydomain.com)
Зона —> mydomain.com
На виртуальном сервере установлена ОС — CentOS5.5

Установка BIND

Прежде всего, нам необходимо установить на сервер сам пакет BIND, а для этого нужно подсоединится к нашему VDS.

Тут есть два варианта в зависимости от того, какой ОС вы пользуетесь на своем персональном компьютере.

В linux системах все довольно просто. Нужно перейти в основной панели на вкладку Places — Connect to Server.., в Service type выбрать SSH соединение, ввести адрес вашего сервера, ваш логин, нажать кнопку «connect». В появившемся окошке ввести свой пароль и… вы уже в терминале операционной системы своего VDS.

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

Итак, мы попали в терминал VDS. Чтобы установить последнюю версию пакета BIND, нужно ввести команду:

yum install bind

Жмем «Enter» и ждем успешного завершения установки.

Создание данных зоны

Следующим шагом на нашем пути будет создание данных для зоны.

Для корректной настройки DNS под BIND данные разбиваются на несколько файлов. Один из них содержит отображения имен узлов в адреса, остальные — отображения адресов обратно в имена. Поиск адреса для имени принято называть прямым отображением, а поиск имени по адресу — обратным отображением.

Мы будем использовать следующие файлы:
1.Файл, содержащий данные преобразования имен хостов в адреса. Его имя для нашей зоны будет иметь вид db.mydomain.com.
2.Файл, содержащий данные преобразования адресов в имена хостов. Его название имеет вид db.addr, где addr — это внешний IP адрес нашего будущего DNS сервера, без последних цифр или маски сети. Для данного примера файл будет назваться
db.91.197.130.
3.Файлы зоны db.cache и db 127.0.0. Эти файлы необходимы для корректной работы DNS.
4.Файл настройки (конфигурационный файл), необходимый для связи всех файлов данных зоны. В версиях BIND 8 и 9 файл обычно называется /etc/named.conf.

Приступим непосредственно к созданию файлов.

Начнем с конфигурационного файла. Чтобы создать его, вводим в терминале VDS команду

vi /etc/named.conf

Файл настройки содержит строки, которые определяют каталог с файлами данных зоны.
Обычно файлы настройки содержат строку, определяющую каталог, в котором расположены файлы данных зоны. Эти строки будут иметь вид:

options { directory "/var/named/"; dump-file "/var/run/named_dump.bd"; statistics-file "/var/run/named.stats"; };

Далее идет описание каждого файла данных зоны, которые необходимо использовать. Строка начинается со слова zone, за ним следует доменное имя и имя класса (in — класс интернета.) В BIND 8 и 9 класс интернета устанавливается по умолчанию, и поэтому нет необходимости указывать класс для него. Тип master указывает на то, что наш DNS сервер будет первичным. В последнем поле содержится имя файла данных зоны.

zone "mydomain.com" IN { type master; file "db.mydomain.com"; };

Данная строка файла настройки предписывает чтение файла корневых указателей:

zone "." { type hint; file "db.cache"; };

Этот файл не содержит данные кэша, а только указатели (hints) корневых DNS-серверов, о чем будет сказано ниже.

В целом конфигурационный файл будет иметь следующий вид:

options { directory "/var/named/"; dump-file "/var/run/named_dump.bd"; statistics-file "/var/run/named.stats"; };

zone «mydomain.com» IN {
type master;
file «db.mydomain.com»;
};

zone «130.197.91.IN-ADDR.ARPA.» IN {
type master;
file «db.91.197.130.»;
};

zone «0.0.127.IN-ADDR.ARPA.» IN {
type master;
file «db.127.0.0»;
};

zone «.» {
type hint;
file «db.cache»;
};

Теперь рассмотрим, как создать файлы данных для mydomain.com., 91.197.130.0, 127.0.0 и cache. Вообще файлы db.127.0.0 и db.cache создаются автоматически, так что описывать их нет необходимости.

Вводим в терминале

vi /var/named/db.mydomain.com.

Теперь приступим к редактированию файла.

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

Для того, чтобы указать стандартное значение, нужно воспользоваться директивой $TTL. Для данного примера возьмем за стандартное значение 3 часа (3h). Первая строчка будет выглядеть так:

$TTL 3H

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

SOA-запись для данного примера будет иметь вид:

mydomain.com. IN SOA ns1.mydomain.com. admin.mydomain.com. ( 1 ; Порядковый номер 3h ; Обновление через 3 часа 1h ; Повторение попытки через 1 час 1w ; Устаревание через 1 неделю 1h ) ; Отрицательное TTL в 1 час

На первом месте указываем доменную зону нашего будущего NS, обязательно в конце домена ставим точку. Зачем это делается, я расскажу чуть позже. Далее следует класс сети, об этом уже было написано выше, его указывать не обязательно. SOA указывает на тип записи. ns1.mydomain.com. — это адрес первичного сервера DNS зоны mydomain.com. А admin.mydomain.com. — почтовый адрес владельца доменной зоны. Скобки позволяют указать несколько строк, относящихся к записи. Следующие в них значения по сути не нужны в данном примере, они используются в основном вторичными серверами, но все же я вкратце опишу, что они значат.

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

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

Обновление (refresh)
Интервал обновления инструктирует вторичный DNS-сервер, с какой частотой следует проверять актуальность информации для зоны. Установленные в данном примере 3 часа будут создавать весьма большую нагрузку на первичный сервер, так что при редком обновлении файлов зоны вторичного сервера стоит установить интервал хотя бы в 24 часа.

Повторение попытки (retry)
Если вторичный сервер не может подключиться к первичному (который вполне возможно уже не работает), он повторяет попытки через равные интервалы времени, указанные данным значением.

Устаревание (expire)
Если вторичный DNS сервер не может соединиться с первичным в течении указанного периода, данные на нем устаревают. Устаревшие данные зоны говорят о том, что информация уже не актуальна и не стоит ее больше использовать. Имеет смысл устанавливать значения устаревания намного большие, чем интервал обновления (от недели до месяца), иначе они будут устаревать еще до того, как успеют обновиться.
Отрицательное TTL

TTL — это время жизни (time to live). Это значение относится ко всем отрицательным ответам DNS-серверов, авторитативных для данной зоны.

Документом RFC 1537 рекомендуются следующие значения для DNS серверов высшего уровня:
Обновление 24 hours
Повторение попытки 2 hours
Устаревание 30 days
Стандартное TTL 4 days

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

mydomain.com. IN NS ns1.mydomain.com. mydomain.com. IN NS ns2.mydomain.com.

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

ns1.mydomain.com. IN A 91.197.130.49 ns2.mydomain.com. IN A 91.197.130.63

Файл db.mydomain.com. готов, перейдем к создания следующего файла. Вводим в терминале:

vi /var/named/chroot/var/named/db.91.197.130.

И редактируем данные как в предыдущем файле.
Сначала прописываем TTL и SOA запись.

$TTL 3H 130.197.91 IN SOA ns1.mydomain.com admin.mydomain.com ( 1 3H 1H 1W 1H )

Далее NS записи:

пробел IN NS ns1.mydomain.com. пробел IN NS ns2.mydomain.com.

А теперь указываем PTR записи — они служат для отображения имен, соответствующих IP адресам. Для данного примера записи будут выглядеть следующим образом:

49.130.197.91 PTR ns1.mydomain.com. 63.130.197.91 PTR ns2.mydomain.com.

Вот наш файл и готов.

Упрощаем код

Теперь самое время рассказать о сокращениях записей, которые помогут более быстро редактировать файлы данных зоны.

Вернемся к нашему конфигурационному файлу. Поле директивы zone определяет доменное имя. Это имя является суффиксом по умолчанию (origin) для всей информации в файлах данных зоны. Суффикс по умолчанию добавляется в конец всех имен, которые не заканчиваются точкой (Помните я говорил о том, что не следует забывать ставить точку в конце имен). Так как каждый файл отвечает за свою зону, то и суффиксы по умолчанию в каждом файле свои.

Исходя из данного принципа сокращений, можно упростить код следующим образом:

Вместо строки: «ns1.mydomain.com. IN A 91.197.130.49» можно указать вот такую строку:

ns1 IN A 91.197.130.49

Запись «49.130.197.91 PTR ns1.mydomain.com.» можно записать так:

49 PTR ns1.mydomain.com.

Если доменное имя совпадает с суффиксом по умолчанию, его можно указывать в виде «@». Обычно такая запись используется в SOA-записях. Например:

@ IN SOA ns1.mydomain.com. admin.mydomain.com. ( 1 3h 1h 1w 1h )

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

130.197.91 IN NS ns1.mydomain.com. «пробел» IN NS ns2.mydomain.com.

Таким сокращением можно пользоваться даже при создании различных типов записей для одного имени.

Итог

Посмотрим теперь, как будут выглядеть наши файлы данных зоны с применением вышеописанных правил сокращения.
Файл db.mydomain.com.

$TTL 3H @ IN SOA ns1.mydomain.com. admin.mydomain.com. ( 1 3h 1h 1w 1h )

«пробел» IN NS ns1.mydomain.com.
«пробел» IN NS ns2.mydomain.com.

ns1 IN A 91.197.130.49
ns2 IN A 91.197.130.63

Файл db.91.197.130.

$TTL 3H @ IN SOA ns1.mydomain.com admin.mydomain.com ( 1 3H 1H 1W 1H )

«пробел» IN NS ns1.mydomain.com.
«пробел» IN NS ns2.mydomain.com.

49 PTR ns1.mydomain.com.
63 PTR ns2.mydomain.com.

Поздравляю! Мы закончили настройку нашего DNS сервера с двумя записями NS.

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

/etc/init.d/nammed start /etc/init.d/nammed stop /etc/init.d/nammed restart

Для тестирования серверов существует очень полезная программка — nslookup.

habr.com

Как спрятать DNS-запросы от любопытных глаз провайдера / Habr

Настройка 1.1.1.1 от Cloudflare и других DNS-сервисов по-прежнему требует навыков работы в командной строке

Шифрование трафика между вашим устройством и DNS-сервисом помешает посторонним лицам отслеживать трафик или подменить адрес

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

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

«Открытые» DNS-сервисы позволяют обходить сервисы провайдеров ради конфиденциальности и безопасности, а кое в каких странах — уклоняться от фильтрации контента, слежки и цензуры. 1 апреля (не шутка) компания Cloudflare запустила свой новый, бесплатный и высокопроизводительный DNS-сервис, предназначенный для повышения конфиденциальности пользователей в интернете. Он также обещает полностью скрыть DNS-трафик от посторонних глаз, используя шифрование.

Названный по своему IP-адресу, сервис 1.1.1.1 — это результат партнёрства с исследовательской группой APNIC, Азиатско-Тихоокеанским сетевым информационным центром, одним из пяти региональных интернет-регистраторов. Хотя он также доступен как «открытый» обычный DNS-резолвер (и очень быстрый), но Cloudflare ещё поддерживает два протокола шифрования DNS.

Хотя и разработанный с некоторыми уникальными «плюшками» от Cloudflare, но 1.1.1.1 — никак не первый DNS-сервис с шифрованием. Успешно работают Quad9, OpenDNS от Cisco, сервис 8.8.8.8 от Google и множество более мелких сервисов с поддержкой различных схем полного шифрования DNS-запросов. Но шифрование не обязательно означает, что ваш трафик невидим: некоторые службы DNS с шифрованием всё равно записывают ваши запросы в лог для различных целей.

Cloudflare пообещал не журналировать DNS-трафик и нанял стороннюю фирму для аудита. Джефф Хастон из APNIC сообщил, что APNIC собирается использовать данные в исследовательских целях: диапазоны 1.0.0.0/24 и 1.1.1.0/24 изначально были сконфигурированы как адреса для «чёрного» трафика. Но APNIC не получит доступ к зашифрованному трафику DNS.

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

Но учитывая важность вопроса — в последнее время во всех новостях говорят о превращении пользовательских данных в продукт — я решил посмотреть, как работает DNS-шифрование у Cloudflare. В итоге моя внутренняя лабораторная крыса победила — и я обнаружил, что тестирую и разбираю клиенты для нескольких провайдеров DNS через три протокола DNS-шифрования: DNSCrypt, DNS по TLS и DNS по HTTPS. Все они работоспособны, но предупреждаю: хотя процедура становится проще, но вряд ли вы сможете объяснить шифрование DNS родителям по телефону (если только они не опытные пользователи командной строки Linux).

Как работает DNS

Есть много причин для лучшей защиты DNS-трафика. Хотя веб-трафик и другие коммуникации могут быть защищены криптографическими протоколами, такими как Transport Layer Security (TLS), но почти весь трафик DNS передаётся незашифрованным. Это означает, что ваш провайдер (или кто-то другой между вами и интернетом) может регистрировать посещаемые сайты даже при работе через сторонний DNS — и использовать эти данных в своих интересах, включая фильтрацию контента и сбор данных в рекламных целях.

Как выглядит типичный обмен данными между устройством и DNS-резолвером

«У нас есть проблема “последней мили” в DNS, — говорил Крикет Лю, главный архитектор DNS в компании Infoblox, которая занимается информационной безопасностью. — Большинство наших механизмов безопасности решают вопросы коммуникаций между серверами. Но есть проблема с суррогатами резолверов на различных операционных системах. В реальности мы не можем их защитить». Проблема особенно заметна в странах, где власти более враждебно относятся к интернету.

В некоторой степени помогает использование DNS, который не ведёт логи. Но это всё равно не мешает злоумышленнику фильтровать запросы по контенту или перехватывать адреса методом пакетного перехвата или глубокой инспекции пакетов. Кроме пассивной прослушки есть угроза более активных атак на ваш DNS-трафик — спуфинг DNS-сервера со стороны провайдера или спецслужб с перенаправлением на собственный сервер для отслеживания или блокировки трафика. Что-то подобное (хотя, по-видимому, не злонамеренно), похоже, происходит со случайным перенаправлением трафика на адрес 1.1.1.1 из сети AT&T, судя по сообщениям на форумах DSLReports.

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

Вот где вступают в игру протоколы шифрования DNS: это DNSCrypt (среди прочих, его поддерживает OpenDNS от Cisco), DNS по TLS (поддерживается Сloudflare, Google, Quad9, OpenDNS) и DNS по HTTPS (поддерживается Сloudflare, Google и сервисом блокировки «взрослого» контента CleanBrowsing). Шифрование гарантирует, что трафик не просканируют и не изменят, и что запросы не получит и не обработает поддельный DNS-сервер. Это защищает от атак MiTM и шпионажа. DNS-прокси с одной из этих служб (непосредственно на устройстве или на «сервере» в локальной сети) поможет предотвратить DNS-утечки через VPN, поскольку прокси-сервер всегда будет самым быстрым DNS-сервером среди всех доступных.

Однако эта опция защиты недоступна массовому пользователю. Ни один из этих протоколов нативно не поддерживается ни одним DNS-резолвером, который идёт в комплекте с ОС. Все они требуют установки (и, вероятно, компиляции) клиентского приложения, которое действует как локальный «сервер» DNS, ретранслируя запросы, сделанные браузерами и другими приложениями вверх по течению к безопасному провайдеру DNS по вашему выбору. И хотя две из трёх данных технологий предлагаются на роль стандартов, ни один из проверенных нами вариантов пока не представлен в окончательном виде.

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

Сообщество DNSCrypt пыталось сделать доступный инструмент для тех, кто не обладает навыками работы в командной строке, выпустив программы DNSCloak (слева) под iOS и Simple DNSCrypt (справа) под Windows

Для полноты картины в исторической перспективе начнём обзор с самой первой технологии шифрования DNS — DNSCrypt. Впервые представленный в 2008 году на BSD Unix, инструмент DNSCrypt изначально предназначался для защиты не от прослушки, а от DNS-спуфинга. Тем не менее, его можно использовать как часть системы обеспечения конфиденциальности — особенно в сочетании с DNS-сервером без логов. Как отметил разработчик DNSCrypt Фрэнк Денис, гораздо больше серверов поддерживают DNSCrypt, чем любой другой вид шифрования DNS.

«DNSCrypt — это немного больше, чем просто протокол, — говорит Фрэнк Денис. — Сейчас сообщество и активные проекты характеризуют его гораздо лучше, чем мой изначальный протокол, разработанный в выходные». Сообщество DNSCrypt создало простые в использовании клиенты, такие как Simple DNSCrypt для Windows и клиент для Apple iOS под названием DNS Cloak, что делает шифрование DNS доступнее для нетехнических людей. Другие активисты подняли независимую сеть приватных DNS-серверов на основе протокола, помогающего пользователям уклониться от использования корпоративных DNS-систем.

«DNSCrypt — это не подключение к серверам конкретной компании, — сказал Денис. — Мы призываем всех поднимать собственные сервера. Сделать это очень дёшево и легко. Теперь, когда у нас есть безопасные резолверы, я пытаюсь решить задачу фильтрации контента с учётом конфиденциальности».

Для тех, кто хочет запустить DNS-сервер с поддержкой DNSCrypt для всей своей сети, лучшим клиентом будет DNSCrypt Proxy 2. Старая версия DNSCrypt Proxy по-прежнему доступна как пакет для большинства основных дистрибутивов Linux, но лучше загрузить бинарник новой версии непосредственно с официального репозитория на GitHub. Есть версии для Windows, MacOS, BSD и Android.

Опыт сообщества DNSCrypt по защите конфиденциальности воплощён в DNSCrypt Proxy. Программа легко настраивается, поддерживает ограничения по времени доступа, шаблоны для доменов и чёрный список IP-адресов, журнал запросов и другие функции довольно мощного локального DNS-сервера. Но для начала работы достаточно самой базовой конфигурации. Есть пример файла конфигурации в формате TOML (Tom’s Obvious Minimal Language, созданный соучредителем GitHub Томом Престоном-Вернером). Можете просто переименовать его перед запуском DNSCrypt Proxy — и он станет рабочим файлом конфигурации.

По умолчанию прокси-сервер использует открытый DNS-резолвер Quad9 для поиска и получения с GitHub курируемого списка открытых DNS-сервисов. Затем подключается к серверу с самым быстрым откликом. При необходимости можно изменить конфигурацию и выбрать конкретный сервис. Информация о серверах в списке кодируется как «штамп сервера». Он содержит IP-адрес поставщика, открытый ключ, информацию, поддерживает ли сервер DNSSEC, хранит ли провайдер логи и блокирует ли какие-нибудь домены. (Если не хотите зависеть от удалённого файла при установке, то можно запустить «калькулятор штампов» на JavaScript — и сгенерировать собственный локальный статичный список серверов в этом формате).

Для своего тестирования DNSCrypt я использовал OpenDNS от Cisco в качестве удалённого DNS-сервиса. При первых запросах производительность DNSCrypt оказалась немного хуже, чем у обычного DNS, но затем DNSCrypt Proxy кэширует результаты. Самые медленные запросы обрабатывались в районе 200 мс, в то время как средние — примерно за 30 мс. (У вас результаты могут отличаться в зависимости от провайдера, рекурсии при поиске домена и других факторов). В целом, я не заметил замедления скорости при просмотре веб-страниц.

Основное преимущество DNSCrypt в том, что он похож на «обычный» DNS. Хорошо это или плохо, но он передаёт UDP-трафик по порту 443 — тот же порт используется для безопасных веб-соединений. Это даёт относительно быстрый резолвинг адресов и снижает вероятность блокировки на файрволе провайдера. Чтобы ещё больше снизить вероятность блокировки, можно изменить конфигурацию клиента и передавать запросы по TCP/IP (как показало тестирование, это минимально влияет на время отклика). Так шифрованный DNS-трафик для большинства сетевых фильтров похож на трафик HTTPS — по крайней мере, с виду.

Показан трафик DNSCrypt и локальный трафик DNSCrypt Proxy. Снифер Wireshark говорит, что это трафик HTTPS, потому что я форсировал использование TCP. Если пустить его по UDP, то Wireshark увидит трафик Chrome QUIC

С другой стороны, DNSCrypt для шифрования не полагается на доверенные центры сертификации — клиент должен доверять открытому ключу подписи, выданному провайдером. Этот ключ подписи используется для проверки сертификатов, которые извлекаются с помощью обычных (нешифрованных) DNS-запросов и используются для обмена ключами с использованием алгоритма обмена ключами X25519. В некоторых (более старых) реализациях DNSCrypt есть условие для сертификата на стороне клиента, который может использоваться в качестве схемы управления доступом. Это позволяет им журналировать ваш трафик независимо от того, с какой IP-адреса вы пришли, и связывать его с вашим аккаунтом. Такая схема не используется в DNSCrypt 2.

С точки зрения разработчика немного сложно работать с DNSCrypt. «DNSCrypt не особенно хорошо документирован, и не так много его реализаций», — говорит Крикет Лю из Infoblox. На самом деле мы смогли найти только единственный клиент в активной разработке — это DNSCrypt Proxy, а OpenDNS прекратил поддерживать его разработку.

Интересный выбор криптографии в DNSCrypt может напугать некоторых разработчиков. Протокол использует Curve25519 (RFC 8032), X25519 (RFC 8031) и Chacha20Poly1305 (RFC 7539). Одна реализация алгоритма X24419 в криптографических библиотеках Pyca Python помечена как «криптографически опасная», потому что с ней очень легко ошибиться в настройках. Но основной используемый криптографический алгоритм Curve25519, является «одной из самых простых эллиптических кривых для безопасного использования», — сказал Денис.

Разработчик говорит, что DNSCrypt никогда не считался стандартом IETF, потому что был создан добровольцами без корпоративной «крыши». Представление его в качестве стандарта «потребовало бы времени, а также защиты на заседаниях IETF», — сказал он. «Я не могу себе этого позволить, как и другие разработчики, которые работают над ним в свободное время. Практически все ратифицированные спецификации, связанные с DNS, фактически написаны людьми из одних и тех же нескольких компаний, из года в год. Если ваш бизнес не связан с DNS, то действительно тяжело получить право голоса».

Хотя несколько DNS-сервисов используют DNSCrypt (например, CleanBrowsing для блокировки «взрослого» контента и Cisco OpenDNS для блокировки вредоносных доменов), новые ориентированные на приватность DNS-провайдеры (в том числе Google, Cloudflare и Quad9) отказались от DNSCrypt и выбрали одну из других, одобренных группой IETF технологий: DNS по TLS и DNS по HTTPS. Сейчас DNSCrypt Proxy поддерживает DNS по HTTPS и указывает Cloudflare, Google и Quad9 в настройках по умолчанию.

TLS стал приоритетом для CloudFlare, когда понадобилось усилить шифрование веб-трафика для защиты от слежки

У DNS по TLS (Transport Layer Security) несколько преимуществ перед DNSCrypt. Во-первых, это предлагаемый стандарт IETF. Также он довольно просто работает по своей сути — принимает запросы стандартного формата DNS и инкапсулирует их в зашифрованный TCP-трафик. Кроме шифрования на основе TLS, это по существу то же самое, что и отправка DNS по TCP/IP вместо UDP.

Существует несколько рабочих клиентов для DNS по TLS. Самый лучший вариант, который я нашел, называется Stubby, он разработан в рамках проекта DNS Privacy Project. Stubby распространяется в составе пакета Linux, но есть также версия для MacOS (устанавливается с помощью Homebrew) и версия для Windows, хотя работа над последней ещё не завершена.

Хотя мне удалось стабильно запускать Stubby на Debian после сражения с некоторыми зависимостями, этот клиент регулярно падал в Windows 10 и имеет тенденцию зависать на MacOS. Если вы ищете хорошее руководство по установке Stubby на Linux, то лучшая найденная мной документация — это пост Фрэнка Сантосо на Reddit. Он также написал shell скрипт для установки на Raspberry Pi.

Положительный момент в том, что Stubby допускает конфигурации с использованием нескольких служб на основе DNS по TLS. Файл конфигурации на YAML позволяет настроить несколько служб IPv4 и IPv6 и включает в себя настройки для SURFNet, Quad9 и других сервисов. Однако реализация YAML, используемая Stubby, чувствительна к пробелам, поэтому будьте осторожны при добавлении новой службы (например, Cloudflare). Сначала я использовал табы — и всё поломал.

Клиенты DNS по TLS при подключении к серверу DNS осуществляют аутентификацию с помощью простой инфраструктуры открытых ключей (Simple Public Key Infrastructure, SPKI). SPKI использует локальный криптографический хэш сертификата провайдера, обычно на алгоритме SHA256. В Stubby этот хэш хранится как часть описания сервера в файле конфигурации YAML, как показано ниже:

upstream_recursive_servers:
#IPv4
#Cloudflare DNS over TLS server

- address_data: 1.1.1.1
  tls_auth_name: "cloudflare-dns.com"
  tls_pubkey_pinset:
  - digest: "sha256"
    value: yioEpqeR4WtDwE9YxNVnCEkTxIjx6EEIwFSQW+lJsbc=
- address_data: 1.0.0.1
  tls_auth_name: "cloudflare-dns.com"
  tls_pubkey_pinset:
  - digest: "sha256"
    value: yioEpqeR4WtDwE9YxNVnCEkTxIjx6EEIwFSQW+lJsbc=

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

После успешного запуска Stubby я изменил сетевые настройки сети DNS, чтобы направлять запросы на 127.0.0.1 (localhost). Сниффер Wireshark хорошо показывает этот момент переключения, когда трафик DNS становится невидимым.

Переключаемся с обычного трафика DNS на шифрование TLS

Хотя DNS по TLS может работать как DNS по TCP, но шифрование TLS немного сказывается на производительности. Запросы dig к Cloudflare через Stubby у меня выполнялись в среднем около 50 миллисекунд (у вас результат может отличаться), в то время как простые DNS-запросы к Cloudflare получают ответ менее чем за 20 мс.

Частично замедление работы происходит на стороне сервера из-за лишнего использования TCP. Обычно DNS работает по быстрому протоколу UDP: отправил и забыл, в то время как сообщение TCP требует согласования соединения и проверки получения пакета. Основанная на UDP версия DNS по TLS под названием DNS over Datagram Transport Layer Security (DTLS) сейчас в экспериментальной разработке — она может увеличить производительность протокола.

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

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

Google и Cloudflare, похоже, одинаково видят будущее зашифрованного DNS

И Google, и Cloudflare, кажется, видят протокол DNS по HTTPS, также известный как DoH, как самый перспективный вариант для шифрования DNS. Опубликованный в виде черновика стандарта IETF, протокол DoH инкапсулирует DNS-запросы в пакеты HTTPS, превращения их в обычный зашифрованный веб-трафик.

Запросы отправляются как HTTP POST или GET с телом в формате сообщения DNS (датаграммы из обычных DNS-запросов) или как запрос HTTP GET в формате JSON (если вы не против небольшого оверхеда). И здесь нет никаких проблем с управлением сертификатами. Как и при обычном веб-трафике HTTPS, для подключения через DoH не требуется аутентификация, а сертификат проверяется центром сертификации.

Фиксация DNS-транзакции через DoH. Видно только HTTPS, TLS и ничего больше

HTTPS — довольно громоздкий протокол для запросов DNS, особенно в формате JSON, поэтому придётся смириться с некоторым снижением производительности. Необходимые ресурсы на стороне сервера почти наверняка заставят прослезиться администратора обычного DNS-сервера. Но простота работы с хорошо понятными веб-протоколами делает разработку как клиентского, так и серверного кода для DoH намного более доступной для разработчиков, собаку съевших на веб-приложениях (всего несколько недель назад инженеры Facebook выпустили концепт сервера и клиента DoH на Python).

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

Например, возьмём клиент туннелирования Argo от Cloudflare (aka cloudflared). Это многофункциональный инструмент туннелирования, предназначенный в первую очередь для установления безопасного канала для связи веб-серверов с CDN-сетью Cloudflare. DNS по HTTPS — просто ещё одна служба, которую теперь поддерживает CDN.

По умолчанию, если запустить Argo из командной строки (в Linux и MacOS для этого нужны привилегии суперпользователя, а на Windows нужно запускать клиента из PowerShell от имени администратора), то он направляет DNS-запросы на https://cloudflare-dns.com/dns-query. Если не настроен обычный DNS, то возможна небольшая проблемка, потому что данный адрес должен резолвиться в 1.1.1.1, иначе Argo не запустится.

Это можно исправить одним из трёх способов. Первый вариант: установить устройство с локальным хостом (127.0.0.1 для IPv4 и ::1 для IPv6) как основной DNS-сервер в сетевой конфигурации, а затем добавить 1.1.1.1 в качестве дополнительного резолвера. Это рабочий вариант, но он не идеален с точки зрения приватности и производительности. Лучше добавить URL сервера из командной строки при загрузке:

$ sudo cloudflared proxy-dns --upstream https://1.0.0.1/dns-query

Если вы уверены, что хотите перейти на DNS-сервер от Cloudflare, что даёт преимущество автоматического обновления, — то можете настроить его в качестве службы в Linux, используя YAML-файл конфигурации, содержащий адреса IPv4 и IPv6 службы DNS от Cloudflare:

proxy-dns: true
proxy-dns-upstream:
- https://1.1.1.1/dns-query
- https://1.0.0.1/dns-query

При настройке с правильной восходящей адресацией производительность dig-запросов через Argo широко варьируется: от 12 мс для популярных доменов аж до 131 мс. Страницы с большим количеством межсайтового контента загружаются… немного дольше обычного. Опять же, ваш результат может быть другим — вероятно, он зависит от вашего местоположения и связности. Но это примерно то, чего я ожидал от мрачного протокол DoH.

Как Cloudflare, мы считаем, что туннели иллюстрируют операцию «Арго» лучше, чем Бен Аффлек

Дабы убедиться, что проблема именно в протоколе DoH, а не в программистах Cloudflare, я испытал два других инструмента. Во-первых, прокси-сервер от Google под названием Dingo. Его написал Павел Форемски, интернет-исследователь из Института теоретической и прикладной информатики Академии наук Польши. Dingo работает только с реализацией DoH от Google, но его можно настроить на ближайшую службу Google DNS. Это хорошо, потому что без такой оптимизации Dingo сожрал всю производительность DNS. Запросы dig в среднем выполнялись более 100 миллисекунд.

Во время проверки обработки стандартных запросов службой dns.google.com я наткнулся на альтернативу дефолтному адресу 8.8.8.8 от Google (172.217.8.14, если знаете). Я добавил его в Dingo из командной строки:

$ sudo ./dingo-linux-amd64 -port=53 -gdns:server=172.216.8.14

Это сократило время отклика примерно на 20%, то есть примерно до того показателя, как у Argo.

А оптимальную производительность DoH неожиданно показал DNSCrypt Proxy 2. После недавнего добавления DoH Cloudflare в курируемый список публичных DNS-сервисов DNSCrypt Proxy почти всегда по умолчанию подключается к Cloudflare из-за низкой задержки этого сервера. Чтобы убедиться, я даже вручную сконфигурировал его под резолвер Cloudflare для DoH, прежде чем запустить батарею dig-запросов.

Все запросы обрабатывались менее чем за 45 миллисекунд — это быстрее, чем собственный клиент Cloudflare, причём с большим отрывом. С сервисом DoH от Google производительность оказалась похуже: запросы обрабатывались в среднем около 80 миллисекунд. Это показатель без оптимизации на ближайший DNS-сервер от Google.

В целом производительность DNSCrypt Proxy по DoH практически неотличима от резолвера DNS по TLS, который я проверял ранее. На самом деле он даже быстрее. Я не уверен, то ли это из-за какой-то особой реализации DoH — может быть, из-за использования стандартного формата сообщений DNS, инкапсулированных в HTTPS, вместо формата JSON — то ли связано с тем, как Cloudflare обрабатывает два разных протокола.

Я не Бэтмен, но моя модель угроз всё равно немного сложнее, чем у большинства людей

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

Тем не менее, важно отметить, что одно лишь шифрование DNS не скроет ваши действия в интернете. Если на сервере хостятся несколько сайтов, то расширение TLS под названием Server Name Indicator (SNI), используемое в соединениях HTTPS, всё равно может показать открытым текстом название сайта, на который вы зашли. Для полной конфиденциальности всё равно нужно использовать VPN (или Tor) для такой инкапсуляции трафика, чтобы провайдер или какая-либо другая шпионящая сторона не могла вытянуть метаданные из пакетов. Но ни один из перечисленных сервисов не работает с Tor. И если против вас работает правительственное агентство, то ни в чём нельзя быть уверенным.

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

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

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

habr.com

Настройка DNS в Ubuntu | Losst

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

Когда компьютеру нужно узнать IP адрес какого-либо домена, он отправляет запрос известному ему DNS серверу. Эти сервера могут быть получены автоматически от роутера по DHCP или же заданы в ручную. В этой статье мы рассмотрим как выполняется настройка DNS Ubuntu 16.04 и более старых версиях.

Содержание статьи:

Настройка DNS в Ubuntu через GUI

Раньше, для настройки DNS серверов, которые будут использоваться системой было достаточно внести адреса нужных серверов в файл /etc/resolv.conf. Но сейчас всей конфигурацией сети в Ubuntu управляет NetworkManager, а этот файл теперь представляет собой только ссылку на файл NetworkManager.

Этот способ до сих пор работает, но в нем вы можете настроить DNS на LiveCD, или до перезагрузки. После перезагрузки все настройки собьются и придется все делать заново. Поэтому, чтобы все сохранилось нужно выполнять все действия через интерфейс NetworkManager. Сначала откройте контекстное меню для значка сети на панели и выберите «Изменить подключения»:

Выберите ваше подключение и нажмите «Изменить»:

В открывшемся окне перейдите на вкладку «Параметры IPv4»:

Затем, в поле «Способ настройки» выберите «Автоматически (DHCP, только адрес)»:

Теперь немного ниже появиться поле «Серверы DNS», где вам нужно прописать нужные серверы, можно несколько адресов через запятую. Например, можно указать сервера от Google:

Поле этого нажмите «Сохранить» и «Закрыть». Теперь можете переподключитесь к этому соединению и можете проверять текущий DNS сервер:

nslookup ya.ru

Собственно, это все, но есть еще один способ настройки через консоль, если этот не сработал или вы предпочитаете работать из консоли.

Настройка DNS через терминал Ubuntu

В Ubuntu есть унифицированный интерфейс настройки сети, который настраивается через конфигурационный файл /etc/network/interfaces. Сначала смотрим список сетевых интерфейсов:

ls /sys/class/net/

Откройте файл для редактирования и найдите в нем имя своего сетевого интерфейса, например, auto enp0s3, если такой секции нет, ее нужно добавить:

sudo vi /etc/network/interfaces

auto enp0s3 iface enp0s3 inet dhcp

Затем, добавьте в эту секцию строчку:

dns-nameserver 8.8.8.8

Здесь адрес 8.8.8.8 — это адрес вашего DNS сервера. Но эта настройка сработает, только если ваш DHCP клиент не пытается назначить адрес самостоятельно. Чтобы указать DNS адрес на уровне DHCP сервера нужно добавить такую строчку в конфигурационный файл /etc/dhcp/dhclient.conf:

sudo vi /etc/dhcp/dhclient.conf

supersede domain-name-servers 8.8.8.8

Здесь тоже адрес 8.8.8.8 означает адрес DNS сервера. Для верности, вы можете добавить свои адреса DNS серверов в файл /etc/resolvconf/resolv.conf.d/base:

sudo vi /etc/resolvconf/resolv.conf.d/base

nameserver 8.8.8.8

Чтобы настройки вступили в силу необходимо перезапустить сеть:

sudo systemctl restart networking

Возможно, даже лучше будет если вы полностью перезагрузите компьютер. Теперь вы можете открыть /etc/resolv.conf и посмотреть применялся ли новый адрес DNS:

Как видите, в моем примере все заработало. Подобно этому выполняется настройка dns linux для любого дистрибутива.

Выводы

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

losst.ru