Что такое ns сервер

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

Я сам создаю и продвигаю сайты различных тематик, и мне неоднократно приходилось переносить ресурсы заказчиков с одного хостинга на другой, делалось это в целях безопасности и смены нестабильного хостинга на более надежный. Почитайте пост про мой выбор надежного хостинга «Лучший хостинг для сайта в России» Давайте поподробнее рассмотрим все технические моменты работы с  DNS серверами.

DNS сервера  — это совокупность множества серверов, расположенных в сети интернет, которые передают информацию в реальном времени между собой  о том или ином доменном имени. Тем самым, DNS является системой управления всех доменов. Используя  такие сервера, можно узнать через панель  администратора домена, кому он принадлежит, а также проверить ip адрес, на котором он находится.  Я бы сравнил эту систему с паспортным столом, где наш домен получает свою прописку, когда временную, а когда и постоянную.

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

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

Для домена в обязательном порядке должен быть прописан список dns серверов, не менее двух NS-записей, иногда может потребоваться и четыре записи. Это делается для того, чтобы гарантировать работоспособность сайта,  в случае недоступности серверов другие сервера страхуют их. Обязательно проверьте данные записи. Может случиться, что с сайтом все в порядке, а у Вас паника, и Вы не можете понять что происходит с сайтом. Чтобы прописать данные сервера в домене, необходимо просто зайти в панель управления домена в раздел DNS-сервера и вписать вместо старых данных свои.

Вот мой список dns серверов для блога firelinks.ru:

поля для прописки своих NS-записей

Обратите внимание, что после внесения NS-записей в dns сервер для домена (да и вообще в принципе), их обновление может происходить от 1 дня до 7 дней, все зависит от Вашего провайдера. Бывает и такое, что обновление записей прошло успешно, люди видят сайт, а Вы со своего компьютера не можете на него попасть, и Вам выдают ошибку или же просто написано, что сайт не может быть найден. Не стоит печалиться, тут все дело обстоит именно в обновлении записей Вашего интернет-провайдера, у меня это происходит 1,5 дня, и все становится доступно.

Также есть интересный метод ускорить видимость сайта для себя. Для этого Вам необходимо обратиться к хостеру и попросить его дать Вам временные записи ip адреса Вашего сайта, чтобы не ждать полного обновления их на Вашем провайдере. К примеру, мои записи сайта имели следующий вид:

Данную запись необходимо сделать на своем компьютере в системном файле hosts. У меня  на компьютере установлена Windows 7  x64, и путь к моему файлу выглядит так:

Если же Вы используете операционную систему Unix, то путь выглядит так:

Я прописываю данную запись в самом низу файла, и все работает нормально. Ну вот, теперь Вы не зависите от того, как обновятся записи провайдеров Ваших серверов и спокойно можете продолжать работу над проектом, проводить проверку его скорости работы и оптимизацию контента.

место куда надо прописать Ip адрес днс сервера

Существую быстро обновляемые и бесплатные DNS сервера, их еще называют «публичными». Выглядят они следующим образом:

8.8.8.8 и 8.8.4.4 — для поисковой системы Google;

208.67.222.222 и 208.67.220.220 — для OpenDNS .

Чтобы их прописать на своем компьютере, необходимо зайти в свойства сетевого подключения, выбрать протокол TCP/IP, и в его свойствах прописать DNS сервера.

firelinks.ru

Зачем нужны DNS-сервера и что это такое?

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

Дело в том, что на технологическом уровне все устройства в любой сети уже имеют уникальные имена (идентификаторы или IP), но они мало подходят для использования их людьми, ибо представляют из себя набор цифр (читайте про то, что такое АйПи и MAC адреса).

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

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

Вот именно на этих ДНС-серверах (иногда их еще называют NS от Name Server, т.е server имен) и держится весь интернет (как плоский мир на трех китах, стоящих на черепахе). Сервер, если вы помните, это просто служебный компьютер не требующий непосредственного участия человека в своей работе (настроили его — он и пашет в режиме 24 на 7). И таких DNS-серверов в сети очень много.

Как работает DNS и причем тут файл Hosts?

На заре интернета ДНС вообще не существовало. Но как же тогда работала сеть? Как браузер понимал, что ktonanovenkogo.ru — это то же самое, что IP адрес 109.120.169.66? За это дело тогда (да и сейчас тоже) отвечал так называемый файл Hosts, где были прописаны все хосты тогда еще маленького интернета.

Такой файл находился (и сейчас находится) на каждом компьютере пользователя (на вашем тоже он есть) подключенного к сети (как его найти смотрите по приведенной выше ссылке).

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

109.120.169.66 ktonanovenkogo.ru

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

Сейчас файл Hosts стал рудиментом (пережитком прошлого) и там обычно есть только одна запись (127.0.0.1 localhost) означающая, что локальным хостом нужно считать данный компьютер.

Правда иногда его используют вирусы и другие зловреды, чтобы вместо одного сайта вы попадали на другой (про фишинг слышали?) — ведь для этого достаточно добавить всего одну строчку в файл Hosts (можете сами прописать в нем, например, «109.120.169.66 yandex.ru» и вместо Яндекса браузер вам будет упорно открывать мой блог). Вот именно поэтому его целостность охраняют большинство антивирусов.

Как ДНС-сервера помогают браузеру ориентироваться в сети?

То есть сейчас всеми делами с адресацией в сети рулят именно ДНС-сервера, хотя по своей сути они очень похожи на файл Hosts, но только хранятся на них данные о многих миллионах адресов, да и размещены они удаленно.

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

Еще раз поясню цепочку «метаний» браузера при вводе в него Урл адреса сайта. Итак, сначала он обращается к файлу Hosts, потом к ближайшему ДНС-серваку. Он же в ответ передает нужную информацию (о том, какой именно IP адрес соответствует данному домену) нашему браузеру или запрашивает ее у вышестоящего NS-сервера, если такой информации у себя он не находит.

Что такое ns сервер

И лишь только после этого браузер обращается к самому сайту по только что узнанному IP адресу. Долго, правда? Но что делать? Иначе никак.

Правда браузер «хитрит» и сохраняет всю полученную от ДНС серверов информацию в свой кеш, чтобы потом не терять время на эти запросы по поводу IP адреса сайта. Естественно, что кеш хранится не вечно, но часто посещаемые пользователем сайты благодаря этому в браузере будут открываться быстрее (кэш — это вообще вещь!).

Какую роль играют NS-сервера хостинга в DNS системе?

На приведенном выше рисунке показана сильно упрощенная схема, по которой не очень понятна роль отдельных уровней ДНС-серверов. Чуть ниже приведена более развернутая схема (хотя и опять же очень упрощенная).

Что такое ns сервер

