Как отправить dns запрос через сокет

Составляем DNS-запрос вручную

В этой статье мы изучим двочиный формат сообщений Domain Name Service (DNS) и напишем вручную одно сообщение. Это больше, чем вам нужно для использования DNS, но я подумал, что для развлечения и в образовательных целях интересно посмотреть, что находится под капотом.

Написать запросы DNS в двоичном формате
Отправить сообщение в теле датаграммы UDP с помощью Python
Прочитать ответ от DNS-сервера

Обзор DNS

DNS используется для перевода человекочитаемых доменных имён (таких как example.com ) в машиночитаемые IP-адреса (такие как 93.184.216.34). Для использования DNS нужно отправить запрос на DNS-сервер. Этот запрос содержит доменное имя, которое мы ищем. DNS-сервер пытается найти IP-адрес этого домена в своём внутреннем хранилище данных. Если находит, то возвращает его. Если не может найти, то перенаправляет запрос на другой DNS-сервер, и процесс повторяется до тех пор, пока IP-адрес не будет найден. Сообщения DNS обычно отправляются по протоколу UDP.

Стандарт DNS описан в RFC 1035. Все диаграммы и бóльшая часть информации для этой статьи взята в данном RFC. Я бы рекомендовал обратиться к нему, если что-то непонятно.

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

Формат запроса

У всех сообщений DNS одинаковый формат:

+---------------------+ | Заголовок | +---------------------+ | Вопрос | Вопрос для сервера имён +---------------------+ | Ответ | Ресурсные записи (RR) с ответом на вопрос +---------------------+ | Authority | Записи RR с указанием на уполномоченный сервер +---------------------+ | Дополнительно | Записи RR с дополнительной информацией +---------------------+

Вопрос и ответ находятся в разных частях сообщения. В нашем запросе будут секции «Заголовок» и «Вопрос».

Заголовок

У заголовка следующий формат:

0 1 2 3 4 5 6 7 8 9 A B C D E F +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | ID | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ |QR| Opcode |AA|TC|RD|RA| Z | RCODE | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | QDCOUNT | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | ANCOUNT | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | NSCOUNT | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | ARCOUNT | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

На этой диаграмме каждая ячейка представляет единственный бит. В каждой строчке 16 колонок, что составляет два байта данных. Диаграмма поделена на строки для простоты восприятия, но реальное сообщение представляет собой непрерывный ряд байтов.

Поскольку у запросов и ответов одинаковый формат заголовка, некоторые поля не имеют отношения к запросу и будут установлены в значение 0. Полное описание каждого из полей см. в RFC1035, раздел 4.1.1.

Для нас имеют значение следующие поля:

ID: Произвольный 16-битный идентификатор запроса. Такой же ID используется в ответе на запрос, так что мы можем установить соответствие между ними. Возьмём AA AA.
QR: Однобитный флаг для указания, является сообщение запросом (0) или ответом (1). Поскольку мы отправляем запрос, то установим 0.

Opcode: Четырёхбитное поле, которое определяет тип запроса. Мы отправляем стандартный запрос, так что указываем 0. Другие варианты:

0: Стандартный запрос
1: Инверсный запрос
2: Запрос статуса сервера
3-15: Зарезервированы для будущего использования

Полный заголовок

Совместив все поля, можно записать наш заголовок в шестнадцатеричном формате:

AA AA - ID 01 00 – Параметры запроса 00 01 – Количество вопросов 00 00 – Количество ответов 00 00 – Количество записей об уполномоченных серверах 00 00 – Количество дополнительных записей

Для получения параметров запроса мы объединяем значения полей от QR до RCODE, помня о том, что не упомянутые выше поля установлены в 0. Это даёт последовательность 0000 0001 0000 0000 , которая в шестнадцатеричном формате соответствует 01 00 . Так выглядит стандартный DNS-запрос.

Вопрос

Секция вопроса имеет следующий формат:

0 1 2 3 4 5 6 7 8 9 A B C D E F +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | | / QNAME / / / +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | QTYPE | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | QCLASS | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

Для составления надписи нужно закодировать каждую секцию URL, получив ряд байтов. Надпись — это ряд байтов, перед которыми стоит байт беззнакового целого, обозначающий количество байт в секции. Для кодирования нашего URL можно просто указать ASCII-код каждого символа.

07 65 – у 'example' длина 7, e 78 61 – x, a 6D 70 – m, p 6C 65 – l, e 03 63 – у 'com' длина 3, c 6F 6D – o, m 00 - нулевой байт для окончания поля QNAME 00 01 – QTYPE 00 01 – QCLASS

В секции QNAME разрешено нечётное число байтов, так что набивка байтами не требуется перед началом секции QTYPE.

Отправка запроса

Мы отправляем наше DNS-сообщение в теле UDP-запроса. Следующий код Python возьмёт наш шестнадцатеричный DNS-запрос, преобразует его в двоичный формат и отправит на сервер Google DNS по адресу 8.8.8.8:53.

import binascii import socket def send_udp_message(message, address, port): """send_udp_message sends a message to UDP server message should be a hexadecimal encoded string """ message = message.replace(" ", "").replace("\n", "") server_address = (address, port) sock = socket.socket(socket.AF_INET, socket.SOCK_DGRAM) try: sock.sendto(binascii.unhexlify(message), server_address) data, _ = sock.recvfrom(4096) finally: sock.close() return binascii.hexlify(data).decode("utf-8") def format_hex(hex): """format_hex returns a pretty version of a hex string""" octets = [hex[i:i+2] for i in range(0, len(hex), 2)] pairs = [" ".join(octets[i:i+2]) for i in range(0, len(octets), 2)] return "\n".join(pairs) message = "AA AA 01 00 00 01 00 00 00 00 00 00 " \ "07 65 78 61 6d 70 6c 65 03 63 6f 6d 00 00 01 00 01" response = send_udp_message(message, "8.8.8.8", 53) print(format_hex(response))

Можете запустить этот скрипт, скопировав код в файл query.py и запустив в консоли команду $ python query.py . У него нет никаких внешних зависимостей, и он должен работать на Python 2 или 3.

Чтение ответа

После выполнения скрипт выводит ответ от DNS-сервера. Разобьём его на части и посмотрим, что можно выяснить.

Заголовок

Сообщение начинается с заголовка, как и наше сообщение с запросом:

AA AA – Тот же ID, как и раньше 81 80 – Другие флаги, разберём их ниже 00 01 – 1 вопрос 00 01 – 1 ответ 00 00 – Нет записей об уполномоченных серверах 00 00 – Нет дополнительных записей

