Администрирование #05. DNS.
Я опять, как и в статье про DHCP, постараюсь идти от сильного упрощения к менее сильному упрощению. Статья ориентирована на уровень студентов и начинающих админов. Я не буду затрагивать вопросы безопасности или конкретной реализации, но постараюсь затронуть те вопросы, которые «проскакивают», либо вовсе игнорируют популярные статьи типа «что такое DNS».
Часть 1. История.
Наиболее увлекательное художественное описание того, как всё начиналось, доступно в rfc1034.
В давние времена, когда сети были маленькими, а компьютеры большими, кто-то заметил, что, во-первых, IP-адреса запоминать не очень удобно (гораздо удобнее слова, которые имеют смысл), а во-вторых, надо бы как-то обозначать один объект с несколькими сетевыми адресами.
«Давай запишем в текстовый файл соответствия сетевых адресов и понятных человеку имён» - сказал кто-то.
«А давайте!» - ответили остальные.
Сейчас вы можете найти файл «hosts» у себя на компьютере и посмотреть в него – почти так всё и было. Люди запоминали имя, запрашивали по имени ресурс. Система смотрела в файлике соответствие имени и сетевого адреса и возвращала по имени адрес. За файлик назначили ответственного, он вносил туда изменения и раздавал через файлообменник свежую версию всем желающим.
А потом сеть стала расти. Файлик стал очень большой и грозил увеличиваться дальше стремительными темпами, долго скачивался (потому что каналы передачи данных были узкие), поиск по файлу становился затрудненным, изменения вносились не сразу (у ответственного бывает выходной, праздник и болеющий ребенок), а еще корпорациям хотелось иметь свой файлик с шахматами и поэтессами внутренними ресурсами, недоступный никому извне.
«Идите в жопу» - сказал ответственный.
«Вот дерьмо, как же быть?» - подумали остальные.
И придумали DNS – Domain Name System – систему доменных имён. Люди были не дураки. Они подумали: «если мы уж внедряем такую сложную систему, на которую потребуется выделить бабло, давайте запихаем туда всё, связанное с именованием ресурсов!». И запихнули.
Что получилось. Общий смысл остался – по имени возвращается адрес. Теперь доменное имя стало состоять из частей, разделенных точкой (Например, pikabu.ru) и за каждую часть (домен определенного уровня иерархии, уровни нумеруются справа налево) стал отвечать свой сервер имён со своим персональным ответственным (на самом деле, всё немного сложнее, разберем в следующих частях). Система стала распределенной и иерархической. Запрос адреса по имени стало возможным разбить на части, и, пройдясь по цепочке серверов имён, найти нужный с нужным ответом. Каждый ответственный теперь мог менять свой кусочек информации, независимо от остальных. В зависимости от настроек, эта информация становилась доступной для всех через некоторое время. К записи о домене добавили дополнительную информацию: информацию о почтовых серверах, о доступных ресурсах, о псевдонимах, служебную информацию и т.д. Корпорации теперь могли делать так, что изнутри на запрос отвечал один сервер имён, а снаружи компании на тот же самый запрос отвечал другой сервер и возвращал другой адрес.
Сформулируем, зачем нужен DNS:
1) Чтобы при вводе имени сайта, например, pikabu.ru, в браузере, система могла понять, на какой сетевой адрес «стучаться»
2) Чтобы при вводе синонима имени сайта www.pikabu.ru, система могла понять, что это имя всё равно, что pikabu.ru
3) Чтобы когда вы отсылаете письма с яндекса на gmail, сервер яндекса знал, на какой сетевой адрес отправить письмо, то есть, где искать почтовый сервер gmail’a
4) Чтобы в ответ, почтовый сервер gmail мог проверить, что адрес, с которого пришло письмо, принадлежит почтовому серверу яндекса.
5) Чтобы при каких-либо проблемах с данной системой, можно было узнать контакты ответственного лица и связаться с ним
«А давайте будем брать за запись о домене деньги?» - подумал кто-то хваткий. И в чьих-то глазах зажглись зеленые искры в виде долларов. Но это уже совсем другая история.
Часть 2. Домен, зона и другие страшные слова.
Отойдём от абстракций и перейдем к конкретике. Зона – это набор ресурсных записей домена, то есть, фактически – это информация о домене и вся та сопутствующая лабуда, о которой мы говорили в части 1. Причем, заметьте, домен в нашем случае, это не «pikabu», а именно «pikabu.ru», так как, скажем, «pikabu.net» - это уже совсем другой домен. Это как директория «помойка» может лежать у вас как на диске C:\, так и на диске D:\ и это будут две разные директории. Зона может быть текстовым файликом или записью в базе данных сервера имён.
Выглядит, примерно так (мне не жалко):
@ означает подставить имя домена целиком
Ресурсная запись (Resource Record – RR) - собственно, информация о некотором ресурсе- состоит из нескольких полей: Владелец, Тип, Класс, TTL, данные. Владелец – это домен, к которому запись относится. Тип может быть одним из стандартных (например, A, AAAA, MX, NS, SOA, TXT и т.д.). Класс раньше разделял записи для Интернет и для других сетей, сейчас, вроде, используется только IN для Интернет. TTL – время, на которое запись разрешено закэшировать резолверу (рекурсивному кэширующему серверу, см. Часть 3). Ну и данные – собственно нужная информация, формат которой зависит от типа записи.
Запись SOA (Start Of Authority) – это начальная запись зоны и она должна быть обязательно, потому остановимся на ней подробнее. В ней содержится целый ряд полей:
- Первичный (Primary) DNS-сервер для некоторой зоны — DNS-сервер, на котором хранится полная исходная информация об этой зоне.
- e-mail ответственного лица
- serial – серийный номер зоны. Фактически, это номер изменения файла зоны. Если у главного DNS-сервера, отвечающего за зону, есть подчиненные сервера, то они периодически сравнивают номер копии зоны у себя с номером на главном сервере. Если на главном номер больше – подчиненные сервера обновляют у себя зону.
- refresh – это то, как часто подчиненные сервера будут пытаться обновить зону
- retry – это то, как часто подчиненные сервера будут пытаться обновить зону, если в первый раз произошла ошибка (например, главный сервер был недоступен)
- expire – то, сколько времени подчиненный сервер может считать информацию о зоне актуальной, если главный сервер ему так и не ответил
- TTL – мы уже говорили – на сколько можно закэшировать запись.
NS – записи содержат сведения о DNS-серверах, где хранится информация о зоне (их может быть больше одного).
А – запись связывает имя с IPv4 адресом. Кстати, если сделать несколько записей с одним именем, но разными адресами, то в ответах они будут чередоваться (чаще всего по алгоритму round robin) – поэкспериментируйте на pikabu.ru и его трех адресах ;)
MX – записи определяют имена почтовых серверов для данного домена (а чтобы узнать их адреса, на почтовые сервера должны быть А-записи в соответствующем домене). Эти записи примечательны тем, что у них есть приоритет (чем меньше приоритет – тем главнее сервер, равный приоритет – распределение нагрузки).
Чуть позже рассмотрим еще PTR записи. Ну а про остальные, если интересно, можно прочитать в вики.
Часть 3. Как идёт запрос.
Пока у нас есть куча не особо связанных между собой кусков. Сейчас определим еще пару понятий и попробуем посмотреть, как система работает в целом. Вообще, у кого английский хоть на базовом уровне, советую посмотреть зашибенный комикс в шести частях + бонус.
Вы уже поняли, что в системе есть DNS-сервера – сервера имён, на которых хранятся файлы зон. Есть клиенты, которые пытаются узнать адрес по имени (браузер, в котором мы шароебимся по сайтикам, например).
DNS-сервера бывают рекурсивными (которые могут пройтись по всей цепочке и вернуть готовый ответ) и нерекурсивными (которые возвращают информацию о DNS-серверах, ответственных за следующую зону). А еще DNS-сервера бывают кэширующими (которые на время запоминают те ответы, которые через них проходят) и некэширующими (угадайте..).
Вспоминаем, что система DNS иерархическая. У этой иерархии есть вершина (или корень) – корневая зона, за которой зарезервировано нулевое имя, и за которую отвечают корневые сервера. Эта зона невидимо присутствует во всех доменных именах - на самом деле, все они заканчивают на точку-ничего (можно посмотреть на первую картинку с файлом зоны и увидеть эти точки). Корневые сервера содержат информацию о доменах первого уровня (ru, com, net и т.д.). Этих серверов всего 13 штук (но физически их гораздо больше – резервирование, распределение нагрузки, всё такое). Почему 13? Так исторически сложилось: тогда максимальное количество данных в пакете было 512 байт и туда влезало только 13 записей. Корневые сервера нерекурсивные и некэширующие, кстати.
И сейчас я кратенько перескажу тот самый комикс. Итак, вы вводите в своем любимом браузере адрес любимого сайта pikabu.ru – что же происходит с точки зрения DNS?
1) Браузер роется у себя в кэше – может, вы недавно уже заходили на пикабу и он это еще помнит. Если нет, идем дальше.
2) Потом браузер обращается с животрепещущим вопросом «где же pikabu.ru?» к операционной системе. Она проверяет в своём кэше (может, вы недавно пинговали пикабу?) и в файлике hosts. Если не нашла, передает вопрос тому серверу, который у вас указан на компьютере в качестве DNS.
3) Этот сервер, обычно, сервер провайдера, кэширующий и рекурсивный. То есть, он вернет вам адрес сайта или ошибку. Сначала он проверяет свой кэш (может, ваш сосед по общаге только что запрашивал пикабу?). А еще смотрит в своих зонах (может, он за пикабу и отвечает?). Если ничего не находит, этот сервер начинает собирать ответ, используя нерекурсивные запросы.
4) Первым делом, запрос отправляется на ближайший корневой сервер (вру, там еще есть манипуляции с кэшем, но мы их опустим - пусть ничего нигде не найдено). Адреса корневых серверов известны и меняются очень редко, так что они просто забиты руками во все DNS-сервера. Корневой сервер отвечает, что он в душе не знает адреса «pikabu.ru», но вот тебе список серверов, отвечающих за «ru». Кстати, возвращает он имена и «приклеенные» ip-адреса, а то вы могли бы зациклится в своих запросах.
Кстати, слышали, что rpin вроде как передает права на управление зоной ru Ростелекому?
5) Ок, наш сервер сохранил инфу в кэше (и теперь за всеми сайтами, заканчивающимися на .ru будет обращаться уже к этим серверам). Берет верхний сервер из списка и спрашивает его, где же «pikabu.ru»? Ему отвечают списком из трех адресов, он возвращает верхний операционной системе. Все счастливы, все прописали себе в кэш, что могли, подключаемся к этому IP-адресу и читаем пикабу.
Часть 4. Обратная зона.
Случается так, что нам нужна обратная процедура: не по имени узнать адрес, а по адресу имя. Такие запросы, в частности, используют почтовые сервера, чтобы бороться со спамом. То есть, приходит нам письмо от vasya@gaza.net, например, с адреса 1.23.45.6. И мы хотим узнать, а правда ли адрес 1.23.45.6 является адресом почтового сервера этого домена. Для этого нам надо получить имя по адресу 1.23.45.6 и сравнить его с MX-записью домена (кто заморачивается почтовиками, почитайте еще про spf обязательно).
Для преобразования ip-адресов в имена существует специальный домен in-addr.arpa и специальная запись типа PTR. Как это выглядит, видно на скриншоте. У пикабу, кстати, какая-то лажа с его гуглопочтой, так что пример на другом домене (надеюсь, они не обидятся). Обратите внимание, что IP-адрес переворачивается (задача для самостоятельного раздумья – вспомнить про адресацию и понять, почему).
Часть 5. Внутренняя зона – что за зверь?
Это немножко вбоквел. Например, вы зарегистрировали домен не для себя, а для компании. В компании решили организовать доменную структуру (AD поднять, например). И для этой доменной структуры у вас появляется внутренняя зона DNS. Зона, причем, может быть та же самая, что и в инете, но к той интернетовской зоне она не будет иметь никакого отношения. У вас появляются контроллеры домена (или иные DNS-сервера – держатели внутренней зоны) в вашей локальной сети. На всех компьютерах вашей организации в качестве DNS-серверов вы указываете контроллеры домена (на которых поднята роль DNS). Во внутренней зоне находятся записи внутренних ресурсов: все компьютере в домене, внутренние web-порталы, и т.д. На DNS-серверах корпорации указаны «Forwarders» - сервера, на которые пойдет запрос, если ответа не найдется во внутренней зоне (это уже сервера провайдера, обычно).
Ну, предположим, что pikabu.ru – большая корпорация, в которой есть доменная структура и вы в этой корпорации работаете. Если вы изнутри этой зоны (сидя на работе) выполните команду «nslookup pikabu.ru», вы получите список внутренних DNS-серверов компании, а на сайт пикабушечки не попадёте. Всё потому, что вам ответит внутренний сервер компании, в котором прописано, что «pikabu.ru – это ж я сам и есть, а еще все мои дублирующие сервера!». А вот если вы выполните эту команду из дома, получите внешние адреса пикабу – потому что вам ответит DNS-сервер хостинг-провайдера.
Теперь, предположим, вы с работы набрали www.pikabu.ru. Допустим, у вас в корпорации нет компа с именем www и внутреннего ресурса такого тоже нет. Корпоративный DNS не найдет у себя в зоне записи www и перенаправит запрос на адрес форварда. Мы помним, что это адрес сервера провайдера. И вот тут ответ будет идентичный, что изнутри, что снаружи корпорации, потому что мы искали во внешней зоне.
И третий вариант, у вас в домене есть компьютер W01-vasya-PC.pikabu.ru. Изнутри компании вам внутренний DNS вернет его внутренний адрес. А вот запрос извне "Где W01-vasya-PC.pikabu.ru?" вернет вам "такого хоста не существует" - потому что DNS хостинг-провайдера, где находится ваша внешняя зона pikabu.ru (и куда в конце-концов дочапает DNS-запрос) понятия не имеет о вашей внутренней зоне.
Часть 6. Интересные факты:
Сейчас для распределения нагрузки на корневые сервера используется anycast – это такая публикация маршрутов в сети (BGP), при которой, вам ответит географически ближайший сервер, а не тот, до которого маршрут по некоторым причинам короче.
Максимальное имя поддомена 63 символа, максимальное общее доменное имя 255 символов.
Обычно, обратную зону надо просить прописывать своего провайдера. Но есть вариант, при котором провайдер делает у себя пару записей, а вы после этого можете менять PTR-запись прям у себя в админке родного DNS от хостинг-провайдера (ну, насколько я поняла). Статья вот.
P.S.: Что-то дофига получилось, мда. Надеюсь, кому-то стало понятнее. Правки по существу приветствуются.
