Редактирование: DNS

{{Значения|DNS (значения)}}
{{Карточка протокола
|Аббр = DNS
|Название = Domain Name System
|Уровень = Прикладной
|Семейство = TCP/IP
|Порт = 53/[[TCP]], 53/[[UDP]]
|Назначение = Разрешение доменных имён
|Спецификация = RFC 1034, RFC 1035 / STD 13
|Клиенты = Встроен во все [[сетевая операционная система|сетевые ОС]]
|Серверы = [[BIND]], [[NSD]], [[PowerDNS]] или Microsoft DNS Server
}}
[[Файл:DNS-names-ru.svg|Пример структуры доменного имени|thumb|400px|right]]
'''DNS''' ({{lang-en|Domain Name System}} «система доменных имён») — компьютерная [[Распределённая база данных|распределённая система]] для получения информации о [[Доменное имя|доменах]]. Чаще всего используется для получения [[IP-адрес]]а по имени [[хост]]а (компьютера или устройства), получения информации о маршрутизации почты, обслуживающих узлах для протоколов в домене ([[SRV-запись]]).

[[Распределённые базы данных|Распределённая база данных]] DNS поддерживается с помощью иерархии [[DNS-сервер]]ов, взаимодействующих по определённому [[Протокол передачи данных|протоколу]].

Основой DNS является представление об иерархической структуре [[доменное имя|доменного имени]] и ''зонах''. Каждый сервер, отвечающий за имя, может ''делегировать'' ответственность за дальнейшую часть домена другому серверу (с административной точки зрения — другой организации или человеку), что позволяет возложить ответственность за актуальность информации на серверы различных организаций (людей), отвечающих только за «свою» часть доменного имени.

Начиная с 2010 года в систему DNS внедряются средства проверки целостности передаваемых данных, называемые ''DNS Security Extensions'' ([[DNSSEC]]). Передаваемые данные не шифруются, но их достоверность проверяется криптографическими способами. Внедряемый стандарт [[DANE]] обеспечивает передачу средствами DNS достоверной криптографической информации ([[Сертификат открытого ключа|сертификатов]]), используемых для установления безопасных и защищённых соединений [[Транспортный уровень|транспортного]] и [[Протоколы прикладного уровня|прикладного]] уровней.

== Ключевые характеристики 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), команда которого тесно сотрудничала с НИИ.<ref>{{Книга|автор=IEEE Annals [3B2-9] man2011030074.3d 11:54|заглавие=|ответственный=|издание=|место=|издательство=|год=29/7/011|страницы=|страниц=Page 74|isbn=|isbn2=}}</ref>

Адреса назначались вручную. Чтобы запросить имя хоста и адрес и добавить компьютер в главный файл, пользователи связывались с [[сетевым информационным центром]] (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 cache poisoning|отравление кэша DNS]], в котором данные распространяются на кэширующие преобразователи под предлогом того, что они являются авторитетным сервером происхождения, тем самым загрязняя хранилище данных потенциально ложной информацией и длительными сроками действия (время жизни). Впоследствии, запросы легитимных приложений могут быть перенаправлены на сетевые хосты, контролируемые злоумышленником.

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

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

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

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

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

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

Для повышения устойчивости системы используется множество серверов, содержащих идентичную информацию, а в протоколе есть средства, позволяющие поддерживать синхронность информации, расположенной на разных серверах. Существует 13 [[Корневые серверы DNS|корневых серверов]], их адреса практически не изменяются.<ref>Текущая версия корневой зоны всегда находится по адресу: ftp://ftp.internic.net/domain/named.root</ref>

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

=== Рекурсия ===

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

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

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

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

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

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

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

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

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

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

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

=== Обратный DNS-запрос ===
{{main|Обратный просмотр DNS}}<!-- собственно, это перенаправление, но ту статью как раз можно переработать в статью об обратном DNS --Incnis Mrsi -->
DNS используется в первую очередь для преобразования символьных имён в IP-адреса, но он также может выполнять обратный процесс. Для этого используются уже имеющиеся средства DNS. Дело в том, что с записью DNS могут быть сопоставлены различные данные, в том числе и какое-либо символьное имя. Существует специальный домен <code>in-addr.arpa</code>, записи в котором используются для преобразования IP-адресов в символьные имена. Например, для получения DNS-имени для адреса <code>11.22.33.44</code> можно запросить у DNS-сервера запись <code>44.33.22.11.in-addr.arpa</code>, и тот вернёт соответствующее символьное имя. Обратный порядок записи частей IP-адреса объясняется тем, что в IP-адресах старшие биты расположены в начале, а в символьных DNS-именах старшие (находящиеся ближе к корню) части расположены в конце.

== Записи DNS ==
{{main|Типы ресурсных записей DNS}}

'''Записи DNS''', или '''ресурсные записи''' ({{lang-en|resource records}}, {{lang-en2|RR}}), — единицы хранения и передачи информации в DNS. Каждая ресурсная запись состоит из следующих полей<ref>{{Cite web|url=https://tools.ietf.org/html/rfc5395.html|title=Domain Name System (DNS) IANA Considerations|publisher=tools.ietf.org|lang=en|accessdate=2019-02-07}}</ref>:
* ''имя'' (NAME) — доменное имя, к которому привязана или которому «принадлежит» данная ресурсная запись,
* ''тип'' (TYPE) ресурсной записи — определяет формат и назначение данной ресурсной записи,
* ''класс'' (CLASS) ресурсной записи; '''''теоретически''''' считается, что DNS может использоваться не только с [[TCP/IP]], но и с другими типами сетей, код в поле ''класс'' определяет тип сети<ref>{{Cite web|url=https://tools.ietf.org/html/rfc5395.html|title=Domain Name System (DNS) IANA Considerations|publisher=tools.ietf.org|lang=en|accessdate=2019-02-07}}</ref>,
* ''TTL'' (Time To Live) — допустимое время хранения данной ресурсной записи в кэше ''неответственного'' '''DNS-сервера''',
* длина поля данных (RDLEN),
* ''поле данных'' (RDATA), формат и содержание которого зависит от ''типа'' записи.

Наиболее важные типы DNS-записей:
* '''Запись A''' (''address record'') или '''запись адреса''' связывает имя хоста с адресом протокола IPv4. Например, запрос A-записи на имя <code>referrals.icann.org</code> вернёт его IPv4-адрес — <code>192.0.34.164</code>.
* '''Запись AAAA''' (''IPv6 address record'') связывает имя хоста с адресом протокола [[IPv6]]. Например, запрос AAAA-записи на имя <code>K.ROOT-SERVERS.NET</code> вернёт его [[IPv6]]-адрес — <code>2001:7fd::1</code>.
* '''Запись CNAME''' (''canonical name record'') или '''каноническая запись имени''' (псевдоним) используется для перенаправления на другое имя.
* '''[[Запись MX]]''' (''mail exchange'') или '''почтовый обменник''' указывает [[Почтовый сервер|сервер(ы) обмена почтой]] для данного домена.
* '''Запись NS''' (''name server'') указывает на [[DNS-сервер]] для данного домена.
* '''Запись PTR''' (''pointer''<ref>{{Cite web|url=https://tools.ietf.org/html/rfc1034.html|title=Domain names - concepts and facilities|author=P. V. Mockapetris|publisher=tools.ietf.org|lang=en|accessdate=2019-02-07}}</ref><ref>{{Cite web|url=https://tools.ietf.org/html/rfc1035.html|title=Domain names - implementation and specification|author=P. V. Mockapetris|publisher=tools.ietf.org|lang=en|accessdate=2019-02-07}}</ref>) обратная DNS-'''запись''' или '''запись указателя''' связывает IP-адрес хоста с его каноническим именем. Запрос в домене <code>in-addr.arpa</code> на IP-адрес хоста в reverse-форме вернёт имя ([[FQDN]]) данного хоста (см. [[#Обратный DNS-запрос|Обратный DNS-запрос]]). Например (на момент написания), для IP-адреса <code>192.0.34.164</code> запрос записи PTR <code>164.34.0.192.in-addr.arpa</code> вернёт его каноническое имя <code>referrals.icann.org</code>. В целях уменьшения объёма нежелательной корреспонденции (спама) многие серверы-получатели электронной почты могут проверять наличие PTR-записи для хоста, с которого происходит отправка. В этом случае PTR-запись для IP-адреса должна соответствовать имени отправляющего почтового сервера, которым он представляется в процессе [[SMTP]]-сессии.
* '''Запись [[Типы ресурсных записей DNS|SOA]]''' (''Start of Authority'') или '''начальная запись зоны''' указывает, на каком сервере хранится эталонная информация о данном домене, содержит контактную информацию лица, ответственного за данную зону, ''тайминги'' (параметры времени) кеширования зонной информации и взаимодействия DNS-серверов.
* [[SRV-запись]] (''server selection'') указывает на серверы для сервисов, используется, в частности, для [[Jabber]] и [[Active Directory]].

== Зарезервированные доменные имена ==

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

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

== Программное обеспечение DNS ==
Серверы имен:

* [[BIND]] (Berkeley Internet Name Domain) [http://www.isc.org/]
* [[djbdns]] ([[Daniel J. Bernstein]]'s DNS) [http://cr.yp.to/djbdns.html]
* [[Dnsmasq]] [http://www.thekelleys.org.uk/dnsmasq/doc.html]
* [[MaraDNS]] [http://www.maradns.org/]
* [[NSD]] (Name Server Daemon) [http://www.nlnetlabs.nl/projects/nsd/]
* [[PowerDNS]] [http://www.powerdns.com/]
* [[OpenDNS]] [http://www.opendns.com/]
* [[Microsoft DNS Server]] (в серверных версиях операционных систем [[Windows NT]])
* [[MyDNS]] [http://mydns-ng.com/]

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

== Примечания ==
{{примечания}}

== Ссылки ==
* [https://web.archive.org/web/20040805020053/http://www.dns.net/dnsrd/ DNS Resources Directory] {{ref-en}}
* [http://www.bind9.net/ Ресурсы, посвящённые DNS & BIND] {{ref-en}}
* [http://www.circleid.com Общество CircleID DNS] {{ref-en}}
* [http://www.dnssec.net/ Повышение безопасности DNS (DNSSEC)] {{ref-en}}
* [https://web.archive.org/web/20031008105543/http://www.ietf.org/html.charters/dnsext-charter.html Рабочий комитет IETF занимающийся разработкой расширенной спецификации DNS (DNSEXT)] {{ref-en}}
* [http://www.root-servers.org/ Сайт корневых DNS-серверов] {{ref-en}}
* [http://www.whois-service.ru/dns/ Просмотр DNS-записей домена]
* [http://dmoztools.net/Computers/Internet/Protocols/DNS/Web_Tools Веб-инструменты для DNS, каталог на сайте dmoz.org] {{ref-en}}

=== Статьи ===
* [http://inforsec.ru/technical-security/network-security/77-dns-attack Обзор схем и типов DNS-атак]

=== Документы RFC ===
* RFC 1034 — Domain Names — Concepts and Facilities
* RFC 1035 — Domain Names — Implementation and Specification
* RFC 1912 — Common DNS Operational and Configuration Errors
* RFC 1591 — Domain Name System Structure and Delegation
* RFC 1713 — Tools for DNS Debugging
* RFC 2606 — Reserved Top Level DNS Names

{{викифицировать}}
{{переработать}}
{{rq|cleanup|renew}}

{{URI scheme}}
{{IPstack}}
{{Компоненты Microsoft Windows}}

[[Категория:Стандарты Интернета]]
[[Категория:TCP/IP]]
[[Категория:DNS| ]]
[[Категория:Интернет-протоколы]]