Преобразуем 81 80 в двоичный формат:

8 1 8 0 1000 0001 1000 0000

Преобразуя эти биты по вышеуказанной схеме, можно увидеть:

QR = 1: Это сообщение является ответом
AA = 0: Этот сервер не является уполномоченным для доменного имени example.com
RD = 1: Для этого запроса желательна рекурсия
RA = 1: На этом DNS-сервере поддерживается рекурсия
RCODE = 0: Ошибки не обнаружены

Секция вопроса

Секция вопроса идентична такой же секции в запросе:

07 65 – у 'example' длина 7, e 78 61 – x, a 6D 70 – m, p 6C 65 – l, e 03 63 – у 'com' длина 3, c 6F 6D – o, m 00 - нулевой байт для окончания поля QNAME 00 01 – QTYPE 00 01 – QCLASS

Секция ответа

У секции ответа формат ресурсной записи:

0 1 2 3 4 5 6 7 8 9 A B C D E F +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | | / / / NAME / | | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | TYPE | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | CLASS | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | TTL | | | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | RDLENGTH | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--| / RDATA / / / +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

C0 0C - NAME 00 01 - TYPE 00 01 - CLASS 00 00 18 4C - TTL 00 04 - RDLENGTH = 4 байта 5D B8 D8 22 - RDDATA

0 1 2 3 4 5 6 7 8 9 A B C D E F +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | 1 1| OFFSET | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

Первые два бита установлены в значение 1, а следующие 14 содержат беззнаковое целое, которое соответствует смещению байт от начала сообщения до первого упоминания этого имени.

В данном случае смещение составляет c0 0c или двоичном формате:

1100 0000 0000 1100

Расширения

Мы увидели, как составить DNS-запрос. Теперь можно попробовать следующее:

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

Десятичный	Hex	Двоичный	Десятичный	Hex	Двоичный
0	0	0000	8	8	1000
1	1	0001	9	9	1001
2	2	0010	10	A	1010
3	3	0011	11	B	1011
4	4	0100	12	C	1100
5	5	0101	13	D	1101
6	6	0110	14	E	1110
7	7	0111	15	F	1111

Как видите, можно представить любой байт (8 бит) двумя шестнадцатеричными символами. ↑

IT-инфраструктура
Сетевые технологии
IT-стандарты
Стандарты связи

Настройка BIND в качестве DNS-сервера частной сети на базе Ubuntu 18.04

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

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

Версию CentOS, используемую в данном руководстве, можно найти здесь.

Предварительные требования

Для выполнения данного руководства вам потребуется следующая инфраструктура. Создайте каждый сервер **в одном центре обработки данных **с активированной опцией частной сети:

Свежий сервер Ubuntu 18.04, который будет использоваться в качестве основного DNS-сервера, ns1.
(Рекомендуется) Второй сервер Ubuntu 18.04, который используется в качестве дополнительного DNS-сервера, ns2.
Дополнительные серверы в одном центре обработки данных, которые будут использовать ваши DNS-серверы.

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

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

Пример инфраструктуры и целей

В рамках данной статьи мы предполагаем следующее:

У нас есть два сервера, которые будут назначены в качестве наших серверов имен DNS. В этом руководстве мы будем использовать наименования ns1 и ns2.
У нас есть два дополнительных клиентских сервера, которые будут использовать созданную нами инфраструктуру DNS. В этом руководстве мы будем использовать наименования host1 и host2. Вы можете добавить любое количество, которое захотите, для вашей инфраструктуры.
Все эти серверы существуют в одном центре обработки данных. Мы полагаем, что это центр обработки данных nyc3.
Для всех этих серверов активирована опция частной сети (и в подсети 10.128.0.0/16 ; вам, возможно, нужно будет отредактировать эти параметры для ваших серверов).
Все серверы подключены к проекту, который запущен на example.com. Поскольку наша система DNS будет полностью внутренней и частной, вам не нужно будет приобретать доменное имя. Однако использование собственного домена может помочь избежать конфликтов с доменами с публичной маршрутизацией.

С учетом этих предположений мы решили, что будет полезно использовать схему именования, которая использует nyc3.example.com для обращения к нашей частной подсети или зоне. Таким образом, частным полным доменным именем (FQDN) для host1 будет host1.nyc3.example.com. Соответствующую информацию см. в следующей таблице:

Хост	Роль	Частное FQDN	Частный IP-адрес
ns1	Основной DNS-сервер	ns1.nyc3.example.com	10.128.10.11
ns2	Дополнительный DNS-сервер	ns2.nyc3.example.com	10.128.20.12
host1	Стандартный хост 1	host1.nyc3.example.com	10.128.100.101
host2	Стандартный хост 2	host2.nyc3.example.com	10.128.200.102

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

К концу данного руководства мы получим основной DNS-сервер, ns1, и, в качестве опции, дополнительный DNS-сервер, ns2, который будет служит в качестве резервного сервера.

Давайте начнем с установки нашего основного DNS-сервера, ns1.

Установка BIND на DNS-серверах

Примечание: красным цветом выделяется важная информация! Он часто будет использоваться для чего-то, что необходимо заменить на собственные настройки или того, что нужно изменить или добавить в файл конфигурации. Например, если вы увидите что-то вроде host1.nyc3.example.com , замените эти данные на FQDN вашего сервера. Аналогичным образом, если вы увидите host1_private_IP , замените эти данные на частный IP-адрес вашего сервера.

На обоих DNS-серверах, ns1 и ns2, обновите кэш пакета apt с помощью следующей команды:

Теперь можно переходить к установке BIND:

Настройка режима IPv4 для Bind

Прежде чем продолжить, давайте настроим режим IPv4 в BIND, так как наша частная сеть использует исключительно IPv4. На обоих серверах отредактируйте файл настроек по умолчанию bind9 с помощью следующей команды:

Добавьте “-4” в конец параметра OPTIONS . Результат будет выглядеть следующим образом:

/etc/default/bind9

. . . OPTIONS="-u bind -4"

Сохраните файл и закройте его после завершения.

Перезапустите BIND для вступления изменений в силу:

Теперь, после установки BIND, давайте настроим основной DNS-сервер.

Настройка основного DNS-сервера

Конфигурация BIND состоит из множества файлов, которые включены в основной файл конфигурации, named.conf . Эти имена файлов начинаются с named , потому что это имя процесса, который запускает BIND (сокращение от “domain name daemon”). Мы начнем с настройки файла параметров.

Настройка файла параметров

На сервере ns1 откройте файл named.conf.options для редактирования:

Над существующим блоком options создайте новый блок ACL (список контроля доступа) под названием “trusted”. Именно здесь мы создадим список клиентов, для которых мы будем разрешать рекурсивные DNS-запросы (т. е. запросы от ваших серверов, находящихся в том же центре обработки данных, что и ns1). С помощью нашего примера частных IP-адресов мы добавим ns1, ns2, host1 и host2 в наш список надежных клиентов:

/etc/bind/named.conf.options — 1 of 3

acl "trusted" < 10.128.10.11; # ns1 - can be set to localhost 10.128.20.12; # ns2 10.128.100.101; # host1 10.128.200.102; # host2 >; options < . . .

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

/etc/bind/named.conf.options — 2 of 3

 . . . >; options < directory "/var/cache/bind"; . . . >

Под директивой directory добавьте выделенные цветом строки конфигурации (и замените в соответствующем IP-адресе ns1), чтобы результат выглядел примерно следующим образом:

/etc/bind/named.conf.options — 3 of 3

 . . . >; options < directory "/var/cache/bind"; recursion yes; # enables resursive queries allow-recursion < trusted; >; # allows recursive queries from "trusted" clients listen-on < 10.128.10.11; >; # ns1 private IP address - listen on private network only allow-transfer < none; >; # disable zone transfers by default forwarders 8.8.8.8; 8.8.4.4; >; . . . >;

После завершения редактирования сохраните и закройте файл named.conf.options . Согласно конфигурация выше, только ваши собственные серверы (т. е. доверенные) смогут запрашивать у вашего DNS-сервера внешние домены.

Далее мы настроим локальный файл, чтобы задать ваши DNS-зоны.

Настройка локального файла

На сервере ns1 откройте файл named.conf.local для редактирования:

Файл должен содержать только несколько комментариев. Здесь мы зададим наши зоны. DNS-зоны определяют конкретную область для управления и определения записей DNS. Поскольку наши домены будут находиться в субдомене nyc3.example.com, мы будем использовать его в качестве зоны прямого просмотра. Поскольку частные IP-адреса нашего сервера находятся в пространстве IP-адресов 10.128.0.0/16 , мы создадим зону обратного просмотра, чтобы мы могли определять обратный просмотр в этом диапазоне.

Добавьте зону прямого просмотра со следующими строками, заменив имя зоны на собственное, и закрытый IP-адрес дополнительного DNS сервера в директиве allow-transfer :

/etc/bind/named.conf.local — 1 of 2

zone "nyc3.example.com" < type master; file "/etc/bind/zones/db.nyc3.example.com"; # zone file path allow-transfer < 10.128.20.12; >; # ns2 private IP address - secondary >;

Если, согласно нашему предположению, нашей частной подсетью является 10.128.0.0/16 , добавьте зону обратного просмотра с помощью следующих строк (обратите внимание, что имя зоны обратного просмотра начинается с “128.10”, что представляет собой битное преобразование "10.128"):

/etc/bind/named.conf.local — 2 of 2

 . . . >; zone "128.10.in-addr.arpa" < type master; file "/etc/bind/zones/db.10.128"; # 10.128.0.0/16 subnet allow-transfer < 10.128.20.12; >; # ns2 private IP address - secondary >;

Если ваши серверы охватывают несколько частных подсетей, но находятся в одном центре обработки данных, обязательно указывайте дополнительную зону и файл зоны для каждой отдельной подсети. После добавления всех необходимых зон сохраните и закройте файл named.conf.local .

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

Создание файла для зоны прямого просмотра

Файл зоны прямого просмотра — это место, где мы будем определять DNS-записи для прямого просмотра DNS. Т. е., когда DNS получает запрос имени, например, “host1.nyc3.example.com”, будет выполняться поиск в файле зоны прямого просмотра для получения соответствующего частного IP-адреса для host1.

Давайте создадим директорию, в которой будут находиться наши файлы зоны. Согласно конфигурации named.conf.local, это должна быть директория /etc/bind/zones :

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

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

Первоначально он будет выглядеть примерно следующим образом:

/etc/bind/zones/db.nyc3.example.com — original

$TTL 604800 @ IN SOA localhost. root.localhost. ( 2 ; Serial 604800 ; Refresh 86400 ; Retry 2419200 ; Expire 604800 ) ; Negative Cache TTL ; @ IN NS localhost. ; delete this line @ IN A 127.0.0.1 ; delete this line @ IN AAAA ::1 ; delete this line

Во-первых, вам необходимо отредактировать запись SOA. Замените первую запись “localhost” на полное доменное имя (FQDN) ns1, а затем замените “root.localhost” на “admin.nyc3.example.com”. При каждом изменении файла зоны вам нужно будет увеличивать значение serial, прежде чем перезапускать процесс named . Мы увеличим значение до “3”. Теперь файл должен выглядеть примерно следующим образом:

/etc/bind/zones/db.nyc3.example.com — updated 1 of 3

