Dns записи домена: Страница не найдена | REG.RU

DNS сервер BIND (теория) / Хабр

Основная цель DNS — это отображение доменных имен в IP адреса и наоборот — IP в DNS. В статье я рассмотрю работу

DNS сервера BIND

(Berkeley Internet Name Domain, ранее: Berkeley Internet Name Daemon), как сАмого (не побоюсь этого слова) распространенного. BIND входит в состав любого дистрибутива UNIX. Основу BIND составляет демон

named

, который для своей работы использует порт UDP/53 и для некоторых запросов TCP/53.

Основные понятия Domain Name System

Исторически, до появления доменной системы имен роль инструмента разрешения символьных имен в IP выполнял файл /etc/hosts, который и в настоящее время играет далеко не последнюю роль в данном деле. Но с ростом количества хостов в глобальной сети, отслеживать и обслуживать базу имен на всех хостах стало нереально затруднительно. В результате придумали DNS, представляющую собой иерархическую, распределенную систему доменных зон. Давайте рассмотрим структуру Системы Доменных Имён на иллюстрации:

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

домены первого уровня

(ru, net, org и др). Информация о серверах корневой зоны расположена на данном

сайте корневых серверов

. Настройки корневой зоны всегда доступны

тут

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

Зона — это любая часть дерева системы доменных имен, размещаемая как единое целое на некотором DNS-сервере. Зону, для бОльшего понимания, можно назвать «зоной ответственности». Целью выделения части дерева в отдельную зону является передача ответственности (Делегирование) за эту ветвь другому лицу или организации. На иллюстрации, примеры зон выделены синим градиентом (зона name., зона k-max.name. со всем подчиненными ресурсами, www.openoffice.org со всем подчиненными поддоменами и ресурсами). На иллюстрации выделены не все зоны, а лишь некоторые для общего понимания и представления. В каждой зоне имеется, по крайней мере, один авторитетный сервер DNS, который хранит ВСЮ информацию о зоне, за которую он отвечает.

Домен — это именованная ветвь или поддерево в дереве имен DNS, то есть это определенный узел, включающий в себя все подчиненные узлы. Следующая цитата из книги Linux Network Administrators Guide хорошо проясняет картину относительно разницы между зоной и доменом:

Таким образом, пространство имен раздроблено на зоны ( zones), каждая из которых управляется своим доменом. Обратите внимание на различие между зоной (zone) и доменом (domain): домен groucho.edu затрагивает все машины в университете Groucho Marx, в то время как зона groucho.edu включает только хосты, которые работают в непосредственно компьютерном центре, например в отделе математики. Хост в отделе физики принадлежат другой зоне, а именно physics.groucho.edu.

Каждый узел в иерархии DNS отделен от своего родителя точкой. Если провести аналогию с файловой системой Linux, система доменных имен имеет похожую структуру, за тем исключением, что разделитель в файловой системе —

слэш

, а в DNS —

точка

. А так же

DNS адрес

читается справа налево (от корневого домена к имени хоста) в отличии от пути в файловой системе Linux.

Доменное имя начинается с точки

(

корневого домена

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

доменное имя

полностью отражает

структуру иерархии DNS

. Часто (я бы сказал — всегда в повседневной жизни), последняя точка (обозначение корневого домена) в доменном имени опускается (то есть в браузере мы вводим не k-max.nam

e.

, а k-max.nam

e

). Итак, разобрав структуру доменного имени, мы незаметно подошли к понятию

FQDN

.

FQDN (англ. Fully Qualifed Domain Name, полностью определённое имя домена) — это имя домена, однозначно определяющее доменное имя и включающее в себя имена всех родительских доменов иерархии DNS, в том числе и корневого. Своеобразный аналог абсолютного пути в файловой системе. Давайте разберем вышесказанное на примере имени домена mail.k-max.name:

mail.k-max.name.
 |     |  |  | |
 |     |  |  | +-корневой домен
 |     |  |  +---домен первого уровня
 |     |  +------точка, разделяющая домены/части FQDN
 |     +---------домен второго уровня
 +---------------поддомен/домен третьего уровня, возможно - имя хоста

Различие между

FQDN

и обычным доменным (

неFQDN

) именем появляется при именовании доменов второго, третьего (и т. д.) уровня. Для

получения FQDN

требуется

обязательно

указать в доменном имени домены более высокого уровня (например, mail является доменным именем, однако FQDN имя выглядит как mail. k-max.name.). Максимальный размер FQDN — 255 байт, с ограничением в 63 байта на каждое имя домена.

Поддомены, коротко говоря, это — подчиненные домены. По большому счету, все домены в интернете являются подчиненными за исключением корневого. Например домен k-max является поддоменом домена name, а name, в свою очередь — поддоменом корневого домена.

Итак, на схеме выше мы рассмотрели корневой домен, следующим в иерархии идут домены первого/верхнего уровня, они же TLD, они же Top-Level Domain. К данным доменам относятся национальные домены (ru., ua. и др) и общие домены (com., net., и др). Существуют так же специализированные домены, которые не опубликованы в системе DNS, но используются программами (домен .onion используется анонимной сетью Tor для перехвата и последующей маршрутизации обращений к скрытым сервисам этой сети). Еще есть т.н. зарезервированные доменные имена, определенные в RFC 2606 (Reserved Top Level DNS Names — Зарезервированные имена доменов верхнего уровня) определяет названия доменов, которые следует использовать в качестве примеров (например, в документации), а также для тестирования. К таким именам относятся например example.com, example.org и example.net, а также test, invalid и др. Ниже по иерархии, как видно, идут домены третьего уровня и т.д. Заканчивается доменная иерархия — именами хостов, которые задаются соответствующими ресурсными записями или хостовыми записями.

Ресурсные записи

Ресурсная запись

— это то, собственно ради чего в конечном счете и существует DNS.

Ресурсная запись

— это единица хранения и передачи информации в DNS. Каждая такая запись несет в себе

информацию соответствия

какого-то

имени

и

служебной информации

в DNS, например соответствие имени домена — IP адреса.

Запись ресурса состоит из следующих полей:

• имя (NAME) — доменное имя, к которому привязана или которому «принадлежит» данная ресурсная запись, либо IP адрес. При отсутствии данного поля, запись ресурса наследуется от предыдущей записи.
• Time To Live (TTL) — дословно «время жизни» записи, время хранения записи в кэше DNS (после указанного времени запись удаляется), данное поле может не указываться в индивидуальных записях ресурсов, но тогда оно должно быть указано в начале файла зоны и будет наследоваться всеми записями.
• класс (CLASS) — определяет тип сети, (в 99,99% случаях используется IN (что обозначает — Internet). Данное поле было создано из предположения, что DNS может работать и в других типах сетей, кроме TCP/IP)
• тип (TYPE) — тип записи синтаксис и назначение записи
• данные (DATA) — различная информация, формат и синтаксис которой определяется типом.

При этом, возможно использовать следующие символы:

• ; — Вводит комментарий
• # — Также вводит комментарии (только в версии BIND 4.9)
• @ — Имя текущего домена
• ( ) — Позволяют данным занимать несколько строк
• * — Метасимвол (только в поле имя)

Со всем набором ресурсных записей можно ознакомиться в

wikipedia

. Наиболее часто применяемые

ресурсные записи следующими

(далее, мы обязательно рассмотрим их на практике):

• A — (address record/запись адреса) отображают имя хоста (доменное имя) на адрес IPv4. Для каждого сетевого интерфейса машины должна быть сделана одна A-запись. Например, следующая запись отображает доменное имя k-max.name. в IPv4 адрес хоста 81.177.139.65 (поле NAME — k-max.name., поле TTL — 86400, поле CLASS — IN, поле DATA — 81. 177.139.65):
  

  k-max.name.             86400   IN      A       81.177.139.65

• AAAA (IPv6 address record) аналогична записи A, но для IPv6.
• CNAME (canonical name record/каноническая запись имени (псевдоним)) — отображает алиас на реальное имя (для перенаправления на другое имя), например, следующая запись задает алиас ftp для хоста www.k-max.name.:
  

  ftp             86400   IN      CNAME       www.k-max.name.

• MX (mail exchange) — указывает хосты для доставки почты, адресованной домену. При этом поле NAME указывает домен назначения, поля TTL, CLASS — стандартное значение, поле TYPE принимает значение MX, а поле DATA указывает приоритет и через пробел — доменное имя хоста, ответственного за прием почты. Например, следующая запись показывает, что для домена k-max.name направлять почту сначала на mx.k-max.name, затем на mx2.k-max.name, если с mx.k-max.name возникли какие-то проблемы. При этом, для обоих MX хостов должны быть соответствующие A-записи:
  

  k-max.name.             17790   IN      MX      10 mx.k-max.name.
  k-max.name.             17790   IN      MX      20 mx2.k-max.name.

• NS (name server/сервер имён) указывает на DNS-сервер, обслуживающий данный домен. Вернее будет сказать — указывают сервера, на которые делегирован данный домен. Если записи NS относятся к серверам имен для текущей зоны, доменная система имен их практически не использует. Они просто поясняют, как организована зона и какие машины играют ключевую роль в обеспечении сервиса имен. Например, зону name. обслуживают следующие NS:
  

  name.                   5772    IN      NS      l6.nstld.com.
  name.                   5772    IN      NS      m6. nstld.com.
  name.                   5772    IN      NS      c6.nstld.com.
  name.                   5772    IN      NS      j6.nstld.com.
  ......

  
  зону k-max.name обслуживают:

  k-max.name.             1577    IN      NS      ns2.jino.ru.
  k-max.name.             1577    IN      NS      ns1.jino.ru.

• PTR (pointer) — отображает IP-адрес в доменное имя (о данном типе записи поговорим ниже в разделе обратного преобразования имен).
• SOA (Start of Authority/начальная запись зоны) — описывает основные/начальные настройки зоны, можно сказать, определяет зону ответственности данного сервера. Для каждой зоны должна существовать только одна запись SOA и она должна быть первая. Поле Name содержит имя домена/зоны, поля TTL, CLASS — стандартное значение, поле TYPE принимает значение SOA, а поле DATA состоит из нескольких значений, разделенных пробелами: имя главного DNS (Primary Name Server), адрес администратора зоны, далее в скобках — серийный номер файла зоны (Serial number). При каждом внесении изменений в файл зоны данное значение необходимо увеличивать, это указывает вторичным серверам, что зона изменена, и что им необходимо обновить у себя зону. Далее — значения таймеров (Refresh — указывает, как часто вторичные серверы должны опрашивать первичный, чтобы узнать, не увеличился ли серийный номер зоны, Retry — время ожидания после неудачной попытки опроса, Expire — максимальное время, в течение которого вторичный сервер может использовать информацию о полученной зоне, Minimum TTL — минимальное время, в течение которого данные остаются в кэше вторичного сервера). Ниже в примере приведено 2 одинаковые записи SOA (хотя вторая и записана в несколько строк), но они одинаковы по значению и формат записи второй более понятен в силу его структурированности:
  

  k-max.name.             86400   IN      SOA     ns1.jino.ru. hostmaster.jino.ru. 2011032003 28800 7200 604800 86400
  k-max.name.              86400   IN      SOA     ns1.jino.ru. hostmaster.jino.ru. (
                                                    2011032003 ; serial (серийный номер)
                                                    28800 ; refresh (обновление)
                                                    7200 ; retry (повторная попытка)
                                                    604800 ; expire (срок годности)
                                                    86400) ; minimum TTL (минимум)

• SRV (server selection) — указывают на сервера, обеспечивающие работу тех или иных служб в данном домене (например Jabber и Active Directory).

Давайте рассмотрим, что есть

Делегирование

.

Делегирование

(корректнее сказать

делегирование ответственности

) — это операция

передачи ответственности за часть дерева доменных имен (зону)

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

корневой домен

делегирует полномочия серверам отвечающим за TLD, TLD же в свою очередь, делегируют полномочия управления зонами — серверам второго уровня, иногда на этом цепочка заканчивается, но бывает, что делегирование простирается до 4 и даже 5 уровней.

Для бОльшего понимания, приведу пример. Делегирование управления поддоменом k-max.name другому лицу (в моем случае — хостеру) приводит к созданию новой зоны, которая администрируется независимо от остального пространства имен (независимо от вышестоящего name.). Зона k-max.name после делегирования полномочий теперь не зависит от name. и может содержать все (вернее сказать — любые имена, которые я захочу) доменные имена, которые заканчиваются на *.k-max.name. С другой стороны, зона name. содержит только доменные имена, оканчивающиеся на *.name., но не входящие в делегированные этой зоны, такие, например, как k-max.name или a-lab.name или любая другая. k-max.name может быть поделен на поддомены с именами вроде mail.k-max.name, ftp.k-max.name и некоторые из этих поддоменов могут быть выделены в самостоятельные зоны, и ответственность за данные зоны может так же быть делегирована. Если ftp.k-max.name будет являться самостоятельной зоной, то зона k-max.name не будет содержать доменные записи, которые заканчиваются на *.ftp.k-max.name.

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

Серверы DNS

Выше, при рассмотрении типов ресурсных записей я упоминал о

первичном

и

вторичном

сервере. Кроме данных типов, существует еще один тип —

кэширующий

.

Главный сервер DNS (он же первичный, он же master, он же primary) — это авторитетный сервер (иногда называют — авторитативный, как правильнее называть — не знаю), который хранит главную копию файла данных зоны, сопровождаемую администратором системы.

Вторичный сервер — тоже является авторитетным, но он копирует главный файл зоны с первичного сервера. Отличие главного от вторичного лишь в том, что главный загружает свою информацию из конфигурационных файлов зоны, а вторичный — загружает (получает) настройки зон — с главного сервера. Вторичный DNS может получать свои данные и от другого вторичного сервера. Любой запрос относительно хоста в пределах зоны, за которую отвечает авторитетный сервер, будет в конце концов передан одному из этих серверов (главному или вторичному). Вторичных серверов может быть сколько угодно много. В зависимости от настроек, главный сервер может посылать вторичному сигнал о изменении зоны, при этом вторичный, получив сигнал производит копирование. Данное действие называется трансфер зоны (zone transfer). Существует два механизма копирования зоны: полное копирование (AXFR) и инкрементальное (incremental) копирование зоны (IXFR).

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

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

Клиенты DNS (resolver)

Как же программы на конечных машинах знают куда и в каком виде посылать запросы DNS?

Они этого не знают. Для разрешения имен и IP адресов клиентскими приложениями используется

библиотека Resolver

. Это не какое-то специальное приложение, это функциональность системы (ядра). Т.о. приложения посылают

системные вызовы

gethostbyname(2) и gethostbyaddr(2), а ядро уже на основании настроек в файле /etc/nsswitch.conf определяет по какому пути ему далее действовать. Данный файл определяет какие сервисы (будь то

файл /etc/hosts

или

DNS

) и в каком порядке использовать. В ранних версиях библиотеки Linux —

libc

, использовался

файл /etc/host.conf.

Вот фрагмент файла, который нас интересует:

root@DNS:~# cat /etc/nsswitch.conf
......
hosts:          files dns
networks:       files

Две строки данного фрагмента указывают ядру производить преобразование имен хостов в IP (строка

hosts: files dns

) сначала из

файла hosts

, затем силами

DNS

, а так же преобразование имен сетей в IP (строка

networks: files

) с помощью файла /etc/network.Возможны так же параметры

nis

или

nisplu

, определяющие использовать

Network Information System (NIS)

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

Если согласно /etc/nsswitch.conf запрос отправляется DNS, то используются настройки из файла /etc/resolv.conf, который определяет

какие

серверы DNS использовать. Вот типичный пример файла /etc/resolv.conf:

root@DNS:~# cat /etc/resolv.conf
nameserver 192.168.1.1
nameserver 192.168.1.2
domain  examle.com

Директива

nameserver

определяет адрес

сервера доменных имен

, который будет выполнять рекурсивные запросы resolver. В данном файле указано

использовать север имен

сначала 192.168.1.1 затем, если первый не смог обработать запрос, 192.168.1.2. Рекомендуется не использовать более 3х

параметров nameserver

. Если

опция nameserver

не задана, то резолвер попытается соединиться с сервером на локальном хосте.

Параметр domain

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

опция search

, которая задает дополнительные домены, в которых необходимо произвести поиск и разрешение имени хоста. Опции search и domain нельзя использовать совместно.

Кроме кэша на ДНС сервере, существуют кэши интернет-браузеров, кэши резолверов. Довольно прозрачную картину предоставляет Wikipedia:

Запросы DNS

В DNS имеются следующие типы запросов:

итеративный

(он же

прямой

),

обратный

и

рекурсивный

.

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

Рекурсивный запрос посылает DNS серверу доменное имя и просит возвратить IP адрес запрошенного домена. При этом сервер может обращаться к другим DNS серверам.

Обратный запрос посылает IP и просит вернуть доменное имя.

Любой DNS-server должен отвечать на итеративные запросы. Возможно настроить DNS отвечать и на рекурсивные запросы. Если DNS не настроен отвечать на рекурсивные запросы, он обрабатывает их как итеративные.

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

Давайте разберем, что тут нарисовано по шагам:

1. Клиент (браузер, почтовая программа, либо любое другое приложение) отправляет запрос резолверу, резолвер на основании указанных конфигов определяет адрес настроенного сервера имен.
2. Резолвер посылает запрос указанному серверу имен.
3. Сервер имен принимает данный рекурсивный запрос и, т.к. не имеет информации ни о домене, ни, возможно, даже о зоне name., отправляет рекурсивный (или нерекурсивный в зависимости от настроек) запрос серверу, отвечающему за корневую зону.
4. Сервер корневой зоны не обрабатывает рекурсивные запросы, в результате обрабатывает данный запрос как итеративный и возвращает имя и адрес сервера, авторитетного за зону name.
5. Сервер последовательно продолжает опрашивать авторитативные сервера для последующих зон, в порядке убывания уровня зон в имени
6. пока не получает удовлетворительный ответ, данных шагов может быть больше, в зависимости от длины доменного имени
7. и «вложенности» доменных имен.
8. В итоге, сервер получает необходимый ответ от сервера имен, хранящего необходимую ресурсную запись о хосте.
9. Сервер провайдера локальной сети возвращает резолверу клиента запрошенные данные.

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

какому из корневых серверов наш DNS-сервер отправит запрос?

Для решения данного вопроса DNS-серверы BIND используют метрику, называемую временем отклика (roundtrip time, или RTT), для выбора среди авторитативных DNS-серверов одной зоны. RTT определяет задержку, с которой приходит ответ на запросы от удаленного сервера. Каждый раз, при передаче запроса удаленному серверу, DNS-сервер BIND запускает внутренний таймер. Таймер останавливается при получении ответа, и метрика фиксируется локальным сервером. Если приходится выбирать один из нескольких авторитативных серверов, выбор падает на сервер с наименьшим показателем RTT.

До того как BIND впервые послал запрос какому-либо серверу и получил от него ответ, удаленному серверу присваивается случайное значение RTT, которое меньше, чем все прочие, полученные на основании замеров. Таким образом, DNS BIND гарантированно опросит все авторитативные серверы для определенной зоны случайным образом, прежде чем начнет выбирать предпочтительный на основании метрики.

Ответы DNS сервера

Ответы DNS бывают следующего типа:

• Авторитативный ответ (authoritative response) приходит от серверов, являющихся ответственными за зону.
• Неавторитативный ответ (non authoritative response) приходит от серверов, которые не отвечают за зону (от кэширующих).

Ответ DNS обычно содержит следующую информацию:

• Запись заголовка — служебную информацию о запросе.
• Запись запроса — повторяет отправленный запрос.
• Запись ответа — собственно, сам ответ.
• Записи авторитетных серверов — информацию об авторитетных серверах, хранящих информацию по текущему запросу.
• Дополнительную информацию — дополнительные записи, например адреса NS-серверов.

Вышенаписанное наглядно подтверждается утилитой dig:

root@DNS:~# dig ya.ru
; <<>> DiG 9.7.3 <<>> ya.ru (раздел заголовка)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 53499
;; flags: qr rd ra; QUERY: 1, ANSWER: 7, AUTHORITY: 2, ADDITIONAL: 3

;; QUESTION SECTION: (раздел запроса)
;ya.ru.                         IN      A

;; ANSWER SECTION: (раздел ответа)
ya.ru.                  4813    IN      A       87.250.250.203
ya.ru.                  4813    IN      A       87.250.251.3
ya.ru.                  4813    IN      A       93.158.134.3
ya.ru.                  4813    IN      A       93.158.134.203
ya.ru.                  4813    IN      A       213.180.204.3
ya.ru.                  4813    IN      A       77.88.21.3
ya.ru.                  4813    IN      A       87.250.250.3

;; AUTHORITY SECTION: (авторитативные сервера)
ya.ru.                  4813    IN      NS      ns1.yandex.ru.
ya.ru.                  4813    IN      NS      ns5.yandex.ru.

;; ADDITIONAL SECTION: (дополнительная информация - адреса авторитативных name servers)
ns5.yandex.ru.          345565  IN      A       213.180.204.1
ns1.yandex.ru.          345565  IN      A       213.180.193.1
ns1.yandex.ru.          3565    IN      AAAA    2a02:6b8::1

;; Query time: 7 msec
;; SERVER: 192.168.1.1#53(192.168.1.1)
;; WHEN: Sat Jul  2 23:02:45 2011
;; MSG SIZE  rcvd: 238

Обратное преобразование имен

DNS

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

Обратное преобразование имен

или

обратным отображением

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

DNS

не может эффективно выполнять поиск по IP адресу в такой базе.

Для обратного преобразования в DNS используется специальный домен in-addr.arpa.

Ресурсные записи в данном домене в

поле Name

содержат

IP-адреса,

в

поле Type

—

PTR

, а в

поле Data

—

FQDN-имя

соответствующее данному IP.

На схеме представлена структура домена arpa. Думаю, что тут все довольно наглядно. Домен arpa. имеет 2 поддомена in-addr и ip6, отвечающие за IPv4 и IPv6 адреса соответственно. Домен in-addr.arpa. имеет от *.0.in-addr.arpa. до *.255.in-addr.arpa. поддоменов, каждый из которых так же имеет по 256 поддоменов.

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

Наглядно приведенную схему можно представить командами:

[root@DNS~]# dig www.ru
...
;; QUESTION SECTION:
;www.ru                                IN      A

;; ANSWER SECTION:
www.ru                 52119   IN      A       194.87.0.50
...
[root@DNS~]# dig -x 194.87.0.50
...
;; QUESTION SECTION:
;50.0.87.194.in-addr.arpa.      IN      PTR

;; ANSWER SECTION:
50.0.87.194.in-addr.arpa. 30385 IN      PTR     www.ru
....

При этом, команду dig -x 194.87.0.50 правильнее будет представить как dig 50.0.87.194.in-addr.arpa., то есть записи в поддоменах *.in-addr.arpa. представлены в так называемой обратной нотации (или reverse форме), то есть хосту с IP 194.87.0.50 будет соответствовать PTR-запись, имеющая FQDN 50.0.87.194.in-addr.arpa., которая в свою очередь указывает на домен

www.ru

Хочется отметить, что чаще всего за обратную зону и ее редактирование отвечает поставщик интернета.

Как и обещал, описываю ресурсную запись PTR в домене IN-ADDR.ARPA, соответствующая приведенной выше записи А для машины www.ru. будет иметь такой вид:

50.0.87.194 IN PTR www.ru

Имя 50.0.87.194 не заканчивается точкой и поэтому является относительным. Вопрос: относительным относительно чего? Ни в коем случае не относительно «www.ru». Для того чтобы эта запись была FQDN, домен по умолчанию должен называться «IN-ADDR.ARPA.». Этого можно добиться либо поместив записи PTR в отдельный файл, в котором доменное имя зоны по умолчанию — IN-ADDR.ARPA. (заданный в файле начальной загрузки демона named), либо изменив этот домен с помощью директивы $ORIGIN. Если домен по умолчанию определен как 0.87.194.IN-ADDR.ARPA., то запись можно представить так:

80 IN PTR www.ru

Регистрация доменных имен

В двух словах хотел бы затронуть вопрос

регистрации доменных имен

.

Регистрация доменов — это действие, посредством которого клиент сообщает регистратору, каким DNS-серверам следует делегировать поддомен, и также снабжает регистратора контактной и платежной информацией. Регистратор передает информацию в соответствующий реестр. Чаще всего, это процесс внесения в реестр зоны первого уровня (то есть в TLD зоны ru, com или др.), записи о новом доменном подимени.

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

Уровни доменов, для которых необходима обязательная регистрация лица, ответственного за домен, следующие:

• корневой домен
• все домены первого уровня (TLD)
• некоторые домены второго уровня (например, com.ru или co.uk)

Регистратором для корневого домена

является организация

ICANN

. Чтобы стать регистратором доменов в зонах второго уровня (.com .net .org .biz .info .name .mobi .asia .aero .tel .travel .jobs …), необходимо получить аккредитацию ICANN.

Правила регистрации в международных (gTLD — com., org, и др.) доменах устанавливаются ICANN. Правила регистрации в национальных (ccTLD — ru, us и др.) доменах устанавливаются их регистраторами и/или органами власти соответствующих стран, например единые правила для всех регистраторов в доменах .ru, и.рф задаются Координационным центром национального домена сети Интернет. Для многих доменов (в том числе и для ru) регистратор не единственный. При наличии нескольких регистраторов все они должны использовать единую (централизованную или распределённую) базу данных для исключения конфликтов и обеспечения уникальности доменного имени.

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

В завершение статьи хочу отметить так же о таком маркетинговом нюансе, что иногда домены второго уровня называют именами доменов ПЕРВОГО уровня, тем самым «опуская» значение корневого домена и принимая за корневой домен — домены TLD.

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

Резюме

Итак, в сегодняшней статье я постарался как можно понятней описать работы доменной системы имен. Надеюсь, это у меня получилось. Мы рассмотрели иерархическую структуру базы данных DNS, а так же рассмотрели процессы взаимодействия клиентов и серверов DNS, а так же разновидности серверов DNS. В следующей статье я рассмотрю практические вопросы установки и настройки DNS сервера BIND на Linux. Буду рад Вашим комментариям.

Что еще почитать:

man (5) resolver:

http://www.opennet.ru/man.shtml?topic=resolver&category=5&russian=0

man (3) gethostbyname:

http://www.opennet.ru/cgi-bin/opennet/man.cgi?topic=gethostbyname&category=3
Linux Network Administrators Guide v2 Russian: скачать.

RFC882, 1035, 1183

Разместил с разрешения mcsim85, у которого еще нет полноценного аккаунта на хабре, но который за такие качественный статьи безусловно его заслуживает! На всякий случай ссылка на оригинал.

Проверка работоспособности DNS для поддержки репликации каталогов

• 
  05/31/2017
• Чтение занимает 8 мин

В этой статье

Область применения. Windows Server 2016, Windows Server 2012 R2, Windows Server 2012Applies To: Windows Server 2016, Windows Server 2012 R2, Windows Server 2012

Чтобы проверить параметры системы доменных имен (DNS), которые могут помешать репликации Active Directory, можно начать с выполнения базового теста, обеспечивающего правильную работу DNS для вашего домена.To check Domain Name System (DNS) settings that might interfere with Active Directory replication, you can begin by running the basic test that ensures that DNS is operating properly for your domain. После выполнения базового теста можно протестировать другие аспекты функций DNS, включая регистрацию записей ресурсов и динамическое обновление.After you run the basic test, you can test other aspects of DNS functionality, including resource record registration and dynamic update.

Хотя вы можете выполнять этот тест основных функций DNS на любом контроллере домена, обычно этот тест выполняется на контроллерах домена, на которых могут возникать проблемы репликации, например контроллеры домена, которые сообщают о событиях с идентификаторами 1844, 1925, 2087 или 2088 в журнале DNS службы каталогов Просмотр событий.Although you can run this test of basic DNS functionality on any domain controller, typically you run this test on domain controllers that you think may be experiencing replication issues, for example, domain controllers that report Event IDs 1844, 1925, 2087, or 2088 in the Event Viewer Directory Service DNS log.

Выполнение базовой проверки DNS контроллера доменаRunning the domain controller basic DNS test

Основная проверка DNS проверяет следующие аспекты функциональности DNS:The basic DNS test checks the following aspects of DNS functionality:

• Подключение: Тест определяет, зарегистрированы ли контроллеры домена в DNS, может ли быть обращена команда ping , а также подключение к серверу Lightweight Directory (протокол LDAP/RPC).Connectivity: The test determines whether domain controllers are registered in DNS, can be contacted by the ping command, and have Lightweight Directory Access Protocol / remote procedure call (LDAP/RPC) connectivity. Если проверка подключения завершается сбоем на контроллере домена, другие тесты для этого контроллера домена не выполняются.If the connectivity test fails on a domain controller, no other tests are run against that domain controller. Проверка подключения выполняется автоматически перед запуском любого другого теста DNS.The connectivity test is performed automatically before any other DNS test is run.
• Ключевые службы: Тест подтверждает, что следующие службы работают и доступны на проверенном контроллере домена: служба клиента DNS, служба сетевого входа в систему, служба центр распространения ключей (KDC) и служба DNS-сервера (если служба DNS установлена на контроллере домена).Essential services: The test confirms that the following services are running and available on the tested domain controller: DNS Client service, Net Logon service, Key Distribution Center (KDC) service, and DNS Server service (if DNS is installed on the domain controller).
• Конфигурация клиента DNS: Тест подтверждает доступность DNS-серверов на всех сетевых адаптерах клиентского компьютера DNS.DNS client configuration: The test confirms that DNS servers on all network adapters of the DNS client computer are reachable.
• Регистрация записей ресурсов: Тест подтверждает, что запись ресурса узла (A) каждого контроллера домена зарегистрирована по крайней мере на одном из DNS-серверов, настроенных на клиентском компьютере.Resource record registrations: The test confirms that the host (A) resource record of each domain controller is registered on at least one of the DNS servers that is configured on the client computer.
• Зона и начало центра (SOA): Если на контроллере домена работает служба DNS-сервера, тест подтверждает, что Active Directory зона домена и запись ресурса начальной зоны (SOA) для зоны домена Active Directory.Zone and start of authority (SOA): If the domain controller is running the DNS Server service, the test confirms that the Active Directory domain zone and start of authority (SOA) resource record for the Active Directory domain zone are present.
• Корневая зона: Проверяет наличие корневой зоны (.).Root zone: Checks whether the root (.) zone is present.

Членство в группах «Администраторы предприятия» (или эквивалентное) является минимальным требованием для выполнения этих процедур.Membership in Enterprise Admins, or equivalent, is the minimum required to complete these procedures.

Для проверки основных функций DNS можно использовать следующую процедуру.You can use the following procedure to verify basic DNS functionality.

Чтобы проверить основные функциональные возможности DNS:To verify basic DNS functionality:

1. На контроллере домена, который требуется протестировать, или на компьютере, входящем в домен, на котором установлены средства домен Active Directory Services (AD DS), откройте командную строку от имени администратора.On the domain controller that you want to test or on a domain member computer that has Active Directory Domain Services (AD DS) Tools installed, open a command prompt as an administrator. Чтобы открыть командную строку от имени администратора, нажмите кнопку Пуск .To open a command prompt as an administrator, click Start .

2. В поле Начать поиск введите Командная строка.In Start Search, type Command Prompt.

3. Вверху меню Пуск щелкните правой кнопкой мыши элемент Командная строка и выберите пункт Запуск от имени администратора.At the top of the Start menu, right-click Command Prompt, and then click Run as administrator. Если отобразится диалоговое окно Контроль учетных записей пользователей, подтвердите, что отображаемое в нем действие — то, которое требуется, и нажмите кнопку Продолжить.If the User Account Control dialog box appears, confirm that the action it displays is what you want, and then click Continue.

4. В командной строке введите следующую команду и нажмите клавишу ВВОД: dcdiag /test:dns /v /s:<DCName> /DnsBasic /f:dcdiagreport.txtAt the command prompt, type the following command, and then press ENTER: dcdiag /test:dns /v /s:<DCName> /DnsBasic /f:dcdiagreport.txt
   Замените фактическое различающееся имя, имя NetBIOS или DNS-имя контроллера домена для < DCName > .Substitute the actual distinguished name, NetBIOS name, or DNS name of the domain controller for <DCName>. В качестве альтернативы можно проверить все контроллеры домена в лесу, введя/e: вместо/s:.As an alternative, you can test all the domain controllers in the forest by typing /e: instead of /s:.
   Параметр/f указывает имя файла, которое в предыдущей команде dcdiagreport.txt.The /f switch specifies a file name, which in the previous command is dcdiagreport.txt. Если требуется поместить файл в расположение, отличное от текущего рабочего каталога, можно указать путь к файлу, например/f:c:reportsdcdiagreport.txt.If you want to place the file in a location other than the current working directory, you can specify a file path, such as /f:c:reportsdcdiagreport.txt.

5. Откройте файл dcdiagreport.txt в блокноте или в аналогичном текстовом редакторе.Open the dcdiagreport.txt file in Notepad or a similar text editor. Чтобы открыть файл в блокноте, в командной строке введите Notepad dcdiagreport.txt и нажмите клавишу ВВОД.To open the file in Notepad, at the command prompt, type notepad dcdiagreport.txt, and then press ENTER. Если файл помещен в другой рабочий каталог, укажите путь к файлу.If you placed the file in a different working directory, include the path to the file. Например, если вы поместили файл в к:Репортс, введите Notepad c:reportsdcdiagreport.txt и нажмите клавишу ВВОД.For example, if you placed the file in c:reports, type notepad c:reportsdcdiagreport.txt, and then press ENTER.

6. Перейдите к сводной таблице в нижней части файла.Scroll to the Summary table near the bottom of the file.
   Обратите внимание на имена всех контроллеров домена, которые сообщают о состоянии «предупреждать» или «ошибка» в сводной таблице.Note the names of all the domain controllers that report «Warn» or «Fail» status in the Summary table. Попробуйте определить, существует ли проблемный контроллер домена, выполнив поиск по строке «DC: DCName», где DCName — фактическое имя контроллера домена.Try to determine if there is a problem domain controller by finding the detailed breakout section by searching for the string «DC: DCName,» where DCName is the actual name of the domain controller.

При появлении очевидных изменений конфигурации внесите необходимые изменения.If you see obvious configuration changes that are required, make them, as appropriate. Например, если вы заметили, что один из контроллеров домена имеет очевидно неверный IP-адрес, его можно исправить.For example, if you notice that one of your domain controllers has an obviously incorrect IP address, you can correct it. Затем повторно запустите тест.Then, rerun the test.

Чтобы проверить изменения конфигурации, повторно выполните команду Dcdiag/test: DNS/v с параметром/e: или/s:, как нужно.To validate the configuration changes, rerun the Dcdiag /test:DNS /v command with the /e: or /s: switch, as appropriate. Если на контроллере домена не включена версия IP 6 (IPv6), то следует рассчитывать на сбой проверки узла (AAAA) в тесте, но если IPv6 не используется в сети, эти записи не требуются.If you do not have IP version 6 (IPv6) enabled on the domain controller, you should expect the host (AAAA) validation portion of the test to fail, but if you are not using IPv6 on your network, these records are not necessary.

Проверка регистрации записи ресурсаVerifying resource record registration

Конечный контроллер домена использует запись ресурса DNS-псевдонима (CNAME) для указания партнера по репликации исходного контроллера домена.The destination domain controller uses the DNS alias (CNAME) resource record to locate its source domain controller replication partner. Несмотря на то, что контроллеры домена под управлением Windows Server (начиная с Windows Server 2003 с пакетом обновления 1 (SP1)) могут обнаружить исходные партнеры репликации с помощью полных доменных имен или, если это не удается, требуется NetBIOS-намессе запись ресурса псевдонима (CNAME), которая должна быть проверена на правильность работы DNS.Although domain controllers running Windows Server (starting with Windows Server 2003 with Service Pack 1 (SP1)) can locate source replication partners by using fully qualified domain names (FQDNs)or, if that fails, NetBIOS namesthe presence of the alias (CNAME) resource record is expected and should be verified for proper DNS functioning.

Для проверки регистрации записей ресурсов, включая регистрацию записи ресурса псевдонима (CNAME), можно использовать следующую процедуру.You can use the following procedure to verify resource record registration, including alias (CNAME) resource record registration.

Проверка регистрации записи ресурсаTo verify resource record registration

1. Откройте командную строку как администратор.Open a command prompt as an administrator. Чтобы открыть командную строку от имени администратора, нажмите кнопку Пуск.To open a command prompt as an administrator, click Start. В поле Начать поиск введите Командная строка.In Start Search, type Command Prompt.
2. Вверху меню Пуск щелкните правой кнопкой мыши элемент Командная строка и выберите пункт Запуск от имени администратора.At the top of the Start menu, right-click Command Prompt, and then click Run as administrator. Если отобразится диалоговое окно Контроль учетных записей пользователей, подтвердите, что отображаемое в нем действие — то, которое требуется, и нажмите кнопку Продолжить.If the User Account Control dialog box appears, confirm that the action it displays is what you want, and then click Continue. С помощью средства Dcdiag можно проверить регистрацию всех записей ресурсов, необходимых для расположения контроллера домена, выполнив dcdiag /test:dns /DnsRecordRegistration команду.You can use the Dcdiag tool to verify registration of all the resource records that are essential for domain controller location by running the dcdiag /test:dns /DnsRecordRegistration command.

Эта команда проверяет регистрацию следующих записей ресурсов в DNS:This command verifies registration of the following resource records in DNS:

• псевдоним (CNAME): запись ресурса на основе глобального уникального идентификатора (GUID), которая находит партнера репликации.alias (CNAME): the globally unique identifier (GUID)-based resource record that locates a replication partner
• узел (A): запись ресурса узла, которая содержит IP-адрес контроллера домена.host (A): the host resource record that contains the IP address of the domain controller
• Записи ресурсов LDAP SRV: службы (SRV), которые находят LDAP-серверы.LDAP SRV: the service (SRV) resource records that locate LDAP servers
• GC SRV : записи ресурсов службы (SRV), которые находят серверы глобального каталогаGC SRV : the service (SRV) resource records that locate global catalog servers
• PDC SRV : записи ресурсов службы (SRV), которые находят хозяева операций эмулятора основного контроллера домена.PDC SRV : the service (SRV) resource records that locate primary domain controller (PDC) emulator operations masters

Для проверки регистрации записи ресурса псевдонима (CNAME) можно использовать следующую процедуру.You can use the following procedure to verify alias (CNAME) resource record registration alone.

Проверка регистрации записи ресурса псевдонима (CNAME)To verify alias (CNAME) resource record registration

1. Откройте оснастку DNS.Open the DNS snap-in. Чтобы открыть службу DNS, нажмите кнопку Пуск.To open DNS, click Start. В окне начать поиск введите днсмгмт. msc и нажмите клавишу ВВОД.In Start Search, type dnsmgmt.msc, and then press ENTER. Если откроется диалоговое окно Контроль учетных записей пользователей, убедитесь, что оно отображает нужное действие, и нажмите кнопку продолжить.If the User Account Control dialog box appears, confirm that it displays the action you want, and then click Continue.
2. Используйте оснастку DNS, чтобы выбрать любой контроллер домена, на котором работает служба DNS-сервера, где на сервере размещается зона DNS с тем же именем, что и домен Active Directory контроллера домена.Use the DNS snap-in to locate any domain controller that is running the DNS Server service, where the server hosts the DNS zone with the same name as the Active Directory domain of the domain controller.
3. В дереве консоли щелкните зону с именем _msdcs. Dns_Domain_Name.In the console tree, click the zone that is named _msdcs.Dns_Domain_Name.
4. В области сведений убедитесь, что имеются следующие записи ресурсов: запись ресурса псевдонима (CNAME) с именем Dsa_Guid. _msdcs. Dns_Domain_Name и соответствующую запись ресурса узла (a) для имени DNS-сервера.In the details pane, verify that the following resource records are present: an alias (CNAME) resource record that is named Dsa_Guid._msdcs.Dns_Domain_Name and a corresponding host (A) resource record for the name of the DNS server.

Если запись ресурса псевдонима (CNAME) не зарегистрирована, убедитесь, что динамическое обновление работает правильно.If the alias (CNAME) resource record is not registered, verify that dynamic update is functioning properly. Используйте тест в следующем разделе, чтобы проверить динамическое обновление.Use the test in the following section to verify dynamic update.

Проверка динамического обновленияVerifying dynamic update

Если основная проверка DNS показывает, что записи ресурсов не существуют в DNS, используйте динамический тест обновления, чтобы определить, почему служба сетевого входа в систему не зарегистрировала записи ресурсов автоматически.If the basic DNS test shows that resource records do not exist in DNS, use the dynamic update test to determine why the Net Logon service did not register the resource records automatically. Чтобы убедиться, что Active Directory зона домена настроена на принятие безопасных динамических обновлений и на регистрацию тестовой записи (_dcdiag_test_record), выполните следующую процедуру.To verify that the Active Directory domain zone is configured to accept secure dynamic updates and to perform registration of a test record (_dcdiag_test_record), use the following procedure. Тестовая запись удаляется автоматически после теста.The test record is deleted automatically after the test.

Проверка динамического обновленияTo verify dynamic update

1. Откройте командную строку как администратор.Open a command prompt as an administrator. Чтобы открыть командную строку от имени администратора, нажмите кнопку Пуск.To open a command prompt as an administrator, click Start. В поле Начать поиск введите Командная строка.In Start Search, type Command Prompt. Вверху меню Пуск щелкните правой кнопкой мыши элемент Командная строка и выберите пункт Запуск от имени администратора.At the top of the Start menu, right-click Command Prompt, and then click Run as administrator. Если отобразится диалоговое окно Контроль учетных записей пользователей, подтвердите, что отображаемое в нем действие — то, которое требуется, и нажмите кнопку Продолжить.If the User Account Control dialog box appears, confirm that the action it displays is what you want, and then click Continue.
2. В командной строке введите следующую команду и нажмите клавишу ВВОД: dcdiag /test:dns /v /s:<DCName> /DnsDynamicUpdateAt the command prompt, type the following command, and then press ENTER: dcdiag /test:dns /v /s:<DCName> /DnsDynamicUpdate
   Замените различающееся имя, имя NetBIOS или DNS-имя контроллера домена для < DCName > .Substitute the distinguished name, NetBIOS name, or DNS name of the domain controller for <DCName>. В качестве альтернативы можно проверить все контроллеры домена в лесу, введя/e: вместо/s:.As an alternative, you can test all the domain controllers in the forest by typing /e: instead of /s:. Если IPv6 не включен на контроллере домена, следует рассчитывать на сбой записи ресурса узла (AAAA) в тесте, что является нормальным условием, когда IPv6 не включен.If you do not have IPv6 enabled on the domain controller, you should expect the host (AAAA) resource record portion of the test to fail, which is a normal condition when IPv6 is not enabled.

Если безопасные динамические обновления не настроены, для их настройки можно использовать следующую процедуру.If secure dynamic updates are not configured, you can use the following procedure to configure them.

Включение безопасных динамических обновленийTo enable secure dynamic updates

1. Откройте оснастку DNS.Open the DNS snap-in. Чтобы открыть службу DNS, нажмите кнопку Пуск.To open DNS, click Start.
2. В окне начать поиск введите днсмгмт. msc и нажмите клавишу ВВОД.In Start Search, type dnsmgmt.msc, and then press ENTER. Если откроется диалоговое окно Контроль учетных записей пользователей, убедитесь, что оно отображает нужное действие, и нажмите кнопку продолжить.If the User Account Control dialog box appears, confirm that it displays the action you want and then click Continue.
3. В дереве консоли щелкните правой кнопкой мыши соответствующую зону и выберите пункт Свойства.In the console tree, right-click the applicable zone, and then click Properties.
4. На вкладке Общие убедитесь, что тип зоны — интегрированная Active Directory.On the General tab, verify that the zone type is Active Directory-integrated.
5. В меню динамические обновления щелкните только безопасные.In Dynamic Updates, click Secure only.

Регистрация записей ресурсов DNSRegistering DNS resource records

Если записи ресурсов DNS не отображаются в DNS для исходного контроллера домена, вы проверили динамические обновления и хотите зарегистрировать записи ресурсов DNS немедленно, можно принудительно выполнить регистрацию вручную с помощью следующей процедуры.If DNS resource records do not appear in DNS for the source domain controller, you have verified dynamic updates, and you want to register DNS resource records immediately, you can force registration manually by using the following procedure. Служба сетевого входа в систему на контроллере домена регистрирует записи ресурсов DNS, необходимые для того, чтобы контроллер домена находился в сети.The Net Logon service on a domain controller registers the DNS resource records that are required for the domain controller to be located on the network. Служба DNS-клиента регистрирует запись ресурса узла (A), на которую указывает запись псевдонима (CNAME).The DNS Client service registers the host (A) resource record that the alias (CNAME) record points to.

Регистрация записей ресурсов DNS вручнуюTo register DNS resource records manually

1. Откройте командную строку как администратор.Open a command prompt as an administrator. Чтобы открыть командную строку от имени администратора, нажмите кнопку Пуск.To open a command prompt as an administrator, click Start.
2. В поле Начать поиск введите Командная строка.In Start Search, type Command Prompt.
3. В верхней части меню Пуск щелкните правой кнопкой мыши пункт Командная строка и выберите команду Запуск от имени администратора.At the top of the Start, right-click Command Prompt, and then click Run as administrator. Если отобразится диалоговое окно Контроль учетных записей пользователей, подтвердите, что отображаемое в нем действие — то, которое требуется, и нажмите кнопку Продолжить.If the User Account Control dialog box appears, confirm that the action it displays is what you want, and then click Continue.
4. Чтобы вручную инициировать регистрацию записей ресурсов локатора контроллеров домена на исходном контроллере домена, в командной строке введите следующую команду и нажмите клавишу ВВОД: net stop netlogon && net start netlogonTo initiate registration of domain controller locator resource records manually on the source domain controller, at the command prompt, type the following command, and then press ENTER: net stop netlogon && net start netlogon
5. Чтобы инициировать регистрацию записи ресурса узла (A) вручную, в командной строке введите следующую команду и нажмите клавишу ВВОД: ipconfig /flushdns && ipconfig /registerdnsTo initiate registration of the host (A) resource record manually, at the command prompt, type the following command, and then press ENTER: ipconfig /flushdns && ipconfig /registerdns
6. В командной строке введите следующую команду и нажмите клавишу ВВОД: dcdiag /test:dns /v /s:<DCName>At the command prompt, type the following command, and then press ENTER: dcdiag /test:dns /v /s:<DCName> Замените различающееся имя, имя NetBIOS или DNS-имя контроллера домена для < DCName > .Substitute the distinguished name, NetBIOS name, or DNS name of the domain controller for <DCName>. Проверьте выходные данные теста, чтобы убедиться, что тесты DNS пройдены.Review the output of the test to ensure that the DNS tests passed. Если IPv6 не включен на контроллере домена, следует рассчитывать на сбой записи ресурса узла (AAAA) в тесте, что является нормальным условием, когда IPv6 не включен.If you do not have IPv6 enabled on the domain controller, you should expect the host (AAAA) resource record portion of the test to fail, which is a normal condition when IPv6 is not enabled.

Как изменить DNS-записи домена? | firstvds.ru

Управление DNS-записями домена (A, AAAA, MX, CNAME, TXT и др.) осуществляется через DNS-хостинг — на серверах имён, куда делегирован домен. Именно там хранятся все записи домена. 

Если ваш домен делегирован на серверы имён FirstVDS (ns1.firstvds.ru ns2.firstvds.ru), настройка записей выполняется через панель управления ISPmanager или, если она не используется, DNSmanager. Данные доступа к ним указаны в Инструкции к серверу в Личном кабинете — раздел Товары — Виртуальные серверы — выберите ваш сервер в списке, сверху «Инструкция».

Изменение DNS-записей через ISPmanager

Откройте панель ISPmanager и перейдите в раздел Домены — Доменные имена. Выберите нужный домен в списке, сверху «Записи». 

Здесь с помощью кнопок «Создать», «Изменить», «Удалить» можно управлять записями домена. 

После завершения редактирования записей вернитесь в раздел Домены — Доменные имена, выберите домен, настройки которого менялись, и нажмите сверху «Передать в NSы». Это немного ускорит процесс обновления записей на наших серверах имён.

Статус обновления можно увидеть на этой же странице в колонке «Состояние»:

Окончательно новые настройки вступят в силу после обновления глобального кэша DNS — оно занимает от 2 до 72 часов.

Изменение DNS-записей через DNSmanager

Откройте панель DNSmanager и перейдите в раздел Главное — Доменные имена. Выберите в списке нужный домен и сверху нажмите «Записи». 

Помните, что редактирование записей в DNSmanager работает только для доменов с типом master. Если у домена тип slave, значит, он создавался через панель ISPmanager, и записи нужно менять оттуда.

В меню «Записи» с помощью кнопок «Создать», «Изменить», «Удалить» можно редактировать записи домена. На серверах имён данные обновятся автоматически.

Новые записи начнут работать после обновления глобального DNS-кэша.

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

Что такое DNS. Сроки обновления DNS-записей. Как побыстрее начать работу с новым доменом. Типы записей DNS. Как настроить автоматические субдомены. Правильная переадресация на адрес без www в начале.

Что такое DNS

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

DNS (Domain Name System) – это система, обеспечивающая соответствие доменов ip-адресам. За хранение DNS-записей в интернете отвечает отдельный класс серверов – ns-сервера. Часть из них поддерживается администраторами доменных зон, другая – хостерами и интернет-провайдерами. У этих серверов есть своя иерархия, и обновляются записи на серверах не сразу: на некоторых – очень быстро, на других – в течение пары суток. Наиболее популярное программное обеспечение для ns-серверов называется BIND.

Сроки обновления DNS-записей

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

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

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

Что касается субдоменов, то зачастую, при их создании, они становятся доступны либо сразу, либо в течение 5-20 минут (должны обновиться записи на ns-серверах хостера).

Как побыстрее начать работу с новым доменом

Если вы зарегистрировали домен, либо изменили записи DNS, и вам срочно нужно начать работу с сайтом, вы можете добавить одну строчку в файл hosts вашей операционной системы (в Windows файл находится по адресу C:\WINDOWS\system32\drivers\etc, папка по умолчанию скрыта, и необходимо включить отображение скрытых папок в панели управления):

xxx.xxx.xxx.xxx site.ru

где xxx.xxx.xxx.xxx – ip-адрес сервера, site.ru – доменное имя вашего сайта.

Типы записей DNS

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

Запись NS необходима для указания DNS-сервера, обслуживающего ваш домен. Услуги своего DNS-сервера может предложить регистратор домена или хостинг-провайдер. Другой вариант – настроить собственный NS-сервер, и использовать его.

Запись A необходима для указания IP-адреса вашего сайта. IP-адрес предоставляет ваш хостинг-провайдер.

Запись AAAA используется для указания IP-адреса версии 6 (IPv6). На данный момент эти адреса еще не получили повсеместной поддержки.

Запись MX указывает на IP-адрес вашего почтового сервера. Необходима для доставки почты на почтовые ящики вашего домена.

Запись CNAME служит для указания одного домена в качестве адреса другого домена, то есть задает вашему домену или субдомену такой же IP-адрес, как и у домена, ссылку на который вы укажете в записи.

Запись PTR – это обратная запись, которая позволит при запросе IP-адреса вашего сайта, получить полное доменное имя. Важно, если вы используете для домена почтовый сервер, поскольку правильность PTR-записи проверяется многими почтовыми серверами (чтобы определить, не является ли письмо спамом). Эту запись устанавливает хостинг-провайдер. Проверить правильность записи можно с помощью специального сервиса. Зачастую проблем не возникает, и запись изначально установлена правильно.

Как настроить автоматические субдомены для каждого пользователя. Создание wildcard DNS-записи

Wildcard запись – это DNS-запись отвечающая за все субдомены *.site.ru. Указание такой записи может понадобиться, к примеру, для CMS (WordPressMU, Drupal), используемой для управления субдоменами.

Для создания такой записи необходимо зайти в раздел управления DNS-записями домена и добавить запись типа A, в качестве субдомена указать символ *, а в качестве адреса – IP-адрес сервера, зачастую совпадающий с IP-адресом, указанным для основного домена. Если вам не удается это сделать, нужно обратиться в техническую поддержку.

Заодно рассмотрим, как сконфигурировать Apache для работы с wildcard субдоменами. Пусть в конфигурационном файле сервера есть секция, описывающая виртуальный хост:

<VirtualHost *:80>
DocumentRoot "/home/site.ru"
ServerName "site.ru"
ServerAlias "www.site.ru"
ErrorLog logs/site.ru-error.log
CustomLog logs/site.ru-access.log common
</VirtualHost>

Вам необходимо лишь добавить псевдоним *.site.ru:

ServerAlias "www.site.ru" "*.site.ru"

Правильная переадресация с www.site.ru на site.ru. Редирект 301

Часть пользователей ссылается на ваш сайт, добавляя к адресу www. Другие www не добавляют. Это может негативно сказываться на продвижении в поисковых системах. Устраним проблему на примере сервера Apache:

1. Убедитесь, что на сервере включен модуль ModRewrite: в файле httpd.(.*)$ http://site.ru/$1 [L,R=301]

Это позволит правильно обработать запросы к вашему сайту, когда в конце домена стоит точка: site.ru. вместо site.ru

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

Александр Виниченко, системный администратор
для http://hosting101.ru

Типы DNS записей | 2IP.ua

Записи DNS, или Ресурсные записи (англ. Resource Records, RR) — единицы хранения и передачи информации в DNS.

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

• Запись A.
• Запись AAAA.
• Запись CNAME.
• Запись MX.
• Запись NS.
• TXT-запись.
• Запись PTR.
• Запись SOA.
• SRV-запись.

Запись A задает IP-адрес этого хоста. С помощью записей A выполняется запрос на преобразование имени домена в IP-адрес.

Запись AAAA (IPv6 address record) связывает имя хоста с адресом протокола IPv6. Например, запрос AAAA-записи на имя K.ROOT-SERVERS.NET вернет его IPv6 адрес — 2001:7fd::1

Запись типа CNAME (Canonical Name — Каноническое имя) позволяют присваивать хосту мнемонические имена. Если DNS при обращении к псевдониму обнаруживает запись CNAME, содержащую полное имя, DNS затем запрашивает полное имя домена.

Записи MX содержат определение хоста системы обмена почтой для почтовых сообщений, отправляемых в этот домен. С помощью записей этого типа и значений параметров конфигурации хостов системы обмена почтой в SMTP (Простой протокол передачи почты) определяются адреса хостов, обрабатывающих и перенаправляющих почту для этого домена. Каждому хосту системы обмена почтой должна соответствовать запись адреса хоста (A) в существующей области.

Запись NS указывает ответственный сервер для данного хоста.

Запись типа TXT обычно используется для текстового описания доменного имени.

Запись PTR (pointer) или запись указателя связывает IP хоста с его каноническим именем. Например, (на момент написания), для 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-сервера (Primary Name Server), адрес, необходимый для установления технических контактов (Hostmaster), серийный номер (Serial number) различные значения таймеров (Refresh, Retry, Expire, Minimum TTL)

SRV-запись (server selection) указывает на серверы для сервисов, используется, в частности, для Jabber и Active Directory.

Проверить DNS записи домена

Проверить DNS записи домена можно при помощи консольных утилит host, dig и nslookup. Последняя есть также в Windows системах, в Linux шире всего используется host. dig при этом обладает большим функционалом.

В Linux системах проверять DNS записи домена удобнее всего при помощи утилиты host

Без указания дополнительных параметров вызов host запрашивает A-запись DNS домена

host example.com

example.com has address 123.123.123.123

Требуемый тип записи можно указать непосредственно — например, запросить А-запись (ее значение выводится по-умолчанию, но можно запросить и ее наряду с MX-записями, CNAME и т.д.)

host -t a example.com

example.com has address 123.123.123.123

nslookup работает по сути таким же образом и удобна пользователям, ранее работавшим с Windows

Самым обширным функционалом обладает утилита dig

dig example.com

; <<>> DiG 9.10.3-P4-Ubuntu <<>> example.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 43826
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;server-gu.ru. IN A

;; ANSWER SECTION:
example.com. 5638 IN A 123.123.123.123

;; Query time: 49 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Sun Oct 29 19:02:47 +05 2017
;; MSG SIZE rcvd: 67

В выводе dig можно заметить строку ;; SERVER: 8.8.8.8#53(8.8.8.8). В ней указан DNS сервер от которого получен ответ, это тот сервер, который определен в /etc/resolv.conf на компьютере. Иногда требуется узнать значение какой-либо записи не дожидаясь обновления зон DNS, которое может занимать до 72 часов.

Сделать это можно обратившись к NS серверу непосредственно

dig @ns.somecompany.com example.com

Ответ даст не сервер заданный в /etc/resolv.conf, а указанный в запросе ns.somecompany.com

С ключом +short она отработает также как host

dig +short example.com

123.123.123.123

Общие записи DNS — Справка DNSimple

Содержание

Система доменных имен (DNS) состоит из множества различных типов записей (или записей ресурсов): A , AAAA , CNAME , MX , CAA и т. Д. Некоторые типы записей являются общими. Другие менее актуальны, устарели или заменены.

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

Общие типы записей

Это наиболее распространенные типы записей DNS:

Общие записи DNS

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

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

В этой статье используется пример .com — ваше доменное имя.

1. Корневой домен ( example.com )

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

В большинстве случаев эта конфигурация представляет собой запись A, указывающую на IP-адрес, на котором размещен ваш сайт. Однако это также может быть АЛИАС, если ваш сайт размещен в другом месте (это часто бывает, когда вы хотите указать свой корневой домен на облачный сервис, такой как Heroku, Netlify, GitHub и т. Д.) или запись URL-адреса, если домену нужно перенаправить в другое место.

Для проверки

1. Используйте dig example.com , чтобы проверить наличие корневой записи.

2. Ответ должен вернуть хотя бы одну запись A, как показано ниже:

     копать dnsimple.com
   
    ;; РАЗДЕЛ ОТВЕТА:
    dnsimple.com. 59 IN A 104.245.210.170
     

   И ALIAS, и записи URL синтезируются как записи A.

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

2. Субдомен www: ( www.example.com )

Как правило, в дополнение к корневому домену настраивается субдомен www . Есть несколько возможностей:

1. Использование записи A для указания на тот же IP-адрес корневого домена.
2. Использование записи CNAME для указания на корневой домен.
3. Использование записи URL для перенаправления в корневой домен.

Использование записи ALIAS для субдомена www не является неправильным, но, как правило, в этом нет необходимости.В большинстве случаев вы можете заменить ALIAS на CNAME.

Для проверки

1. Используйте dig www.example.com , чтобы проверить наличие записи www.

2. Ответ должен вернуть хотя бы одну запись A или ровно одну запись CNAME, как показано ниже:

     копать www.dnsimple.com
   
    ;; РАЗДЕЛ ОТВЕТА:
    www.dnsimple.com. 59 IN A 104.245.210.170
     

     копать www.dnsimple.com
   
    ;; РАЗДЕЛ ОТВЕТА:
    www.dnsimple.com. 3599 В CNAME dnsimple.com.
    dnsimple.com. 59 IN A 104.245.210.170
     

3. Записи электронной почты MX

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

Для проверки

1. Используйте dig MX example.com , чтобы проверить наличие записей MX в корневом домене.

2. Ответ должен вернуть хотя бы одну запись MX, как показано ниже:

     Dig MX www.dnsimple.com
   
    ;; РАЗДЕЛ ОТВЕТА:
    dnsimple.com. 3599 В MX 1 aspmx.l.google.com.
    dnsimple.com. 3599 IN MX 5 alt1.aspmx.l.google.com.
    dnsimple.com. 3599 IN MX 5 alt2.aspmx.l.google.com.
    dnsimple.com. 3599 IN MX 10 alt3.aspmx.l.google.com.
    dnsimple.com. 3599 IN MX 10 alt4.aspmx.l.google.com.
     

4. Запись CAA

Желательно добавить запись CAA в корневой домен, чтобы указать, какие центры сертификации могут выдавать сертификат для вашего домена.

Для проверки

1. Используйте dig CAA example.com , чтобы проверить наличие записи CAA в корневом домене.

2. Ответ должен вернуть хотя бы одну запись CAA, как показано ниже:

     dig CAA www.dnsimple.com
   
    ;; РАЗДЕЛ ОТВЕТА:
    dnsimple.com. 3599 IN CAA 0 iodef "mailto: [email protected]"
    dnsimple.com. 3599 IN CAA 0 проблема "amazonaws.com"
    dnsimple.com. 3599 IN CAA 0 проблема "comodoca.com"
    dnsimple.com. 3599 В CAA 0 проблема "letsencrypt.org "
    dnsimple.com. 3599 IN CAA 0 issueewild "comodoca.com"
     

записей ресурсов DNS — Cisco

Записи ресурсов

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

Примечание: Есть ряд других типов записей, которые активно не поддерживаются. К ним относятся адресат почты (MD), пересылка почты (MF), почтовая группа (MG), информация о почтовом ящике или списке рассылки (MINFO), переименование почты (MR) и NULL. Вы можете получить полный список типов записей DNS в параметрах DNS IANA.

Требования

Для этого документа нет особых требований.

Используемые компоненты

Этот документ не ограничивается конкретными версиями программного и аппаратного обеспечения.

Условные обозначения

Дополнительные сведения об условных обозначениях в документах см. В разделе «Условные обозначения технических советов Cisco».

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

Должна быть ровно одна запись SOA для каждого домена сервера имен (каждого поддомена).Это касается поддоменов IN-ADDR.ARPA (обратные домены). Область пространства имен, в которой есть отдельная SOA, называется зоной.

Формат этой записи виден в этих выходных данных. Значения, указанные для временных интервалов в этой SOA, рекомендованы RFC 1537.

 DOMAIN.NAME. IN SOA Hostname.Domain.Name. Mailbox.Domain.Name. (
                                1; серийный номер
                                86400; обновить за секунды (24 часа)
                                7200; повторить попытку через секунды (2 часа)
                                2592000; истекает через секунды (30 дней)
                                345600); TTL в секундах (4 дня)


Рекорд SOA для вымышленного файла foo.edu может выглядеть примерно так:

FOO.EDU. В SOA FOO.EDU. Joe_Smith.Foo.EDU. (
                                910612; серийный номер
                                28800; обновить через 8 часов
                                7200; повторить попытку через 2 часа
                                604800; истекает через 7 дней
                                86400); TTL - 1 день 

Поля данных записи SOA

Этот список содержит пояснения к полям данных в фиктивной записи SOA.

• ДОМЕННОЕ ИМЯ. —Имя домена, к которому относится запись SOA. Обратите внимание на конечную точку (.). Это означает, что к имени не следует добавлять суффикс.

• IN —Класс записи DNS. IN означает «Интернет».

• SOA —Тип DNS-записи, начало полномочий в этом примере.

• Имя хоста.Имя домена. —Поле происхождения должно содержать имя хоста первичного сервера имен для этой зоны, хоста, на котором находятся официальные данные.

• Почтовый ящик.Домен.Имя. —Почтовый ящик лица, ответственного за (службу имен) этого домена. Чтобы преобразовать это поле в пригодный для использования адрес электронной почты, замените первую точку (.) На @ (знак at). В этом примере, если есть проблемы с foo.edu, отправьте электронное письмо на адрес [email protected].

• Серийный номер — серийный номер текущей версии базы данных DNS для этого домена.Серийный номер — это средство, с помощью которого другие серверы имен узнают, что ваша база данных была обновлена. Этот серийный номер начинается с 1 и должен быть монотонно возрастающим целым числом. Не ставьте десятичную точку в серийный номер, так как это может привести к запутанным и неприятным результатам. Некоторые администраторы DNS используют дату последнего изменения в качестве серийного номера в формате ГГММДДЧЧММ, другие просто увеличивают serno на небольшое число при каждом обновлении базы данных. Половинная скобка, которая стоит перед serno и закрывается после минимального времени жизни (TTL), позволяет SOA занимать несколько строк.

  Когда вторичный сервер имен для домена foo.edu связывается с первичным сервером имен, чтобы проверить, не было ли изменений в базе данных DNS первичного, и если вторичный сервер должен выполнить перенос зоны, он сравнивает свой собственный серийный номер с серийным номером основной сервер имен.

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

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

• Обновить — Сообщает вторичному серверу имен, как часто опрашивать первичный сервер имен и как часто проверять изменение серийного номера. Этот интервал влияет на время, необходимое для распространения изменений DNS, внесенных на первичном сервере имен.

• Retry —Интервал в секунду, с которым вторичный сервер имен пытается повторно подключиться к первичному серверу имен в случае, если ему не удалось подключиться в течение интервала обновления.

• Expire — количество секунд, по истечении которых вторичный сервер имен должен «истечь» данные первичного сервера имен, если ему не удается повторно подключиться к первичному серверу имен.

• TTL — значение по умолчанию, которое применяется ко всем записям в базе данных DNS на сервере имен.Для каждой записи ресурса DNS можно настроить значение TTL. TTL по умолчанию для записи SOA используется только в том случае, если для конкретной записи ресурса не настроено явное значение. Это значение предоставляется официальными серверами имен (первичным и вторичным серверами имен для определенной зоны), когда они отвечают на запросы DNS.

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

Запись NS принимает следующий формат:

 DOMAIN.NAME. IN NS Hostname.Domain.Name. 

Значение NS-записи для домена — это имя сервера имен для этого домена. Вам необходимо указать NS-запись для каждого первичного или вторичного сервера имен для домена.

Запись адреса (запись A) дает адрес IPv4, соответствующий имени хоста. Может быть несколько IP-адресов, соответствующих одному имени хоста, также может быть несколько имен хостов, каждое из которых сопоставляется с одним и тем же IP-адресом.

Запись A принимает следующий формат:

 Host.domain.name. IN A xx.xx.xx.xx (адрес IPv4) 

Для работы команды, такой как telnet host.domain.name , в DNS должна быть допустимая запись A для Host.domain.name (или должно быть CNAME, указывающее на имя хоста с допустимой записью A).

Примечание. Расширения DNS для поддержки адресов IPv6 рассматриваются в RFC 1886.

Запись информации о хосте (HINFO) может быть настроена для предоставления информации о типе оборудования и операционной системе (ОС) для каждого хоста. Его присутствие необязательно, но наличие доступной информации может быть полезно.

Для каждого имени хоста может быть только одна запись HINFO.

Запись HINFO принимает следующий формат:

 Host.DOMAIN.NAME. IN HINFO «Тип процессора» «Операционная система» 

Примечание: Поля типа ЦП и ОС являются обязательными.Если вы хотите оставить одно из этих полей пустым, укажите его как «» (пустое пространство, заключенное в двойные кавычки). Вы не можете использовать только пару двойных кавычек [«»].

Примечание: Официальные имена компьютеров, которые вам нужны для HINFO, можно найти в RFC 1700. RFC 1700 перечисляет полезную информацию, такую ​​как значения / etc / services, адреса оборудования производителя Ethernet и значения по умолчанию HINFO.

Запись текста (TXT) позволяет связать любой произвольный текст с именем хоста.Некоторые нестандартные реализации команды bind не поддерживают запись TXT. Однако некоторые нестандартные реализации команды bind действительно поддерживают фиктивный тип записи под названием «UINFO», который делает то же самое. Cisco рекомендует использовать только тип записи «TXT».

У вас может быть несколько записей TXT для одного имени хоста.

Запись TXT принимает следующий формат:

 Host.DOMAIN.NAME. IN TXT »системный менеджер: melvin @ host.доменное имя"
                   В TXT "меласу" 

Зона может иметь одну или несколько записей почтового обмена (MX). Эти записи указывают на хосты, которые принимают почтовые сообщения от имени хоста. Хост может быть MX для самого себя. Записи MX не обязательно указывают на хост в той же зоне.

Запись MX принимает следующий формат:

 Host.domain.name. IN MX nn Otherhost.domain.name.
                        В MX nn Otherhost2.доменное имя. 

Номера предпочтений «MX» nn (значения от 0 до 65535) обозначают порядок, в котором почтовые программы выбирают записи «MX» при попытке доставки почты на хост. Чем ниже номер MX, тем выше приоритет хоста.

Запись канонического имени (CNAME) используется для определения псевдонима хоста.

Запись CNAME имеет следующий формат:

 alias.domain.name. В CNAME otherhost.domain.название. 

Это определяет alias.domain.name как псевдоним для хоста, каноническим (стандартным) именем которого является otherhost.domain.name.

Примечание: Имя хоста, существующее как CNAME, не может иметь других записей DNS, примененных к нему. Например, если ваш домен называется Philophysics.arizona.edu, и он имеет отдельное имя (так что у него есть собственные записи SOA и NS), то вы не можете предоставить философию .arizona.edu запись CNAME. Для этого отправьте электронное письмо на адрес anyuser @ Философия.arizona.edu, вам необходимо использовать записи MX и / или A.

Записи указателя противоположны записям A и используются в файлах зоны обратного сопоставления для сопоставления IP-адреса с именем хоста. В отличие от других записей SOA, записи указателя (PTR) используются только в обратных (IN-ADDR.ARPA) доменах. Для каждого адреса в Интернете должна быть ровно одна запись PTR. Например, если хост gadzooks.poetry.arizona.edu имеет IP-адрес 128.196.47.55, то для него должна быть запись PTR в следующем формате:

 55.47.196.128.IN-ADDR.ARPA. В ПТР gadzooks.poetry.arizona.edu. 

Обратные домены содержат в основном записи PTR (плюс записи SOA и NS вверху).

R-утилиты Berkeley используют значение записи PTR для аутентификации имени хоста. Хотя DNS указывает, что регистр не имеет значения в именах хостов, имейте в виду, что некоторые операционные системы чувствительны к регистру имен хостов.

Как я могу изменить записи DNS для своего домена?

Расширенная поддержка может помочь!

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

Обзор

Файл зоны — это небольшой набор инструкций по преобразованию указанного доменного имени в Интернете в соответствующую числовую форму IP-адреса. Эти инструкции находятся в файле на сервере, который управляет сайтом.

В этой статье объясняется, как редактировать файл зоны, размещенный на серверах имен (mt) Media Temple, NS1.MEDIATEMPLE.NET и NS2.MEDIATEMPLE.СЕТЬ.

Требования

Для того, чтобы изменения вступили в силу, у вас должны быть указаны NS1.MEDIATEMPLE.NET и NS2.MEDIATEMPLE.NET в качестве серверов имен у вашего регистратора. См. (Mt) информацию о DNS / сервере имен Media Temple для получения дополнительной информации (mt) о сервере имен Media Temple.

Здесь также можно отредактировать файл зоны, в ожидании предстоящих изменений, для использования серверов имен (mt) Media Temple, даже если вы в настоящее время не используете их для своего домена.

Проверьте свои текущие серверы имен в Whois.сеть.

Видео

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

Инструкции

ПРИМЕЧАНИЕ:

Любые изменения в файле зоны DNS необходимо будет распространить по Интернету. Как правило, мы рекомендуем отводить 24–48 часов на распространение DNS. Читайте ниже о том, как снизить значение TTL для плавного перехода.

1. Войдите в Учетный центр.
2. Щелкните домен, который хотите отредактировать.

3. В разделе DNS & ZONE FILES нажмите Edit DNS Zone File.
   
4. Следуйте инструкциям ниже, чтобы узнать, как внести нужные изменения.

Инструкции

1. Войдите в Account Center.
   • Для пользователей Grid Personal, Pro и Elite: нажмите синюю кнопку ADMIN , связанную с вашим сервером Grid.

   • В разделе САЙТЫ щелкните домен, который хотите отредактировать.

   • Для пользователей (gs) Grid Service или Grid Lite: щелкните домен, который хотите отредактировать.

2. В разделе DNS & ZONE FILES нажмите Edit DNS Zone File.
   
3. Следуйте инструкциям ниже, чтобы узнать, как внести нужные изменения.

Инструкции

ПРИМЕЧАНИЕ:

Любые изменения в файле зоны DNS необходимо будет распространить по Интернету.Как правило, мы рекомендуем отводить 24–48 часов на распространение DNS. Читайте ниже о том, как снизить значение TTL для плавного перехода.

1. Войдите в Account Center.
2. Нажмите синюю кнопку ADMIN , связанную с вашим сервером WordPress.

3. Наведите курсор на слот сайта, к которому вы хотите получить доступ. Затем щелкните Управление .

4. Нажмите Домены .

5. Нажмите кнопку УПРАВЛЕНИЕ, связанную с вашим доменом.

6. В разделе DNS & ZONE FILES нажмите Edit DNS Zone File.
   
7. Следуйте инструкциям ниже, чтобы узнать, как внести нужные изменения.

Инструкции

1. Войдите в Учетный центр.
   • Щелкните DOMAIN TOOLS , чтобы обновить основной домен.
   • Щелкните свой альтернативный домен.
2. В разделе DNS & ZONE FILES нажмите Edit DNS Zone File.

Обновление и добавление записей

1. Щелкните прямо в одном из текстовых полей существующей записи, чтобы изменить его, или чтобы добавить новую запись, щелкните кнопку + ДОБАВИТЬ СТРОКУ.

2. Введите вашу информацию для новой записи.
   • Имя: введите поддомен своего домена или оставьте поле пустым, если вы хотите изменить свой домен верхнего уровня. Пример: store, если вы хотите store.gs-example.com.

   • Тип: выберите один из раскрывающегося меню.A для IP, CNAME для домена, MX для почты.

   • Данные: введите IP-адрес или доменное имя. Доменные имена должны заканчиваться точкой. Записи MX также должны иметь номер перед доменом, разделенный одним пробелом.
     • Пример MX: 10 mail.example.com.
3. Нажмите кнопку СОХРАНИТЬ ИЗМЕНЕНИЯ, чтобы сохранить изменения.

TXT записей

Записи TXT

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

Максимальное количество символов для записей TXT — 255. В некоторых случаях может потребоваться превышение этого лимита символов для одной записи. Для этого разделите строку на блоки, длина которых не превышает 255 символов, и объедините их, используя кавычки.

Ниже приведен образец ключа для записи DKIM TXT, длина которой превышает 255 символов, и инструкции по его добавлению.

Пример 2048-битного ключа, длина которого превышает 255 символов:

MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA4TWhAkE9cQBB7g2C6jGb 4jdiaShZEtWBkupXFtBdOdJTvrMTAEPIhZske9 + п.н. / ILDYbWG0Tzw7DcmWoTPF + J,
bNDh5mN8hSy1pPxyxsmvtFqr5bMlaWl42arkWR3Zzq9A / ReMcEfZ5avwP2JubH72
Bg0SP6NNfrUD9sAWtzOIAt1rT1UygohlB + 2EdeHdWFN9neHHDN / hVzL82qufuMZ0
bOAHyn / kuT9hK0HkHc + vHTGIloPlhr6siNfmGwU / Lmv7d7uY / YFpvMvZrl90Fu77
5J7944VNMp6E7tGlJjlt01zDGa5Qh2K1funRdrObLxxMgq0Z7RMx5GD5CHMS4tRn

eQIDAQAB

Чтобы ввести указанный выше ключ в поле TXT, разделите его на несколько строк, используя кавычки:

«MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA4TWhAkE9cQBB7g2C6jGb
4jdiaShZEtWBkupXFtBdOdJTvrMTAEPIhZske9 + п.н. / ILDYbWG0Tzw7DcmWoTPF + J,
bNDh5mN8hSy1pPxyxsmvtFqr5bMlaWl42arkWR3Zzq9A / ReMcEfZ5avwP2JubH72″

«Bg0SP6NNfrUD9sAWtzOIAt1rT1UygohlB + 2EdeHdWFN9neHHDN / hVzL82qufuMZ0
bOAHyn / kuT9hK0HkHc + vHTGIloPlhr6siNfmGwU / Lmv7d7uY / YFpvMvZrl90Fu77

5J7944VNMp6E7tGlJjlt01zDGa5Qh2K1funRdrObLxxMgq0Z7RMx5GD5CHMS4tRn eQIDAQAB»

Добавьте обе строки в одно и то же поле данных записи TXT.Не ставьте пробелы между строками.

SRV записи

Подробные инструкции о том, как создать запись SRV для вашего домена, см. В разделе: Как создать запись SRV?

Поиск DNS

Чтобы выполнить поиск в DNS и убедиться, что вы правильно ввели запись, вы можете использовать команду dig, чтобы найти ее:

 
копайте любой _autodiscover._tcp.example.com
  

Вы должны увидеть ответ с информацией, подобной следующей:

 
;; РАЗДЕЛ ОТВЕТА:
_autodiscover._tcp.example.com. 43200 IN SRV 0 5 80 webmail.example.com.
  

Сбросить на (mt) Media Temple по умолчанию

Это направит ваш сайт и электронную почту на ваш (mt) сервер Media Temple — это стандартная конфигурация DNS, с которой добавляется ваш домен.

1. Для доступа к файлу зоны выполните действия, описанные в предыдущем разделе.
2. Щелкните REVERT ZONE и сохраните.

Нужен плавный переход DNS? Понизьте свой TTL.

No related posts.