Если вы владелец сайта, то знаете, что при покупке хостинга (или получении его бесплатно) вам выдают адреса NS-серверов (обычно их два), которые нужно будет прописать у вашего регистратора доменных (как это сделать описано чуть ниже). Например, мой хостер Инфобокс выдал мне два адреса (ns1.pa.infobox.ru и ns2.pa.infobox.ru).

Вопрос, как эти адреса NS участвуют в схеме определения IP-адреса по имени домена. Собственно, это показано на приведенном выше рисунке, но я все же поясню:

  1. Как я уже писал выше, ваш компьютер при вводе в адресной строке Урла типа «ktonanovenkogo.ru» в первую очередь связывается с DNS-серверами вашего интернет-провайдера. Если в их кэше имеется IP адрес соответствующий данному домену, то он незамедлительно будет выдан браузеру и все на этом закончится. В смысле, браузер используя полученный АйПи обратится к моему блогу и откроет запрашиваемую вами страницу.
  2. Если у вашего интернет-провайдера этой информации не найдется, то он обратится к одному из корневых ДНС-серваков (их не так уж и много и информация на них обновляется не часто — от одного до нескольких раз в сутки).
  3. Корневые серваки не могут дать вам сразу пару «домен — IP», но зато могут сказать, где эту информацию наверняка можно найти. Т.е. они выдают интернет-провайдеру адреса тех ДНС-серверов, в которых прописана искомая информация об интересующем домене. В нашем случае это будут как раз те самые адреса NS хостера, где физически в данный момент расположены файлы сайта (ns1.pa.infobox.ru и ns2.pa.infobox.ru в моем случае).
  4. Получив эту информацию ваш интернет-провайдер обратится по одному из полученных NS-адресов и найдет там информацию о том, какой АйПи-адрес на данный момент соответствует домену «ktonanovenkogo.ru».
  5. ДНС-server вашего интернет-провайдера запомнит эту информацию в свой кэш (чтобы при следующих обращения не повторять всю приведенную выше цепочку запросов) и незамедлительно передаст искомый IP вашему браузеру.
  6. И только после этого браузер сможет обратиться к виртуальному серваку моего хостинга, где расположен блог https://ktonanovenkogo.ru. В результате на экране вашего компьютера откроется одна из страниц моего сайта.

ktonanovenkogo.ru

  • dns-ns-1

    DNS сервер это сокращение от Domain Name System (или Domain Name Service) — фактически система (или служба) серверов доменных имен.

    DNS-серверы выполняют функцию преобразования доменных имен в IP-адреса и наоборот. Система DNS представляет собой базу данных, распределенную по всей сети Интернет, и целую сеть серверов. Каждый DNS-сервер знает своих «соседей» и способен быстро и автоматически, по специально разработанной иерархической схеме, опрашивать их, если к нему поступил запрос на установление соответствия «IP — доменное имя» или, наоборот, «доменное имя — IP». Для соединения с web-сервером и получения соответствующей web-страницы браузеру необходим IP-адрес этого имени. Браузер вызывает функцию DNS для получения данной информации. Функция отображения доменных имен в IP-адреса, которую предоставляет DNS, называется name resolution (разрешение имен). Протокол, который используется для выполнения функции разрешения имен, называется DNS-протокол.

    «DNS-клиентами» являются практически все сайты, размещенные в сети Интернет. Всякий раз, когда вы при посещении wap или web-страниц набираете доменное имя, служба DNS серверов должна выяснить, какому IP-адресу соответствует данное имя домена. Именно по этой причине правильное задание DNS-серверов является одной из важнейших настроек для работы wap или web-сайтов в сети Интернет.

    Интернет представляет собой самую большую компьютерную сеть. С точки зрения пользователя, каждый узел или ресурс в этой сети идентифицируется уникальным именем – так называемым доменным именем. Некоторыми примерами ресурсов Интернет, для которых определяются доменные имена, являются: Web-серверы; Mail-серверы.

    С точки зрения сетевого оборудования (например, роутера), которое перенаправляет коммуникационные пакеты по Интернет, уникальный ресурс идентифицируется IP-адресом, который представляет собой набор из четырех групп чисел, разделенных точками (например, 123.67.43.245). Для доступа к ресурсам Интернета по доменным именам, понятным пользователям, а не по этим IP-адресам, пользователям нужна система, которая преобразовывает доменные имена в IP-адреса и обратно. Такое преобразование является первоочередной задачей сервисов, называемых Domain Name System (DNS).

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

    Функция DNS, описанная выше, включает следующие составные части. Во-первых, необходимо иметь репозиторий для хранения доменных имен и соответствующих им IP-адресов. Так как количество доменных имен весьма велико, то основными требованиями являются масштабируемость и эффективность. Также должно существовать ПО, которое управляет этим репозиторием и предоставляет функцию разрешения имен. Эти две функции (управление репозиторием доменных имен и предоставление сервиса разрешения имен) выполняются компонентой DNS, называемой name-сервер. Существует несколько категорий таких серверов – рекурсивный name-сервер и stub resolver, различающиеся по своим возможностям. Коммуникационный протокол, различные компоненты DNS, политики, которые определяют конфигурацию этих компонент, процедуры создания, хранения и использования доменных имен составляют инфраструктуру DNS.

    Name-сервер выполняет следующие функции:
    предоставляет информацию о сервере который отвечает за дочернюю зону;
    предоставляет преобразование доменного имени в IP-адрес или IP-адрес в доменное имя, называемое инверсным преобразованием;
    предоставляет сообщение об ошибке, если запрос сделан для записи DNS, которой не существует.

    Двумя основными компонентами ПО DNS являются name-сервер и resolver. Основные функции name-сервера состоят в обслуживании базы данных (называемой зонным файлом), содержащей информацию о зоне, и в предоставлении ответов на запросы разрешения имени посредством авторитетных ответов. Основной функцией ПО resolver’а является запрос или серия запросов разрешения имени. Основными данными DNS является зонный файл; другим типом данных DNS является конфигурационный файл.

    Name-сервер (DNS-сервер, NS-запись) — это сервер, являющийся частью системы DNS. Для парковки домена на хостинг необходимо указывать у регистратора домена значение Primary и Secondary Name-серверов. Для нашего хостинга Name-серверы имеют следующий вид:
    NS1.foxcloud.net
    NS2.foxcloud.net

    Существует два основных типа name-серверов: авторитетные name-серверы и кэширующие name-серверы. Термин авторитетный относится к зоне. Если name-сервер содержит ресурсные записи, касающиеся конкретной зоны, он называется авторитетным name-сервером для данной зоны. Такой сервер предоставляет ответы на запросы разрешения имен для данной зоны, используя ресурсные записи в своем собственном зонном файле. Кэширующий name-сервер, в противоположность предыдущему типу name-сервера, предоставляет ответы посредством серии запросов либо к авторитетным name-серверам, расположенным выше в иерархии доменов, либо из кэша, полученного из ответов на предыдущие запросы.

    Resolver’ы

    Такое ПО, как web-браузеры и e-mail клиенты, которые требуют доступа к ресурсам Интернета, используют DNS-клиент, называемый client resolver или stub resolver. Stub resolver формулирует запрос на разрешение имени для ресурса, который отыскивается в Интернете, и посылает этот запрос кэширующему name-серверу. Как правило, stub resolver сконфигурирован таким образом, чтобы иметь список кэширующих name-серверов для обеспечения большей надежности данной операции. Stub resolver обычно называется просто resolver’ом. Кэширующий name-сервер, который получил запрос от stub resolver’а, также формирует запросы для посылки их авторитетным name-серверам (если он не может ответить на запрос из своего кэша), и, следовательно, также иногда указывается как resolver, потому что он имеет рекурсивную компоненту и компоненту кэширования.

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