@ IN SOA ns1.nyc3.example.com. admin.nyc3.example.com. ( 3 ; Serial . . .

Далее удалите три записи в конце файла (после записи SOA). Если вы уверены, какие строки следует удалить, удаляйте строки с комментарием “delete this line”.

В конце файла добавьте записи для имени сервера со следующими строками (замените имена на собственные). Обратите внимание, что во втором столбце указывается, что это записи “NS”.

/etc/bind/zones/db.nyc3.example.com — updated 2 of 3

. . . ; name servers - NS records IN NS ns1.nyc3.example.com. IN NS ns2.nyc3.example.com.

Теперь добавьте записи A для ваших хостов, которые принадлежат к этой зоне. Это может быть любой сервер, имя которого будет заканчиваться на “.nyc3.example.com” (замените имена и частные IP-адреса). Используя приведенные в качестве примера имена и частные IP-адреса, мы добавим записи A для ns1, ns2, host1 и host2 примерно таким образом:

/etc/bind/zones/db.nyc3.example.com — updated 3 of 3

. . . ; name servers - A records ns1.nyc3.example.com. IN A 10.128.10.11 ns2.nyc3.example.com. IN A 10.128.20.12 ; 10.128.0.0/16 - A records host1.nyc3.example.com. IN A 10.128.100.101 host2.nyc3.example.com. IN A 10.128.200.102

Сохраните и закройте файл db.nyc3.example.com .

Полученный нами в итоге пример файла зоны для прямого просмотра выглядит следующим образом:

/etc/bind/zones/db.nyc3.example.com — updated

$TTL 604800 @ IN SOA ns1.nyc3.example.com. admin.nyc3.example.com. ( 3 ; Serial 604800 ; Refresh 86400 ; Retry 2419200 ; Expire 604800 ) ; Negative Cache TTL ; ; name servers - NS records IN NS ns1.nyc3.example.com. IN NS ns2.nyc3.example.com. ; name servers - A records ns1.nyc3.example.com. IN A 10.128.10.11 ns2.nyc3.example.com. IN A 10.128.20.12 ; 10.128.0.0/16 - A records host1.nyc3.example.com. IN A 10.128.100.101 host2.nyc3.example.com. IN A 10.128.200.102

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

Создание файла (файлов) зоны для обратного просмотра

Файлы зоны для обратного просмотра служат местом, где мы будем определять PTR записей DNS для обратного просмотра DNS. Т. е., когда DNS получает запрос для IP-адреса, например, “10.128.100.101”, она будет выполнять поиск по файлу (файлам) зоны для обратного просмотра, чтобы получить соответствующее полное доменное имя, в нашем случае это “host1.nyc3.example.com”.

В ns1 для каждой зоны обратного просмотра, заданной в файле named.conf.local, необходимо создать файл зоны для обратного просмотра. При создании нашего файла (или файлов) зоны для обратного просмотра мы будем опираться в качестве примера на файл зоны db.local. Скопируйте его в надлежащее место с помощью следующих команд (замените имя файла назначения, чтобы оно соответствовало определению вашей зоны для обратного просмотра):

Отредактируйте файл зоны для обратного просмотра, который соответствует зоне(-ам), определенной(-ым) в named.conf.local:

Первоначально он будет выглядеть примерно следующим образом:

/etc/bind/zones/db.10.128 — original

$TTL 604800 @ IN SOA localhost. root.localhost. ( 1 ; Serial 604800 ; Refresh 86400 ; Retry 2419200 ; Expire 604800 ) ; Negative Cache TTL ; @ IN NS localhost. ; delete this line 1.0.0 IN PTR localhost. ; delete this line

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

/etc/bind/zones/db.10.128 — updated 1 of 3

@ IN SOA ns1.nyc3.example.com. admin.nyc3.example.com. ( 3 ; Serial . . .

Теперь удалите две записи в конце файла (после записи SOA). Если вы уверены, какие строки следует удалить, удаляйте строки с комментарием “delete this line”.

/etc/bind/zones/db.10.128 — updated 2 of 3

. . . ; name servers - NS records IN NS ns1.nyc3.example.com. IN NS ns2.nyc3.example.com.

Затем добавьте записи PTR для всех ваших серверов, чей IP-адрес соответствует подсети файла зоны, который вы редактируете. В нашем примере это будут все наши хосты, поскольку все они находятся в подсети 10.128.0.0/16 . Обратите внимание, что первый столбец включает два последних байта частных IP-адресов ваших серверов в обратном порядке. Обязательно замените имена и частные IP-адреса согласно данным ваших серверов:

/etc/bind/zones/db.10.128 — updated 3 of 3

. . . ; PTR Records 11.10 IN PTR ns1.nyc3.example.com. ; 10.128.10.11 12.20 IN PTR ns2.nyc3.example.com. ; 10.128.20.12 101.100 IN PTR host1.nyc3.example.com. ; 10.128.100.101 102.200 IN PTR host2.nyc3.example.com. ; 10.128.200.102

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

Полученный нами в итоге пример файла зоны для обратного просмотра выглядит следующим образом:

/etc/bind/zones/db.10.128 — updated

$TTL 604800 @ IN SOA nyc3.example.com. admin.nyc3.example.com. ( 3 ; Serial 604800 ; Refresh 86400 ; Retry 2419200 ; Expire 604800 ) ; Negative Cache TTL ; name servers IN NS ns1.nyc3.example.com. IN NS ns2.nyc3.example.com. ; PTR Records 11.10 IN PTR ns1.nyc3.example.com. ; 10.128.10.11 12.20 IN PTR ns2.nyc3.example.com. ; 10.128.20.12 101.100 IN PTR host1.nyc3.example.com. ; 10.128.100.101 102.200 IN PTR host2.nyc3.example.com. ; 10.128.200.102

Мы завершили редактирование наших файлов, и теперь мы можем проверить наши файлы на ошибки.

Проверка синтаксиса конфигурации BIND

Запустите следующую команду для проверки синтаксиса файлов named.conf* :

Если в ваших именованных файлах конфигурации нет ошибок в синтаксисе, вы должны будете вернуться в командную строку без каких-либо сообщений об ошибках. При обнаружении проблем с файлами конфигурации вы должны будете просмотреть сообщение об ошибке и раздел «Настройка основного DNS сервера», а затем снова воспользоваться командой named-checkconf .

Команда named-checkzone может использоваться для проверки корректности ваших файлов зоны. Первый аргумент команды указывает имя зоны, а второй аргумент определяет соответствующий файл зоны, оба из которых определены в named.conf.local .

Например, чтобы проверить конфигурацию зоны для прямого просмотра “ nyc3.example.com ”, запустите следующую команду (измените на ваши имена зоны для прямого просмотра и файла):

А чтобы проверить конфигурацию зоны для обратного просмотра “ 128.10 .in-addr.arpa”, запустите следующую команду (замените на данные, соответствующие вашей зоне для обратного просмотра и файлу):

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

Перезапуск BIND

Если у вас есть настроенный брандмауэр UFW, откройте доступ к BIND с помощью следующей команды:

Теперь ваш основной DNS-сервер настроен и может отвечать на запросы DNS. Давайте перейдем к созданию дополнительного DNS-сервера.

Настройка дополнительного DNS-сервера

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

На сервере ns2 отредактируйте файл named.conf.options :

В верхней части файла добавьте ACL с частными IP-адресами всех ваших доверенных серверов:

/etc/bind/named.conf.options — updated 1 of 2 (secondary)

acl "trusted" < 10.128.10.11; # ns1 10.128.20.12; # ns2 - can be set to localhost 10.128.100.101; # host1 10.128.200.102; # host2 >; options < . . .

Под директивой directory добавьте следующие строки:

/etc/bind/named.conf.options — updated 2 of 2 (secondary)

 recursion yes; allow-recursion < trusted; >; listen-on < 10.128.20.12; >; # ns2 private IP address allow-transfer < none; >; # disable zone transfers by default forwarders < 8.8.8.8; 8.8.4.4; >;

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

Теперь необходимо отредактировать файл named.conf.local :

Определите slave-зоны, соответствующие master-зонам основного DNS-сервера. Обратите внимание, что в качестве типа используется slave, в файле отсутствует путь, и существует директива masters , которая должна быть настроена на частный IP-адрес основного DNS-сервера. Если вы определили несколько зон для обратного просмотра на основном DNS-сервере, обязательно проверьте, что все они были добавлены на этом этапе:

/etc/bind/named.conf.local — updated (secondary)

zone "nyc3.example.com" < type slave; file "db.nyc3.example.com"; masters < 10.128.10.11; >; # ns1 private IP >; zone "128.10.in-addr.arpa" < type slave; file "db.10.128"; masters < 10.128.10.11; >; # ns1 private IP >;

Сохраните и закройте файл named.conf.local .

Запустите следующую команду для проверки валидности ваших файлов конфигурации:

После выполнения проверки перезапустите BIND:

Разрешите подключение DNS к серверу, внеся изменения в правила брандмауэра UFW:

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

Настройка DNS-клиентов

Прежде чем все ваши серверы в доверенном ACL смогут отправлять запросы на ваши DNS-серверы, вы должны настроить для каждого из них использование ns1 и ns2 в качестве сервера имен. Этот процесс варьируется в зависимости от операционной системы, но для большинства дистрибутивов Linux он подразумевает добавление ваших серверов доменных имен в файл /etc/resolv.conf .

Клиенты Ubuntu 18.04

На Ubuntu 18.04 настройка сетевого взаимодействия выполняется с помощью Netplan, абстракции, которая позволяет вам записывать стандартную конфигурацию сети и применять ее к несовместимому сетевому ПО, отвечающему за бекэнд. Для настройки DNS нам потребуется записать файл конфигурации Netplan.

Во-первых, найдите устройство, связанное с вашей частной сетью, отправив частной подсети команду ip address :

Output
3: eth1: mtu 1500 qdisc fq_codel state UP group default qlen 1000 inet 10.128.100.101/16 brd 10.128.255.255 scope global eth1 valid_lft forever preferred_lft forever

В этом примере используется частный интерфейс eth1 .

Далее необходимо создать новый файл в /etc/netplan с именем 00-private-nameservers.yaml :

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

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

/etc/netplan 00-private-nameservers.yaml

network: version: 2 ethernets: eth1: # Private network interface nameservers: addresses: - 10.128.10.11 # Private IP for ns1 - 10.132.20.12 # Private IP for ns2 search: [ nyc3.example.com ] # DNS zone

Сохраните файл и закройте его после завершения.

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

Output
Warning: Stopping systemd-networkd.service, but it can still be activated by: systemd-networkd.socket Do you want to keep these settings? Press ENTER before the timeout to accept the new configuration Changes will revert in 120 seconds

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

Теперь проверьте DNS-преобразователь системы, чтобы определить, применены ли изменения в конфигурацию DNS:

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

Output
. . . Link 3 (eth1) Current Scopes: DNS LLMNR setting: yes MulticastDNS setting: no DNSSEC setting: no DNSSEC supported: no DNS Servers: 10.128.10.11 10.128.20.12 67.207.67.2 67.207.67.3 DNS Domain: nyc3.example.com . . .

Ваш клиент должен быть настроен на использование ваших внутренних DNS-серверов.

Клиенты Ubuntu 16.04 и Debian

В серверах Ubuntu 16.04 и Debian вы можете изменить файл /etc/network/interfaces :

Внутри найдите строку dns-nameservers и добавьте ваши серверы доменных имен в начало списка, который уже добавлен в файл. Под этой строкой добавьте опцию dns-search , указывающую на базовый домен вашей инфраструктуры. В нашем случае это будет “nyc3.example.com”:

/etc/network/interfaces

 . . . dns-nameservers 10.128.10.11 10.128.20.12 8.8.8.8 dns-search nyc3.example.com . . .

Сохраните файл и закройте его после завершения.

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

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

Output
RTNETLINK answers: No such process Waiting for DAD. Done

Еще раз проверьте, что ваши настройки были применены, введя следующую команду:

Вы должны увидеть ваши серверы доменных имен в файле /etc/resolv.conf , а также ваш домен поиска:

Output
# Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8) # DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN nameserver 10.128.10.11 nameserver 10.128.20.12 nameserver 8.8.8.8 search nyc3.example.com

Ваш клиент настроен для использования ваших DNS-серверов.

Клиенты CentOS

В CentOS, RedHat и Fedora Linux отредактируйте файл /etc/sysconfig/network-scripts/ifcfg- eth0 . Возможно, вам придется заменить eth0 на имя вашего основного сетевого интерфейса:

Найдите опции DNS1 и DNS2 и задайте для них частные IP-адреса ваших основного и дополнительного серверов доменных имен. Добавьте параметр DOMAIN , используя базовый домен вашей инфраструктуры. В этом руководстве это будет “nyc3.example.com”:

/etc/sysconfig/network-scripts/ifcfg-eth0

. . . DNS1=10.128.10.11 DNS2=10.128.20.12 DOMAIN='nyc3.example.com' . . .

Сохраните файл и закройте его после завершения.

Перезапустите сетевую службу с помощью следующей команды:

Команда может зависнуть на несколько секунд, но через короткое время вы должны вернуться в командную строку.

Убедитесь, что изменения вступили в силу, введя следующую команду:

Вы должны увидеть ваши серверы доменных имен и домена поиска в списке:

/etc/resolv.conf

nameserver 10.128.10.11 nameserver 10.128.20.12 search nyc3.example.com

Ваш клиент теперь может подключиться и использовать ваши DNS-серверы.

Тестирование клиентов

Используйте nslookup для проверки того, могут ли ваши клиенты отправлять запросы вашим серверам доменных имен. У вас должна быть возможность сделать это для всех клиентов, которые были настроены и находятся в доверенном ACL.

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

Мы можем начать выполнять прямой просмотр.

Прямой просмотр

Например, мы можем выполнить прямой просмотр для получения IP-адреса host1.nyc3.example.com с помощью следующей команды:

Запрос “host1” расширяется до “host1.nyc3.example.com”, потому что опция search задана для вашего частного субдомена, а запросы DNS будут пытаться просмотреть этот субдомен перед поиском по всему хосту. Результат описанной выше команды будет выглядеть следующим образом:

Output
Server: 127.0.0.53 Address: 127.0.0.53#53 Non-authoritative answer: Name: host1.nyc3.example.com Address: 10.128.100.101

Теперь мы можем проверить обратный просмотр.

Обратный просмотр

Чтобы протестировать обратный просмотр, отправьте DNS-серверу запрос на частный IP-адрес host1:

Результат будет выглядеть следующим образом:

Output
11.10.128.10.in-addr.arpa name = host1.nyc3.example.com. Authoritative answers can be found from:

Если все имена и IP-адреса будут передавать правильные значения, это означает, что ваши файлы зоны настроены надлежащим образом. Если вы получите неожиданные значения, обязательно проверьте файлы зоны на вашем основном DNS-сервере (например, db.nyc3.example.com и db.10.128 ).

Поздравляем! Ваши внутренние DNS-серверы настроены надлежащим образом! Теперь мы перейдем к сохранению записей зоны.

Сохранение DNS-записей

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

Добавление хоста в DNS

При добавлении хоста в вашу среду (в одном центре обработки данных) вам нужно добавить его в DNS. Здесь представлен список шагов, которые вам нужно предпринять:

Основной сервер доменных имен

Файл зоны для прямого просмотра: добавьте запись A для нового хоста, увеличив значение “Serial”
Файл зоны для обратного просмотра: добавьте запись PTR для нового хоста, увеличив значение “Serial”
Добавьте частный IP-адрес вашего нового хоста в доверенный ACL ( named.conf.options )

Протестируйте ваши файлы конфигурации:

Затем перезагрузите BIND:

Ваш основной сервер должен быть настроен для использования нового хоста.

Дополнительный сервер доменных имен

Добавьте частный IP-адрес вашего нового хоста в доверенный ACL ( named.conf.options )

Проверьте синтаксис конфигурации:

Затем перезагрузите BIND:

Ваш вторичный сервер теперь будет принимать подключения с нового хоста.

Настройка нового хоста для использования вашей DNS

Настройте /etc/resolv.conf для использования ваших DNS-серверов
Выполните проверку с помощью nslookup

Удаление хоста из DNS

Если вы удалите хост из вашей среды или захотите просто убрать его из DNS, просто удалите все данные, которые были добавлены при добавлении сервера в DNS (т. е. выполните описанные выше шаги в обратно порядке).

Заключение

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

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

Thanks for learning with the DigitalOcean Community. Check out our offerings for compute, storage, networking, and managed databases.

Настройка использования DNS-фильтрации SkyDNS в локальной (корпоративной) сети

Для того, чтобы начать использовать сервис DNS-фильтрации SkyDNS необходимо:

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

определить, через какой шлюз осуществляется выход в интернет;
определить, какие службы (Active Directory, DNS, proxy, DHCP) на каких серверах выполняются, какие IP адреса используются для этих служб и компьютеров пользователей;
определить, каким образом получают сетевые настройки компьютеры (по DHCP или прописаны вручную);

либо установить на компьютеры пользователей SkyDNS Agent;
либо использовать сервис динамического DNS (типа DynDNS или no-ip.com) и привязать имя хоста, зарегистрированное в сервисе динамического DNS, к профилю в аккаунте SkyDNS;

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

Внимание! Если провайдер предоставил вам внешний IP адрес из одной из подсетей для частных сетей (т.е. IP адрес не является внешним), то возможными решениями будут являться установка агента SkyDNS на компьютеры в локальной сети, использование роутера ZyXEL Keenetic или привязка того IP адреса, который определился для вас нашим сервисом. Но в последнем случае возможен конфликт настроек с другими пользователями нашего сервиса на том же IP адресе, поэтому мы рекомендуем делать это с осторожностью. Список подсетей для частных (немаршрутизируемых) сетей следующий: 192.168.0.0/16, 172.16.0.0/12, 10.0.0.0/8, 100.64.0.0/10.

Централизованное управление настройками фильтрации

Администратор может создавать/удалять/изменять различные профили фильтрации через веб-интерфейс (личный кабинет на сайте SkyDNS) или агент SkyDNS.

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

В случае удаления используемого профиля фильтрации агент SkyDNS будет использовать профиль фильтрации Основной.

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

Если требуются раздельные настройки фильтрации для каждого компьютера (группы компьютеров)

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

Если в локальной сети развернуты службы Active Directory, то:

пропишите в аккаунте SkyDNS адрес домена контроллера и пропишите алиасы для локальных ресурсов (создаются только A записи);
либо установите специальную версию агента SkyDNS CS (данная версия предоставляется пользователям платных тарифов по запросу в тех.поддержку).

Стандартный агент SkyDNS принимает DNS запросы на локальном для каждого компьютера IP адресе 127.0.0.1 и осуществляет запросы DNS к серверам SkyDNS 193.58.251.251.

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

Если требуются одинаковые настройки фильтрации для всех или основной части компьютеров в сети

Ниже приведены примеры настройки использования DNS-сервера SkyDNS для разрешения внешних DNS-имен.

Пример №1.
В локальной сети отсутствуют серверы DNS, прокси-серверы и т.п. Компьютеры используют серверы DNS в интернете.

Привяжите внешний статический IP адрес или имя хоста, зарегистрированное в сервисе динамического DNS, к профилю в аккаунте SkyDNS.

Настройте компьютеры на использование DNS-сервера SkyDNS с IP адресом 193.58.251.251.

Пример №2.
В локальной сети имеется сервер DNS, который используют все компьютеры в сети.

Настройте существующий сервер DNS на пересылку запросов внешних DNS-имен на DNS-сервер SkyDNS с IP адресом 193.58.251.251.

Пример №3.
В локальной сети используется сервис DHCP для выдачи компьютерам сетевых настроек.

Настройте сервис DHCP для выдачи адреса DNS сервера 193.58.251.251 тем компьютерам, на которых требуется фильтрация.

Пример №4.

В локальной сети имеется прокси-сервер, который используют все компьютеры в сети.

Настройте прокси-сервер на использование DNS-сервера SkyDNS с IP адресом 193.58.251.251. Укажите в настройках прокси-сервера DNS-сервер 193.58.251.251. Если прокси-сервер использует системный клиент DNS операционной системы или получает список серверов DNS из настроек ОС, то в сетевых настройках ОС пропишите DNS-сервер SkyDNS с IP адресом 193.58.251.251.

Пример №5.
В локальной сети имеется прокси-сервер запущенный на ОС Windows, который используют все компьютеры в сети. Внешний IP адрес динамический.

Настройте прокси-сервер на использование DNS-сервера с IP адресом 127.0.0.1. Укажите в настройках прокси-сервера DNS-сервер 127.0.0.1. Если прокси-сервер использует системный клиент DNS операционной системы или получает список серверов DNS из настроек ОС, то дополнительных настроек не требуется.

Установите на компьютер, на котором запущен прокси-сервер агент SkyDNS.

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

Внимание. Невозможна работа на одном хосте агента SkyDNS и DNS сервера, который может идти в составе ПО совместно с прокси-сервером.

Пример №6.
В локальной сети имеется сервер DNS и прокси-сервер, которые используют все компьютеры в сети.

Настройте существующий сервер DNS на пересылку запросов внешних DNS-имен на DNS-сервер SkyDNS с IP адресом 193.58.251.251.

Настройте прокси-сервер на использование имеющегося DNS-сервера или на использование DNS-сервера SkyDNS с IP адресом 193.58.251.251 (в последнем случае будут недоступны внутренние веб-ресурсы, если они имеются в локальной сети). Если в локальной сети имеются внутренние веб-ресурсы и прокси-сервер, то имеет смысл внедрить использование Web Proxy Autodiscovery Protocol и/или файл proxy auto-config (PAC), что позволяет тонко настраивать браузеры пользователей в каких случаях использовать прокси-сервер, а в каких обращаться к веб-ресурсам напрямую.

Пример №7.
В локальной сети развернуты службы Active Directory.

Если у вас в организации развернуты службы Active Directory, то также существует внутренний для организации сервер DNS.

Настройте существующий сервер DNS на пересылку запросов внешних DNS-имен на DNS-сервер SkyDNS с IP адресом 193.58.251.251.

Подробнее про настройку Службы DNS здесь.

Пример №8.
В локальной сети развернуты службы Active Directory, имеется прокси-сервер, на части компьютеров пользователей установлены ОС Windows, на другой части — Linux. Внешний IP-адрес динамический. Требуется для разных компьютеров применять различные настройки фильтрации.

В данном случае раздельные настройки фильтрации для компьютеров с Linux не будут применяться. Но возможно для компьютеров с Linux и части компьютеров с Windows применять одни настройки фильтрации и различные настройки фильтрации для других компьютеров с Windows.

Используйте сервис динамического DNS (типа DynDNS или no-ip.com) и привяжите имя хоста, зарегистрированное в сервисе динамического DNS, к профилю в аккаунте SkyDNS.
Настройте существующий сервер DNS на пересылку запросов внешних DNS-имен на DNS-сервер SkyDNS с IP адресом 193.58.251.251. Подробнее про настройку Службы DNS здесь.
Настройте прокси-сервер на использование имеющегося DNS-сервера или на использование DNS-сервера SkyDNS с IP адресом 193.58.251.251 (в последнем случае будут недоступны внутренние веб-ресурсы, если они имеются в локальной сети).
Настройте компьютеры с Linux на использование существующего сервера DNS и прокси-сервера.
Настройте компьютеры с Windows, на которых должны применяться те же настройки фильтрации, на использование существующего сервера DNS и прокси-сервера.
Установите на другие компьютеры с Windows агент SkyDNS или SkyDNS CS. Создайте и примените необходимые профили фильтрации. Отключите использование прокси-сервера на данных компьютерах.

Пример №9.
В локальной сети развернуты службы Active Directory, на части компьютеров пользователей установлены ОС Windows, на другой части — Linux. Имеется подсеть внешних IP адресов с маской 28 (14 внешних IP адресов). Требуется для разных компьютеров применять различные настройки фильтрации.

Создайте до 14 включительно профилей фильтрации в аккаунте SkyDNS.
Привяжите к каждому профилю по IP адресу из имеющихся внешних IP адресов.
Запустите до 14 включительно серверов DNS (например bind9) принимающих запросы от компьютеров в локальной сети каждый на своем IP. Можно запустить DNS серверы с различными конфигурационными файлами или использовать виртуализацию и запустить каждый экземпляр в отдельной виртуальной машине.
Настройте каждый экземпляр как slave для зон в DNS сервере, используемом службами Active Directory.
Настройте на каждом DNS сервере пересылку запросов внешних DNS-имен на DNS-сервер SkyDNS с IP адресом 193.58.251.251 с индивидуального сокета для этого сервера DNS.
На шлюзе доступа в интернет настройте Source NAT на каждый из имеющихся 14 внешних IP для каждого из сокетов, с которых DNS серверы осуществляют запросы.
Разбейте компьютеры в локальной сети на 14 групп и каждой группе выдайте с помощью DHCP один из созданных DNS серверов.

Для дома
Для бизнеса
Для учебных заведений и библиотек
Для провайдеров
Для разработчиков
Система аналитики SkyDNS Data
Проверка безопасности

О компании
Контакты
Партнерам
Работа у нас
Новости
Условия использования
Политика конфиденциальности

Установка и примеры настройки Dnsmasq

Обновлено

Обновлено: 28.10.2022 Опубликовано: 03.09.2021

Используемые термины: Dnsmasq, DNS, Linux. Данная инструкция будет состоять из двух основных частей — установка программного обеспечения и примеры по его настройки под различные задачи. Мы рассмотрим примеры работы на системах Linux Ubuntu и Rocky Linux (CentOS).

Установка, настройка системы и запуск

1. Установка выполняется немного, по-разному, в зависимости от выбранного дистрибутива Linux. Рассмотрим примеры систем на базе Deb и RPM. а) Для Debian / Ubuntu (Deb):

apt install dnsmasq
б) Для Rocky Linux / CentOS (RPM):
yum install dnsmasq
Установка завершена.

После установки или старта сервиса мы можем увидеть ошибку:

failed to create listening socket for port 53: Address already in use

Как правило, она связана с тем, что на компьютере работает сервис systemd-resolved, который занял порт 53. Чтобы это исправить, отключаем его:

systemctl disable systemd-resolved --now
2. После установки разрешим автозапуск сервиса. Вводим команду:
systemctl enable dnsmasq
Для систем на базе RPM также необходимо запустить сервис:
systemctl start dnsmasq

3. Настраиваем брандмауэр. Нам необходимо открыть UDP порт 53. Как правило, используется 2 системы управления netfilter — iptables и firewalld. Рассмотрим обе. а) При использовании iptables (как правило, для систем на базе Deb):

iptables -I INPUT -p udp --dport 53 -j ACCEPT
И сохраняем правило. б) При использовании firewalld (как правило, для систем на базе RPM):
firewall-cmd --permanent --add-port=53/udp
firewall-cmd --reload

4. Проверяем работоспособность сервиса. На любом из компьютеров в сети делаем запрос при помощи nslookup:

nslookup dmosk.ru 192.168.0.15

* где 192.168.0.15 — адрес в сети нашего сервера, куда мы установили dnsmasq. Мы должны получить ответ на подобие:

Server: 192.168.0.15
Address: 192.168.0.15#53

Non-authoritative answer:
Name: dmosk.ru
Address: 92.53.96.18

Наш dnsmasq установлен и готов к дальнейшей настройке.

Примеры настройки dnsmasq

Переходим к основной части инструкции. Приведем примеры использования и соответствующей настройки dnsmasq.

1. Перевод запросов на другой DNS-сервер для определенного домена

Предположим, у нас есть задача — переводить все запросы для имен с доменом consul на другой DNS-сервер, который находится в нашей сети. Также, данный сервер слушает не на стандартном для NS-сервера порту (53), а на порту 8600. Кстати, это реальный пример работы при настройке кластера consul. Создаем конфигурационный файл:

vi /etc/dnsmasq.d/consul
В него добавим одну строку:
server=/consul/127.0.0.1#8600

* в данном примере мы будем переводить все запросы для домена consul на сервер 127.0.0.1 (в этом примере локальный сервер, но может быть любой) и порт 8600.

Если мы работаем в системе с включенным SELinux и переводим запросы на нестандартный порт, то необходимо добавить правило:

semanage port -a -t dns_port_t -p tcp 8600
* где 8600 — порт, на который переводим запросы DNS.

Чтобы настройки вступили в силу, перезапускаем dnsmasq:
systemctl restart dnsmasq

2. Настройка кэширования

