Настройка DNS на Ubuntu Server 20.04

Настройка DNS на Ubuntu Server 20.04

Преамбула.

Поставил намедни сервер Ubuntu Server 20.04

Настроил сеть. И выкусил!

В /etc/resolv.conf:
127.0.0.53
options edns0

Перезагрузка сервисов и указание руками не помогает

Ранее в Linux.

В Linux обычно запускался локальный DNS-сервер для ускорения работы
Он кеширует ответы повторяющихся DNS-запросов

В /etc/resolv.conf помещается директива — nameserver 127.0.0.1
IP адреса внешних DNS-серверов переносятся в настройки локального

Некторые утилиты при работе нуждаются в изменении файла resolv.conf

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

Утилита resolvconf является посредником между конфликтующими утилитами

Сам файл resolv.conf заменяется символической ссылкой /run/resolvconf/resolv.conf

В следствии утилиты используют динамически сгенерированный файл

Если в ОС отсутствует служба resolvconf.service — файл resolv.conf поддерживается руками

Проблемы пришли с появлением Systemd и NetworkManager

Система инициализации Systemd имеет собственный распознаватель systemd-resolved

Он запускается по умолчанию, требует настройки

NetworkManager — прокладка посути между resolvconf и Systemd

Имеем, что в ОС порт 53 может прослушивать несколько разных распознавателей

Во избежание конфликтов NetworkManager и systemd-resolved используют вместо 127.0.0.1:
127.0.0.1 — dnsmasq или unbound с настройками по дефолту
127.0.1.1 — dnsmasq или unbound, запускается NetworkManager
127.0.0.53 — systemd-resolved, запускается по дефолту

Настройка распознавателя systemd-resolved

На Ubuntu Server 20.04 служба установлена и работает по дефолту

При ее отсутствии установка:
# apt install systemd-resolved

Правим строку «hosts: files resolve dns»:
# vi /etc/nsswitch.conf
passwd: files systemd
group: files systemd
shadow: files
gshadow: files

hosts: files resolve dns
networks: files

protocols: db files
services: db files
ethers: db files
rpc: db files

Где:
«hosts: files resolve dns» — последовательность обращений утилит для разрешения доменных имен

Т.е. в данном случае:
Утилита обратится к файлу /etc/hosts
Затем обратиться к сервису systemd-resolved
Затем обратиться к DNS серверам

Указываем systemd-resolved IP-адреса DNS-серверов, для разрешения доменных имен:

# vi /etc/systemd/resolved.conf
[Resolve]
DNS=8.8.8.8 8.8.8.4 192.168.1.9

Утилитамы не использующие библиотечные вызовы, обращающимися к DNS-серверам напрямую

Получают IP адреса из /etc/resolv.conf

Для них нужно создать символическую ссылку:
# ln -svi /run/systemd/resolve/stub-resolv.conf /etc/resolv.conf

По итогу имеем:
$ cat /run/systemd/resolve/stub-resolv.conf
nameserver 8.8.8.8 # из файла конфигурации /etc/systemd/resolved.conf
nameserver 8.8.8.4 # из файла конфигурации /etc/systemd/resolved.conf
nameserver 192.168.1.9 # из файла конфигурации /etc/systemd/resolved.conf

Символическая ссылка /run/systemd/resolve/resolv.conf

Содержит DNS-сервера, полученные от DHCP-сервера и из файла /etc/systemd/resolved.conf

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

# ln -svi /run/systemd/resolve/resolv.conf /etc/resolv.conf

Включаем запуск службы при загрузке ОС:
# systemdctl enable systemd-resolved
# reboot

После перезагрузки проверяем

Источник

Настройка DNS на Ubuntu Server 18.04 LTS

Стало достаточно традиционным для Linux запускать небольшой локальный DNS-сервер, который ускоряет работу, кешируя ответы на повторяющиеся DNS-запросы. В этом случае в общесистемный /etc/resolv.conf помещается директива nameserver 127.0.0.1 , а ip-адреса внешних DNS-серверов переносятся в настройки локального.

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

При этом файл resolv.conf заменяется символической ссылкой на /run/resolvconf/resolv.conf и программы используют динамически сгенерированный файл. В системе без службы resolvconf.service файл resolv.conf поддерживается вручную или набором скриптов. И эти скрипты могут мешать друг другу при попытках одновременного доступа к файлу.

Всё работало хорошо, пока не появились NetworkManager и Systemd. Система инициализации Systemd имеет свой собственный резолвер systemd-resolved , запущенный по умолчанию и требующий отдельной настройки. А NetworkManager пытается дружить со всеми — с resolvconf , с Systemd , с наиболее распространёнными DNS-резолверами.

Всё это привело к тому, что теперь в одной системе порт 53 может слушать несколько разных резолверов, причём для избежания конфликтов NetworkManager и systemd-resolved используют вместо 127.0.0.1 другие ip-адреса в loopback-сети:

• 127.0.0.1 — dnsmasq или unbound с настройками по умолчанию
• 127.0.1.1 — dnsmasq или unbound , запущенный NetworkManager
• 127.0.0.53 — systemd-resolved , запущенный по умолчанию

Настройка службы systemd-resolved

В Ubuntu Server эта служба уже установлена и запущена сразу после установки операционной системы. Но если это не так, установить ее несложно:

Следующим шагом будет правка файла /etc/nsswitch.conf — находим строку, которая начинается с hosts :

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

Осталось сообщить systemd-resolved ip-адреса DNS-серверов, к которым следует обращаться для резолвинга:

Для целей совместимости с приложениями, которые не используют библиотечные вызовы, а обращаются к DNS-серверам напрямую, получая их ip-адреса из /etc/resolv.conf , следует создать символическую ссылку. Обычно этого не требуется, ссылка уже существует после установки systemd-resolved :

В файле /run/systemd/resolve/stub-resolv.conf указан один-единственный сервер 127.0.0.53 :

Кроме того, можно создать символическую ссылку на /run/systemd/resolve/resolv.conf . Этот файл содержит DNS-сервера, полученные от DHCP-сервера и из файла конфигурации /etc/systemd/resolved.conf . В этом случае локальный кеширующий сервер не используется, что замедлит резолвинг.

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

Настройка службы resolvconf.service

Служба предоставляет остальным программам централизованный интерфейс для добавления и удаления записей в /etc/resolv.conf при изменении сетевой конфигурации, запуске и остановке процессов и т.д.

После установки /etc/resolv.conf будет представлять из себя ссылку на /run/resolvconf/resolv.conf .

При этом исходный файл /etc/resolv.conf (который на самом деле ссылка на /run/systemd/resolve/resolv.conf ) будет сохранен как original в директории /etc/resolvconf/resolv.conf.d/ (чтобы восстановить его при удалении службы resolvconf.service ). В этой же директории есть есть еще три файла — base , head и tail — которые позволяют вручную добавить записи в динамически формируемый /run/resolvconf/resolv.conf .

Теперь добавим пару записей в файл tail (сервера OpenDNS):

Перезагрузим службу и посмотрим сформированный /run/resolvconf/resolv.conf :

Первая запись — это резолвер systemd-resolved , а две другие записи были добавлены в конец resolv.conf из файла tail . Благодаря тому, что первая запись это 127.0.0.53 — резолвинг будет работать быстро, потому что systemd-resolved кеширует ответы DNS-серверов.

Но если мы остановим службу systemd-resolved , резолвинг все равно будет работать, используя сервера 208.67.222.222 и 208.67.220.220 — хотя и гораздо медленнее.

Используем только resolv.conf

Так делать не рекомендуется, потому что резолвинг будет работать медленно, но рассмотрим и этот вариант для полноты картины. Первым делом изменим имя файла /etc/resolv.conf на /etc/resolv.conf.back , а потом создадим свой resolv.conf :

Для Ubuntu Desktop запретим вездесущему NetworkManager вмешиваться в процесс распознавания доменных имен:

Остановим службы resolvconf.service и systemd-resolved.service :

Проверим, как теперь работает распознавание доменных имен:

Источник

Глава 6. Настройка сервера имен