ru.foxcloud.net

Типичные ситуации

Давайте рассмотрим типичные ситуации, знакомые многим веб-разработчикам.

Редирект домена на www

Часто нужно сделать редирект домена iskettlemanstillopen.com на www.iskettlemanstillopen.com. Регистраторы типа Namecheap или DNSimple называют это URL Redirect. Вот пример из админки Namecheap:

Что такое ns сервер

Символ @ означает корневой домен iskettlemanstillopen.com. Давайте посмотрим на запись A у этого домена:

$ dig iskettlemanstillopen.com ;; QUESTION SECTION: ;iskettlemanstillopen.com. IN A  ;; ANSWER SECTION: iskettlemanstillopen.com. 500 IN A 192.64.119.118 

Этот IP принадлежит Namecheap’у, и там крутится маленький веб-сервер, который просто делает перенаправление на уровне HTTP на адрес http://www.iskettlemanstillopen.com:

$ curl -I iskettlemanstillopen.com curl -I iskettlemanstillopen.com HTTP/1.1 302 Moved Temporarily Server: nginx Date: Fri, 19 Jul 2013 23:53:21 GMT Content-Type: text/html Connection: keep-alive Content-Length: 154 Location: http://www.iskettlemanstillopen.com/ 

CNAME для Heroku или Github

Взгляните на скриншот выше. На второй строке там CNAME. В этом случае www.iskettlemanstillopen.com указывает на приложение, запущенное на Heroku.

$ heroku domains === warm-journey-3906 Domain Names warm-journey-3906.herokuapp.com www.iskettlemanstillopen.com 

С Github похожая история, но там нужно создать специальный файл в корне репозитория, и назвать его CNAME. См. документацию.

Wildcards

Большинство DNS-серверов поддерживают шаблоны (wildcards). Например, есть wildcard CNAME для *.web01.bugsplat.info указывает на web01.bugsplat.info. Тогда любой хост на web01 будет указывать на web01.bugsplat.info и не нужно создавать новые записи:

$ dig randomapp.web01.bugsplat.info  ;; QUESTION SECTION: ;randomapp.web01.bugsplat.info. IN A  ;; ANSWER SECTION: randomapp.web01.bugsplat.info. 300 IN CNAME web01.bugsplat.info. web01.bugsplat.info. 15 IN A 192.241.250.244 

habr.com

Запись A

Запись A (address) — адресная запись, необходима для связи домена и IP-адреса сервера. Проще говоря, для работы вашего сайта и всех поддоменов.

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

Примеры записи A:

Прописать А-запись вы можете по инструкции Как добавить запись А (поддомен)

Запись CNAME

CNAME (Canonical name) — каноническое имя для псевдонима. Запись CNAME чаще всего используется для переадресации поддомена на другой домен. Добавить запись можно по инструкции Как добавить запись CNAME.

Примеры записи CNAME:

В данном примере, если вы введете доменное имя webmail.site.ru в строку браузера, вы будете переадресованы на сайт webmail.hosting.reg.ru.

Одновременно добавить запись CNAME и запись A для одного и того же поддомена невозможно, т.е. нельзя добавить и запись A и запись CNAME для поддомена webmail.site.ru.

Запись MX

MX (Mail Exchanger) — адрес почтового шлюза для домена. Состоит из двух частей — приоритета и адреса узла. Записи MX критически важны для работы почты. Благодаря им отправляющая сторона «понимает» на какой сервер нужно отправлять почту для вашего домена.

Пример записи MX:

Записей MX может быть несколько. Делается это для того, чтобы в случае недоступности одного из почтовых серверов, почта была все же отправлена на другой. Приоритет записи определяет, на какой сервер нужно отправлять почту в первую очередь. Если приоритет одинаковый, сервер выбирается случайным образом. Чтобы добавить MX-запись, воспользуйтесь инструкцией Как добавить запись MX.

Запись NS

NS (Authoritative name server) — адрес узла, отвечающего за доменную зону. Проще говоря, запись NS указывает, какие DNS-серверы хранят информацию о домене. Критически важна для работы службы DNS.

Запись PTR

Обратная DNS-запись — связывает IP-адрес сервера с его каноническим именем (доменом). PTR-запись широко применяется в фильтрации почты. Для всех серверов виртуального хостинга REG.RU обратные DNS-записи уже прописаны. Если у вас виртуальный сервер VPS или выделенный сервер, прописать PTR-запись можно по инструкции Как настроить PTR-запись.

Запись SOA

SOA (Start of Authority) — указывает, на каком сервере хранится эталонная информация о доменном имени. Критически важна для работы службы DNS. Подробнее о том, что такое SOA-запись и как ее проверить, вы можете ознакомиться в инструкции

Запись SPF

SPF (Sender Policy Framework) — указывает сервера, которые могут отправлять почту от имени домена. Запись SPF вносят в TXT-запись домена.

Пример записи SPF:

В данном примере:

  • v=spf1 — определяет версию используемой записи SPF;
  • include:_spf.hosting.reg.ru — включает в запись SPF значение SPF-записи другого домена. Т.е. для домена будут действовать в том числе все значения записи SPF для домена «_spf.hosting.reg.ru»;
  • ip4:37.140.192.92 — разрешает прием почты с IP-адреса 37.140.192.92;
  • a — разрешает приём почты с сервера, IP-адрес которого стоит в ресурсной A-записи домена. Проще говоря с сервера, где размещен сайт;
  • mx — разрешает приём почты, если отправляющий сервер указан в одной из записей MX для домена;
  • ~all — если письмо пришло с сервера, который не входит в вышеперечисленный список, его стоит проанализировать более тщательно. Также иногда используется -all — в этом случае письмо не проходит дополнительных проверок и сразу отвергается.

Подробнее о настройке записи SPF читайте в инструкции Как настроить SPF-запись.

Запись TXT

TXT (Text string) — содержит любую текстовую запись. Широко применяется для проверок на право владения доменом при подключении дополнительных сервисов, а также для записи SPF и ключа DKIM.

Записей TXT может быть сколько угодно. Вам может потребоваться добавить записи TXT при подключении бесплатной Яндекс.Почты и при получении бесплатного SSL-сертификата, и они не будут друг другу мешать, так как необходимы для подтверждения владения доменом в разных сервисах, в первом случае — в Яндекс, во втором — в сертификационном центре Global Sign.

Добавить TXT-запись вы можете по инструкции Как добавить запись TXT.

www.reg.ru

Все да не все…

Лично у меня после прочтения «Как привязать домен» возникла некоторая неоднозначность.

Допустим, мы купили домен с именем domen.ru и имеем внешний статический IP адрес 67.89.110.20. И больше ничего.
В статье упоминается что привязка, как правило, осуществляется DNS записями типа ns1.domen.ru и ns2.domen.ru. Более ни про ns1.domen.ru, ни про ns2.domen.ru нигде в статье не упоминается. Не понятно начто они, куда ведут и зачем нужны. Вместо этого всплывают новые NS сервера ns1.reg.ru и ns2.reg.ru. Косвенно понятно (по названию reg.ru), что они не имеют никакого отношения к нашему серверу domen.ru с ISPConfig и адресом 67.89.110.20 и физически расположены у регистратора reg.ru. Если регистратор дает такие NS сервера сразу — хорошо. Но, например, nic.ru не дает. Соответственно купить домен domen.ru и иметь статический IP адрес 67.89.110.20 становиться недостаточным. Нужно покупать primary и secondary NS сервера, что в nic.ru стоит дороже самого домена. Об этом в статье не сказано. Немного подумав и купив эти NS сервера, возникает вопрос: если NS сервера предоставляет регистратор, то и все операции по назначению и привязке нашего сервера выполняются на сайте регистратора. Зачем нам вообще ISPConfig с вкладкой DNS? Там нужно заводить зону? Чем занимается поднятый ISPConfig bind? Может его(bind) лучше остановить? Ответа в статье нет…

Вернемся к DNS записями типа ns1.domen.ru и ns2.domen.ru. Во многих материалах форума и сайта упоминаются именно они. И судя по domen.ru как раз они и расположены на нашем локальном сервере. Тогда NS сервера ns1.reg.ru и ns2.reg.ru вроде как нам и не нужны. Хорошо, экономим больше половины денег, если регистрируемся на nic.ru… Но тест эти сервера не пройдут. Потому что их IP адреса одинаковы (ns1.domen.ru = ns2.domen.ru = domen.ru = 67.89.110.20), а это противоречит RFC. Особо педантичные NS сервера, прсекут это и удалят у себя записи о вашем домене domen.ru. Мой провайдер так и делает — сервер то сутки доступен, то сутки не доступен. Для чего на форуме и сайте постоянно упоминают эту (нерабочую в моем случае) конфигурацию — не понятно…

Еще подумав, можно предположить, что можно купить один NS сервер у регистратора, а второй поднять у себя. Тогда IP адреса разные и все требования соблюдаются. Ну что же пойдем на nic.ru и закожем себе такой сервер через услугу Primary-standart, ведь мы собрались первичный сервер поднять у регистратора, а вторичный у себя(можно и наоборот). Но в панели DNS ISPConfig я не смог найти возможности поднять только Secondary(вторичный) DNS сервер. Нет описания такой конфигурации и в статье и на форуме…

serverdoma.ru

Здесь мы обсуждаем вопросы применения записи описания ресурсов NS (Name Server). Подробно разбираем вопрос некорректного делегирования зон, а также алгоритм выбора наиболее подходящего авторитативного сервера для обслуживания запросов к зоне.

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

Кроме того, запись NS позволяет делегировать поддомены, поддерживая тем самым иерархию доменов системы доменных имен Internet. Для того, чтобы домен был виден в сети в зоне описания домена старшего уровня должна быть указана запись типа NS для этого поддомена. Формат записи NS можно записать в виде:

[domain][ttl] IN NS [server]

В поле domain указывается имя домена, для которого сервер, указанный последним аргументом записи NS, поддерживает описание зоны. Значение поля ttl обычно оставляют пустым, тем самым, заставляя named устанавливать значение по умолчанию (поле minimum из записи SOA для данной зоны в старых версиях BIND или значение директивы управления $TTL).

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

Записи NS указывают как на master, так и на slave серверы. Последние, обычно, принадлежат другим зонам, и для них следует указывать полное доменное имя сервера с указанием имени машины и имени зоны. Например, для сервера из домена polyn.kiae.su c именем ns следует писать полностью ns.polyn.kiae.su. Для того чтобы придерживаться какого-то единого стиля и во избежание ошибок, рекомендуется писать всегда полное имя сервера.

Какой либо разницы между master и slave в NS не указывается. Обычно primary master записывают первым, а резервные серверы указывают вслед за ним.

Приведем пример записи описывающей сервер доменных имен для поддомена:

$ORIGIN vega.ru.
zone1 IN NS ns.zone1.vega.ru.

В данном примере в качестве первой строки используется команда $ORIGIN, которая определяет имя текущей зоны (см. материал «Файлы описания зоны. Директивы управления»). Здесь она введена только для того, чтобы определить текущую зону.

В поле имени зоны указано имя zone1 без точки на конце. В данном контексте это означает делегирование зоны в домене vega.ru, полное имя которой будет zone1.vega.ru.

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

$ORIGIN vega.ru.
zone1 IN NS ns.zone1

т.к. имя принадлежит текущему домену и может быть расширено его именем.

В этом месте, видимо, следует обратить внимание на тот факт, что для записи доменных имен и имен зон существуют не только синтаксические ограничения, о которых упоминалось в материале «Правила именования хостов», а также при описании записи SOA, но и численные ограничения.

Длина метки узла дерева доменных имен должна находится в пределах от 1 до 63 октетов (RFC 2181). Любопытно, что написано не «символов», а октетов, то бишь байтов.

При этом длина полного имени (Full Qualified Doman Name -FQDN) не должна превышать 255 октетов, включая разделители ( те самые символы «.», которые ставятся между именами меток узлов). Полное имя узла — это имя от узла до корня дерева доменных имен.

Таким образом, максимальное имя корпоративного домена в зоне ru (что-то типа «corporative-name.ru») не может быть больше 63 символов, а вместе с двумя точками и «ru» не должно превышать 67 символов.

Теперь вернемся к NS записям. NS-записи обычно следуют сразу за записью SOA в файле описания зоны и указывают на серверы, которые ответственны за эту зону:

$ORIGIN ru.
Webstatistics 3600 IN SOA ns.webstatistics.ru. hostmaster.webstatistics.ru. (
1 3600 600 86400 3600 )
3600 IN NS ns.webstatistics.ru.
3600 IN NS ns4.nic.ru.

В данном случае описана зона webstatistics.ru и для нее вслед за SOA указано два сервера доменных имен: ns.webstatistics.ru — primary master и ns4.nic.ru — slave.

