Настройки порядка разрешения имен в системе хранятся в файле
Обновлено: 05.07.2024
Под разрешением имен понимаются методы, которые позволяют преобразовывать имена компьютеров или служб в редактируемые компьютеры, обычно числовые адреса.
Содержание
случаи использования
В Unix каждому пользователю и группе назначается идентификационный номер (UID или GID) от 0 до 65535. Здесь также пользователь входит в систему под своим именем, однако права доступа проверяются с помощью числового UID и GID групп, к которым принадлежит пользователь. С другой стороны, такие программы, как «ls» и «ps», преобразуют числовые идентификаторы обратно в имена, чтобы получить вывод, который легко читается пользователем.
Процедура
Есть несколько методов, которые можно использовать для разрешения имен. Часто используются несколько процедур, которые запрашиваются в определенном порядке, пока одна из них не сможет дать верный ответ.
Например, разрешение имен компьютера Windows в сети SMB (гибридный узел) происходит в следующем порядке:
- Кэш DNS-имен (DNS-кеш): выполняется поиск в DNS-кеше на локальном компьютере.
- Файл Hosts: выполняется поиск файла hosts на локальном компьютере.
- DNS-запрос: запрос отправляется на DNS-сервер в сети.
- Кэш имен NetBIOS : поиск в кэше имен NetBIOS выполняется на локальном компьютере.
- WINS- запрос: запрос отправляется на WINS-сервер в сети.
- Широковещательная передача: широковещательная передача NetBIOS отправляется в собственную подсеть.
- Файл Lmhosts: выполняется поиск файла Lmhosts на локальном компьютере.
Файлы локальной конфигурации
Самый простой способ разрешить имена - использовать локальные файлы, содержащие соответствующее назначение. В текстовых файлах - как в таблице - одному или нескольким адресам или номерам присваиваются имена.
Файлы локальной конфигурации используются, когда централизованная организация данных не требуется или когда данные меняются очень редко. Поскольку эти файлы доступны локально, разрешение будет работать, даже если сеть полностью или частично вышла из строя. Поэтому очень важные данные часто (также) вводятся в локальные файлы.
Примеры (UNIX):
- /etc/passwd
Локальная база данных пользователей. Здесь вводятся администратор («root») и системный пользователь служб (например, пользователь, с правами которого работает веб-сервер ). Если централизованное управление пользователями отсутствует, сюда также вводятся «обычные» пользователи. - /etc/protocols
Названия протоколов и номер , присвоенный в IANA . Эти даты меняются очень редко. - /etc/hosts (см. файл hosts )
Локальная таблица имен хостов. Например, здесь определяется псевдоним «localhost». Веб-сервер может ввести здесь имя сервера базы данных, чтобы иметь возможность связываться с базой данных даже в случае сбоя разрешения сетевых имен.
Визуальное сравнение:
адресная книга в мобильном телефоне сравнима с локальным файлом конфигурации: сохраненные телефонные номера можно искать, не спрашивая кого-то еще. Информация также доступна, если справочная служба недоступна из-за технической ошибки. Для этого адресная книга не поддерживается автоматически: новые или измененные телефонные номера не появляются автоматически в адресной книге.
Трансляция
Предпринята попытка найти имя посредством широковещательной рассылки в напрямую подключенной сети. Используется эта процедура, например, ARP в Ethernet сетях , чтобы узнать MAC - адрес для с адресом IPv4 .
Визуальное сравнение:
в офисе открытой планировки, в котором вы находитесь, вы называете имя партнера, которому хотите позвонить, и спрашиваете его номер телефона. Когда вы его получите, вы можете позвонить нужному партнеру. Согласно принципу, можно связаться только с людьми, находящимися в одной комнате.
Специальные услуги
Компьютер запрашивает необходимую информацию у специальной сетевой службы. Другие службы используются в зависимости от приложения. Благодаря централизованному управлению данными изменения можно вносить в один момент, при этом не нужно настраивать запрашивающие компьютеры.
Визуальное сравнение:
вы (только) знаете номер телефона справочной службы. Вы звоните им, чтобы узнать номер телефона третьего лица. Новые номера телефонов следует сообщать только справочной службе, а не каждому владельцу телефона. Если у справочной службы возникнут технические проблемы, звонить можно, только если у вас есть альтернативный способ узнать номер телефона.
Локальный кеш
Компьютер просматривает свой локальный кеш, чтобы узнать , разрешил ли он это имя. Если да, то требуемый адрес / номер находится в кеше, который можно использовать повторно. Это кэширование используется, в частности, в связи со службами имен для уменьшения количества обращений и ускорения разрешения.
Визуальное сравнение:
вы хотите позвонить тому, с кем недавно разговаривали по телефону. Таким образом, вы просто нажимаете повторный набор, потому что в телефоне сохранены последние номера.
последовательность
Эту статью или раздел необходимо отредактировать. Подробности должны быть указаны на странице обсуждения . Пожалуйста, помогите улучшить его , а затем удалите этот флаг.Порядок не стандартизирован, но зависит от различных факторов.
- : операционная система, для которой
Sun установила приоритет. B. Разрешение имен DNS в Windows XP и Windows 2000 и разрешение имен NetBIOS Windows NT. - используемых протоколов IP или NetBIOS поверх TCP / IP :
Если используется только протокол IP, имя может быть преобразовано только в IP-адрес с разрешением имени DNS. Если используется NetBIOS через TCP / IP, можно использовать NetBIOS и разрешение имен DNS. - файлов конфигурации и опций:
В UNIX-подобных системах порядок определяется записями в файле /etc/nsswitch.conf ( /etc/netsvc.conf в AIX ). В Samba и сервера Samba TNG знают опцию «Имя решительность заказ». В Windows, начиная с Windows NT 3.5, порядок может быть установлен в разделе реестра HKEY_LOCAL_MACHINE \ SYSTEM \ CurrentControlSet \ services \ Tcpip \ ServiceProvider (небольшое число означает высокий приоритет). Стандартные под Windows 7 : 1. локальное имя, 2. файл hosts, 3. DNS и 4. NetBIOS.
Особые формы
Визуальное сравнение:
вы звоните по телефонному номеру, который нашли, используя один из описанных выше методов. Ответившему (по этому номеру) сообщают, с кем именно он хотел бы поговорить.
Заметки по ходу настройки "разного" в Linux. Хочу разобраться - читаю исходники. Программирование, администрирование, микроэлектроника, фотографирование и пр.
вторник, 4 сентября 2012 г.
Настройка разрешения доменных имен в Ubuntu. ping hostname unknown host
Правильная настройка системы разрешения имен в Ubuntu
root@mir: ping microserver
ping: unknown host microserver
2. Трудности просмотра через графические программы (Nautilus). Требуется указывать ip-адрес, что влечёт за собой его предварительное выяснение.
3. Неработающий просмотр сети в Nautilus.
Данная заметка написана для окончательного понимания процесса именования и разрешения имен в Ubuntu.
Правильная настройка включает в себя как настройку микросервера так и клиентов, т.к. многие возможности недоступны "из-коробки".
Что можно получить при правильной настройке разрешения имен в Ubuntu 12.04 микросервера
Автоматическую конфигурацию клиентов сети, проводных и беспроводных, с корректным заданием шлюза в сеть интернет.
Корректно работающий просмотр сетей в Windows и Ubuntu.
Автоматическую доступность всех компьютеров и устройств по их именам. по NetBIOS-именам в домашней локальной сети, домашней беспроводной сети.
Работающий кэширующий DNS сервер в домашней сети
Дополнительные возможности локальных соединений (link-local) точка-точка (ad-hoc) проводных клиентов без сервера в сети.
Сервисы обмена файлами, сетевые принтеры.
Автоматически публикуемые сервисы mDNS, что на пользовательском уровне обеспечивает удобство в разных программах, таких как eKiga, Nautilus.
Например:
 |
| Навигатор Avahi -SSH. Список устройств с доступом SSH |
 |
| Броузер Nautilus видит опубликованные сервисы Avahi |
Имя компьютера - Hostname
Имя компьютера(hostname) задается в файле /etc/hostname
Процесс разрешения имен в Ubuntu - name resolve order
Файл /etc/nssswitch.conf конфигурирует способ, которым следуют стандартные библиотечные процедуры разрешения имен, будь то имена компьютеров (hosts), пользователей (users), группы (groups).
Каждая база данных имен может иметь разнообразные источники - текстовые файлы (/etc/hosts), локальные базы данных, DNS, NIS, WINS, LDAP и пр.
Так сказать - исторические наслоения способов разрешения имен.
.
hosts: files wins dns
.
Первое простейшее решение - /etc/hosts
Простой текстовый файл /etc/hosts сопоставляющий имя компьютера (hostname) и ip-адрес. Аналог листка бумаги с записанными ip-адресами и именем компьютера.
Если на микросервере внести запись в /etc/hosts и на настольном компьютере проделать тоже самое, то проблема решиться. Вот выдержка из файлов:
После этого, пинги по имени компьютера проходят в обе стороны.
root@mir: ping microserver
Главный недостаток этого способа - это ip-адрес, который может меняться при каждой загрузке, если настроено динамическое получение, посредством dhcp. Исправляется это выделением постоянного ip-адреса настольному компьютеру на сервере dhcp, с помощью директивы host (dhcp-host) в конфигурационном файле.
Второй недостаток в том, что при увеличении сети, для нормального разрешения имен, надо на каждом компьютере добавлять информацию о каждом компьютере сети, что весьма трудоемко и чревато пропусками.
Что и ограничивает применение этого способа в небольших одноранговых сетях со статической ip-адресацией и в тестовых условиях недоступности динамических сервисов.
Конфигурация без усилий. Avahi - ZeroConf - mDNS - .local
Avahi - свободная реализация разделов "DNS Service Discovery" и "Multicast DNS" спецификации "Zeroconf Networking".
Multicast DNS (mDNS) - децентрализованная широковещательная доменная система имен. Была разработана в компании Apple, под кодовым именем Bonjour. Предназначена для автоматического конфигурирования сетевого интерфейса при соединениях без выделенного сервера, т.н. link-local. Например, соединение двух компьютеров посредством ehternet-интерфейса, простым ethernet-проводом, в результате произойдет автоконфигурация интерфейсов и компьютеры будут иметь dns имена вида host.local. Использование этой технологии позволит обойтись без ручного вмешательства в сетевые настройки.
Домен .local является доменом по умолчанию, для mDNS.
В настольной Ubuntu сервис avahi устанавливается по умолчанию и работает. Настольный компьютер отзывается по адресу: mir.local с любого компьютера оборудованного avahi.
Есть конфигурационный файл: /etc/default/avahi-daemon, но настроек в нём нет.
Основной конфигурационный файл: /etc/avahi/avahi-daemon.conf
Также доступны: /etc/avahi/hosts и папка для статически определимых сервисов /etc/avahi/services/
Для быстрой публикации сервисов роутеров и пр. оборудования, без поддержки avahi, надо создать xml-файл вида в папке /etc/avahi/services/.
<?xml version="1.0" standalone='no'?><!--*-nxml-*-->
<!DOCTYPE service-group SYSTEM "avahi-service.dtd">
В моих условиях, демон avahi-daemon обязателен к установке, т.к. это резко упрощает взаимодействие между компьютерами.
Повышается удобство работы по протоколу ssh - ssh microserver.local, что часто избавляет от выяснения текущего ip-адреса и через какой интерфейс идёт подключение к микросерверу. А интерфейсом может быть много и на всех на них работает сервис mDNS.
Единственный недостаток - это продолжающаяся недоступность компьютеров по именам(hostname). ping mir & ping microserver - всё ещё не работают "из коробки".
И эту проблему может автоматически решить DNS-сервер в локальной домашней сети.
Централизованная система доменных имен DNS - bind9
Domain Name Service (DNS) - сервис сети Интернет, отображающий (преобразующий) ip-адреса в доменные имена (также и в полностью уточнённые доменные имена FQDN) и обратно.
Микросервер с установленным сервисом DNS выступает в роли сервера имен (name server).
Если объяснить просто, то DNS сервер, это программа ведения списка имен компьютеров, с возможностью обращения к нему через локальную (глобальную) сеть по стандартному протоколу. В частности, список имен (база данных имен), доступен по протоколу UDP на порту 53. Обращаясь с ip-адресом, можно получить имя компьютера и наоборот.
Наиболее известный сервер DNS - BIND (Berkley Internet Naming Daemon).
Установка сервиса DNS bind9 и сопутствующих утилит.
На сервере BIND существует возможность динамического обновления доменной зоны, информацией поставляемой DHCP сервером, о именах подключенных клиентов, что дает искомую возможность доступности по hostname.
Однако, конфигурацию BIND отложим на потом, т.к. есть более быстрый способ - DNSMasq.
DNSMasq - альтернатива связке BIND & DHCPd
DNSmasq - легкий DNS,DHCP,TFTP сервер, применим в небольших домашних сетях.
Возможности сервера позволяют автоматически вносить в список имен DNS, имена компьютеров обращающихся по протоколу DHCP. Это обеспечивает доступность нового компьютера всем компьютерам локальной сети по имени вида: mir, mir.home.
Один конфигурационный файл /etc/dnsmasq.conf
Для того, чтобы новый сервер dnsmasq не конфликтовал с dhcpd сервером, тот надо остановить и исключить из автозагрузки, что можно сделать в файле: /etc/default/isc-dhcpd-server. Либо деинсталлировать, что менее полезно. Также, при использовании виртуализации, сервер dnsmasq используется в качестве dns-сервера для виртуальных машин и может вызывать конфликт с новой копией.
Минимальная настройка конфигурации DNSMasq для микросервера:
Клиентский компьютер получивший настройки от микросервера:
 |