Как уже обсуждалось в главе 2, сеть TCP/IP может полагаться на различные схемы преобразования имен в адреса. Самый простой способ, у которого нет никаких преимуществ над способом, где все пространство имен разделено на зоны, таблица хостов, сохраненная в /etc/hosts . Это полезно только для маленьких LAN, которые управляются одним администратором, и не имеют никакого IP общения с внешним миром. Формат файлов hosts был уже описан главе 5.

С другой стороны Вы можете использовать BIND ( Berkeley Internet Name Domain) для перевода имен хостов в IP-адреса. Конфигурация BIND может быть сложной задачей, но если только Вы сделаете это, то изменения в сетевой топологии могут быть легко отслежены. На Linux, как и на многих других Unix-подобных cистемах, сервис обеспечивается через программу, называемую named. При запуске эта программа загружает множество основных файлов в собственный кэш и ждет запрос от удаленных или локальных пользовательских процессов. Имеющиеся способы требуют, чтобы Вы обязательно ввели имя сервера для каждого хоста.

Библиотека Resolver

Когда мы говорим о » resolver«, то не подразумеваем никакого специального приложения, речь идет только об интерфейсе: системе функций, которая может быть найдена в стандарной библиотеке C. Основными вызовами являются gethostbyname(2) и gethostbyaddr(2) , которые ищут все IP-адреса, принадлежащие хосту, и наоборот. Они могут быть сконфигурированы при простом просмотре информации о хосте, при запросе ряда серверов, или при использовании баз данных hosts NIS (Network Information Service).

Функции читают файл настройки. Он сообщает, какой сервис использовать и в каком порядке. Старая стандартная библиотека Linux, libc, использовала файл /etc/host.conf , но библиотека GNU Version 2, glibc, использует файл /etc/nsswitch.conf .

Файл host.conf

Опции в /etc/host.conf должны быть на отдельных строках. Области могут быть отделены пустым пространством (пробелами или табуляцией). Знак # вводит комментарий до конца строки. Доступны следующие опции:

Эта опция определяет порядок, в котором перебираются все доступные сервисы. Значение hosts связывает запросы сервера с поиском хостов в /etc/hosts , bind с пакетом named , а nis с NIS-поиском. Любое или все значения сразу могут быть определены. Порядок, в котором они появляются в строках, определяет последовательность, в которой будут перебираться сервисы.

Эта опция определяет, разрешено ли хосту в /etc/hosts иметь несколько IP-адресов, которые обычно называются «multi-homed». Этот флаг не действует на DNS или NIS запросы. Допустимые значения: on или off . По умолчанию off.

Как уже объяснено в предыдущем разделе, DNS позволяет найти имя хоста, принадлежащего IP-адресу, используя домен in-addr.arpa . Попытки серверов поддержать ложное имя хоста называются «спуфинг» («spoofing»). Чтобы обезопасить себя от этого, библиотека может быть сконфигурирована на проверку, является ли настоящий IP-адрес фактически связанным с полученным именем хоста. Если нет, то этому имени будет отказано в преобразовании и возвращен код ошибки. Это поведение зависит от того, включен ли nospoof .

Эта опция может принимать значения on или off . Если она включена, то любые попытки спуфинга будут внесены в протокол syslog.

Эта опция берет как аргумент имя домена, которое будет удалено из имени хоста перед поиском. Это полезно для информационных элементов, где Вы хотите точно определить имя хоста с локальным доменом. При поиске хоста с именем локального домена будет удалено имя этого домена. Таким образом, легко осуществить поиск в /etc/hosts . Добавляемое имя домена должно оканчиваться точкой (.), например linux.org.au. .

Опция trim позволяет рассматривать Ваш хост как локальный для нескольких доменов.

Типовой файл для vlager показан в примере 6-1.

Пример 6-1. Образец файла host.conf

Resolver и переменные окружения

Установки из файла host.conf могут быть изменены, используя ряд переменных окружения:

Определяет файл, который будет считан вместо /etc/host.conf .

Отменяет опцию order в host.conf . Сервисы, заданные как hosts , bind , и nis , разделяются пробелом, запятой, двоеточием или точкой с запятой.

Определяет действия, принимаемые против спуфинга. Эта установка полностью отключается опцией off . Значения warn и warn off включают проверку спуфинга, но соответственно включают и выключают протоколирование (logging). Значение * включает проверку, но оставляет logging, как определено в файле host.conf .

Эта переменная может быть использована для перекрытия опции multi из host.conf . Допустимы значения on или off .

Определяет список trim-доменов, который отключает те, что заданы в host.conf .

Определяет список trim-доменов, которые добавляются к заданным в host.conf .

Файл nsswitch.conf

Version 2 GNU standard library включает более мощный и гибкий механизм, чем старый host.conf . Понятие сервиса имен было расширено с включением ряда различных типов информации. Опции конфигурации для всех функций, которые делают запрос к базам данных, были вынесены в один файл конфигурации nsswitch.conf .

Файл nsswitch.conf позволяет администратору конфигурировать большое число разных баз данных. Мы ограничим наше обсуждение параметрами, которые касаются хостов и поиска адресов IP.

Опции в nsswitch.conf должны располагаться на отдельных строках. Поля разделяются пробелами или табуляцией. Знак # как обычно определяет комментарий. Каждая строка описывает свой сервис. Первое поле в каждой строке задает имя базы данных, заканчивающееся двоеточием. База данных для преобразования адресов hosts . Связанная база данных, которая используется для преобразования имен сетей в адреса, networks .

Доступны следующие параметры:

Использовать Domain Name System (DNS), чтобы найти адрес. Это имеет смысл только для адресов машин, но не сетей. Этот механизм использует файл /etc/resolv.conf , который мы обсудим позже.

Искать локальный файл для хоста или имени сети и связанный адрес. Опция использует традиционные /etc/hosts и /etc/network .

nis или nisplus

Использовать Network Information System (NIS), чтобы найти адрес. NIS и NIS+ подробно рассмотрены в главе 13.

Порядок, в котором перечислены сервисы, определяет последовательность их опроса. Список порядка опроса находится в описании сервиса в файле /etc/nsswitch.conf . Сервисы опрашиваются слева направо, и по умолчанию опрос прекращается когда преобразование выполнено.

Простой пример спецификации баз данных host и network показан в примере 6-2.

Пример 6-2. Образец файла nsswitch.conf

Этот пример заставляет систему искать компьютеры сначала в Domain Name System, а в случае неудачи в файле /etc/hosts . Поиск имени сети использует только файл /etc/networks .

Имеются два возможных действия:

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

Resolver перейдет к следующему сервису в списке и будет пытаться использовать его.

Доступные значения состояния, которые мы можем использовать:

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

Не было ошибки в поисковой таблице, но компьютер адресата или сеть не найдены. Заданное по умолчанию действие для этого состояния continue .

Сервис недоступен. Файл hosts или networks нечитаем для сервиса files , сервер имен или NIS-сервер не отвечают на запросы сервисов dns или nis . Заданное по умолчанию действие для этого состояния continue .

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

Простой пример того, как Вы могли бы использовать этот механизм, показан в примере 6-3.

Пример 6-3. Файл nsswitch.conf с командой Action

Этот пример пытается искать компьютеры через Domain Name Service. Если состояние возврата не unavailable, resolver возвращает любой найденный адрес. Если, и только если, DNS возвращает unavailable, resolver делает попытку использовать локальный /etc/hosts . Это означает, что он должен использовать файл hosts , только если наш сервер имен является недоступным.

Настройка сервера имен: файл resolv.conf

При конфигурировании библиотеки resolver для того, чтобы использовать сервис BIND для поиска хостов, Вы обязательно должны сообщить, какое имя сервера используете. Существует отдельный файл, предназначенный специально для этого, называемый resolv.conf . Если этот файл не существует или пуст, то resolver примет имя сервера, определенного для Вашего локального хоста. Если Вы запускаете сервер на Вашем локальном хосте, то должны установить это имя отдельно, как это сделать будет объяснено позже в следующем разделе. Если в локальной сети есть возможность использовать существующее имя сервера, то ему должно отдаваться предпочтение.

Самая важная опция в resolv.conf это name server , которая задает IP-адрес используемого сервера. Если Вы определите несколько имен серверов, используя опцию name server несколько раз, то они будут проверяться в этом порядке. Поэтому Вы должны поместить наиболее надежный сервер первым. Могут поддерживаться не более трех серверов. Если опция name server не задана, то resolver попытается соединиться с сервером на локальном хосте.

Две других опции, domain и search , имеют дело с заданными по умолчанию доменами, которые берутся из имени хоста, если BIND не может найти адрес с первого запроса. Опция search определяет список доменов, которые необходимо проверить. Пункты списка разделены пробелом или табуляцией. Обычно при подключении к компьютер в локальном домене не указывают полностью квалифицированное имя, но использование имени вроде gauss в командной строке приведет на локальный домен, например, mathematics.groucho.edu .

Это только цель инструкции domain . Она позволяет Вам определять заданное по умолчанию имя домена, которое будет добавлено, когда DNS терпит неудачу при поиске имени хоста. Например, когда дано имя gauss , resolver не может найти машину gauss. в DNS, поскольку такого домена верхнего уровня нет. Когда дано mathematics.groucho.edu как значение по умолчанию, resolver повторяет запрос для gauss с заданным по умолчанию доменом.

Но как только Вы выйдете за пределы домена отдела математики, хорошая жизнь кончится. Конечно, Вы также хотели бы иметь записи вроде quark.physics для компьютеров в отделе Физики.

Это делается с помощью search list. Список может быть определен, используя опцию search , которая является обобщением инструкции domain . Он задает перечень доменов, которые будут использовать для поиска машины с коротким именем.

Инструкции search и domain исключают друг друга и не могут появляться больше одного раза. Если никакая опция не задана, resolver пробует взять заданный по умолчанию домен из локального имени хоста (hostname) системным вызовом getdomainname(2) . Если локальный hostname не имеет доменной части, заданный по умолчанию домен будет принят как корневой домен.

Если Вы помещаете инструкцию search в resolv.conf , Вы должны внимательно следить, какие домены туда попадают. Библиотека Resolver до BIND 4.9 создавала заданный по умолчанию список поиска из имени домена, когда список поиска не был задан. Этот заданный по умолчанию список был составлен из заданного по умолчанию домена и всех родительских доменов до корневого. Это вызывало проблемы потому, что запросы DNS попадали на сервера, которые никогда не имели дела с нужным доменом.

Предположим, что Вы из сети Virtual Brewery хотите обратиться к foot.groucho.edu . Но ошибочно вместо foot набираете foo , который не существует. Сервер имен GMU сообщит Вам, что не знает такой компьютер. Со списком поиска старого стиля resolver теперь продолжил бы пробовать найти имя с добавлением vbrew.com и com . Последнее проблематично, потому что groucho.edu.com вполне может оказаться реальным доменом. Их сервер имен мог бы даже найти в своем домене foo . В результате Вы попадете на машину, к которой совсем не стремились! Вряд ли Вы на ней зарегистрируетесь, но с толку будете сбиты основательно.

Для некоторых прикладных программ эти поддельные ведущие поисковые таблицы могут быть проблемой защиты. Следовательно, Вы должны обычно ограничивать домены в Вашем списке поиска локальная организацией. В отделе математики Groucho Marx University список поиска обычно установлен в maths.groucho.edu и groucho.edu .

Когда запрашивается имя vale , resolver ищет vale , а в случае неудачи еще и vale.vbrew.com .

Ошибкоустойчивость Resolver

Если Вы запускаете LAN внутри большей сети, непременно должны использовать центральные сервера имен, если они доступны. Преимущество этого состоит в том, что они имеют богатые кэши, так как все запросы направлены к ним. Эта схема имеет недостаток: когда сгорел базовый кабель в нашем университете при пожаре, невозможно было дальше работать в LAN нашего отдела, потому что resolver не мог достичь какого-либо из серверов. Не было login на X-терминалах, печати на принтерах и т.д.

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

Один из способов это обойти: устанавливать локальный сервер, который определяет имена из Вашего локального домена и пересылает все запросы для других имен к главным серверам. Конечно, это применимо только тогда, когда Вы используете Ваш собственный домен.

Источник