Такого простого указания на серверы доменных имен зоны для нормальной работы недостаточно. Нужно еще знать IP-адреса этих серверов. Для slave его можно найти в зоне nic.ru, а вот для ns.webstatistics.ru нужно использовать «приклеенную» адресную запись (см. подробнее материал «Адресная запись «Address». Балансировка нагрузки. Round Robin. Учет топологии сетей.»).

Рассмотрим еще одну причину использования NS-записей в описаниях зон — делегирование зоны.

До сих пор мы рассматривали NS запись только для объявления сервера доменных имен для той зоны, которую описываем, например, zone.ru:

@ IN SOA ns.zone.ru. hostmaster.zone.ru. (
2002092602 1d 3h 4w 3h )
IN NS ns.zone.ru.
IN NS ns.provider.ru.

Но это только часть функций NS записи. Теперь делегируем право ответственности за часть зоны другому администратору и выделяем в домене zone.ru зону subzone1. Этот факт мы должны отобразить в описании зоны zone.ru:

@ IN SOA ns.zone.ru. hostmaster.zone.ru. (
2002092602 1d 3h 4w 3h )
IN NS ns.zone.ru.
IN NS ns.provider.ru.
ns IN A 192.168.0.1
;
subzone1 IN NS ns.subzone1.zone.ru.
IN NS ns.zone.ru.
ns.subzone1 IN A 192.168.1.1

В данном случае имя subzone1 будет расширено именем текущей зоны (zone.ru), т.к. оно не завершается символом «.», а текущим является zone.ru, которое берется из файла конфигурации named потому, что указан символ «@» в записи SOA описания зоны.

На то, что subzone1 — это имя поддомена, указывает запись NS, потому, как у нее первое поле принимает значение имени домена (зоны).

При этом для зоны subzone1.zone.ru определено два авторитативных сервера: ns.subzone1.zone.ru и ns.zone.ru. Теперь, если к нашему серверу обратятся за адресом хоста из subzone1.zone.ru, то отошлем их к другим серверам, которые ответственны за эту зону.

Фраза «отошлем к другим серверам» означает то, что наш сервер вернет запрашивающему его клиенту или серверу, который выполняет рекурсивный запрос, имена и, если в зоне они прописаны, IP-адреса серверов доменных имен, ответственных за зону, где находится хост с заданным клиентом именем или адресом.

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

ns.subzone1 IN A 192.168.1.1

Если внимательно присмотреться к описанию этого примера, то становится ясно, что наш сервер никуда никого отправлять не будет, т.к. он сам является авторитативным для зоны subzone1.zone.ru. Скорее всего, он является slave-ом, а ns.subzone1.zone.ru — это master.

Просто мы имеем еще один файл описания зоны, который копируем с ns.subzone1.zone.ru, и где находится описание зоны subzone1.zone.ru.

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

Теперь, когда понятна процедура делегирования зоны, вернемся к NS записям, описывающим серверы нашей зоны в нашем же описании зоны, а не там, где нам эту зону (нашу зону) делегировали.

С нашим сервером проблем не возникает. Мы сами его администрируем. А вот с администраторами серверов, которые (серверы) мы прописываем в зоне в качестве авторитативных, следует сначала договориться. Не нужно прописывать имена серверов «от балды». Эти серверы должны быть действительно slave для вашей зоны. Как правило, при регистрации домена проверяются все серверы, указанные в заявке.

Вообще говоря, по идее, неправильное указание имени сервера авторитативного за зону внутри описания самой этой зоны не должно влиять на работу других серверов. BIND не проверяет соответствие серверов в родительской зоне и в зоне-потомке. Другое дело неправильное делегирование (lame delegation), когда сервер родительской зоны перенаправляет клиента к серверу, который не является авторитативным для зоны-потомка.

В нашем случае, например, сервер ns.zone.ru может быть не настроен в качестве slave для зоны subzone1.zone.ru. Тогда ряд запросов может быть отвергнут, что, конечно, плохо.

Еще раз подитожим, что под некорректным делегированием понимают:

  • наличие NS-записи, в которой указано имя сервера доменных имен, чей адрес невозможно найти;
  • наличие NS-записи, в которой указано имя сервера доменных имен, не отвечающего на запросы;
  • наличие NS-записи, в которой указано имя сервера доменных имен, негативно отвечающего на запросы.

На самом деле проблема некорректного делегирования достаточно серьезна. Так, например, Men&Mice в августе 2002 провела исследование 5000 случайно выбранных доменов в зоне com. Некорректное делегирование зоны было выявлено в 20% случаев. Это на один процент лучше, чем было в мае 2002 года, но все равно достаточно много. Любопытно, что в 14% случаев информация о делегировании зоны не совпадала с данными, указанными в самой зоне, а 17% случаев не удалось найти авторитативных серверов зоны.

Вообще говоря, проблема некорректного делегирования имеет решение, если сервер родительской зоны поддерживает механизм зон-заглушек (stub zone). Этот реализован в современных версиях BIND. Он позволяет серверу родительской зоны отслеживать изменения NS-записей делегированной зоны.

Для создания stub зоны следует в файл конфигурации named добавить:

zone «webstatistics.ru» {
type stub;
file «webstatistics.ru»;
masters {144.206.192.60;};
}

В этом случае сервер, на котором организована stub зона будет срисовывать в соответствующий файл запись SOA и NS-записи описания зоны.

Пусть описание зоны будет иметь вид:

$ORIGIN ru.
Webstatistics 3600 IN SOA webstatistics.ru. paul.webstatistics.ru. (
1 3600 600 86400 3600 )
3600 IN NS ns.webstatistics.ru.
3600 IN NS ns4.nic.ru.
IN A 144.206.192.60
$ORIGIN webstatistics.ru.
ns 3600 IN A 144.206.192.60
$ORIGIN nic.ru.
ns4 IN A 194.226.96.8
$ORIGIN webstatistics.ru.
www 3 IN A 144.206.192.60
3 IN A 144.206.192.61
3 IN A 144.206.192.62
3 IN A 144.206.160.32

Содержание файла типа stub на для зоны webstatistics.ru будет иметь следующий вид:

; BIND version named 8.2.2-P5-NOESW Mon Mar 20 20:39:05 GMT 2000
; BIND version root@monster.cdrom.com:/usr/obj/usr/src/libexec/named-xfer
; zone ‘webstatistics.ru’ first transfer
; from 144.206.192.60:53 (local 144.206.160.32) using AXFR at Mon Oct 7 19:31:1
; 7 2002
$ORIGIN ru.
Webstatistics 3600 IN SOA ns.webstatistics.ru. paul.webstatistics.ru. (
1 3600 600 86400 3600 )
3600 IN NS ns.webstatistics.ru.
3600 IN NS ns4.nic.ru.
$ORIGIN webstatistics.ru.
ns 3600 IN A 144.206.192.60
; Ignoring info about ns4.nic.ru, not in zone webstatistics.ru.
; $ORIGIN nic.ru.
; ns4 60575 IN A 194.226.96.8

Из этого примера хорошо видно, что в зону были скопированы записи SOA, NS и «приклеенные» адресные записи. При этом адресная запись для slave сервера была проигнорирована, т.к. она принадлежит другой зоне и в ней нет необходимости (подробнее см. материал «Адресная запись «Address». Балансировка нагрузки. Round Robin. Учет топологии сетей.»).

На самом деле есть одна загвоздка, которая делает указанный выше метод не достаточно удобным. Дело в том, что серийный номер родительской зоны не изменяется и, следовательно, slave-ы родительской зоны об изменениях в делегировании ничего знать не будут, если на них не настроить поддержку stub зоны.

В документации по BIND версии 9 не рекомендовано использовать зоны-заглушки для вновь создаваемых зон. Разработчики BIND советуют просто строго следовать правилам делегирования зоны.

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

На самом деле, остался не выясненным еще один вопрос, который тесно увязан с авторитативными серверами доменных имен. Это вопрос о порядке их опроса локальным сервером доменных имен, который выполняет рекурсивный запрос resolver-а.

На самом деле все достаточно просто. Когда сервер получает рекурсивный запрос, и в итоге опроса серверов доменных имен в конце концов получает список авторитативных серверов требуемой зоны, он для каждого из них включает метрику RRT (round trip time). Эта метрика в миллисекундах измеряет время отклика от каждого из серверов. В начальный момент времени, т.е. при первом запросе, она устанавливается в 0.

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

Наиболее эффективен этот алгоритм при работе с корневыми серверами,т.к. к ним приходится обращаться постоянно.

Следует заметить, что серверы, отличные от BIND могу реализовывать другие алгоритмы выбора сервера, т.к. в спецификации DNS этот вопрос не прояснен.

Любопытно, что измерения RTT для корневых серверов проведенные в 2000 году, хорошо совпали с RTT команды ping. Не обобщая этот вывод на все случае жизни, тем не менее можно сказать, что доступность DNS сервера можно оценивать по скорости отклика ping.

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

Рекомендованная литература:

  1. P. Mockapetris. RFC-1034. DOMAIN NAMES — CONCEPTS AND FACILITIES. ISI, 1987. (http://www.ietf.org/rfc/rfc1034.txt?number=1034)
  2. P. Mockapetris. RFC-1035. DOMAIN NAMES — IMPLEMENTATION AND SPECIFICATION. ISI, 1987. (http://www.ietf.org/rfc/rfc1035.txt?number=1035)
  3. Альбитц П., Ли К.. DNS и BIND. — Пер. с англ. — СПб: Символ-Плюс, 2002. — 696 с.
  4. Документация по BIND 9. Справочное руководство системного администратора. (http://www.nominum.com/resources/documentation/Bv9ARM.pdf)
  5. 5. R. Elz, R. Bush. RFC-2181. Clarifications to the DNS Specification. 1997. (http://www.ietf.org/rfc/rfc2181.txt?number=2181)


Полезные ссылки:

  1. http://www.menandmice.com/6000/61_recent_survey.html — результаты исследования Men&Mice по проблемам делегирования зон. Август 2002 года.
  2. http://www.dns.net/dnsrd/trick.html#which-server-queried — FAQ. Описание алгоритма выбора сервера среди авторитативных серверов зоны на основе RTT.
  3. http://www.caida.org/projects/dns-analysis/#logfile — анализ нагрузки корневых серверов и исследование эффективности алгоритма выбора сервера.
  4. http://www2.auckland.ac.nz/net/Internet/rtfm/meetings/47-adelaide/pp-dist/ — материал 2000 года, в котором подмечено совпадение RTT DNS и ping.

info.nic.ru

Ключевые характеристики DNS[править | править код]

DNS обладает следующими характеристиками:

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

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

DNS была разработана Полом Мокапетрисом в 1983 году; оригинальное описание механизмов работы содержится в RFC 882 и RFC 883. В 1987 публикация RFC 1034 и RFC 1035 изменила спецификацию DNS и отменила RFC 882, RFC 883 и RFC 973 как устаревшие.

Дополнительные возможности[править | править код]

  • поддержка динамических обновлений
  • защита данных (DNSSEC) и транзакций (TSIG)
  • поддержка различных типов информации

История[править | править код]

Использование более простого и запоминающегося имени вместо числового адреса хоста относится к эпохе ARPANET. Стэнфордский исследовательский институт (теперь SRI International) поддерживал текстовый файл HOSTS.TXT, который сопоставлял имена узлов с числовыми адресами компьютеров в ARPANET. Поддержание числовых адресов, называемых списком присвоенных номеров, было обработано Джоном Постелем в Институте информационных наук Университета Южной Калифорнии (ISI), команда которого тесно сотрудничала с НИИ.[1]

Адреса назначались вручную. Чтобы запросить имя хоста и адрес и добавить компьютер в главный файл, пользователи связывались с сетевым информационным центром (NIC) SRI, руководимым Элизабет Фейнлер, по телефону в рабочее время.

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

Рабочая группа IETF опубликовала оригинальные спецификации в RFC 882 и RFC 883 в ноябре 1983 года.

В 1984 году четыре студента UC Berkeley, Дуглас Терри, Марк Пейнтер, Дэвид Риггл и Сонгниан Чжоу, написали первую версию сервера имен BIND (Berkeley Internet Name Daemon). В 1985 году Кевин Данлэп из DEC существенно пересмотрел реализацию DNS. Майк Карел, Фил Альмквист и Пол Викси поддерживали BIND с тех пор. В начале 1990-х годов BIND был перенесен на платформу Windows NT. Он широко распространен, особенно в Unix-системах, и по-прежнему является наиболее широко используемым программным обеспечением DNS в Интернете.

В ноябре 1987 года были приняты спецификации DNS — RFC 1034 и RFC 1035. После этого были приняты сотни RFC, изменяющих и дополняющих DNS.

Проблемы с безопасностью[править | править код]

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

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

DNS-ответы ранее не имели криптографической подписи, что давало возможность для множества вариантов атаки. Современные расширения системы безопасности доменных имен (DNSSEC) изменяют DNS, чтобы добавить поддержку криптографически подписанных ответов. Другие расширения, такие как TSIG, добавляют поддержку криптографической аутентификации между доверенными одноранговыми узлами и обычно используются для авторизации передачи зоны или операций динамического обновления.

Некоторые доменные имена могут использоваться для достижения эффектов спуфинга. Например, paypal.com и paypa1.com — это разные имена, но пользователи могут не различать их в графическом пользовательском интерфейсе в зависимости от выбранного шрифта пользователя. Во многих шрифтах буква l и цифра 1 выглядят очень похожими или даже идентичными. Эта проблема остро стоит в системах, которые поддерживают интернационализированные доменные имена, поскольку многие коды символов в ISO 10646 могут отображаться на типичных экранах компьютеров. Эта уязвимость иногда используется в фишинге.

Для подтверждения результатов DNS также могут использоваться такие методы, как обратный DNS с подтверждением прямых записей, но криптографически достоверными они не являются; при этом не учитывается вариант подмены маршрутной информации (англ. BGP hijacking).

Терминология и принципы работы[править | править код]

Ключевыми понятиями DNS являются:

  • Доме́н (англ. domain «область») — узел в дереве имён, вместе со всеми подчинёнными ему узлами (если таковые имеются), то есть именованная ветвь или поддерево в дереве имён. Структура доменного имени отражает порядок следования узлов в иерархии; доменное имя читается слева направо от младших доменов к доменам высшего уровня (в порядке повышения значимости): вверху находится корневой домен (имеющий идентификатор «.»(точка)), ниже идут домены первого уровня (доменные зоны), затем — домены второго уровня, третьего и т. д. (например, для адреса ru.wikipedia.org. домен первого уровня — org, второго — wikipedia, третьего — ru). DNS позволяет не указывать точку корневого домена.
  • Поддомен (англ. subdomain) — подчинённый домен (например, wikipedia.org — поддомен домена org, а ru.wikipedia.org — домена wikipedia.org). Теоретически такое деление может достигать глубины 127 уровней, а каждая метка может содержать до 63 символов, пока общая длина вместе с точками не достигнет 254 символов. Но на практике регистраторы доменных имён используют более строгие ограничения. Например, если у вас есть домен вида mydomain.ru, вы можете создать для него различные поддомены вида mysite1.mydomain.ru, mysite2.mydomain.ru и т. д.
  • Ресурсная запись — единица хранения и передачи информации в DNS. Каждая ресурсная запись имеет имя (то есть привязана к определённому доменному имени, узлу в дереве имён), тип и поле данных, формат и содержание которого зависит от типа.
  • Зона — часть дерева доменных имён (включая ресурсные записи), размещаемая как единое целое на некотором сервере доменных имён (DNS-сервере, см. ниже), а чаще — одновременно на нескольких серверах (см. ниже). Целью выделения части дерева в отдельную зону является передача ответственности (см. ниже) за соответствующий домен другому лицу или организации. Это называется делегированием (см. ниже). Как связная часть дерева, зона внутри тоже представляет собой дерево. Если рассматривать пространство имён DNS как структуру из зон, а не отдельных узлов/имён, тоже получается дерево; оправданно говорить о родительских и дочерних зонах, о старших и подчинённых. На практике большинство зон 0-го и 1-го уровня (‘.’, ru, com, …) состоят из единственного узла, которому непосредственно подчиняются дочерние зоны. В больших корпоративных доменах (2-го и более уровней) иногда встречается образование дополнительных подчинённых уровней без выделения их в дочерние зоны.
  • Делегирование — операция передачи ответственности за часть дерева доменных имён другому лицу или организации. За счёт делегирования в DNS обеспечивается распределённость администрирования и хранения. Технически делегирование выражается в выделении этой части дерева в отдельную зону, и размещении этой зоны на DNS-сервере (см. ниже), управляемом этим лицом или организацией. При этом в родительскую зону включаются «склеивающие» ресурсные записи (NS и А), содержащие указатели на DNS-сервера дочерней зоны, а вся остальная информация, относящаяся к дочерней зоне, хранится уже на DNS-серверах дочерней зоны.
  • DNS-сервер — специализированное ПО для обслуживания DNS, а также компьютер, на котором это ПО выполняется. DNS-сервер может быть ответственным за некоторые зоны и/или может перенаправлять запросы вышестоящим серверам.
  • DNS-клиент — специализированная библиотека (или программа) для работы с DNS. В ряде случаев DNS-сервер выступает в роли DNS-клиента.
  • Авторитетность (англ. authoritative) — признак размещения зоны на DNS-сервере. Ответы DNS-сервера могут быть двух типов: авторитетные (когда сервер заявляет, что сам отвечает за зону) и неавторитетные (англ. Non-authoritative), когда сервер обрабатывает запрос, и возвращает ответ других серверов. В некоторых случаях вместо передачи запроса дальше DNS-сервер может вернуть уже известное ему (по запросам ранее) значение (режим кеширования).
  • DNS-запрос (англ. DNS query) — запрос от клиента (или сервера) серверу. Запрос может быть рекурсивным или нерекурсивным (см. Рекурсия).

Система DNS содержит иерархию DNS-серверов, соответствующую иерархии зон. Каждая зона поддерживается как минимум одним авторитетным сервером DNS (от англ. authoritative — авторитетный), на котором расположена информация о домене.

Имя и IP-адрес не тождественны — один IP-адрес может иметь множество имён, что позволяет поддерживать на одном компьютере множество веб-сайтов (это называется виртуальный хостинг). Обратное тоже справедливо — одному имени может быть сопоставлено множество IP-адресов: это позволяет создавать балансировку нагрузки.

Для повышения устойчивости системы используется множество серверов, содержащих идентичную информацию, а в протоколе есть средства, позволяющие поддерживать синхронность информации, расположенной на разных серверах. Существует 13 корневых серверов, их адреса практически не изменяются.[2]

Протокол DNS использует для работы TCP- или UDP-порт 53 для ответов на запросы. Традиционно запросы и ответы отправляются в виде одной UDP-датаграммы. TCP используется, когда размер данных ответа превышает 512 байт, и для AXFR-запросов.

Рекурсия[править | править код]

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

DNS-запрос может быть рекурсивным — требующим полного поиска, — и нерекурсивным (или итеративным) — не требующим полного поиска.

Аналогично — DNS-сервер может быть рекурсивным (умеющим выполнять полный поиск) и нерекурсивным (не умеющим выполнять полный поиск). Некоторые программы DNS-серверов, например, BIND, можно сконфигурировать так, чтобы запросы одних клиентов выполнялись рекурсивно, а запросы других — нерекурсивно.

При ответе на нерекурсивный запрос, а также при неумении или запрете выполнять рекурсивные запросы, DNS-сервер либо возвращает данные о зоне, за которую он ответственен, либо возвращает ошибку. Настройки нерекурсивного сервера, когда при ответе выдаются адреса серверов, которые обладают большим объёмом информации о запрошенной зоне, чем отвечающий сервер (чаще всего — адреса корневых серверов), являются некорректными, и такой сервер может быть использован для организации DoS-атак.

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

Рассмотрим на примере работу всей системы.

Предположим, мы набрали в браузере адрес ru.wikipedia.org. Браузер спрашивает у сервера DNS: «какой IP-адрес у ru.wikipedia.org»? Однако сервер DNS может ничего не знать не только о запрошенном имени, но и даже обо всём домене wikipedia.org. В этом случае сервер обращается к корневому серверу — например, 198.41.0.4. Этот сервер сообщает — «У меня нет информации о данном адресе, но я знаю, что 204.74.112.1 является ответственным за зону org.» Тогда сервер DNS направляет свой запрос к 204.74.112.1, но тот отвечает «У меня нет информации о данном сервере, но я знаю, что 207.142.131.234 является ответственным за зону wikipedia.org.» Наконец, тот же запрос отправляется к третьему DNS-серверу и получает ответ — IP-адрес, который и передаётся клиенту — браузеру.

В данном случае при разрешении имени, то есть в процессе поиска IP по имени:

  • браузер отправил известному ему DNS-серверу рекурсивный запрос — в ответ на такой тип запроса сервер обязан вернуть «готовый результат», то есть IP-адрес, либо пустой ответ и код ошибки NXDOMAIN;
  • DNS-сервер, получивший запрос от браузера, последовательно отправлял нерекурсивные запросы, на которые получал от других DNS-серверов ответы, пока не получил ответ от сервера, ответственного за запрошенную зону;
  • остальные упоминавшиеся DNS-серверы обрабатывали запросы нерекурсивно (и, скорее всего, не стали бы обрабатывать запросы рекурсивно, даже если бы такое требование стояло в запросе).

Иногда допускается, чтобы запрошенный сервер передавал рекурсивный запрос «вышестоящему» DNS-серверу и дожидался готового ответа.

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

Рекурсивные запросы требуют больше ресурсов от сервера (и создают больше трафика), так что обычно принимаются от «известных» владельцу сервера узлов (например, провайдер предоставляет возможность делать рекурсивные запросы только своим клиентам, в корпоративной сети рекурсивные запросы принимаются только из локального сегмента). Нерекурсивные запросы обычно принимаются ото всех узлов сети (и содержательный ответ даётся только на запросы о зоне, которая размещена на узле, на 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, или ресурсные записи (англ. resource records, RR), — единицы хранения и передачи информации в DNS. Каждая ресурсная запись состоит из следующих полей[3]:

  • имя (NAME) — доменное имя, к которому привязана или которому «принадлежит» данная ресурсная запись,
  • тип (TYPE) ресурсной записи — определяет формат и назначение данной ресурсной записи,
  • класс (CLASS) ресурсной записи; теоретически считается, что DNS может использоваться не только с TCP/IP, но и с другими типами сетей, код в поле класс определяет тип сети[4],
  • TTL (Time To Live) — допустимое время хранения данной ресурсной записи в кэше неответственного DNS-сервера,
  • длина поля данных (RDLEN),
  • поле данных (RDATA), формат и содержание которого зависит от типа записи.

Наиболее важные типы DNS-записей:

  • Запись A (address record) или запись адреса связывает имя хоста с адресом протокола IPv4. Например, запрос A-записи на имя referrals.icann.org вернёт его IPv4-адрес — 192.0.34.164.
  • Запись AAAA (IPv6 address record) связывает имя хоста с адресом протокола IPv6. Например, запрос AAAA-записи на имя K.ROOT-SERVERS.NET вернёт его IPv6-адрес — 2001:7fd::1.
  • Запись CNAME (canonical name record) или каноническая запись имени (псевдоним) используется для перенаправления на другое имя.
  • Запись MX (mail exchange) или почтовый обменник указывает сервер(ы) обмена почтой для данного домена.
  • Запись NS (name server) указывает на DNS-сервер для данного домена.
  • Запись PTR (pointer[5][6]) обратная DNS-запись или запись указателя связывает IP-адрес хоста с его каноническим именем. Запрос в домене in-addr.arpa на IP-адрес хоста в reverse-форме вернёт имя (FQDN) данного хоста (см. Обратный DNS-запрос). Например (на момент написания), для IP-адреса 192.0.34.164 запрос записи PTR 164.34.0.192.in-addr.arpa вернёт его каноническое имя referrals.icann.org. В целях уменьшения объёма нежелательной корреспонденции (спама) многие серверы-получатели электронной почты могут проверять наличие PTR-записи для хоста, с которого происходит отправка. В этом случае PTR-запись для IP-адреса должна соответствовать имени отправляющего почтового сервера, которым он представляется в процессе SMTP-сессии.
  • Запись SOA (Start of Authority) или начальная запись зоны указывает, на каком сервере хранится эталонная информация о данном домене, содержит контактную информацию лица, ответственного за данную зону, тайминги (параметры времени) кеширования зонной информации и взаимодействия DNS-серверов.
  • SRV-запись (server selection) указывает на серверы для сервисов, используется, в частности, для Jabber и Active Directory.

Зарезервированные доменные имена[править | править код]

Документ RFC 2606 (Reserved Top Level DNS Names — Зарезервированные имена доменов верхнего уровня) определяет названия доменов, которые следует использовать в качестве примеров (например, в документации), а также для тестирования. Кроме example.com, example.org и example.net, в эту группу также входят test, invalid и др.

Интернациональные доменные имена[править | править код]

Доменное имя может состоять только из ограниченного набора ASCII-символов, позволяя набрать адрес домена независимо от языка пользователя. ICANN утвердил основанную на Punycode систему IDNA, преобразующую любую строку в кодировке Unicode в допустимый DNS набор символов.

Программное обеспечение DNS[править | править код]

Серверы имен:

  • BIND (Berkeley Internet Name Domain) [1]
  • djbdns (Daniel J. Bernstein’s DNS) [2]
  • Dnsmasq [3]
  • MaraDNS [4]
  • NSD (Name Server Daemon) [5]
  • PowerDNS [6]
  • OpenDNS [7]
  • Microsoft DNS Server (в серверных версиях операционных систем Windows NT)
  • MyDNS [8]

См. также[править | править код]

  • Атака Каминского
  • Альтернативные корневые серверы DNS
  • OpenDNS
  • Google Public DNS
  • Яндекс.DNS
  • Киберсквоттинг
  • Тайпсквоттинг
  • Динамический DNS
  • Round robin DNS — распределение нагрузки между одинаковыми серверами.
  • ICANN
  • DNSSEC
  • DNS-клиент
  • DNS-сервер
  • Nslookup

Ссылки[править | править код]

  • DNS Resources Directory  (англ.)
  • Ресурсы, посвящённые DNS & BIND  (англ.)
  • Общество CircleID DNS  (англ.)
  • Повышение безопасности DNS (DNSSEC)  (англ.)
  • Рабочий комитет IETF занимающийся разработкой расширенной спецификации DNS (DNSEXT)  (англ.)
  • Сайт корневых DNS-серверов  (англ.)
  • Просмотр DNS-записей домена
  • Веб-инструменты для DNS, каталог на сайте dmoz.org  (англ.)

Статьи[править | править код]

  • Обзор схем и типов DNS-атак

ru.wikipedia.org

You May Also Like

About the Author: admind

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Этот сайт использует Akismet для борьбы со спамом. Узнайте как обрабатываются ваши данные комментариев.