| Сетевые настройки проводной сети home |
 |
| Окно "Маршруты" |
default via 192.168.3.1 dev home proto static
NMBD сервер имен для SMB/CIFS клиентов (обычно Windows компьютеры). NMBD отвечает на запросы "NetBIOS over IP", задаваемые клиентами Samba, SMB/CIFS такими как Windows Vista, Windows 7.
NetBIOS over IP - специальная адаптация раннего протокола NetBIOS к сетям TCP/IP.
Протокол является обеспечивающим участником процесса "Сетевое окружение" в Windows, со стороны микросервера.
NMBD слушает такие широковещательные запросы на порту 137 по протоколу UDP и если встречает в запросе собственное NetBIOS-имя, то возвращает IP-адрес компьютера, на котором запущен. По умолчанию, NetBIOS имя компьютера совпадает с hostname, но может быть изменено в конфигурации smb.conf.
NetBIOS микросервера = microserver
Также могут быть добавлены дополнительные имена NetBIOS к компьютеру. Для чего это может быть понадобиться?
В многосетевых компьютерах NMBD демон запускается на каждом интерфейсе и по идее возвращает IP-адрес интерфейса.
NMBD следует порядку разрешения NetBIOS имен, указанному в конфигурации smb.conf, также и с привлечением файл /etc/samba/lmhosts.
Файл /etc/samba/lmhosts - подобен файлу /etc/hosts, но только для имен NetBIOS.
Синтаксис текстового файла lmhosts можно просмотреть подробно в man lmhosts, но для понимания достаточно:
192.168.3.1 MICROSERVER
Файл lmhosts может быть использован для указание NetBIOS имени различных статических устройств, присутствие которых в сети Windows желательно, но они сами не могут конфигурировать свое NetBIOS имя (отсутствующий nmbd-демон) и разумеется для тестирования протокола Samba.
Действие NMBD ограничивается сегментом сети, т.к. протокол широковещательный (multicast).
WINS - Windows Internet Name Service
NMBD может быть настроен как WINS сервер (Windows Internet Name Service) и как WINS proxy.
Преимущества WINS сервера в том, что этот сервер поддерживает динамическую базу данных NetBIOS-имен компьютеров, которые сами и регистрируют свои имена на WINS сервере, также поддерживает уникальность NetBIOS имен в локальной сети.
Рекомендуется использовать в сетях, состоящих из более чем одного сегмента (наш случай), что позволяет при правильно настроенной IP-маршрутизации, просматривать компьютеры другой подсети.
Функциональность WINS сервера запускается указанием директивы wins support = yes в конфигурационном файле /etc/samba/smb.conf. База имен WINS сервера хранится в файле /var/locks/wins.dat.
Опция wins server более подходит для клиентской настройки Samba (например на компьютере mir). Указывает, сервер wins.
Указание о том, на каком сервере регистрировать свое имя, клиентский компьютер может получить при динамической конфигурации по протоколу DHCP, для этого в используются опции в /etc/dhcp/dhcpd.conf (при использовании isc-dhcp-server), на пример для микросервера:
.
option netbios-name-servers 192.168.3.1;
.
при использовании сервера DNSMasq в качестве DHCP:
.
dhcp-option=44,192.168.3.1
dhcp-option=44,192.168.5.1
dhcp-option=46,8
.
т.к. используется 2 интерфейса (home & ap). Опция dhcp-option=46,8 задает способ запроса NetBIOS имен, в данном случае - гибридный - через WINS-сервер и затем широковещательный.
Возможные значения опция 46:
1.B-node (Broadcast): Разрешение имен с помощью широковещательных запросов, WINS не используется.
2. P-node (Peer): Используется только WINS.
4. M-node (Mixed): Смешанный тип, сначала используется широковещательный запрос, затем в случае неудачи - WINS
8. H-node (Hybrid): WINS, а затем широковещательный запрос.
Sep 4 11:03:34 mir dhclient: DHCPACK of 192.168.3.80 from 192.168.3.1
Sep 4 11:03:34 mir dhclient: bound to 192.168.3.80 -- renewal in 20410 seconds.
Sep 4 11:03:34 mir NetworkManager[1237]: <info> (home): DHCPv4 state changed preinit -> reboot
Sep 4 11:03:34 mir NetworkManager[1237]: <info> Activation (home) Stage 4 of 5 (IP4 Configure Get) scheduled.
Sep 4 11:03:34 mir NetworkManager[1237]: <info> Activation (home) Stage 4 of 5 (IP4 Configure Get) started.
Sep 4 11:03:34 mir NetworkManager[1237]: <info> address 192.168.3.80
Sep 4 11:03:34 mir NetworkManager[1237]: <info> prefix 24 (255.255.255.0)
Sep 4 11:03:34 mir NetworkManager[1237]: <info> gateway 192.168.3.1
Sep 4 11:03:34 mir NetworkManager[1237]: <info> hostname 'mir'
Sep 4 11:03:34 mir NetworkManager[1237]: <info> nameserver '192.168.3.1'
Sep 4 11:03:34 mir NetworkManager[1237]: <info> domain name 'home'
Sep 4 11:03:34 mir NetworkManager[1237]: <info> wins '192.168.5.1'
Sep 4 11:03:34 mir NetworkManager[1237]: <info> Activation (home) Stage 5 of 5 (IP Configure Commit) started.
А вот воспользуется ли какой-либо демон этой полученной информацией? Samba клиент по идее должен обновить опцию wins servers, но не факт. Ключевое слово по теме: dhcpcd-hook-samba. И да, в Ubuntu 12.04 эти изменения не вносятся, что и показывает содержимое клиентской конфигурации Samba:
i@mir$ cat /etc/samba/smb.conf | grep wins
Для исправления данной оплошности, надо сделать несколько изменений в клиентской конфигурации.
Существуют автоматически вызываемые скрипты, который выполняются, когда dhclient завершает работу, располагаются они в /etc/dhcp/dhclient-exit-hooks.d/. Там можно обнаружить скрипт обновления времени, например.
Достаточно создать скрипт,в этой папке, который будет автоматически редактировать файл /etc/samba/smb.conf на клиенте и вносить сведения о новом сервере wins:
Незабываем сделать скрипт исполняемым:
i@mir$ chmod +x /etc/dhcp/dhclient-exit-hooks.d/smb-wins-update
Проверка - простым просмотром файла /etc/samba/smb.conf на клиенте, после подключения.
Winbind используется совместно с Name Service Switch (переключатель-диспетчер служб имен).
В файле /etc/nsswitch.conf можно указать:
hosts: files dns wins
и если имя не удалось разрешить стандартными средствами linux, то будет использован wins сервер.
А вот какой WINS сервер будет использован зависит от настроек сети Windows.
Конфигурация windbind сервера выполняется в файле /etc/samba/smb.conf
Воспользуемся командой net (man net). Видим, что в домашней сети не обнаружено доменов Windows:
Проверить наличие WINS сервера в локальной сети:
i@mir$ wbinfo -p
Ping to winbindd succeeded
failed to call wbcResolveWinsByName: WBC_ERR_WINBIND_NOT_AVAILABLE
Could not lookup WINS by name MICROSERVER
Команда smbclient не зависит от работы winbind и можно просмотреть ресурсы микросервера:
Доменное имя — символьное представление IP-адреса в системе доменных имён (Domain Name System, DNS). В статье рассмотрена настройка разрешения (resolution) доменных имён.
Contents
Name Service Switch
Name Service Switch (NSS) — функциональность стандартной библиотеки Си ( glibc ), на основе которой выполняется разрешение доменных имён при вызове getaddrinfo(3) . NSS объединяет управление базами данных различных служб, позволяя настраивать порядок поиска в этих базах с помощью файла nsswitch.conf(5) . За разрешение доменных имён отвечает база данных hosts, для которой glibc предлагает следующие службы:
- files — читает файл /etc/hosts , см. hosts(5) ;
- dns — распознаватель glibc, читает файл /etc/resolv.conf , см. resolv.conf(5) .
systemd предоставляет три службы NSS для разрешения имён:
Разрешение доменных имён с NSS
Базы данных NSS можно опрашивать утилитой getent(1) . Разрешение доменного имени через NSS выполняется следующим образом:
Распознаватель glibc
Распознаватель glibc считывает файл /etc/resolv.conf при каждом разрешении имени, определяя сервер доменных имён и используемые опции.
Перезапись файла /etc/resolv.conf
Сетевые менеджеры иногда перезаписывают файл /etc/resolv.conf . Подробности можно найти в соответствующих статьях:
Помешать программам изменять файл /etc/resolv.conf можно с помощью защиты от записи, атрибутом неизменяемости:
Совет: Если у вас есть несколько процессов, которые желают выполнять запись в /etc/resolv.conf , то используйте resolvconf.Ограничение времени поиска
Если поиск выполняется слишком медленно (например, при работе pacman или в браузере), попробуйте задать тайм-аут с небольшим значением. По истечении тайм-аута распознаватель выбирает следующий сервер имён из списка. Добавьте следующую строку в /etc/resolv.conf :
Задержка при разрешении имени с IPv6
Из-за неправильной настройки DNS-сервера или межсетевого экрана может возникать пятисекундная задержка при попытке выполнить разрешение имени двумя запросами, A и AAAA [1]. Добавьте следующую опцию в /etc/resolv.conf , чтобы решить проблему:
Имена в локальном домене
Чтобы имена локальных хостов можно было указывать без доменного имени, добавьте следующую строку в файл /etc/resolv.conf (домен замените на необходимый):
Утилиты
С помощью специализированных DNS-утилит можно отправлять запросы конкретным DNS-серверам и/или запросы к записям DNS/DNSSEC определённого типа. NSS при этом не используется, поскольку в утилитах такого рода обычно имеется собственная реализация протокола DNS.
Например, для сбора DNS-информации можно использовать утилиту drill(1) из пакета ldns . Следующая команда запросит TXT-запись домена у указанного сервера имён:
Если DNS-сервер не указать, то drill будет отправлять запросы одному из указанных в /etc/resolv.conf серверов.
- knot — khost(1) и kdig(1) . — unbound-host(1) . — dig(1) , host(1) , nslookup(1) , а также набор dnssec- утилит.
Производительность
-
drill и dig выводят время, затраченное на запрос к серверу.
- На маршрутизаторах часто установлен собственный распознаватель, который выступает в качестве DNS-сервера для локальной сети; он же обычно предоставляет и DNS-кэш.
- Если переключение между серверами происходит слишком медленно, попробуйте уменьшить тайм-аут.
Приватность и безопасность
DNS в приложениях
Chromium включает DoH, если сервера имён, используемые системным распознавателем, его поддерживают. Подробнее (в т.ч. о том, как отключить DoH) см. этот пост.
Oblivious DNS
Oblivious DNS — система распознавания DNS-имён, которая призвана решить некоторые проблемы приватности. Подробнее см. статью Cloudflare.
Сторонние службы DNS
Примечание: Перед использованием DNS-службы какой-либо компании обязательно изучите её политику в отношении приватности и то, как обрабатываются пользовательские данные. Данные представляют некоторую ценость и могут быть проданы третьей стороне.Существует целый DNS-служб от независимых производителей; для некоторых из них также разработаны специализированные программы.
DNS-серверы
DNS-серверы делятся на авторитативные и рекурсивные. Если сервер не принадлежит к одному из этих двух типов, то он представляет из себя так называемый распознаватель-заглушку (stub resolver); его назначение — просто перенаправлять запросы к некоему рекурсивному серверу имён. Заглушки обычно используются для DNS-кэширования на хосте или в локальной сети. Обратите внимание, что то же самое можно получить и установив полноценный сервер имён. В данном разделе представлено сравнение доступных DNS-серверов, более подробное сравнение можно найти в статье Comparison of DNS server software.
Авторитативные серверы
Условное перенаправление
Существует возможность настроить систему на использование определённого DNS-распознавателя для разрешения некоторых доменных имён. Например, очень удобно при подключении к VPN-сети запросы к ней же разрешать с помощью её собственного DNS, в то время как запросы к остальному интернету будут по прежнему разрешаться стандартным распознавателем. Также это можно использовать в локальных сетях.
Для реализации условного перенаправления понадобится локальный распознаватель, потому что glibc такую функцию не поддерживает.
В динамическом окружении (ноутбуки и в некоторой степени настольные компьютеры) необходимо настроить ваш распознаватель на основе сети(-ей), к которой(-ым) вы подключены. Проще всего это сделать с помощью openresolv, поскольку он поддерживает нескольких абонентов. Некоторые сетевые менеджеры также поддерживают этот механизм, либо через openresolv, либо через настройку распознавателя напрямую. Так, в NetworkManager реализовано условное перенаправление без openresolv.
В очередном «конспекте админа» остановимся на еще одной фундаментальной вещи – механизме разрешения имен в IP-сетях. Кстати, знаете почему в доменной сети nslookup на все запросы может отвечать одним адресом? И это при том, что сайты исправно открываются. Если задумались – добро пожаловать под кат. .
Для преобразования имени в IP-адрес в операционных системах Windows традиционно используются две технологии – NetBIOS и более известная DNS.
NetBIOS (Network Basic Input/Output System) – технология, пришедшая к нам в 1983 году. Она обеспечивает такие возможности как:
регистрация и проверка сетевых имен;
установление и разрыв соединений;
связь с гарантированной доставкой информации;
связь с негарантированной доставкой информации;
В рамках этого материала нас интересует только первый пункт. При использовании NetBIOS имя ограниченно 16 байтами – 15 символов и спец-символ, обозначающий тип узла. Процедура преобразования имени в адрес реализована широковещательными запросами.
Небольшая памятка о сути широковещательных запросов.Широковещательным называют такой запрос, который предназначен для получения всеми компьютерами сети. Для этого запрос посылается на специальный IP или MAC-адрес для работы на третьем или втором уровне модели OSI.
Для работы на втором уровне используется MAC-адрес FF:FF:FF:FF:FF:FF, для третьего уровня в IP-сетях адрес, являющимся последним адресом в подсети. Например, в подсети 192.168.0.0/24 этим адресом будет 192.168.0.255
Естественно, постоянно рассылать широковещательные запросы не эффективно, поэтому существует кэш NetBIOS – временная таблица соответствий имен и IP-адреса. Таблица находится в оперативной памяти, по умолчанию количество записей ограничено шестнадцатью, а срок жизни каждой – десять минут. Посмотреть его содержимое можно с помощью команды nbtstat -c, а очистить – nbtstat -R.
Пример работы кэша для разрешения имени узла «хр».
Что происходило при этом с точки зрения сниффера.
В крупных сетях из-за ограничения на количество записей и срока их жизни кэш уже не спасает. Да и большое количество широковещательных запросов запросто может замедлить быстродействие сети. Для того чтобы этого избежать, используется сервер WINS (Windows Internet Name Service). Адрес сервера администратор может прописать сам либо его назначит DHCP сервер. Компьютеры при включении регистрируют NetBIOS имена на сервере, к нему же обращаются и для разрешения имен.
В сетях с *nix серверами можно использовать пакет программ Samba в качестве замены WINS. Для этого достаточно добавить в конфигурационный файл строку «wins support = yes». Подробнее – в документации.
В отсутствие службы WINS можно использовать файл lmhosts, в который система будет «заглядывать» при невозможности разрешить имя другими способами. В современных системах по умолчанию он отсутствует. Есть только файл-пример-документация по адресу %systemroot%\System32\drivers\etc\lmhost.sam. Если lmhosts понадобится, его можно создать рядом с lmhosts.sam.
Сейчас технология NetBIOS не на слуху, но по умолчанию она включена. Стоит иметь это ввиду при диагностике проблем.
если в кэше резолвера адреса нет, система запрашивает указанный в сетевых настройках интерфейса сервер DNS;
Наглядная схема прохождения запроса DNS.
Разумеется, DNS не ограничивается просто соответствием «имя – адрес»: здесь поддерживаются разные виды записей, описанные стандартами RFC. Оставлю их список соответствующим статьям.
Сам сервис DNS работает на UDP порту 53, в редких случаях используя TCP.
DNS переключается на TCP с тем же 53 портом для переноса DNS-зоны и для запросов размером более 512 байт. Последнее встречается довольно редко, но на собеседованиях потенциальные работодатели любят задавать вопрос про порт DNS с хитрым прищуром.
Также как и у NetBIOS, у DNS существует кэш, чтобы не обращаться к серверу при каждом запросе, и файл, где можно вручную сопоставить адрес и имя – известный многим %Systemroot%\System32\drivers\etc\hosts.
В отличие от кэша NetBIOS в кэш DNS сразу считывается содержимое файла hosts. Помимо этого, интересное отличие заключается в том, что в кэше DNS хранятся не только соответствия доменов и адресов, но и неудачные попытки разрешения имен. Посмотреть содержимое кэша можно в командной строке с помощью команды ipconfig /displaydns, а очистить – ipconfig /flushdns. За работу кэша отвечает служба dnscache.
На скриншоте видно, что сразу после чистки кэша в него добавляется содержимое файла hosts, и иллюстрировано наличие в кэше неудачных попыток распознавания имени.
При попытке разрешения имени обычно используются сервера DNS, настроенные на сетевом адаптере. Но в ряде случаев, например, при подключении к корпоративному VPN, нужно отправлять запросы разрешения определенных имен на другие DNS. Для этого в системах Windows, начиная с 7\2008 R2, появилась таблица политик разрешения имен (Name Resolution Policy Table, NRPT). Настраивается она через реестр, в разделе HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows NT\DnsClient\DnsPolicyConfig или групповыми политиками.
Настройка политики разрешения имен через GPO.
При наличии в одной сети нескольких технологий, где еще и каждая – со своим кэшем, важен порядок их использования.
Операционная система Windows пытается разрешить имена в следующем порядке:
проверяет, не совпадает ли имя с локальным именем хоста;
смотрит в кэш DNS распознавателя;
если в кэше соответствие не найдено, идет запрос к серверу DNS;
если не получилось разрешить имя на этом этапе – происходит запрос на сервер WINS;
если постигла неудача, то система пытается получить имя широковещательным запросом, но не более трех попыток;
Для удобства проиллюстрирую алгоритм блок-схемой:
Алгоритм разрешения имен в Windows.
Выполнение второго пинга происходит на несколько секунд дольше, а сниффер покажет широковещательные запросы.
Сниффер показывает запросы DNS для длинного имени и широковещательные запросы NetBIOS для короткого.
Отдельного упоминания заслуживают доменные сети – в них запрос с коротким именем отработает чуть по-другому.
Для того чтоб при работе не нужно было вводить FQDN, система автоматически добавляет часть имени домена к хосту при различных операциях – будь то регистрация в DNS или получение IP адреса по имени. Сначала добавляется имя домена целиком, потом следующая часть до точки.
При попытке запуска команды ping servername система проделает следующее:
Настройка добавления суффиксов DNS через групповые политики.
Настраивать DNS суффиксы можно также групповыми политиками или на вкладке DNS дополнительных свойств TCP\IP сетевого адаптера. Просмотреть текущие настройки удобно командой ipconfig /all.
Суффиксы DNS и их порядок в выводе ipconfig /all.
Из-за суффиксов утилита nslookup выдала совсем не тот результат, который выдаст например пинг:
Это поведение иногда приводит в замешательство начинающих системных администраторов.
При диагностике стоит помнить, что утилита nslookup работает напрямую с сервером DNS, в отличие от обычного распознавателя имен. Если вывести компьютер из домена и расположить его в другой подсети, nslookup будет показывать, что всё в порядке, но без настройки суффиксов DNS система не сможет обращаться к серверам по коротким именам.
Отсюда частые вопросы – почему ping не работает, а nslookup работает.
В плане поиска и устранения ошибок разрешения имен могу порекомендовать не бояться использовать инструмент для анализа трафика – сниффер. С ним весь трафик как на ладони, и если добавляются лишние суффиксы, то это отразится в запросах DNS. Если запросов DNS и NetBIOS нет, некорректный ответ берется из кэша.
Если же нет возможности запустить сниффер, рекомендую сравнить вывод ping и nslookup, очистить кэши, проверить работу с другим сервером DNS.
Кстати, если вспомните любопытные DNS-курьезы из собственной практики – поделитесь в комментариях.
Читайте также: