- Подписка на печатную версию:
- Подписка на электронную версию:
- Подшивки старых номеров журнала (печатные версии)
LXF141:DrBrown2
Материал из Linuxformat.
Содержание |
Что в имени нам... домена?
- DNS Узнаем, как DNS находит иголку в стоге сена.
В самом начале эры межсетевого взаимодействия разрешение имени – преобразование имени компьютера в IP-адрес – осуществлялось путем поиска имени в файле hosts.txt. Файл хранился на одном компьютере и копировался оттуда на все остальные. Когда компьютеров было несколько сотен и их количество росло, скажем, на дюжину в день, схема работала прекрасно. Но на современный Интернет с миллиардом – или около того – компьютеров ее распространить нельзя. (Чтобы немного прояснить масштаб, скажу, что, согласно сайту http://www.eurid.eu, в домене .eu появилось 280 новых записей только за последний час.) Чтобы с этим справиться, нужна распределенная база данных, а имена компьютеров следует организовать в древовидную структуру, допускающую эффективный поиск. Так появилась DNS, или система доменных имен (Domain Name System).
Если в Интернете и есть невоспетый герой, то это DNS. Что в ней героического? А то, что большая часть задачи поиска капли в море Интернета лежит на DNS. Изо всех глубинных технологий Интернета эта самая глубинная. А почему герой не воспет? Потому что в отличие от web-, почтовых или FTP-серверов, у DNS нет клиентской части, о которой знают конечные пользователи. Все это, как мы увидим, происходит за кулисами.
На нашем уроке мы разберемся, как работает DNS, исследуем небольшую часть ее пространства имен, посмотрим, как на самом деле выглядит «клиент» DNS, и выясним, как его настроить.
Работа DNS целиком основана на организации имен компьютеров в древовидную структуру, фрагмент которой показан на рисунке. Листья этого дерева – имена вроде http://www.linuxformat.co.uk. Такие имена называются полностью определенными именами домена (FQDN), и они очень похожи на полные пути к файлам в Linux, за исключением двух моментов. Во-первых, в DNS части имени разделяются точкой ., тогда как части пути – слэшем /. Во-вторых, имена в DNS записываются «от младшего к старшему» – менее значимая часть адреса идет первой, а имена файлов записываются «от старшего к младшему». Мы привыкли к такому порядку, поскольку так в мире записывают обычный почтовый адрес: номер дома, улица, город, страна. [А у нас строго наоборот]
Посмотрим, что происходит, когда вы открываете в браузере http://www.linuxformat.co.uk. Компьютеру нужно преобразовать FQDN в IP-адрес. Если это домашний компьютер, он, вероятно, отправляет запрос на DNS-сервер, запущенный на модеме/маршрутизаторе, который предоставляет вам широкополосное подключение. Тот в свою очередь направляет запрос другому DNS-серверу, вероятно, запущенному у вашего провайдера (см. рисунок). Тут начинается Маленькая Хитрость™. Этот DNS-сервер начинает опрашивать корневые сервера имен и получает ссылку на DNS-сервер, у которого есть информация о домене uk. Процесс получения ссылок на серверы, находящиеся ниже в иерархии имен, продолжается, пока не находится сервер, способный разрешить запрос и предоставить запрашиваемый IP-адрес. Если вы хотите увидеть настоящий маршрут этого процесса, выполните команду
dig +trace www.linuxformat.co.uk
На практике этот маршрут заметно сокращается, так как серверы DNS кэшируют результаты последних запросов и ответ на запрос часто находится в кэше. И если я зайду на один и тот же сайт дважды, во второй раз запрос не уйдет дальше моего локального DNS-сервера. На самом деле, при подключении к web-серверу браузеры часто используют собственный кэш, который ведут сами.
Древовидная структура имен DNS также способствует иерархическому делегированию полномочий выбора имен, гарантируя, что FQDN-имена останутся уникальными. Например, научной общественности Великобритании по сути говорят: «Называйте свои компьютеры как угодно, но имя должно заканчиваться на .ac.uk». Передавая полномочия на уровень ниже, Кембриджскому университету говорят: «Называйте свои компьютеры как угодно, но имя должно заканчиваться на .cam.ac.uk»; и т. д.
Исходные материалы DNS называются записями ресурсов. Я описал функционирование DNS на основе поиска имени компьютера и возвращения IP-адреса. Эта информация хранится в записях ресурсов типа A. DNS поддерживает и записи других типов, для различных целей. Некоторые из них приведены ниже:
- Записи A Преобразуют имена компьютеров в адреса формата IPV4.
- Записи AAAA Преобразуют имена компьютеров в адреса формата IPV6. Ожидается, что они получат большее распространение в будущем.
- Записи MX Задают имена почтовых серверов, используемых указанным доменом для обработки почты.
- Записи NS Эти записи задают сервера имен для указанного домена.
- Записи PTR Используются в основном для обратных запросов – преобразования IP-адресов в имена компьютеров.
- Записи CNAME Эти просто перенаправляют на другое имя компьютера; нечто вроде алиаса.
Обратные запросы
Как мы видим, DNS разработана в основном для связывания доменных имен с IP-адресами. Однако иногда ей приходится выполнять обратное преобразование – из IP-адресов в имена компьютеров. Этот процесс называется обратным запросом DNS и может понадобиться, например, если сервис использует политику управления доступом на основе доменного имени компьютера клиента. Обычная иерархия доменных имен не подходит для этой цели: чтобы найти запись A, содержащую заданный IP-адрес, придется обыскать целое пространство имен, это совершенно нереальное предложение.
Для разрешения обратных запросов существует отдельное дерево имен со специальным именем домена in-addr.arpa. Это дерево разветвляется на четыре уровня, соответствующих четырем так называемым октетам IP-адреса, как показано ниже. Каждому из возможных IP-адресов соответствует узел на нижнем уровне этого дерева. На рисунке показано положение узла для адреса 80.244.178.150. Если прочесть доменное имя этого узла «от младшего к старшему», мы получим 150.178.244.80.in-addr.arpa, в котором октеты IP-адреса идут в обратном порядке.
Эти прямое и обратное пространство имен, предположительно, абсолютно не зависят друг от друга, но на практике небольшое соответствие есть, так как компьютеры в одной и той же IP-подсети по всей вероятности находятся в одном домене.
Клиентская сторона DNS
Хотя имеются утилиты вроде dig и nslookup, пригодные на роли клиентов DNS, на практике они используются только для диагностики. Истинная клиентская сторона DNS скрыта в наборе библиотечных процедур, называемых преобразователями адресов – функций с такими именами, как getaddrinfo() и gethostbyname().
В Linux эти преобразователи адресов могут получать информацию из различных источников, включающих:
- Локальный файл /etc/hosts.
- Сервер имен в локальной сети, такой как NIS или LDAP.
- DNS.
Чтобы узнать, к каким источникам обратиться, преобразователи имен сначала читают так называемый файл выбора сервиса имен /etc/nsswitch.conf, где они надеются разыскать следующую строку:
hosts: files dns
Записи в этом файле ссылаются прямо на имена библиотек, которые знают, как работать с каждым источником. Например, запись “'files” велит преобразователю использовать библиотеку libnss_files, запись “dns” – библиотеку libnss_dns, как показано на рисунке ниже. В случае DNS есть второй файл, который скажет преобразователям, где находятся серверы DNS. Это файл /etc/resolv.conf. Там вы найдете одну или несколько директив nameserver, которые задают адреса серверов имен в количестве до трех, например:
nameserver 192.168.1.254
Если ваш компьютер получает сетевые настройки по DHCP или для работы с его сетевыми интерфейсами используется Network-Manager, этот файл будет заполнен автоматически. Однако для компьютеров со статическими настройками сети вам может понадобиться изменить файл вручную.
Хитрости DNS
С помощью DNS можно дешево и сердито распределить нагрузку вкруговую [round-robin]. С несколькими записями в DNS для одного и того же FQDN, указывающими на различные IP-адреса, DNS выберет из списка совершенно случайный компьютер. Попробуйте попинговать http://pool.ntp.org, каждый раз отмечая пингуемый IP-адрес, и вы поймете, как это работает.
DNS также выступает как соучастник в виртуальном хостинге – иллюзии, при которой создается видимость наличия нескольких web-серверов, тогда как несколько сайтов на самом деле находятся на одном компьютере (с одним и тем же IP-адресом). Это почти полная противоположность ситуации с round-robin, так как теперь в DNS есть несколько FQDN, указывающих на один и тот же IP-адрес. Например, записи A для обоих адресов http://www.linuxformat.co.uk и http://www.tuxradar.co.uk указывают на IP-адрес 80.244.178.150.
Записи NS
DNS выдает обильную информацию о своей структуре; в основном ее можно раскопать командой dig. Для начала, добудем список корневых серверов имен, запросив NS-записи для домена .:
$ dig ns . ;; QUESTION SECTION: ;. IN NS ;; ANSWER SECTION: . 105306 IN NS a.root-servers.net. . 105306 IN NS b.root-servers.net. . 105306 IN NS c.root-servers.net. ;; ADDITIONAL SECTION: b.root-servers.net 52989 IN A 192.228.79.201 c.root-servers.net 400119 IN A 192.33.4.12 d.root-servers.net 54917 IN A 128.8.10.90
Я сократил вывод этой команды. На самом деле, есть 13 корневых серверов имен с именами от a до m. Физических серверов на самом деле гораздо больше тринадцати – под многими из этих имен скрывается множество серверов, находящихся на различных континентах. Все, что делают корневые серверы – выдают списки DNS-серверов для доменов верхнего уровня. Хотя они критичны для работы DNS, их нельзя назвать узким местом схемы, прежде всего потому, что другие DNS-серверы кэшируют информацию, предоставляемую корневыми серверами.
Интересно взглянуть и на записи NS и для других доменов. Например, вот список серверов имен для Кембриджского университета, тоже полученный по команде dig:
$ dig ns cam.ac.uk ;; QUESTION SECTION: ;cam.ac.uk. IN NS ;; ANSWER SECTION: cam.ac.uk. 81899 IN NS authdns0.csx.cam.ac.uk. cam.ac.uk. 81899 IN NS authdns1.csx.cam.ac.uk. cam.ac.uk. 81899 IN NS bitsy.mit.edu. cam.ac.uk. 81899 IN NS dns0.eng.cam.ac.uk. cam.ac.uk. 81899 IN NS dns1.cl.cam.ac.uk. cam.ac.uk. 81899 IN NS ns2.ic.ac.uk. cam.ac.uk. 81899 IN NS dns0.cl.cam.ac.uk.
(Эту информацию также можно получить с помощью команды whois cam.ac.uk.) Вы видите, что хотя большинство этих серверов и вправду находятся в обслуживаемых доменах, два из них тем не менее не там. Это серверы в Массачусетском технологическом институте и Имперском колледже Лондона (ic.ac.uk). А если рассмотреть серверы имен для Имперского колледжа, вы обнаружите, что один из них сидит в Кембридже. Взаимный обмен серверами между университетами – довольно распространенное явление.
Так что в следующий раз, когда зайдете на Facebook отправить почту, вспомните о DNS – невоспетом герое сети.
Кэширование
Многие компоненты DNS, включая серверы-заглушки [stub] DNS и преобразователи адресов, кэшируют результаты, полученные из предшествующих запросов. Кэширование резко снижает количество проходящего большие расстояния DNS-трафика, но из-за него DNS сравнительно медленно реагирует на изменения, потому что обновления не будут распространяться, пока не истечет срок обновления записей в кэше. Максимальное время, в течение которого результат должен храниться в кэше, задается в поле Time To Live в самих записях ресурсов. Некоторые из этих значений (в секундах) можно увидеть в примерах работы команды dig, приведенных на этом уроке. Обычно это величина порядка 24 часов.
Домены верхнего уровня
Существует около двадцати общих доменов верхнего уровня в стиле .com и .edu. Доступ к некоторым, включая .mil и .gov, сильно ограничен; другие, такие как .org, .com и .net более открыты. Существует более двухсот двухбуквенных доменов для названий стран, таких как .fr (Франция) и .ca (Канада). Эти двухбуквенные коды определены в стандарте ISO 3166‑1 alpha-2, но есть и известные исключения: Великобритания использует домен .uk, хотя официальный код страны gb, а Европейский союз .eu – вовсе не страна!
Некоторые домены «подрабатывают» на «суетности». Например, Тувалу, страна площадью около десяти квадратных километров с буквенным кодом tv, договорилась с Verisign о продаже доменов .tv телекомпаниям, а .fm (выданный Федеративным Штатам Микронезии) часто используется радиостанциями.