По умолчанию, dnsmasq работает как кэширующий сервер. Мы же подредактируем настройки. Создаем конфигурационный файл:

vi /etc/dnsmasq.d/cache
cache-size=10000
all-servers
no-negcache

cache-size — размер кэша (количество хостов).
all-servers — задает поведение, при котором наш сервер будет отправлять запрос всем доступным ему серверам DNS и принимать ответ от того, кто первый ему ответит.
no-negcache — не кэшировать негативные ответы.

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

systemctl restart dnsmasq

3. Подмена IP-адресов

Есть несколько вариантов подмены IP-адресов в dnsmasq. Для настройки создадим файл:

В зависимости от ситуации, применяем один из вариантов, описанных ниже.

а) Подмена одного адреса:

* в данном примере если наш сервер получит ответ 1.1.1.1, он его заменит на 2.2.2.2.

б) Подмена адресов в подсети:

* в данном примере все адреса из подсети 1.1.1.0/24 будут заменены на соответствующие адреса подсети 2.2.2.2/24.

* в данном примере адреса в диапазоне от 1.1.1.100 до 1.1.1.200 будут переопределены в адреса в диапазоне от 192.168.0.100 до 192.168.0.200.

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

systemctl restart dnsmasq

4. Произвольный адрес

Мы можем быстро добавить любой адрес и привязать его к доменному имени. Делается это с помощью директивы address:

address=/dmosk.local/127.0.0.1
address=/dmosk.local/192.168.0.15
address=/mail.dmosk.local/192.168.0.16

* в нашем примере dnsmasq будет знать о двух записях — dmosk.local и mail.dmosk.local. Первая будет разрешаться в два адреса.

systemctl restart dnsmasq

5. Форвард запросов на другой сервер

С помощью опции server мы можем указать серверы, на которые нужно передавать запрос DNS.

* в данном примере мы передадим запросы на серверы Google.

systemctl restart dnsmasq

6. Файл hosts

В зависимости от ситуации, нам может потребоваться разрешать некоторые имена с помощью файла /etc/hosts. Или наоборот — настройки из данного файла могут нам мешать.

В dnsmasq предусмотрена директива hosts, с помощью которой мы можем манипулировать результатами с использованием файла hosts.

а) Если мы хотим, чтобы данные из файла учитывались:

б) Если нам не нужны данные из файла:

systemctl restart dnsmasq

Это, далеко, не все возможности dnsmasq. По мере необходимости, они будут дополняться в данной инструкции.

Диагностика и решение проблем

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

* где опция log-queries разрешает логи запросов; log-facility позволяет задать путь до файла с логами.

Создаем каталог для хранения лога:

Перезапускаем dnsmasq, чтобы применить изменения:

systemctl restart dnsmasq

Прочитать лог можно командой (непрерывное чтение):

tail -f /var/log/dnsmasq/dnsmasq.log

Смотрите также

Возможно, также будет интересны инструкции:

Как отправить dns запрос через сокет

Составляем DNS-запрос вручную

Обзор DNS

Формат запроса

Заголовок

Полный заголовок

Вопрос

Отправка запроса

Чтение ответа

Заголовок

Секция вопроса

Секция ответа

Расширения

Настройка BIND в качестве DNS-сервера частной сети на базе Ubuntu 18.04

Предварительные требования

Пример инфраструктуры и целей

Установка BIND на DNS-серверах

Настройка режима IPv4 для Bind

Настройка основного DNS-сервера

Настройка файла параметров

Настройка локального файла

Создание файла для зоны прямого просмотра

Создание файла (файлов) зоны для обратного просмотра

Проверка синтаксиса конфигурации BIND

Перезапуск BIND

Настройка дополнительного DNS-сервера

Настройка DNS-клиентов

Клиенты Ubuntu 18.04

Клиенты Ubuntu 16.04 и Debian

Клиенты CentOS

Тестирование клиентов

Прямой просмотр

Обратный просмотр

Сохранение DNS-записей

Добавление хоста в DNS

Основной сервер доменных имен

Дополнительный сервер доменных имен

Настройка нового хоста для использования вашей DNS

Удаление хоста из DNS

Заключение

Настройка использования DNS-фильтрации SkyDNS в локальной (корпоративной) сети

Централизованное управление настройками фильтрации

Если требуются раздельные настройки фильтрации для каждого компьютера (группы компьютеров)

Если требуются одинаковые настройки фильтрации для всех или основной части компьютеров в сети

Установка и примеры настройки Dnsmasq

Установка, настройка системы и запуск

Примеры настройки dnsmasq

1. Перевод запросов на другой DNS-сервер для определенного домена

2. Настройка кэширования

3. Подмена IP-адресов

4. Произвольный адрес

5. Форвард запросов на другой сервер

6. Файл hosts

Диагностика и решение проблем

Смотрите также

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