Около 20 лет назад интернет плотно вошел в нашу жизнь, однако до сих пор большинство пользователей не совсем представляют, и по каким критериям его выбирают. Самое популярное заблуждение заключается в том, что домен 3-го уровня низко оценивается и используется в крайне редких случаях. Действительно ли неприлично его использовать, например, интернет-магазинами, и чем руководствоваться при выборе? А также в чем заключается различие между понятиями - домен, доменное имя, доменная зона?

Понятие и классификация

Итак, сначала немного об определениях. Доменное имя, или домен, - это символьное имя сайта для его идентификации на просторах интернета. Например, yandex.ru - доменное имя второго уровня. Доменная зона - это окончание, следующее после точки, в данном примере - это.ru, означающее принадлежность сайта к Рунету.

Чаще всего доменные зоны разделяют на группы по территориальному признаку:

• национальному (если необходима привязка к конкретной стране - .by, .ru, .ua и т. д.);
• международному (если такой привязки нет - .com, .info, .biz и т. д.).

Другая классификация подразумевает разделение их по тематике:

• .info - для новостных и информационных порталов;
• .am и.fm - для радиостанций;
• .tv - для телевизионных каналов;
• .biz - для коммерческих сайтов;
• .name - для ресурсов, связанных с какой-то личностью и т. д.

Некоторые применяют организационные доменные зоны:

• .net - для интернет-компаний;
• .com - для бизнеса;
• .org - для некоммерческих предприятий;
• .edu - для образовательных программ.

Эти доменные зоны относятся к доменам первого уровня. Если добавить перед точкой слово - получится домен 2-го уровня (например, yandex.ru), а если еще одну точку и слово впереди, то домен 3-го уровня (news.yandex.ru).

Как зону?

Конечно, в первую очередь следует определиться с тем, на кого будет ориентирован сайт.

Для русскоязычной аудитории подойдет доменная зона.ru, для белорусской - .by, для украинской.ua и т. д. Если привязка к определенной стране не нужна, то лучше выбрать международную зону.com. Крупные компании с разветвленной торговой интернет-структурой предпочитают иметь сайт с одинаковым именем сразу в нескольких доменных зонах. Например, dom.ua - для украинских покупателей, dom.ru - для российских, dom.com - для международных расчетов.

Для уточнения конкретной страны или региона используйте список доменных зон.

Российские домены

Особенностью отечественного интернета является использование в адресе сайта не только латинских букв, но и кириллицы - это доменная зона.рф, .москва, .онлайн (для прямых трансляций), .дети (для сайтов с детской аудиторией), .орг (для общественных организаций), .сайт (для личных порталов, блогов и т. п.) и некоторые другие.

Часто можно встретить доменные имена с причастностью к определенным городам и регионам - spb.ru (Санкт-Петербург), msk.ru (Москва), nov.ru (Новгородская область) и т. д.

Как выбрать имя сайта?

Интернет-ресурсов становится все больше, все сложнее становится подобрать уникальное имя сайта. Поэтому набирают популярность варианты с двумя-тремя словами через дефис. Например, simple-domen-name.ru. Аббревиатуру использовать можно, но при условии, что она общеизвестна, например Нацбанк Беларуси - nbrb.by. Непонятная абракадабра из нескольких букв - не самый удачный вариант, т. к. пользователь вряд ли ее запомнит и не сможет набрать в дальнейшем по памяти.

Главное, чтобы доменная зона были простыми для запоминания и последующего воспроизведения. Не используйте опечатки слов - cofe.ru или cofie.ru. Попросите у знакомых на слух записать адрес. Если при произношении человек смог безошибочно его ввести, значит и другие пользователи смогут найти вас.

Если название фирмы для вас не принципиально, попробуйте использовать в имени ключевое слово (фразу) латиницей, например, computer.ru.

Для чего нужны домены третьего уровня?

В некоторых ситуациях уместнее применять например, если речь идет о блоге или портфолио. В качестве доменной зоны в этом случае может выступать.name. Пример - ivan.ivanov.name. При этом домен второго уровня будет доступен для всех остальных Ивановых.

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

Как получить домен?

Итак, имя сайта придумано, остается только проверить его на уникальность и зарегистрировать, чтобы сайт смог начать функционировать. Для этого сначала вы идете на информационный сервис WHOIS и проверяете, свободен ли домен.

Если имя уникально, переходите на сайт аккредитованного регистратора Руцентра - nic.ru. Здесь регистрация доменной зоны потребует прохождения следующих шагов:

1. Знакомство с правилами оказания услуг и заключение договора оферты в электронном виде. При желании можно заключить бумажную версию, приехав в главной офис RU-CENTER или отправив распечатанную версию по почте в двойном экземпляре (второй после подписания будет возвращен вам назад).
2. Заполнение анкеты (в качестве физического, юридического лица или индивидуального предпринимателя), подача документов. К этому этапу стоит отнестись с особой ответственностью, поскольку при малейшей ошибке, несовпадении данных вы не сможете передать права на домен другому лицу в будущем и сами можете потерять возможность управлять им.
3. Создание заказа на домен и сопутствующие услуги.
4. Формирование стоимости и оплата различными способами - наличными, безналичными, интернет-платежом и т. д.

Для тех, кто по какой-то причине не хочет платить деньги за сайт или делает свои первые шаги в сайтостроительстве, есть бесплатные доменные зоны. Что это такое и как они работают?

Как получить бесплатный домен?

Сразу стоит оговориться, что получить домен 2-го уровня бесплатно практически невозможно. А если такое предложение вам встретится, то, скорее всего, через год за место все равно придется платить, причем немало.

Гораздо чаще встречаются бесплатные домены 3-го уровня. Как их найти?

Один из вариантов - обратиться к бесплатным хостингам и конструкторам сайтов - ucoz.com, narod.ru.

Второй вариант - ввести в поисковике free domains, чтобы попасть на англоязычные ресурсы, где шансов получить качественный домен больше. В числе первых вы найдете сайт freenom.com, где можно не только бесплатно зарегистрировать домен второго уровня в зонах GA, ТК, CF, ML, но и привязать свои DNS, и в дальнейшем распоряжаться полностью собственным сайтом платно. Подобных ресурсов здесь можно найти огромное множество, например, registry.cu.cc, codotvu.com, freedomain.co.nr и многие другие.

Большую популярность набирают новые доменные зоны - .cu.cc, .uni.me, .cz.cc, .eu.org .de.cc, .at.cc, .ch.cc и другие.

Что касается отечественных сервисов, то неплохие условия получения бесплатного домена предлагает.pp.ua (private person). Здесь можно удобно разместить какой-нибудь персональный сайт или личный блог.

Главный вопрос, связанный с такими доменами, - насколько поисковая система к ним релевантна и можно ли продвигать сайт в топ на подобных платформах? Для этого нужно в интересующем поисковике ввести запрос site:ch.cc или site:at.cc (для Google) или url=»*.ch.cc и посмотреть, индексируются ли такие домены в поиске.

Резюме

Зона - то, без чего не может функционировать ни один сайт. Резюмируя все вышесказанное, можно выделить 5 ключевых этапов подключения домена и создания сайта:

1. Выбор доменной зоны по наиболее подходящему для вас принципу - территориальному или тематическому.
2. Создание доменного имени и проверка его на уникальность через специальный сервис WHOIS.
3. Заключение договора на получение домена с российским центром RU-CENTER.
4. Подключение дополнительных услуг.
5. Оплата удобным способом.

Это все, что касается получения платного домена. В случае если вы хотите сделать это бесплатно, этапов всего 2 - найти подходящий сервис, который предоставит домен 3-го уровня на удобных для вас условиях, и создание уникального доменного имени.

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

DNS определяет два типа серверов: первичные и вторичные. Первичный сервер - это сервер, накапливающий файл о зоне, на которую он имеет полномочия. Он несет ответственность за создание, эксплуатацию и изменения зонового файла. Зоновый файл накапливается на локальном диске.

Вторичный сервер – это сервер, который передает полную информацию о зоне для других серверов (первичных или вторичных) и накапливает файл на своем локальном диске. Вторичный сервер не создает и не изменяет зоновый файл. Если изменение требуется, он должен сделать это с помощью первичного сервера, который посылает измененную версию на вторичный.

DNS в Интернете

DNS – это протокол, который может быть использован в различных платформах. В Интернете пространство доменных имен (дерево) разделяется на три различных секции: родовой домен, домен страны и инверсный домен.

Родовой домен

Родовой домен определяет регистрацию хоста (generic domain) в соответствии с его родовой природой. Эти уровни связаны с типами организаций, как это, например, приведено для США в табл. 3.1.

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

В таблице первый уровень в секции родового домена позволяет семь возможных трехсимвольных уровней. Эти уровни соотнесены с типами организаций так, как перечислено в табл. 3.1.

Домены страны

Секция домены страны придерживается того же формата, что и родовые домены, но использует двухсимвольные сокращения страны (например, ru для России) вместо трехсимвольной организационной структуры первого уровня. Аббревиатуры второго уровня могут быть организационными или могут более детально определять национальную принадлежность. Россия (ru), например, использует аббревиатуры отдельных городов (например, spb.ru). Адрес gut.spb.ru может быть расшифрован как Государственный университет телекоммуникаций, Санкт-Петербург, Россия.

Инверсный домен

Инверсный домен использует отражение адреса в имя. Это может понадобиться, например, когда сервер получил запрос от клиента на выполнение определенной задачи. Поскольку сервер имеет файл, который содержит список полномочных клиентов, сервер перечисляет только IP-адреса клиентов (извлекая их из полученного пакета). Чтобы определить, есть ли клиент в разрешенном списке, сервер может запросить DNS-сервер об отображении адреса в имя.

Этот тип запроса называется инверсным запросом, или запросом указателя. Для того чтобы обработать запрос указателя, инверсный домен добавляет к пространству доменных имен узел первого уровня, называемый arpa (по историческим причинам). Второй уровень также именует одиночный узел in-addr (для инверсного адреса). Остаток домена определяет IP-адреса.

Сервер, который обрабатывает инверсный домен, - также иерархический. Это означает, что часть адреса, содержащая сетевой номер (netid), должна быть более высокого уровня (в данном примере это 132), чем часть адреса подсети (subnetid), в данном примере 45; а часть адреса подсети должна быть более высокого уровня, чем адрес хоста (hostid). Такая конфигурация делает вид домена инверсным, если сравнивать с родовым доменом и доменом страны.

Распознавание имен

Отображение имени в адрес или адреса в имя называется "распознавание имя-адрес".

Распознаватель (resolver)

Протоколы DNS разработаны как приложение сервер-клиент. Хост, который нуждается в отображении адреса в имя или имени в адрес, вызывает DNS клиента, который называется распознавателем. Распознаватель получает доступ к ближайшему серверу DNS с запросом на отображение. Если сервер имеет информацию, он выполняет запрос распознавателя; в противном случае он либо отсылает распознаватель к другим серверам, либо сам запрашивает другие сервера для того, чтобы обеспечить эту информацию.

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

Отображение имен в адреса

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

Если имя домена от родовой секции, распознаватель получает доменное имя, такое как kafedra.gut.edu. Запрос посылается распознавателем к местному DNS-серверу для распознавания. Если местный сервер не распознает запроса, он либо отсылает распознаватель к другому серверу, либо запрашивает другой сервер напрямую.

Если имя домена из секции доменов стран, распознаватель получает доменное имя, такое как kafedra.gut.spb.ru. Процедура та же самая.

Отображение адресов в имена

Клиент может послать IP-адрес на сервер для того, чтобы отобразить доменное имя. Это называется PTR-запрос. Для подобного запроса DNS использует инверсный домен. Однако IP-адрес запроса должен быть реверсирован, и должны быть прикреплены две метки, in-addr или arpa, чтобы создать доступный домен с помощью инверсной доменной секции. Например, если распознаватель получил IP-адрес 132.34.45.121, распознаватель вначале инвертирует адрес, а затем добавляет две метки перед посылкой. Посылаемое имя домена - 121.45.34.132.in-addr.arpa. Оно получается с помощью локальной DNS и распознается.

Рекурсивное распознавание

Клиент (распознаватель) может запросить рекурсивный ответ из сервера имени. Если сервер может это сделать, он проверяет свою базу данных и отвечает. Если сервер не уполномочен, он посылает запрос другому серверу (обычно к вышестоящему) и ожидает отклика. Если вышестоящий сервер уполномочен, он отвечает; в противном случае он посылает запрос еще одному серверу. Когда запрос окончательно распознан, ответ перемещается назад, пока окончательно не достигнет запрашиваемого клиента.

Итерационное распознавание

Если клиент не запрашивает рекурсивный ответ, отображение может быть сделано итерационно. Если сервер имеет разрешенное имя, он посылает ответ. Если нет, он возвращает клиенту IP-адрес сервера, который, как он предполагает, может ответить на запрос. Клиент повторяет запрос второму серверу. Если вновь адресованный сервер может распознать запрос, он отвечает IP-адресом; в противном случае он возвращает IP-адрес нового сервера клиенту. Теперь клиент должен повторить запрос третьему серверу. Этот процесс называется итерационным, потому что клиент повторяет один и тот же запрос к множеству серверов.

Кэширование

Каждый раз как сервер получает запрос имени, которого нет в его домене, ему необходимо провести поиск в базе данных адресов первичного сервера. Уменьшение времени поиска увеличило бы эффективность. DNS делает это с помощью механизма, называемого кэшированием. Когда сервер запрашивает отображение от другого сервера и получает отклик, он накапливает эту информацию в своей сверхоперативной памяти (кэш-память), перед тем как послать ее другому клиенту. Если тот же самый или другой клиент запрашивает отображение, он может проверить свою кэш-память и распознать номер. Однако чтобы информировать клиента, что отклик пришел от кэш-памяти, а не от полномочного источника, сервер маркирует отклик как неполномочный.

Кэширование ускоряет распознавание, но может и создать проблемы. Если сервер кэширует отображение за долгое время, он может послать клиенту устаревшее отображение. Чтобы противостоять этому, используются два метода.

При первом из них полномочный сервер всегда добавляет кусок информации для отображения так называемого "времени жизни" (TTL – time to live). Оно определяет время в секундах, в течение которого принимающий сервер может кэшировать информацию. После истечения этого времени отображение недействительно, и любой запрос может быть опять послан к полномочному серверу.

Второй метод состоит в том, что DNS-запрос, который каждый сервер сохраняет в памяти, содержит TTL – ограниченное время для каждого отображения. Кэш-память периодически сканируется, и отображения с истекшим "временем жизни" (TTL) удаляются.

DNS-сообщения

DNS имеет два типа сообщения: запрос и отклик. Оба типа имеют один и тот же формат. Сообщение запроса содержит заголовок, запись запроса, ответную запись, запись полномочий и дополнительные записи (рис. 4.1).

Рис. 4.1. Сообщение запроса и записи

Заголовок

Оба сообщения, запрос и отклик, имеют один и тот же формат заголовка с несколькими полями с установленными нулями для сообщений отклика. Заголовок 12 байт и его формат показан в (табл. 4.2).

Поля заголовков – следующие:

Идентификация . Это 16-битовое поле применяется клиентом для того, чтобы сравнить отклик с запросом. Клиент использует различный номер идентификации каждый раз, когда он посылает запрос. Сервер дублирует этот номер в соответствующем отклике.

Флаги . Это 16-битовое поле, содержащее субполя, показано на (рис. 4.2).

Рис. 3.2. Поле флагов

Короткое описание субполей каждого флага дано ниже.

1. QR (query/response) - запрос/ответ . Это однобитовое субполе, которое определяет тип сообщения. Если оно равно 0, сообщение является запросом. Если оно равно 1, то сообщение - ответ.

2. OpCode (код операции) . Это 4-битовое субполе, которое определяет тип запроса или ответа (0 - тип стандартный, 1 - тип инверсный и 2 - сервер запрашивает состояние).

4. TC (truncated - усеченное) . Это однобитовое поле. Когда оно установлено (значение 1), это означает, что ответ был более чем 512 байт и усечен до 512. Применяется, когда DNS пользуется услугой UDP.

5. RD (recursiondesired – желательна рекурсия) . Это однобитовое субполе. Когда оно установлено (значение 1), это означает, что клиенту желателен рекурсивный ответ. Он устанавливается в сообщении запроса и повторяется в ответном сообщении.

6. RA (recursion available - рекурсия возможна) . Однобитовое субполе. Когда оно установлено в ответе, это означает, что возможен рекурсивный ответ. Устанавливается только в ответном сообщении.

7. Reserved (резервные) . Это трехбитовое субполе с установленными нулями.

8. rCode (r-код) . Это 4-битовое поле, которое показывает состояние ошибки в ответе. Конечно, только полномочный сервер может сделать такую оценку.

Таблица 4.2. показывает возможные значения этого поля.

Значение

Представляем вашему вниманию новый курс от команды The Codeby - "Тестирование Веб-Приложений на проникновение с нуля". Общая теория, подготовка рабочего окружения, пассивный фаззинг и фингерпринт, Активный фаззинг, Уязвимости, Пост-эксплуатация, Инструментальные средства, Social Engeneering и многое другое.

Домены имеют как минимум два DNS сервера, один называется первичным сервером имён (ns1), а другой — вторичным сервером имён (ns2). Вторичные сервера обычно задействуются при проблемах с первичным сервером DNS: если один сервер недоступен, то второй становится активным. Возможны и более сложные схемы с использованием балансировки нагрузки, файерволов и кластеров.

Все DNS записи определённого домена добавляются в первичный сервер имён. Вторичный сервер просто синхронизирует всю информацию, получая её от первичного, на основании параметров, заданных на первичном сервере.

Эта инструкция опишет, как создать первичный DNS сервер, работающий на CentOS . Пожалуйста, обратите внимание, что DNS сервер, представленный в этой инструкции, будет публичным DNS, это означает, что сервер будет отвечать на запросы от любого IP адреса. Как ограничить доступ к серверу, описано в этой инструкции.

Перед тем, как мы начнём, хотелось бы упомянуть, что DNS может быть установлен с или без chroot jail окружением. Окружение chroot jail ограничивает DNS сервер определённой директорией в системе, в отличие от полного системного доступа на сервере. Таким образом, любая уязвимость DNS сервера не скомпромитирует всю систему. Ограничение DNS сервера в определённой директории (процесс называется chrooting) также полезно в тестовых условиях.

Цель

Мы настроим DNS сервер в тестовых условиях для домена example.tst, который является гипотетическим (не существующим) доменом. Таким образом, мы не вмешаемся случайным образом в работу каких-либо реальных доменов.

В этом домене есть три следующих сервера.

Сервер	IP адрес	Хостящиеся службы	FQDN
Сервер A	172.16.1.1	Mail	mail.example.tst
Сервер B	172.16.1.2	Web, FTP	www.example.tst ftp.example.tst
Сервер C	172.16.1.3	Primary DNS server	ns1.example.tst

Мы настроем первичный DNS сервер и добавим необходимый домен и DNS записи как показанов в таблице.

Настраиваем имена хостов

Все хосты должны быть корректно определены с точки зрения FQDN . Это может быть сделано с использованием следующего метода.

Те, кто любит графический интерфейс, могут воспользоваться инструментами NetworkManaget. Для этого наберите команду nmtui . Откроется такой псевдографический интерфейс:

Выбираете «Изменить имя узла» и вводите ns1.example.tst

Когда готово, нажимаете и ОК.

Ещё один способ, всего в одну команду:

Hostnamectl set-hostname ns1.example.tst

После установки, имя хоста может быть проверено следующей командой.

# hostname ns1.example.tst

Hostnamectl status

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

Установка пакетов

Мы будем использовать bind для DNS, который с лёгкостью может быть установлен командой yum.

Установка DNS без chroot:

# yum install bind

Установка DNS с chroot:

# yum install bind bind-chroot

Подготовка конфигурационных файлов

Как было упомянуто ранее, bind может быть настроен с или без chroot. Пути немного различаются, в зависимости от того, был ли установлен chroot.

	Путь до конфигурационного файла	Путь до файлов зоны
Без chroot	/etc/	/var/named/
С chroot	/var/named/chroot/etc/	/var/named/chroot/var/named/

Можно использовать конфигурационный файл named.conf, который поставляется по умолчанию. Тем не менее, мы будем использовать другой примерный конфигурационный файл для простоты использования.

Делаем резервную копию файла /etc/named.conf

Cp /etc/named.conf /etc/named.conf.bak

# cp /usr/share/doc/bind-9.9.4/sample/etc/named.rfc1912.zones /etc/named.conf

# cp /usr/share/doc/bind-9.9.4/sample/etc/named.rfc1912.zones /var/named/chroot/etc/named.conf

Теперь, когда есть резервная копия конфигурационного файла, а сам оригинальнвй файл изменён, двигаемся дальше.

# vim /etc/named.conf

# vim /var/named/chroot/etc/named.conf

Следующие строки были добавлены/изменены.

Options { ## путь до файлов зон ## directory "/var/named"; ## пенераправляем запросы на публичный DNS сервер Google для нелокальных доменов ## forwarders { 8.8.8.8; }; }; ## объявление прямой зоны для example.tst ## zone "example.tst" IN { type master; file "example-fz"; ## файл для прямой зоны размещён в /var/named ## allow-update { none; }; }; ## объявление обратной зоны для сети 172.16.1.0 ## zone "1.16.172.in-addr.arpa" IN { type master; file "rz-172-16-1"; ## файл для обратной зоны размещён в /var/named ## allow-update { none; }; };

Подготовка файлов зон

Дефолтные файлы зон автоматически созданы в /var/named или /var/named/chroot/var/named (для chroot).

Подразумевая, что дефолтные файлы зон не представлены, мы можем скопировать файлы образцов из /usr.

# cp /usr/share/doc/bind-9.9.4/sample/var/named/named.* /var/named/

# cp /usr/share/doc/bind-9.9.4/sample/var/named/named.* /var/named/chroot/var/named

Отлично. Теперь дефолтные файлы зоны готовы, мы создаём наши собственные файлы зоны для example.tst и сети 172.16.1.0. Пока мы создаём файлы зоны, нужно помнить следующее.

• Символ ‘@’ означает NULL в файлах зоны.
• Каждая запись полного доменного имени (FQDN) заканчивается точкой ‘.’ например. mail.example.tst. Без точки, будут проблемы.

1. Прямая зона

Прямая зона содержит карту преобразований из имён в IP адреса. Для публичных доменов, DNS доменов, размещённых на хостингах, содержаться в файле прямой зоны.

# vim /var/named/example-fz

# vim /var/named/chroot/var/named/example-fz $TTL 1D @ IN SOA ns1.example.tst. mial.example.tst. (0 ; serial 1D ; refresh 1H ; retry 1W ; expire 3H) ; minimum IN NS ns1.example.tst. IN A 172.16.1.3 mail IN A 172.16.1.1 IN MX 10 mail.example.tst. www IN A 172.16.1.2 ns1 IN A 172.16.1.3 ftp IN CNAME www.example.tst.

Объяснение : Внутри файла зоны, SOA означает начало авторизации. Это полное доменное имя авторитетного сервера имен. После полного доменного имени, идёт контактный email адрес. Поскольку мы не можем использовать ‘@’ в [email protected], мы перезаписываем email адрес как mial.example.tst.

• NS : Имя сервера
• A : A запись или запись адреса — это IP адрес
• MX : Mail Exchanger запись. Здесь мы используем только один MX с приоритетом 10. В случае множества MX, мы можем использовать различные цифровые приоритеты. Нижний номер выигрывает. Например, MX 0 лучше чем MX 1.
• CNAME : имя в каноническом виде. Если на сервере размещено множество служб, весьма вероятно, что множество имён будут преобразовываться к одному серверу. CNAME сигнализирует, что другие имена сервер может иметь и отсылает к имени, которое содержится в A записи.

2. Обратная зона

Обратная зона содержит карту преобразований из IP адресов в имена. Здесь мы создаём обратную зону для сети 172.16.1.0. В реальном домене, DNS сервер владельца публичного IP блока содержится в файле обратной зоны.

# vim /var/named/rz-172-16-1

# vim /var/named/chroot/var/named/rz-172-16-1 $TTL 1D @ IN SOA ns1.example.tst. sarmed.example.tst. (0 ; serial 1D ; refresh 1H ; retry 1W ; expire 3H) ; minimum IN NS ns1.example.tst. 1 IN PTR mail.example.tst. 2 IN PTR www.example.tst. 3 IN PTR ns1.example.tst.

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

• PTR : PTR или запись указателя, она указывает на полное доменное имя

Завершение

Теперь, когда файлы зон готовы, мы настроем разрешение файлов зоны.

# chgrp named /var/named/*

# chgrp named /var/named/chroot/var/named/*

Сейчас мы зададим IP адрес DNS сервера.

# vim /etc/resolv.conf nameserver 172.16.1.3

Наконец, мы можем запустить службу DNS и убедиться, что она добавлена в автозапуск.

# service named restart # chkconfig named on

Тестирование DNS

Мы можем использовать dig или nslookup для тестирования DNS. Вначале, мы установим необходимые пакеты.

# yum install bind-utils

1. Тестирование прямой зоны с использованием dig

# dig example.tst ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 31184 ;; QUESTION SECTION: ;example.com. IN A ;; ANSWER SECTION: example.com. 86400 IN A 172.16.1.3 ;; AUTHORITY SECTION: example.com. 86400 IN NS ns1.example.com. ;; ADDITIONAL SECTION: ns1.example.com. 86400 IN A 172.16.1.3

2. Проверка PTR с помощью dig

Когда вы используете для тестирования dig, вам всегда следует искать статус "NOERROR". Любое другое состояние означает, что что-то не так.

# dig -x 172.16.1.1 ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 27415 ;; QUESTION SECTION: ;1.1.17.172.in-addr.arpa. IN PTR ;; ANSWER SECTION: 1.1.16.172.in-addr.arpa. 86400 IN PTR mail.example.tst. ;; AUTHORITY SECTION: 1.16.172.in-addr.arpa. 86400 IN NS ns1.example.tst. ;; ADDITIONAL SECTION: ns1.example.tst. 86400 IN A 172.16.1.3

3. Проверка MX с помощью dig

# dig example.tst mx ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 35405 ;; QUESTION SECTION: ;example.tst. IN MX ;; ANSWER SECTION: example.tst. 14366 IN MX 10 mail.example.tst.

Подсказки при решении проблем

1. У меня отключён SELinux.
2. Убедитесь, что ваш файервол не блокирует UDP порт 53
3. /var/log/messages должен содержать полезную информацию в случае, если что-то не так
4. Убедитесь, что владельцев файлов зон является пользователь ‘named’
5. Убедитесь, что IP адрес DNS сервера стоит на первом месте в /etc/resolv.conf
6. Если вы используете example.tst в лабораторных условиях, убедитесь, что отсоединили сервер от Интернета, поскольку example.tst — это несуществующий домен.

Подытожим, этот урок фокусируется на хостинге домена example.tst в лабораторных условиях для демонстрационных целей. Пожалуйста, помните, что это не инструкция по созданию публичного DNS сервера, например DNS сервера, который отвечает на запросы от любых IP адресов. Если вы настраиваете рабочий DNS сервер, убедитесь, что проверили, какие политика относятся к публичным DNS. Другой урок освещает создание вторичного DNS, ограничение доступа к DNS серверу, и реализацию DNSSEC.

Гарант является доверенным посредником между Участниками при проведении сделки.

Руководство для системных администраторов

4. Установка BIND

Запуск вторичного DNS-сервера

Для надежности потребуется установить еще один DNS -сервер. Можно (рано или поздно многие так и поступают) установить более двух авторитетных DNS -серверов для локальных зон. Два DNS -сервера - это минимум, поскольку в случае, если есть только один сервер и он перестает работать, служба доменных имен для зоны перестает функционировать. Второй DNS -сервер делит нагрузку с первым сервером или принимает на себя всю нагрузку в случае аварии на первом сервере. Можно просто установить еще один основной DNS -сервер, но мы не рекомендуем этого делать. Вместо этого следует создать вторичный DNS -сервер. Позже, если вы не испугаетесь дополнительных усилий, которые нужно затратить, чтобы несколько первичных серверов могли дружно сосуществовать, то всегда сможете превратить вторичный сервер в первичный.

Мы копируем файлы /etc/named.conf, db.cache и db.127.0.0 на машину wormhole.movie.edu, а затем редактируем файл настройки, как описано выше. Файл настройки на узле wormhole.movie.edu выглядит теперь следующим образом:

options { directory "/var/named"; };

Протоколы DNS являются частью основных стандартов Интернета. Они определяют процесс, при котором один компьютер может найти другой компьютер на основе его имени. Реализация протоколов DNS означает, что сервер содержит все программное обеспечение, необходимое для создания запросов и ответов службы доменных имен.

Минимальные требования сохранения данных требуют для каждой доменной зоны, не менее двух DNS серверов. Первый сервер DNS называют первичный, он же primary, а по- новому master . Остальные сервера, а их может быть минимум один, а максимум 12, называют вторичные сервера DNS, или иначе secondary , по- новому, slave . По-новому, это начиная с DNS Bind 8-ой версии.

Примечание: BIND это программа для реализации протоколов системы доменных имен (DNS). Название BIND расшифровывается как «Berkeley Internet Name Domain», так как программное обеспечение возникла в начале 1980-х годов в университете Калифорнии в Беркли. В последние годы слово BIND стала больше, чем аббревиатура.

• Первичный и вторичные DNS не обязательно должны находиться на домене, за который отвечают.
• Первичный и вторичные DNS оба являются авторитативными серверами.

Первичный и вторичный DNS

Первичный (primary, master) сервер DNS

Master сервер DNS хранит полную, оригинальную базу данных своей доменной зоны. Данные хранятся в файлах.

При запросе к первичному серверу DNS, он дает авторитативный ответ, благодаря которому по домену находится IP ресурса.

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

Вторичные (secondary, slave) сервера DNS

Как я уже упомянул, для каждой доменной зоны должно быть создано или прикреплено минимум два сервера DNS. Именно минимум. Число вторичных серверов может быть до 12. В большинстве своем, такое количество вторичных серверов это перебор. Как правило, с запасом, достаточно трех вторичных DNS. Да вы и сами видели, что у любого регистратора доменных имен, не больше четырех полей для ввода адресов DNS серверов. Один для первичного сервера, три – для вторичных.

На вторичных DNS серверах база данных имен не храниться, она периодически считывается с первичного сервера, естественно по сети. Периодичность считывания, определяется в записи DNS типа SOA (параметр Refresh, в секундах). Обычно, 3600 секунд, то есть информация на вторичном сервере обновляется каждый час.

Обращу внимание, что считывать данные любой вторичный сервер может не только с первичного сервера, но и любого вторичного. В этом случае, этот сервер с которого считывается информация, будет master сервером для вторичного сервера.

Как лучше разместить первичный и вторичные DNS

Нужно понимать, если DNS сервер «падает», то все сайты, находящиеся в доменной зоне этого DNS падают тоже. Если падает первичный сервер, отвечать на запросы начинают последовательно вторичные DNS сервера. А вот тут и проблема, если все DNS сервера лежат в одной сети, то при падении этой сети, падают все DNS. Отсюда простой вывод, «не нужно хранить все яйца в одной корзине» или в нашем случае, нужно разнесите DNS сервера по разным хостам, а еще лучше по разным территориальным зонам.

Например, хостинг — провайдер предоставил вам два сервера DNS для вашего домена. Правильнее наоборот, он включил ваш домен в доменную зону своих DNS серверов. Найдите в Интернет, сервер вторичных DNS (платный или бесплатный) и дополните свои первичный и вторичный сервера, сторонними DNS серверами. Тем самым, вы обезопасите свой ресурс на случай падения DNS серверов провайдера.

С хотингами могут быть проблемы с добавлением сторонних DNS серверов. У каждого провайдера, своя «песочница» и он устанавливает свои правила. Некоторые хостинги ограничивают клиентов, только своими DNS. Другое дело если у вас, сервер VPS/VDS. Здесь вы полный хозяин и можете сами создавать DNS сервера на своем домене. И опять-таки, на VPS создайте два своих DNS сервера и дополните их двумя сторонними, и лучше разными, DNS серверами.

Где необходимо регистрировать DNS сервера

DNS сервера должны быть прописаны (зарегистрированы) на вашем хостинге или сервере и у регистратора доменных имен. На сервере вторичных доменных имен вы регистрируете только свой домен и берете их вторичные DNS. Независимо от места прикрепления, ваш домен и ваши DNS сервера должны быть зарегистрированы, а, следовательно, связаны:

• У регистратора имен;
• На вашем хостинге или сервере (раздел сервера DNS, управление DNS);
• На сервере вторичных DNS (если используете).

Выводы

• Для работы сайта, его домен должен попадать в доменные зоны, которые обслуживают, первичный и вторичные DNS сервера;
• DNS серверов должно быть, как минимум два. Один первичный и один вторичный DNS. Для более надежной работы сайта, дополните два DNS сервера, еще двумя дополнительными вторичными серверами. Желательно третий и четвертый DNS сервера взять на разных хостингах.

Сервера вторичных DNS

Приведу несколько серверов, где можно взять вторичные DNS.

• 2DNSinfo.ru (бесплатно);
• www.mgnhost.ru/DNS-hosting.php (600 рублей в год за 100 зон);
• http://toobit.ru/hosting/secondary_name_server.php (100 Slave DNS за 1$ в мес.);

При аренде сторонних первичных, да и вторичных DNS серверов, с осторожностью относитесь к импортным DNS хостингам. Попробуйте проверить время их отклика на запрос, для этого есть масса online сервисов. Нормальное время ответа на запрос DNS должен быт от 20 до 120 ms. Хоть у импортных хостингов и сервера разбросаны по всему миру, но, к сожалению, этот мир может быть настолько далеко от вас, что время отклика достигает 800-4000 ms. А это не хорошо.

Как проверить DNS сервера сайта

Для проверки своих и чужих DNS воспользуйтесь любым сервисом Whois – сервиса проверки доменных имен. При проверке не забывайте, что при смене DNS кэширующий сервер очищается каждые 24-72 часа.