Какая служба используется для получения ip адреса по имени хоста компьютера
Каждый раз, посещая всемирную сеть Интернет и заходя на сайты, вы используете DNS (Domain Name System или Domain Name Service), но скорей всего даже не подозреваете об этом. Давайте разберемся, что такое DNS и как оно помогает вам посещать ресурсы.
DNS – это сетевая служба, серверы которой сопоставляют буквенные значения доменного имени с цифровым значением IP-адреса и наоборот.
DNS – это сеть серверов с базами данных, распределенная в сети Интернет. Все серверы связаны между собой, и при поступлении запроса на расшифровку и невозможности по какой-либо причине определить его самостоятельно, сервер передает этот запрос другим подобным серверам по специально разработанным схемам, до тех пор пока доменное имя не будет переведено в IP-адрес. Услугами DNS серверов пользуются буквально все программы, которые работают в Интернет.
DNS указывается веб-мастером при регистрации домена. Этот процесс заключается в заполнении в панели управления доменом двух полей dns1 и dns2 IP или URL адресами сервера Вашего хостинга. Эти адреса обычно выдаются сразу после того, как Вы купите хостинг. При смене хостинга Вам придется сменить и dns. На серверах он сменится моментально, но, может оказаться в кеше Вашего Интернет-провайдера, для обновления которого может потребоваться до 4-х суток. Это означает, что для Вас сайт будет ещё до 4-х суток доступен по адресу прежнего сервера.
DNS (англ. Domain Name System — система доменных имён) — компьютерная распределённая система для получения информации о доменах. Чаще всего используется для получения IP-адреса по имени хоста (компьютера или устройства) , получения информации о маршрутизации почты, обслуживающих узлах для протоколов в домене (SRV-запись) .
Распределённая база данных DNS поддерживается с помощью иерархии DNS-серверов, взаимодействующих по определённому протоколу.
Основой DNS является представление об иерархической структуре доменного имени и зонах. Каждый сервер, отвечающий за имя, может делегировать ответственность за дальнейшую часть домена другому серверу (с административной точки зрения — другой организации или человеку) , что позволяет возложить ответственность за актуальность информации на серверы различных организаций (людей) , отвечающих только за «свою» часть доменного имени.
Domain Name System
Разрешение доменных имён
BIND, PowerDNS или Microsoft DNS Server
DNS (англ. Domain Name System — система доменных имён) — компьютерная распределённая система для получения информации о доменах. Чаще всего используется для получения IP-адреса по имени хоста (компьютера или устройства), получения информации о маршрутизации почты, обслуживающих узлах для протоколов в домене (SRV-запись).
Распределённая база данных DNS поддерживается с помощью иерархии DNS-серверов, взаимодействующих по определённому протоколу.
Основой DNS является представление об иерархической структуре доменного имени и зонах. Каждый сервер, отвечающий за имя, может делегировать ответственность за дальнейшую часть домена другому серверу (с административной точки зрения — другой организации или человеку), что позволяет возложить ответственность за актуальность информации на серверы различных организаций (людей), отвечающих только за «свою» часть доменного имени.
Начиная с 2010 года, в систему DNS внедряются средства проверки целостности передаваемых данных, называемые DNS Security Extensions (DNSSEC). Передаваемые данные не шифруются, но их достоверность проверяется криптографическими способами. Внедряемый стандарт DANE обеспечивает передачу средствами DNS достоверной криптографической информации (сертификатов), используемых для установления безопасных и защищённых соединений транспортного и прикладного уровней.
Файл hosts — как первый шаг к созданию DNS
Для решения задачи разработчики решили использовать словарь, который связывал уникальное имя и IP-адрес каждого компьютера в сети. Таким словарём стал файл hosts.txt, который и отвечал за привязку IP-адреса к имени компьютера. Файл лежал на сервере Стэнфордского исследовательского института, и пользователи сети регулярно вручную скачивали этот файл на свои компьютеры, чтобы сохранять актуальность словаря, ведь новые компьютеры появлялись в сети почти каждый день.
Выглядел hosts.txt тогда (да и сейчас) таким образом:
При наличии такого файла на компьютере пользователя для связи с компьютером Майка, можно было не запоминать цифры, а использовать понятное латинское имя «MIKE-STRATE-PC».
Посмотрим, как выглядит файл и попробуем добавить туда новое имя, чтобы подключиться к компьютеру с использованием данного имени. Для этого отредактируем файл hosts. Вы можете найти его на своём компьютере по следующему адресу:
- В Unix-системах: /etc/hosts
- В Windows-системах: %Путь до папки Windows%/system32/drivers/etc/hosts
Компьютеру с IP-адресом 192.168.10.36, который находится внутри локальной сети мы указали имя «MIKE-STRATE-PC». После чего можно воспользоваться командой ping, которая пошлёт специальный запрос на компьютер Майка и будет ждать от него ответа. Похоже на то, как вы стучитесь в дверь или звоните в звонок, чтобы узнать, «есть ли кто дома?» Такой запрос можно послать на любой компьютер.
По мере развития сети и «обрастания» её новыми клиентами, такой способ становился неудобным. Всем пользователям компьютеров было необходимо всё чаще скачивать свежую версию файла с сервера Стэнфордского исследовательского института, который обновлялся вручную несколько раз в неделю. Для добавлений же новых версий было необходимо связываться с институтом и просить их внести в файл новые значения.
В 1984 году Пол Мокапетрис (Paul Mockapetris) описал новую систему под названием DNS (Domain Name System / Система доменных имён), которая была призвана автоматизировать процессы соотнесения IP-адресов и имён компьютеров, а также процессы обновления имён у пользователей без необходимости ручного скачивания файла со стороннего сервера.
Терминология
Основными компонентами DNS являются:
Домен (доменное имя) — символьное имя для обозначения сервера в сети интернет. Доменные имена являются иерархической структурой, в которой каждый уровень отделяется точкой. Основными уровнями являются:
DNS-сервер — система, ответственная за хранение и поддержание в актуальном состоянии записей о своих дочерних доменах. Каждый DNS-сервер ответственен только за свою зону, то есть DNS-сервер домена .io знает о том, где расположен домен hexlet, DNS-сервер которого знает о расположении своих поддоменов.
Корневой DNS-сервер — система, знающая расположение (IP-адреса) DNS-серверов доменов верхнего уровня.
Ресурсная запись — единица информации DNS-сервера. Каждая ресурсная запись имеет несколько полей:
- Имя (домен, к которому относится запись)
- Тип
- Параметры
- Значение
Обратный DNS-запрос
DNS используется в первую очередь для преобразования символьных имён в IP-адреса, но он также может выполнять обратный процесс. Для этого используются уже имеющиеся средства DNS. Дело в том, что с записью DNS могут быть сопоставлены различные данные, в том числе и какое-либо символьное имя. Существует специальный домен in-addr.arpa, записи в котором используются для преобразования IP-адресов в символьные имена. Например, для получения DNS-имени для адреса 11.22.33.44 можно запросить у DNS-сервера запись 44.33.22.11.in-addr.arpa, и тот вернёт соответствующее символьное имя. Обратный порядок записи частей IP-адреса объясняется тем, что в IP-адресах старшие биты расположены в начале, а в символьных DNS-именах старшие (находящиеся ближе к корню) части расположены в конце.
Ключевые характеристики DNS
DNS обладает следующими характеристиками:
- Распределённость администрирования. Ответственность за разные части иерархической структуры несут разные люди или организации.
- Распределённость хранения информации. Каждый узел сети в обязательном порядке должен хранить только те данные, которые входят в его зону ответственности и (возможно) адреса корневых DNS-серверов.
- Кеширование информации. Узел может хранить некоторое количество данных не из своей зоны ответственности для уменьшения нагрузки на сеть.
- Иерархическая структура, в которой все узлы объединены в дерево, и каждый узел может или самостоятельно определять работу нижестоящих узлов, или делегировать (передавать) их другим узлам.
- Резервирование. За хранение и обслуживание своих узлов (зон) отвечают (обычно) несколько серверов, разделённые как физически, так и логически, что обеспечивает сохранность данных и продолжение работы даже в случае сбоя одного из узлов.
DNS была разработана Полом Мокапетрисом в 1983 году; оригинальное описание механизмов работы содержится в RFC 882 и RFC 883. В 1987 публикация RFC 1034 и RFC 1035 изменила спецификацию DNS и отменила RFC 882, RFC 883 и RFC 973 как устаревшие.
Сопоставление имен
Также стоит пару слов сказать про процедуру обратного сопоставления – получение имени по предоставленному IP-адресу. Это происходит, например, при проверках сервера электронной почты. Существует специальный домен in-addr.arpa, записи в котором используются для преобразования IP-адресов в символьные имена. Например, для получения DNS-имени для адреса 11.22.33.44 можно запросить у DNS-сервера запись 44.33.22.11.in-addr.arpa, и тот вернёт соответствующее символьное имя.
Дополнительные возможности
- поддержка динамических обновлений
- защита данных (DNSSEC) и транзакций (TSIG)
- поддержка различных типов информации
Рекурсия
Термином Рекурсия в DNS обозначают алгоритм поведения DNS-сервера, при котором сервер выполняет от имени клиента полный поиск нужной информации во всей системе DNS, при необходимости обращаясь к другим DNS-серверам.
DNS-запрос может быть рекурсивным — требующим полного поиска, — и нерекурсивным (или итеративным) — не требующим полного поиска.
Аналогично, DNS-сервер может быть рекурсивным (умеющим выполнять полный поиск) и нерекурсивным (не умеющим выполнять полный поиск). Некоторые программы DNS-серверов, например, BIND, можно сконфигурировать так, чтобы запросы одних клиентов выполнялись рекурсивно, а запросы других — нерекурсивно.
При ответе на нерекурсивный запрос, а также — при неумении или запрете выполнять рекурсивные запросы, — DNS-сервер либо возвращает данные о зоне, за которую он ответствен, либо возвращает адреса серверов, которые обладают большим объёмом информации о запрошенной зоне, чем отвечающий сервер, чаще всего — адреса корневых серверов.
В случае рекурсивного запроса DNS-сервер опрашивает серверы (в порядке убывания уровня зон в имени), пока не найдёт ответ или не обнаружит, что домен не существует. (На практике поиск начинается с наиболее близких к искомому DNS-серверов, если информация о них есть в кэше и не устарела, сервер может не запрашивать другие DNS-серверы.)
Рассмотрим на примере работу всей системы.
В данном случае при разрешении имени, то есть в процессе поиска IP по имени:
- браузер отправил известному ему DNS-серверу рекурсивный запрос — в ответ на такой тип запроса сервер обязан вернуть «готовый результат», то есть IP-адрес, либо пустой ответ и код ошибки NXDOMAIN;
- DNS-сервер, получивший запрос от браузера, последовательно отправлял нерекурсивные запросы, на которые получал от других DNS-серверов ответы, пока не получил ответ от сервера, ответственного за запрошенную зону;
- остальные упоминавшиеся DNS-серверы обрабатывали запросы нерекурсивно (и, скорее всего, не стали бы обрабатывать запросы рекурсивно, даже если бы такое требование стояло в запросе).
Иногда допускается, чтобы запрошенный сервер передавал рекурсивный запрос «вышестоящему» DNS-серверу и дожидался готового ответа.
Рекурсивные запросы требуют больше ресурсов от сервера (и создают больше трафика), так что обычно принимаются от «известных» владельцу сервера узлов (например, провайдер предоставляет возможность делать рекурсивные запросы только своим клиентам, в корпоративной сети рекурсивные запросы принимаются только из локального сегмента). Нерекурсивные запросы обычно принимаются ото всех узлов сети (и содержательный ответ даётся только на запросы о зоне, которая размещена на узле, на DNS-запрос о других зонах обычно возвращаются адреса других серверов).
Кто управляет и поддерживает DNS-сервера?
Каждый из этих операторов предоставляет данную услугу бесплатно, а также обеспечивает бесперебойную работу, поскольку при отказе любого из этих серверов станут недоступны целые зоны интернета. Ранее корневые DNS-серверы, являющиеся основой для обработки всех запросов о доменных именах в интернете, располагались в Северной Америке. Однако с внедрением технологии альтернативной адресации они «распространились» по всему миру, и фактически их число увеличилось с 13 до 123, что позволило повысить надёжность фундамента DNS.
Например, в Северной Америке находятся 40 серверов (32,5%), в Европе – 35 (28,5%), еще 6 серверов располагаются в Южной Америке (4,9%) и 3 – в Африке (2,4%). Если взглянуть на карту, то DNS-серверы расположены согласно интенсивности использования интернет-инфраструктуры.
Записи DNS
Записи DNS, или Ресурсные записи (англ. Resource Records, RR) — единицы хранения и передачи информации в DNS. Каждая ресурсная запись состоит из следующих полей:
- имя (NAME) — доменное имя, к которому привязана или которому «принадлежит» данная ресурсная запись,
- TTL (Time To Live) — допустимое время хранения данной ресурсной записи в кэше неответственногоDNS-сервера,
- тип (TYPE) ресурсной записи — определяет формат и назначение данной ресурсной записи,
- класс (CLASS) ресурсной записи; теоретически считается, что DNS может использоваться не только с TCP/IP, но и с другими типами сетей, код в поле класс определяет тип сети [2] ,
- длина поля данных (RDLEN),
- поле данных (RDATA), формат и содержание которого зависит от типа записи.
Наиболее важные типы DNS-записей:
Защита от атак
Атаки на DNS – далеко не новая стратегия хакеров, однако только недавно борьба с этим видом угроз стала принимать глобальный характер.
«В прошлом уже происходили атаки на DNS-сервера, приводящие к массовым сбоям. Как-то из-за подмены DNS-записи в течение часа для пользователей был недоступен известный всем сервис Twitter, – рассказывает Алексей Шевченко, руководитель направления инфраструктурных решений российского представительства ESET. – Но куда опаснее атаки на корневые DNS-сервера. В частности, широкую огласку получили атаки в октябре 2002 года, когда неизвестные пытались провести DDoS-атаку на 10 из 13 DNS-серверов верхнего уровня».
Одним из вариантов может служить технология uRPF (Unicast Reverse Path Forwarding), идея которой заключается в определении того, может ли пакет с определенным адресом отправителя быть принят на конкретном сетевом интерфейсе. Если пакет получен с сетевого интерфейса, который используется для передачи данных, адресованных отправителю этого пакета, то пакет считается прошедшим проверку. В противном случае он отбрасывается.
Несмотря на то что, данная функция может помочь обнаружить и отфильтровать некоторую часть поддельного трафика, uRPF не обеспечивает полную защиту от подмены. uRPF предполагает, что прием и передача данных для конкретного адреса производится через один и тот же интерфейс, а это усложняет положение вещей в случае нескольких провайдеров. Более подробную информацию о uRPF можно найти здесь.
Еще один вариант – использование функции IP Source Guard. Она основывается на технологии uRPF и отслеживании DHCP-пакетов для фильтрации поддельного трафика на отдельных портах коммутатора. IP Source Guard проверяет DHCP-трафик в сети и определяет, какие IP-адреса были назначены сетевым устройствам.
После того как эта информация была собрана и сохранена в таблице объединения отслеживания DHCP-пакетов, IP Source Guard может использовать ее для фильтрации IP-пакетов, полученных сетевым устройством. Если пакет получен с IP-адресом источника, который не соответствует таблице объединения отслеживания DHCP-пакетов, то пакет отбрасывается.
Также стоит отметить утилиту dns-validator, которая наблюдает за передачей всех пакетов DNS, сопоставляет каждый запрос с ответом и в случае несовпадения заголовков уведомляет об этом пользователя. Подробная информация доступна в репозитории на GitHub.
Заключение
Постоянно ведутся работы по повышению надежности, чтобы сделать систему менее чувствительной к сбоям (стихийные бедствия, отключения электросети и т. д.), и это очень важно, поскольку интернет стал неотъемлемой частью нашей жизни, и «терять» его, даже на пару минут, совершенно не хочется.
Кстати, компания 1cloud предлагает своим пользователям VPS бесплатную услугу «DNS-хостинг» – инструмент, упрощающий администрирование ваших проектов за счет работы с общим интерфейсом для управления хостами и ссылающимися на них доменами.
Работа DNS в сети интернет
В настоящее время интернет окружает нас повсюду — мы используем его в мобильных и настольных устройствах. Системы видеонаблюдения и даже чайники взаимодействуют друг с другом с помощью интернета, и для корректной связи с ними нужна система, с помощью которой пользователи смогут одним запросом в адресной строке подключиться к нужному сервису. Всё это ложится на плечи системы DNS, которая внутри себя хранит намного больше информации, чем просто IP-адрес и название устройств. Записи в DNS также отвечают за корректную отправку электронных писем, связывают друг с другом разные домены и доменные зоны.
DNS является распределённой системой, а значит она имеет множество узлов, каждый из которых ответственен за свою зону. Такое возможно благодаря тому, что сама по себе структура DNS является иерархической, то есть выделяет зоны ответственности, где каждый родитель знает о расположении своего дочернего сервера, и знает зону его ответственности.
Рассмотрим работу DNS и её составных частей поближе.
Ресурсные записи DNS
Рассмотрим, какие ресурсные записи используются, и на что они указывают. Основными ресурсными записями DNS являются:
A-запись — одна из самых важных записей. Именно эта запись указывает на IP-адрес сервера, который привязан к доменному имени.
MX-запись — указывает на сервер, который будет использован при отсылке доменной электронной почты.
NS-запись — указывает на DNS-сервер домена.
TXT-запись — в этой записи хранится текстовая информация о домене. Часто используется для подтверждения прав на владение доменом, посредством добавления определённой строки, которую присылает нам интернет-сервис.
Ресурсные записи почти всегда одинаковые, но для некоторых записей могут появляться другие поля, например в MX-записях также присутствует значение приоритета. В основном ресурсные записи имеют следующую структуру:
Имя записи — указывается домен, которому принадлежит данная ресурсная запись.
TTL (time to live / время жизни) — время в секундах, на которое будет закешировано значение ресурсной записи. Это необходимо для разгрузки DNS-серверов. Благодаря кешированию и возможна ситуация, что ближайший DNS-сервер знает IP-адрес запрашиваемого домена.
Класс — предполагалось, что DNS может работать не только в сети интернет, поэтому в записи указывается и её класс. На сегодняшний день поддерживается только одно значение — IN (Internet).
Тип — указывает тип ресурсной записи, основные из которых были разобраны выше.
Значение — непосредственно значение ресурсной записи. В зависимости от типа ресурсной записи значения могут быть представлены в разном виде.
Утилита dig является DNS-клиентом и входит в состав одного из самых распространённых DNS-серверов BIND.
Терминология и принципы работы
Ключевыми понятиями DNS являются:
Система DNS содержит иерархию DNS-серверов, соответствующую иерархии зон. Каждая зона поддерживается как минимум одним авторитетным сервером DNS (от англ. authoritative — авторитетный), на котором расположена информация о домене.
Имя и IP-адрес не тождественны — один IP-адрес может иметь множество имён, что позволяет поддерживать на одном компьютере множество веб-сайтов (это называется виртуальный хостинг). Обратное тоже справедливо — одному имени может быть сопоставлено множество IP-адресов: это позволяет создавать балансировку нагрузки.
Для повышения устойчивости системы используется множество серверов, содержащих идентичную информацию, а в протоколе есть средства, позволяющие поддерживать синхронность информации, расположенной на разных серверах. Существует 13 корневых серверов, их адреса практически не изменяются. [1]
Выводы
DNS-сервера сейчас составляют основу всего интернета и используются почти в каждом действии пользователя в сети, будь то переход на сайт, отправка электронной почты, работы с интернет-приложением на телефоне и так далее. Поэтому знания о принципах работы DNS-серверов и основных ресурсных записях, благодаря которым и возможно перемещение по сети интернет, являются важными для разработчика.
В очередном «конспекте админа» остановимся на еще одной фундаментальной вещи – механизме разрешения имен в 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-курьезы из собственной практики – поделитесь в комментариях.
Являясь провайдером виртуальной инфраструктуры, компания 1cloud интересуется сетевыми технологиями, о которых мы регулярно рассказываем в своем блоге. Сегодня мы подготовили материал, затрагивающий тему доменных имен. В нем мы рассмотрим базовые аспекты функционирования DNS и вопросы безопасности DNS-серверов.
/ фото James Cridland CC
Изначально, до распространения интернета, адреса преобразовывались согласно содержимому файла hosts, рассылаемого на каждую из машин в сети. Однако по мере её роста такой метод перестал оправдывать себя – появилась потребность в новом механизме, которым и стала DNS, разработанная в 1983 году Полом Мокапетрисом (Paul Mockapetris).
Подключение
Необходимо понимать, что доменное имя — это всего лишь абстракция для людей. Сам компьютер и приложения (например, браузер) обращается к сервисам внутри сети интернет только по IP-адресам.
Рассмотрим процесс получения IP-адреса по доменному имени на примере домена ru.hexlet.io .
Возможны два варианта событий:
Компьютер посылает запрос на известный ему DNS-сервер. Чаще всего им является DNS-сервер поставщика интернет-услуг (провайдера): какой IP-адрес у домена ru.hexlet.io?. DNS-сервер провайдера находит в своей базе информацию о том, что домен ru.hexlet.io расположен по IP-адресу 104.25.238.104 и возвращает значение нашему компьютеру. Этот процесс похож на то, как использовался файл hosts.txt .
Ближайший известный DNS-сервер не имеет записи о том, по какому IP-адресу располагается домен ru.hexlet.io . В таком случае запускается цепочка процессов, благодаря которым наш компьютер получит IP-адрес домена:
Так как домен является иерархической структурой, и все DNS-сервера знают IP-адреса корневых DNS-серверов, то к ним и происходит запрос на получение IP-адреса домена.
Корневые DNS-сервера, в соответствии со своей зоной ответственности знают о том, где располагаются DNS-сервера доменов верхнего уровня. Эти адреса возвращаются DNS-серверу нашего провайдера, после чего на нужный DNS-сервер (в нашем случае на DNS-сервер домена .io) посылается запрос на получение IP-адреса домена ru.hexlet.
В соответствии со своей зоной ответственности DNS-сервер домена верхнего уровня возвращает IP-адрес DNS-сервера домена hexlet, на который посылается запрос на получение IP-адреса поддомена ru.
DNS-сервер возвращает IP-адреса поддомена ru, после чего DNS-сервер нашего провайдера возвращает полученный адрес на наш компьютер, который уже может обратиться к домену ru.hexlet.io по его IP-адресу.
Содержание
Рекурсия в DNS
Можно заметить, что оба описанных выше варианта сильно различаются: в первом случае мы просто послали запрос и получили ответ, а во втором — возникла необходимость идти от самого корневого домена в процессе поиска нужной нам записи. Такой процесс является рекурсивным, потому что ближайший DNS-сервер непрерывно посылает запросы к другим DNS-серверам до тех пор, пока не получит необходимые ресурсные записи. Данный процесс можно визуализировать следующим образом:
При запросах 1 и 2 ближайший сервер будет получать информацию о местонахождении DNS-серверов, которые входят в зону ответственности того сервера, на который был послан запрос. При запросе 3 будут получены необходимые ресурсные записи домена hexlet и его поддоменов.
Рекурсивный поиск — это достаточно долгая операция, которая к тому же сильно нагружает сеть и сами DNS-сервера. Именно для того, чтобы избавиться от рекурсии каждый DNS-сервер кеширует информацию о записях, которые получает, для быстрой отдачи этой информации пользователю.
Как видно, рекурсивный поиск предполагает нахождение конечного ответа на наш запрос путём поиска записи по всем необходимым DNS-серверам, начиная с корневого. В противовес такому способу также существует итеративный запрос, который в отличие от рекурсивного выполняет всего лишь одну итерацию — это запрос ближайшему DNS-серверу, от которого мы можем получить как закешированный ответ, так и данные той зоны, за которую он ответственен. Важно отметить, что итеративный запрос предполагает всего один такой запрос.
Чаще всего в интернете DNS-сервера умеют посылать рекурсивные запросы, потому что в таком случае ответ можно закешировать, что в дальнейшем позволит снизить нагрузку как на сам сервер, так и на другие DNS-сервера. Время, на которое DNS-сервер кеширует информацию, указывается в ресурсной записи DNS, о которой сейчас пойдёт речь.
Зарезервированные доменные имена
Интернациональные доменные имена
Доменное имя может состоять только из ограниченного набора ASCII символов, позволяя набрать адрес домена независимо от языка пользователя. ICANN утвердил основанную на Punycode систему IDNA, преобразующую любую строку в кодировке Unicode в допустимый DNS набор символов.
Вы когда-нибудь задавались вопросом, как браузер понимает, какую именно страницу открыть, когда вы вводите в строку адрес сайта? На самом деле, это глубокий вопрос, решать который стоит не непосредственно с перехода на сайты, а со связи компьютеров между собой.
В 70-х — 90-х годах 20 века существовала сеть под названием ARPANET. Это была попытка объединить множество компьютеров министерством обороны США для возможности передачи информации во время войны. Важность такого подхода заключалась в быстрой передаче информации на дальние расстояния. Впоследствии принципы работы ARPANET легли в основу современного интернета.
Изначально вся сеть объединяла компьютеры в четырёх различных институтах США:
- Калифорнийский университет в Лос-Анджелесе;
- Стэнфордский исследовательский центр;
- Университет Юты;
- Калифорнийский университет в Санта-Барбаре.
В самом начале компьютеров, подключённых к сети, было несколько десятков, и их идентификаторы было легко запомнить. Можно было записать эти адреса в блокнот и использовать его так же, как и телефонные книги.
Время шло, и уже к середине 80-х годов вместо нескольких десятков компьютеров сеть стала насчитывать несколько тысяч. И каждый из них имел уникальный идентификатор, который становилось всё сложнее учитывать вручную или запоминать. Необходима была система, которая позволит очеловечить имена компьютеров и хранить все адреса в одном месте, чтобы каждый компьютер в сети имел один и тот же набор всех идентификаторов.
Что такое DNS?
Система доменных имен (DNS) является одной из фундаментальных технологий современной интернет-среды и представляет собой распределенную систему хранения и обработки информации о доменных зонах. Она необходима, в первую очередь, для соотнесения IP-адресов устройств в сети и более удобных для человеческого восприятия символьных имен.
DNS состоит из распределенной базы имен, чья структура напоминает логическое дерево, называемое пространством имен домена. Каждый узел в этом пространстве имеет свое уникальное имя. Это логическое дерево «растет» из корневого домена, который является самым верхним уровнем иерархии DNS и обозначается символом – точкой. А уже от корневого элемента ответвляются поддоменые зоны или узлы (компьютеры).
Пространство имен, которое сопоставляет адреса и уникальные имена, может быть организовано двумя путями: плоско и иерархически. В первом случае имя назначается каждому адресу и является последовательностью символов без структуры, закрепленной какими-либо правилами. Главный недостаток плоского пространства имен – оно не может быть использовано в больших системах, таких как интернет, из-за своей хаотичности, поскольку в этом случае достаточно сложно провести проверку неоднозначности и дублирования.
Пример реальных записей DNS
Не пугайтесь такого длинного вывода. Уже сейчас можно понять почти всё, что тут указано. Разберём вывод каждой секции более детально.
Вывод состоит из нескольких частей:
- Шапка
- Секция запроса
- Секция ответа
- Служебная информация
Шапка запроса
Секция запроса
В секции запроса указывается домен, к которому происходит обращение, класс записи и те записи, которые мы хотим получить. ANY указывает на то, что нужно вывести все доступные ресурсные записи, но если вы хотите поэкспериментировать с утилитой сами, то можете с помощью специального ключа получить вывод только конкретных записей, которые интересуют в настоящий момент.
Секция ответа
Секция ответа достаточно большая, поэтому для удобства разобьём её по типам ресурсных записей.
Как запись A, так и AAAA-запись указывают на IP-адрес, который привязан к нашему домену. A-запись указывает IP в формате IPv4, а запись AAAA — в формате IPv6.
MX-запись также имеет параметр приоритета. Так как серверов для отправки почты может быть несколько, то и записей может быть много, поэтому для определения основного сервера указывается приоритет записи. Чем меньше число, тем выше приоритет.
Запись SOA (Start of Authority) указывает на несколько различных параметров:
- Сервер с эталонной информацией о текущем домене
- Контактную информацию ответственного лица
- Различные параметры кеширования записей
Бывают и некоторые более специфичные ресурсные записи, о которых здесь не было речи, но это не значит, что они бесполезны. Полный перечень таких записей всегда можно найти в документации (например по DNS-серверу BIND).
Читайте также: