Fqdn сервера как узнать: fqdn сервера как узнать | Все о Windows 10

Использвание команды Nslookup для проверки DNS серверов и записей доменов

Nslookup (name server lookup) это утилита командной строки, которую можно использовать для диагностики службы DNS, проверки DNS записей и серверов и обнаружения проблем, связанных с разрешением имен в системе DNS. Утилита nslookup изначально разработана в составе пакета BIND и в дальнейшем портирована на Windows. На данный момент утилита Nslookup входит в состав всех поддерживаемых версий Windows.

Утилита Nslookup умеет отправлять запросы на DNS сервер, который указан в настройках вашего сетевого подключения. Этот адрес считается DNS севером по умолчанию (default server). Пользователь может указать адрес любого другого доступного DNS сервера, в результате чего все следующие DNS запросы будут выполнятся уже на нем.

С помощью утилиты nslookup вы можете узнать IP адрес любого сервера по его DNS имени, выполнить обратное преобразование, получить информацию о различных DNS записях домена.

Вы можете использовать утилиту nslookup в интерактивном или не-интерактивном режиме.

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

Nslookup vmblog.ru

В данном примере мы запросили IP адрес сервера vmblog.ru. Утилита nslookup обратилась к DNS серверу (указан в строке Server) и он вернул, что этому имени соответствует IP адрес 37.252.2.22.

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

Если же вы получит ответ вида:

Server: dns1.someserver.com
Address: хх.хх.хх.хх
*** dns1.contoso.com can't find vmblog.ru: Non-existent domain

Это означает, что для данного имени не найдено записей в DNS зоне.

В том случае, если ваш DNS сервер недоступен или не отвечает, вы получите ошибки DNS request timed out.

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

Строка Non-authoritative answer (Не заслуживающий доверия ответ)означает, что DNS сервер, который выполнил запрос не является владельцем зоны vmblog.ru (в его базе нет записей об этом домене), а для выполнения разрешения имени использовался рекурсивный запрос к другому DNS серверу.

Можно обратиться к авторитетному серверу, указав его адрес непосредственно в параметрах утилиты nslookup. Например, чтобы выполнить разрешение имени на DNS сервере, который содержит данный домен (authoritative server), используйте команду:
nslookup vmblog.ru ns1.vmblog.ru
При запуске nslookup без параметров, утилита переходит в интерактивный режим. В этом режиме вы можете выполнять различные команды. Полный список доступных внутренних команд утилиты nslookup

можно вывести, набрав знак вопроса.

Совет. Обратите внимание, что команды утилиты nslookup являются регистрозависимыми.

Для завершения работы с nslookup наберите команду exit и нажмите Enter.

Чтобы найти DNS сервера, которые отвечают за конкретный домен (authoritative servers), выполните команды:

set query=ns
vmblog.ru

Вы можете выполнить и обратное преобразование (получить DNS имя по IP адресу), для этого просто наберите IP адрес в интерактивной строке nslookup и нажмите Enter.

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

nslookup -type=mx gosuslugi.ru

Не заслуживающий доверия ответ:
gosuslugi.ru MX preference = 20, mail exchanger = mx68.gosuslugi.ru
gosuslugi.ru MX preference = 10, mail exchanger = mx.gosuslugi.ru
mx68.gosuslugi.ru internet address = 109.207.8.100
mx.gosuslugi.ru internet address = 109.207.1.100

Как вы видите, у данного домене 2 MX записи с приоритетами 10 и 20 (Чем меньше число, тем выше приоритет адреса).

Если запись MX не отображается, скорее всего они просто не настроены для данного домена.

Чтобы вывести все DNS записи в доменной зоне, выполните команду:

nslookup -type=any gosuslugi.ru

gosuslugi.ru nameserver = ns2.gosuslugi.ru
gosuslugi.ru nameserver = ns8-l2.nic.ru
gosuslugi.ru nameserver = ns1.gosuslugi.ru
gosuslugi.ru nameserver = ns4-l2.nic.ru
gosuslugi.ru MX preference = 10, mail exchanger = mx.gosuslugi.ru
gosuslugi.ru MX preference = 20, mail exchanger = mx68.gosuslugi.ru
ns2.gosuslugi.ru internet address = 213.59.255.175
ns8-l2.nic.ru internet address = 91.217.21.1


ns1.gosuslugi.ru internet address = 109.207.2.218
ns4-l2.nic.ru internet address = 91.217.20.1
mx.gosuslugi.ru internet address = 109.207.1.100
mx68.gosuslugi.ru internet address = 109.207.8.100

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

set debug

работа с сервером DNS из командной строки.

&nbsp &nbsp Утилита NSLOOKUP присутствует в операционных системах Windows, начиная с Windows NT , и предназначена для формирования запросов к серверам DNS из командной строки. Фактически, утилита является аналогом службы DNS-клиент и позволяет диагностировать проблемы с разрешением имен в системе DNS. По умолчанию, все запросы отправляются на DNS-сервер, адрес которого задан настройками сетевого подключения. В терминах утилиты такой сервер является сервером по умолчанию (default server). Команда ipconfig /all позволяет получить информацию о настройках протокола IP и, в том числе, о серверах DNS, используемых в системе.

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

help позволяет отобразить справку о внутренних командах и опциях nslookup:

Команды nslookup:

(идентификаторы отображаются в верхнем регистре, квадратные скобки «[]» обозначают необязательные параметры)

NAME — печать сведений об узле или домене NAME с помощью сервера по умолчанию
NAME1 NAME2 — та же операция, но в качестве сервера используется NAME2
help или ? — печать сведений о стандартных командах
set OPTION — установить параметр
all — печать параметров, текущего сервера и узла
[no]debug

— печать отладочных сведений
[no]d2 — печать полных отладочных сведений
[no]defname — добавить имя домена ко всем запросам
[no]recurse — запрос рекурсивного ответа на запрос
[no]search — использовать список поиска доменов
[no]vc — всегда использовать виртуальную схему
domain=NAME — установить имя домена по умолчанию NAME
srchlist=N1[/N2/. ../N6] — установить домен N1 и список поиска N1,N2 и т.д.
root=NAME — установить корневой сервер NAME
retry=X — установить число повторов X
timeout=X — установить интервал времени ожидания в X секунд
type=X — установить тип запроса (пр. A,AAAA,A+AAAA,ANY,CNAME,MX ,NS,PTR,SOA,SRV)
querytype=X — то же, что и type
class=X — установить класс запроса ( IN (Internet), ANY)
[no]msxfr — использовать быструю зону MS для передачи
ixfrver=X — текущая версия, использующаяся в передаче запросов IXFR
server NAME — установить сервер по умолчанию NAME, используя текущий сервер по умолчанию
lserver NAME — установить сервер по умолчанию NAME, используя первоначальный сервер
root — сделать текущий сервер по умолчанию корневым сервером
ls [opt] DOMAIN [> FILE] — перечисление адресов в домене DOMAIN (необязательно: вывод в файл FILE)

-a — перечисление канонических имен и псевдонимов
-d — перечисление всех записей
-t TYPE — перечисление записей указанного типа RFC (пр. A,CNAME,MX,NS,PTR etc.)
view FILE — сортировка файла «ls» и его просмотр с помощью pg

exit — выход из программы

Примеры использования команды NSLOOKUP

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

nslookup yandex.ru. — выполнить запрос к DNS-серверу, заданному по умолчанию, на разрешение доменного имени

yandex.ru. Для уменьшения количества ненужных запросов к серверам имен, имя домена нужно вводить в виде полностью определенного имени (fully qualified domain name) , т.е. с точкой в конце. Если этого не делать, то nslookup будет сначала выполнять запрос на разрешение имени относительно домена того компьютера, на котором она выполняется, т.е. yandex.ru.mydomain.ru если имя локального домена — mydomain.ru.

nslookup -type=mx yandex. ru — то же, что и в предыдущем примере, но с указанием типа запрашиваемой записи -type=mx. Сервер DNS ответит на запрос утилиты nslookup перечислением почтовых серверов, обслуживающих домен yandex.ru

nslookup odnoklassniki.ru 8.8.8.8 — определить IP-адрес узла odnokassniki.ru с использованием DNS-сервера 8.8.8.8 (публичный DNS-сервер Google), вместо DNS-сервера, заданного в настройках сетевого подключения.

nslookup -type=mx -timeout=8 vk.com 208.67.220.220 — отобразить запись MX для домена vk.com из базы данных сервера с IP-адресом 208.67.220.220 (сервер OpenDNS). При выполнении команды, максимальное время ожидания ответа сервера — 8 секунд.

nslookup -type=any -timeout=8 vk.com 208.67.220.220 — то же, что и в предыдущем примере, но выполняется запрос на отображение любых типов записей.

Пример отображаемых данных:

Сервер: 208.67.220.220
Не заслуживающий доверия ответ:
vk. com internet address = 87.240.131.119
vk.com internet address = 87.240.131.99
vk.com nameserver = ns2.vkontakte.ru
vk.com nameserver = ns4.vkontakte.ru
vk.com nameserver = ns1.vkontakte.ru
vk.com nameserver = ns4.vkontakte.ru
vk.com nameserver = ns2.vkontakte.ru
vk.com nameserver = ns1.vkontakte.ru
ns1.vkontakte.ru internet address = 93.186.237.2
ns2.vkontakte.ru internet address = 93.186.224.100

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

Address: 8.8.8.8

Non-authoritative answer:
vk.com internet address = 87.240.131.120
vk.com internet address = 87. 240.143.244
vk.com

primary name server = ns1.vkontakte.ru
responsible mail addr = ncc.vkontakte.ru
serial = 2013100501
refresh = 3600 (1 hour)
retry = 900 (15 mins)
expire = 604800 (7 days)
default TTL = 900 (15 mins)
vk.com AAAA IPv6 address = 2a00:bdc0:3:103:1:0:403:901
vk.com AAAA IPv6 address = 2a00:bdc0:3:103:1:0:403:902
vk.com AAAA IPv6 address = 2a00:bdc0:3:103:1:0:403:903
vk.com nameserver = ns1.vkontakte.ru
vk.com nameserver = ns2.vkontakte.ru
vk.com nameserver = ns4.vkontakte.ru
vk.com MX preference = 10, mail exchanger = mail.vk.com
vk.com text =»v=spf1 ip4:93.186.224.0/20 ip4:87.240.128.0/18 mx include:aspmx.googlemail.com ~all»

Сообщение «Не заслуживающий доверия ответ:» (Non-authoritative answer: ) говорит о том, что выполняющий запрос DNS-сервер, не является владельцем зоны vk. com т.е. записи для узла vk.com в его базе отсутствуют, и для разрешения имени использовался рекурсивный запрос к другому DNS-серверу. Если отправить запрос DNS-серверу ns1.vkontakte.ru, то будет получен авторитетный ответ (authoritative answer) :

Server: ns1.vkontakte.ru
Address: 93.186.237.2

vk.com

primary name server = ns1.vkontakte.ru
responsible mail addr = ncc.vkontakte.ru
serial = 2013100501
refresh = 3600 (1 hour)
retry = 900 (15 mins)
expire = 604800 (7 days)
default TTL = 900 (15 mins)
vk.com internet address = 87.240.131.118
vk.com AAAA IPv6 address = 2a00:bdc0:3:103:1:0:403:904
vk.com AAAA IPv6 address = 2a00:bdc0:3:103:1:0:403:905
vk.com AAAA IPv6 address = 2a00:bdc0:3:103:1:0:403:906
vk.com nameserver = ns4.vkontakte.ru
vk.com nameserver = ns1. vkontakte.ru
vk.com nameserver = ns2.vkontakte.ru
vk.com MX preference = 10, mail exchanger = mail.vk.com
vk.com text = «v=spf1 ip4:93.186.224.0/20 ip4:87.240.128.0/18 mx include:aspmx.googlemail.com ~all»
ns4.vkontakte.ru internet address = 93.186.239.253
ns4.vkontakte.ru AAAA IPv6 address = 2a00:bdc0:ff:4::2
ns1.vkontakte.ru internet address = 93.186.237.2
ns1.vkontakte.ru AAAA IPv6 address = 2a00:bdc0:ff:1::2
ns2.vkontakte.ru internet address = 93.186.224.100
ns2.vkontakte.ru AAAA IPv6 address = 2a00:bdc0:ff:2::2
mail.vk.com internet address = 93.186.236.94

Использование опции отладки (debug) позволяет получить дополнительную информацию, содержащуюся в заголовках запросов клиента и ответов сервера (время жизни, флажки, типы записей и т.п.): > server ns1.vkontakte.ru
————

Got answer:
HEADER:

opcode = QUERY, id = 5, rcode = NXDOMAIN
header flags: response, want recursion, recursion avail.
questions = 1, answers = 0, authority records = 1, additional = 0

QUESTIONS:

ns1.vkontakte.ru, type = A, class = IN

AUTHORITY RECORDS:

-> (root)
ttl = 440 (7 mins 20 secs)
primary name server = a.root-servers.net
responsible mail addr = nstld.verisign-grs.com
serial = 2013101600
refresh = 1800 (30 mins)
retry = 900 (15 mins)
expire = 604800 (7 days)
default TTL = 86400 (1 day)

————
————
Got answer:

HEADER:

opcode = QUERY, id = 6, rcode = NOERROR
header flags: response, want recursion, recursion avail.
questions = 1, answers = 1, authority records = 0, additional = 0

QUESTIONS:

ns1.vkontakte.ru, type = A, class = IN

ANSWERS:

-> ns1.vkontakte.ru
internet address = 93. 186.237.2
ttl = 6350 (1 hour 45 mins 50 secs)

————
Default Server: ns1.vkontakte.ru
Address: 93.186.237.2

> vk.com
Server: ns1.vkontakte.ru
Address: 93.186.237.2

————
Got answer:
HEADER:

opcode = QUERY, id = 7, rcode = REFUSED
header flags: response, want recursion
questions = 1, answers = 0, authority records = 0, additional = 0

QUESTIONS:

vk.com, type = ANY, class = IN
————
————
Got answer:
HEADER:

opcode = QUERY, id = 8, rcode = NOERROR
header flags: response, auth. answer, want recursion
questions = 1, answers = 11, authority records = 0, additional = 7

QUESTIONS:

vk.com, type = ANY, class = IN

ANSWERS:

-> vk.com
ttl = 900 (15 mins)
primary name server = ns1. vkontakte.ru
responsible mail addr = ncc.vkontakte.ru
serial = 2013100501
refresh = 3600 (1 hour)
retry = 900 (15 mins)
expire = 604800 (7 days)
default TTL = 900 (15 mins)
-> vk.com
internet address = 87.240.131.99
ttl = 900 (15 mins)
-> vk.com
internet address = 87.240.131.119
ttl = 900 (15 mins)
-> vk.com
AAAA IPv6 address = 2a00:bdc0:3:103:1:0:403:901
ttl = 900 (15 mins)
-> vk.com
AAAA IPv6 address = 2a00:bdc0:3:103:1:0:403:902
ttl = 900 (15 mins)
-> vk.com
AAAA IPv6 address = 2a00:bdc0:3:103:1:0:403:903
ttl = 900 (15 mins)
-> vk.com
nameserver = ns1.vkontakte.ru
ttl = 900 (15 mins)
-> vk. com
nameserver = ns2.vkontakte.ru
ttl = 900 (15 mins)
-> vk.com
nameserver = ns4.vkontakte.ru
ttl = 900 (15 mins)
-> vk.com
MX preference = 10, mail exchanger = mail.vk.com
ttl = 900 (15 mins)
-> vk.com
text = «v=spf1 ip4:93.186.224.0/20 ip4:87.240.128.0/18 mx include:aspmx.googlemail.com ~all»
ttl = 900 (15 mins)
ADDITIONAL RECORDS:
-> ns1.vkontakte.ru
internet address = 93.186.237.2
ttl = 9000 (2 hours 30 mins)
-> ns1.vkontakte.ru
AAAA IPv6 address = 2a00:bdc0:ff:1::2
ttl = 9000 (2 hours 30 mins)
-> ns2.vkontakte.ru
internet address = 93.186.224.100
ttl = 9000 (2 hours 30 mins)
-> ns2.vkontakte.ru
AAAA IPv6 address = 2a00:bdc0:ff:2::2
ttl = 9000 (2 hours 30 mins)
-> ns4. vkontakte.ru
internet address = 93.186.239.253
ttl = 9000 (2 hours 30 mins)
-> ns4.vkontakte.ru
AAAA IPv6 address = 2a00:bdc0:ff:4::2
ttl = 9000 (2 hours 30 mins)
-> mail.vk.com
internet address = 93.186.236.94
ttl = 900 (15 mins)

————
vk.com
ttl = 900 (15 mins)
primary name server = ns1.vkontakte.ru
responsible mail addr = ncc.vkontakte.ru
serial = 2013100501
refresh = 3600 (1 hour)
retry = 900 (15 mins)
expire = 604800 (7 days)
default TTL = 900 (15 mins)
vk.com
internet address = 87.240.131.99
ttl = 900 (15 mins)
vk.com
internet address = 87.240.131.119
ttl = 900 (15 mins)
vk. com
AAAA IPv6 address = 2a00:bdc0:3:103:1:0:403:901
ttl = 900 (15 mins)
vk.com
AAAA IPv6 address = 2a00:bdc0:3:103:1:0:403:902
ttl = 900 (15 mins)
vk.com
AAAA IPv6 address = 2a00:bdc0:3:103:1:0:403:903
ttl = 900 (15 mins)
vk.com
nameserver = ns1.vkontakte.ru
ttl = 900 (15 mins)
vk.com
nameserver = ns2.vkontakte.ru
ttl = 900 (15 mins)
vk.com
nameserver = ns4.vkontakte.ru
ttl = 900 (15 mins)
vk.com
MX preference = 10, mail exchanger = mail.vk.com
ttl = 900 (15 mins)
vk.com
text = «v=spf1 ip4:93.186.224.0/20 ip4:87.240.128.0/18 mx include:aspmx.googlemail.com ~all»
ttl = 900 (15 mins)
ns1.vkontakte.ru
internet address = 93. 186.237.2
ttl = 9000 (2 hours 30 mins)
ns1.vkontakte.ru
AAAA IPv6 address = 2a00:bdc0:ff:1::2
ttl = 9000 (2 hours 30 mins)
ns2.vkontakte.ru
internet address = 93.186.224.100
ttl = 9000 (2 hours 30 mins)
ns2.vkontakte.ru
AAAA IPv6 address = 2a00:bdc0:ff:2::2
ttl = 9000 (2 hours 30 mins)
ns4.vkontakte.ru
internet address = 93.186.239.253
ttl = 9000 (2 hours 30 mins)
ns4.vkontakte.ru
AAAA IPv6 address = 2a00:bdc0:ff:4::2
ttl = 9000 (2 hours 30 mins)
mail.vk.com
internet address = 93.186.236.94
ttl = 900 (15 mins)

nslookup 8.8.4.4 — отобразить имя узла, соответствующее IP-адресу 8.8.4.4

nslookup -ls -d mydomain.ru. > listdns.txt — отобразить все записи для домена mydomain. ru, обслуживаемого текущим DNS-сервером. Вывод направляется в файл listdns.txt текущего каталога. Задавать абсолютный путь к файлу не следует, поскольку все существующие на данный момент версии nslookup.exe успешно перенаправляют стандартный вывод в файл, только если он располагается в текущем каталоге.

При работе в интерактивном режиме, после старта на экран выводится приглашение к вводу команд — символ «>» . При вводе команд необходимо учитывать регистр символов, например, LS -d mydomain.ru. будет воспринята как ошибочна команда, а ls -D mydomain.ru. — как команда с ошибочной опцией.

Весь список команд CMD Windows

Как по IP узнать доменное имя

Если изначально разобраться, в чем кроется разница между именем сайта и его IP-адресом, можно легко по этому самому IP-адресу узнать имя сайта. Не всем пользователям Всемирной паутины известно, что сайт в Интернете имеет несколько имен (как минимум — два). Первое имя (название) легко узнаваемо и привычно пользователю: mail.ru, vk.com, wikipedia.org и др. Его также называют URL или «доменное имя».

За оболочкой видимого и понятного скрывается обратная сторона – техническая. С этой стороны компьютеры имеют дело с именем сайта, более понятным для них, которое как раз и является IP-адресом. Именно это, скажем так второе «техническое», имя сайта и является его настоящим названием в сети Интернет. Например, IP-адрес сайта yandex.ru – 5.255.255.5.

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

Узнать доменное имя по IP

Параллельно возникает вопрос: если узнать адрес IP по названию сайта достаточно легко, можно ли осуществить поиск наоборот? То есть найти нужный сайт по его IP-адресу. Ответ будет положительным, такой поиск возможен, но не без специального «помощника». Ресурс Whoer.net, позволяет в несколько простых шагов достичь нужного результата:

1. Открыть сервис WHOIS в удобном браузере;
2. Ввести в верхнем окне адрес IP;
3. Ниже в строке «хост» отобразится соответствующее имя сайта.

Если, в качестве примера, ввести выше названный IP-адрес 5.255.255.5, то в строке «хост» увидим имя «yandex.ru».

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

DNS сервер BIND — Сайт одного DevOpsa

Основная цель 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.name., а k-max.name). Итак, разобрав структуру доменного имени, мы незаметно подошли к понятию 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. Наиболее часто применяемые ресурсные записи следующими(далее, мы обязательно рассмотрим их на практике):

Давайте рассмотрим, что есть Делегирование. Делегирование (корректнее сказать делегирование ответственности) — это операция передачи ответственности за часть дерева доменных имен (зону) другому лицу или организации. За счет делегирования, в 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

Имена сервера

Имена сервера

Имена сервера задаются с помощью директивы server_name и определяют, в каком блоке server будет обрабатываться тот или иной запрос. См. также “Как nginx обрабатывает запросы”. (www\.)?(?<domain>.+)$; location / { root /sites/$domain; } }

Библиотека PCRE поддерживает именованные выделения, используя следующий синтаксис:

?<name>	Совместимый с Perl 5.10 синтаксис, поддерживается начиная с PCRE-7.0
?'name'	Совместимый с Perl 5.10 синтаксис, поддерживается начиная с PCRE-7.0
?P<name>	Python-совместимый синтаксис, поддерживается начиная с PCRE-4.0

Если nginx отказывается запускаться и выдаёт сообщение об ошибке:

pcre_compile() failed: unrecognized character after (?< in ...

то это значит, что используется старая версия библиотеки PCRE и следует вместо этого попробовать синтаксис “?P<name>”. (www\.)?(.+)$; location / { root /sites/$2; } }

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

Прочие имена

Некоторые имена имеют специальное значение.

Если необходимо обрабатывать запросы без поля “Host” в заголовке в блоке server, который не является сервером по умолчанию, следует указать пустое имя:

server {
    listen       80;
    server_name  example.org  www.example.org  "";
    ...
}

Если директива server_name не задана в блоке server, то nginx будет использовать пустое имя в качестве имени сервера.

Версии nginx вплоть до 0.8.48 в этом случае использовали имя хоста (hostname) машины в качестве имени сервера.

Если имя сервера задано как “$hostname” (0.9.4), то используется имя хоста (hostname) машины.

Если в запросе вместо имени сервера указан IP-адрес, то поле “Host” заголовка запроса будет содержать IP-адрес, и запрос можно обработать, используя IP-адрес как имя сервера:

server {
    listen       80;
    server_name  example. org
                 www.example.org
                 ""
                 192.168.1.1
                 ;
    ...
}

В примерах конфигурации серверов, обрабатывающих все запросы, встречается странное имя “_”:

server {
    listen       80  default_server;
    server_name  _;
    return       444;
}

Оно не является каким-то особенным, это просто одно из множества некорректных доменных имён, которые никогда не пересекутся ни с одним из реальных имён. С тем же успехом можно использовать имена типа “--” и “!@#”.

Версии nginx вплоть до 0.6.25 поддерживали специальное имя “*”, которое многими неверно воспринималось как имя сервера для обработки всех запросов. Оно никогда так не работало, и не работало как имя с маской. Это имя действовало так же, как сейчас действует директива server_name_in_redirect. Специальное имя “*” объявлено устаревшим, а вместо него следует использовать директиву server_name_in_redirect. Заметьте, что с помощью директивы server_name нельзя задать ни имя сервера для обработки всех запросов, ни сервер по умолчанию. Это является свойством директивы listen, а не server_name. См. также “Как nginx обрабатывает запросы”. Можно настроить серверы, слушающие на портах *:80 и *:8080, и указать, что один из них будет сервером по умолчанию для порта *:8080, а другой — для порта *:80:

server {
    listen       80;
    listen       8080  default_server;
    server_name  example.net;
    ...
}

server {
    listen       80  default_server;
    listen       8080;
    server_name  example.org;
    ...
}

Интернационализованные имена

Для указания интернационализированных доменных имён (IDNs) в директиве server_name следует указывать Punycode-представление имени:

server {
    listen       80;
    server_name  xn--e1afmkfd.xn--80akhbyknj4f;  # пример.испытание
    ...
}

Оптимизация

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

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

Поиск в хэш-таблице имён с масками медленнее, чем поиск в хэш-таблице точных имён, поскольку имена сравниваются по доменным частям. Заметьте, что специальное имя с маской вида “.example.org” хранится в хэш-таблице имён с масками, а не в хэш-таблице точных имён.

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

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

server {
    listen       80;
    server_name  example.org  www.example.org  *.example.org;
    ...
}

нежели чем использовать упрощённую форму:

server {
    listen       80;
    server_name  .example.org;
    ...
}

Если задано большое число имён серверов, либо заданы необычно длинные имена, возможно потребуется скорректировать значения директив server_names_hash_max_size и server_names_hash_bucket_size на уровне http. Значение по умолчанию директивы server_names_hash_bucket_size может быть равно 32, 64, либо другой величине, в зависимости от размера строки кэша процессора. Если значение по умолчанию равно 32 и имя сервера задано как “too.long.server.name.example.org”, то nginx откажется запускаться и выдаст сообщение об ошибке:

could not build the server_names_hash,
you should increase server_names_hash_bucket_size: 32

В этом случае следует увеличить значение директивы до следующей степени двойки:

http {
    server_names_hash_bucket_size  64;
    . ..

Если задано большое число имён серверов, то будет выдано другое сообщение об ошибке:

could not build the server_names_hash,
you should increase either server_names_hash_max_size: 512
or server_names_hash_bucket_size: 32

В таком случае сначала следует попробовать установить server_names_hash_max_size в величину, близкую к числу имён серверов, и только если это не поможет или время запуска nginx станет неприемлемо большим, следует попытаться увеличить server_names_hash_bucket_size.

Если сервер является единственным сервером для слушающего порта, то nginx не будет проверять имена сервера вообще (а также не будет строить хэш-таблицы для слушающего порта). За одним исключением: если имя сервера задано регулярным выражением с выделениями, то nginx’у придётся выполнить это выражение, чтобы получить значения выделений.

Совместимость

• Специальное имя сервера “$hostname” поддерживается начиная с версии 0. 9.4.
• Имя сервера по умолчанию является пустой строкой “” начиная с версии 0.8.48.
• Именованные выделения в именах серверов, заданных с помощью регулярных выражений, поддерживаются начиная с версии 0.8.25.
• Выделения в именах серверов, заданных с помощью регулярных выражений, поддерживаются начиная с версии 0.7.40.
• Пустое имя сервера “” поддерживается начиная с версии 0.7.12.
• В качестве первого имени сервера можно задать маску или регулярное выражение начиная с версии 0.6.25.
• Регулярные выражения в имени сервера поддерживаются начиная с версии 0.6.7.
• Имена с маской вида example.* поддерживаются начиная с версии 0.6.0.
• Специальная форма имени вида .example.org поддерживается начиная с версии 0.3.18.
• Имена с маской вида *.example.org поддерживаются начиная с версии 0.1.13.

автор: Игорь Сысоев редактор: Brian Mercer

Основы работы со службой DNS (domain name system)

Общая информация

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

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

 

 

Система доменных имен является одной из фундаментальных технологий современной интернет-среды, так как информация об IP-адресе запрашиваемого узла — обязательное условие получения ответа на любой интернет-запрос. Но IP-адрес представляет собой числовое значение вида «1.23.45.67», неподходящее для комфортного восприятия человеком. К тому же основной принцип распределения IP-адресов в сети — уникальность. Важно и то, что сетевой адрес — не самый устойчивый параметр. Он может изменяться (напр., при смене хоста, обслуживающего запрашиваемый узел, смене хостинг-провайдера, и т.п.). Все перечисленные особенности делают систему навигации по сетевым адресам сложной для человека.

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

Ключевыми характеристиками DNS являются:

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

Иерархия и делегирование доменных имен

Домен представляет собой именованную ветвь в дереве имен, включающую в себя сам узел (напр., домен первого уровня «.com»), а также подчиненные ему узлы (напр., домен второго уровня «example.com», домен третьего уровня «mail.example.com» и т.д.). Для обозначения иерархической принадлежности доменных имен принято использовать понятие «уровень» — показатель положения узла в дереве доменов. Чем ниже значение уровня, тем выше иерархическое положение домена

• «.» — домен нулевого уровня
• «.ru» — домен первого (верхнего) уровня
• «example.com» — домен второго уровня
• «mail.example.com» — домен третьего уровня
• Этот список можно продолжать

 

 

Обратите внимание на домен нулевого уровня «. » (dot — точка), также называемый корневым. На практике точку обычно не указывают («example.com» вместо «example.com.»), т.е. указание корневого домена не является обязательным условиям разрешения IP-адреса. Большинство клиентских программ (интернет-браузеров и т.д.) добавляют домен нулевого уровня автоматически и не отображают его пользователю. Доменное имя, не включающее обозначение домена нулевого уровня называется относительным, включающее же точку на конце — полностью определенным (FQDN — Fully Qualified Domain Name).

Доменная зона — часть иерархического дерева доменных имен (напр. «.ru»), целиком переданная на обслуживание определенному DNS-серверу (чаще нескольким) с целью делегирования другому лицу ответственности за этот и все подчиненные домены («anyaddress.ru», «any.anyaddress.ru»).

Делегирование — передача ответственности за определенную ветвь дерева доменных имен другому физическому или юридическому лицу. Именно эта процедура практически реализует важный принцип работы DNS — распределенность хранения записей и обработки запросов. Сам процесс делегирования представляет собой добавление в ресурсные записи родительской зоны («.ru»), так называемых «склеивающих» («glue») NS-записей для делегируемой дочерней зоны («example.com»), указывающих на DNS-сервера принимающей домен стороны (например, DNS-сервера нашей компании). С этого момента все ресурсные записи домена второго уровня «example.com» и всех его дочерних доменов (например, «mail.example.com» и т.д.) хранятся на DNS-серверах этой компании, а родительская зона «.ru» хранит только указывающие на эти сервера NS-записи.

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

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

 

Основные типы ресурсных записей

Ресурсная запись (RR — Resource Record) — единица хранения и передачи информации в DNS, включающая в себя следующие элементы (поля):

• Имя (Name) — имя домена, к которому относится запись
• TTL (Time To Live) — допустимое время хранения записи неответственным сервером
• Тип (Type) — параметр, определяющий назначение и формат записи в поле данных (Rdata)
• Класс (Class) — тип сети передачи данных (подразумевается возможность DNS работать с типами сетей, отличных от TCP/IP)
• Длина поля данных (Rdlen)
• Поле данных (Rdata) — содержание и формат поля зависят от типа записи

 

Ниже представлены типы ресурсных записей, используемые чаще всего:

• A (IPv4 Address Record — адресная запись) — связывает доменное имя с IPv4-адресом хоста
• AAAA (IPv6 Address Record) — связывает доменное имя с IPv6-адресом хоста (аналогично А-записи)
• CNAME (Canonical Name Record — каноническая запись имени) — используется для перенаправления на другое доменное имя
• MX (Mail Exchange — почтовый обменник) — ссылается на почтовый сервер, обслуживающий домен
• NS (Name Server — сервер имен) — ссылается на DNS-сервер, ответственный за домен
• TXT — текстовое описание домена. Зачастую требуется для выполнения специфических задач (например, подтверждения права собственности на домен при привязке его к почтовому сервису)
• PTR (Point to Reverse — запись указателя) — связывает ip-адрес машины с доменом, используется преимущественно для проверки сторонними почтовыми сервисами отправляемых через эту машину электронных писем на отношение к домену, указанному в параметрах почтового сервера. При несоответствии этих параметров письмо проверяется более тщательно по другим критериям.

 

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

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

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

 

 

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

 

P. S. Другие инструкции:

Спасибо за Вашу оценку! К сожалению, проголосовать не получилось. Попробуйте позже

ITband.ru » Взаимодействие Active Directory и DNS

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

Прежде всего, если вы понимаете принципы работы DNS, то ничего сверхсложного рассказано не будет. Так же не будет никакого дизассемблера и прочих “мудреных” штук. Все в пределах обычного, человеческого, понимания.

Active Directory использует DNS как механизм поиска контроллеров домена и других объектов. Выделяют три следующих компонента, от которых зависит работа AD в DNS:

• Domain controller locator
• Доменные имена Active Directory в DNS
• Объекты Active Directory в DNS

А теперь давайте рассмотрим более подробно:

Domain controller locator	Представлен службой NET LOGON, позволяющей клиентам найти контроллеры домена.
Доменные имена Active Directory в DNS	Каждый домен имеет DNS имя (к примеру: inadmin.ru ), так же каждый компьютер из этого домена имеет свое DNS имя ( к примеру: Server01.inadmin.ru ). Архитектурно, каждый компонент хранится как объект в Active Directory и как узел в DNS. Тут есть принципиальное отличие, хотя имена одинаковы, но выполняют они разные роли. DNS разрешает имена доменов и компьютеров из ресурсных записей. Для этого посылается запрос на DNS сервер, который хранит DNS базу данных Active Directory разрешает доменные объекты. Получаемы путем запроса к контроллерам домена, такими как LDAP запросы.
Объекты Active Directory в DNS	Когда DNS хранится в Active Directory, то для каждой DNS зоны создается контейнер ( класс dnsZone ). Внутри данного объекта хранятся объекты DNS (класс dnsNode) для каждого уникального имени. Эти уникальные имена включают изменения, связанные с хостовой машиной. У каждого объекта dnsNode есть атрибут с несколькими значениями dnsRecord, который содержит значение для каждой ресурсной записи, связанной с именем объекта.

Имена компьютеров

Домены Active Directory имеют два типа имен. DNS и NetBIOS. Оба этих имени видны для конечных пользователей. Имена доменов обычно определяются DNS именем, но для обратной совместимости ( с Windows 2000) каждый домен содержит NetBIOS имя. NetBIOS это “короткое” имя. Содержит до 15 ASCII символов. Последний ,т.е. 16-й, зарезервирован как NetBIOS суффикс. NetBIOS суффикс описывает тип данной записи:

00	Workstation Service
03	Messenger Service
20	File Service (also called Host Record)
1B	Domain Master Browser – Primary Domain Controller for a domain
1C	Domain Controllers for a domain (group record with up to 25 IP addresses)
01	Master Browser
1E	Browser Service Elections

DNS имя называют полным именем или FQDN (fully qualified domain name). FQDN имя получается путем сложения имени компьютера ( первые 15 байт SAMAccountName, без символа “$”) и первичного DNS суффикса ( DNS имя домена, в котором находится компьютер). Для ОС Windows можно посмотреть по пути WIN+Break. По умолчанию, первичный DNS суффикс для FQDN имени должен быть таким же, как и имя Active Directory домена, в котором компьютер находится. При необходимости можно добавить другие доменные суффиксы, которые создаются как msDS-AllowedDNSSuffixes атрибуты.

Итак мы имеем, что для Server01.inadmin.ru

• Префикс – это первая часть имени. В моем примере: Server01
• Суффикс – это вторая часть имени, содержащий домен, в котором находится компьютер.В моем примере: inadmin.ru

Так же есть SPN ( service principal name ), это немного другое. Обычно SPN имя получается из DNS имени хоста. SPN используется в процессе взаимной аутентификации между клиентом и сервером, располагающим конкретными службами. Клиент находит учетную учетную запись компьютера использующей SPN сервис. И пытается с ней соединиться.

Active Directory в DNS

Физическая структура информации Active Directory в DNS представлена DNS зонами и ресурсными записями, которые хранятся в Active Directory, как Active Directory интегрированные DNS зоны (Active Directory поддерживает хранение DNS зон в файлах). Кроме того, протокол динамических обновлений DNS используется Active Directory для автоматизации обновления ресурсных записей DNS, что бы автоматически поддерживать актуальность данных. Для работы Active Directory необходима поддержка SRV записей и динамических обновлений зоны. Active Directory использует DNS как механизм поиска необходимой информации, предоставляя компьютерам возможность поиска IP адреса контроллеров домена и другой необходимой информации.

Во время инсталляции контроллера домена SRV и A записи динамически регистрируются в DNS. Оба типа записей необходимы для механизма поиска контроллеров домена ( Domain controller locator ). После установки Active Directory необходимые записи можно найти на контроллере домена в :
%systemroot%\System32\Config\Netlogon.dns.

При поиске контроллеров домена в домене или лесу Active Directory, клиент запрашивает SRV и A ресурсные записи. Эти ресурсные записи предоставляют клиент DNS имена и IP адреса контроллеров домена. Когда контроллер домена добавляется в домен или в лес Active Directory, в DNS зоне добавляются необходимые записи для нового контроллера домена. Именно по этой причине, DNS сервер должен поддерживать динамические обновления. В противном случае, необходимо вручную вносить необходимые изменения в DNS.

• _msdcs – это поддомен, определенный Microsoft. Его задача определять расположение DC, которые выполняю определнные роли в лесу и в домене. Данная зона хранится в forest-wide application directory partition. Служба Net Logon регистрирует SRV записи для идентификации Well-Known ресурсов, таких как DC (Domain Controller), GC (Global Catalog), PDC (Primary Domain Controller), Domains (Globally Unique Identifier, GUID), как префиксы в поддомене _msdcs. Определенные таким образом поддомены определяют контроллеры домена, находящиеся в домене или лесу и выполняющие определенные роли. Что бы определять расположение DC по типу или по GUID, сервера Windows регистрируют SRV по следующему шаблону:

_Service._Protocol.DcType. _msdcs. DnsDomainName

• SRV Записи. Когда контроллер домена загружается, служба Net Logon с помощью динамических обновлений регистрирует SRV и А записи на DNS сервере. SRV записи используются для закрепления имени службы ( к примеру LDAP) за DNS именем компьютера, на котором запущена данная служба. Когда рабочая станция подключается к домену, то она запрашивает DNS на наличие SRV записей по такой форме:

_Service ._ Protocol . DnsDomainName

Так как Active Directory использует TCP протокол, клиенты находят LDAP сервер в таком виде:

_ldap. _tcp. DnsDomainName

SRV записи, регистрируемые службой Net Logon

В следующей таблице, мы увидим какие SRV записи регистрируются службой Net Logon. А так же область применения записи и кто ее регистрирует.

• DnsDomainName DNS имя домена, в котором находится сервер
• DnsForestName DNS имя леса, т.е. DNS имя корневого домена леса.

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

_ldap._tcp. DnsDomainName .	Позволяет клиенту найти сервер с запущенным LDAP сервисом в домене DnsDomainName. К примеру: _ldap._tcp.inadmin.ru
_ldap._tcp. SiteName . _sites. DnsDomainName .	Позволяет клиенту найти сервер с запущенным LDAP сервисом в домене DnsDomainName в сайте SiteName. SiteName относительное имя, которое хранится в контейнере Configuration в Active Directory. К примеру: _ldap._tcp.Moscow._Sites.inadmin.ru
_ldap._tcp.dc._msdcs. DnsDomainName .	Позволяет клиенту найти контроллер домена в домене DnsDomainName. Все DС регистрируют данную SRV запись.
_ldap._tcp. SiteName . _sites.dc._msdcs. DnsDomainName .	Позволяет клиенту найти контроллер домена в домене DnsDomainName в сайте SiteName. Все DС регистрируют данную SRV запись.
_ldap._tcp.pdc._msdcs. DnsDomainName .	Позволяет клиенту найти PDC в домене DnsDomainName.Только PDC сервер регистрирует данную SRV запись.
_ldap._tcp.gc._msdcs. DnsForestName .	Позволяет клиенту найти PDC в лесу DnsForestName.Только GC сервера регистрируют данную SRV запись.
_ldap._tcp. SiteName . _sites.gc._msdcs. DnsForestName .	Позволяет клиенту найти GC в лесу DnsForestName.Только GC сервера принадлежащие данному лесу регистрируют данную SRV запись. К примеру: _ldap._tcp.Moscow._Sites._gc. _msdcs.inadmin.ru
_gc._tcp.DnsForestName.	Позволяет клиенту найти GC в данном домене. Только GC сервера принадлежащие данному лесу DnsForestName регистрируют данную SRV запись. К примеру: _gc._tcp.inadmin.ru
_gc._tcp.SiteName. _sites.DnsForestName.	Позволяет клиенту найти GC в данном лесу DnsForestName в сайте SiteName. Только GC сервера принадлежащие данному лесу DnsForestName регистрируют данную SRV запись. К примеру: _gc._tcp._Moscow._Sites.inadmin.ru
_ldap._tcp. DomainGuid . domains._msdcs. DnsForestName .	Позволяет клиентам найти DC по GUID. GUID это 128-битный уникальный указатель. Расчитано на тот момент, когда DnsDomainName и DnsForestName изменились. К примеру: _ldap._tcp.4f904480-7c78-11cf-b057-00aa006b4f8f.domains. _msdcs.inadmin.ru
_kerberos._tcp. DnsDomainName .	Позволяет клиентам найти Kerberos KDC в данном домене DnsDomainName. Все DC регистрируют данную SRV запись.
_kerberos._udp. DnsDomainName .	Тоже самое, что и _kerberos._tcp. DnsDomainName только через UDP
_kerberos._tcp. SiteName . _sites. DnsDomainName .	Позволяет клиентам найти Kerberos KDC в данном домене DnsDomainName в сайте SiteName. Все DC регистрируют данную SRV запись.
_kerberos._tcp.dc._msdcs. DnsDomainName .	Позволяет клиентам найти DC на котором запущена роль Kerberos KDC в данном домене DnsDomainName. Все DC с ролью KDC регистрируют данную SRV запись.
_kerberos.tcp. SiteName . _sites.dc._msdcs. DnsDomainName .	Позволяет клиентам найти DC на котором запущена роль Kerberos KDC в данном домене DnsDomainName в сайте SiteName. Все DC с ролью KDC регистрируют данную SRV запись.
_kpasswd._tcp.DnsDomainName.	Позволяет найти Kerberos Password Change для текущего домена. Все DC c ролью kerberos KDC регистрирую данную SRV запись
_kpasswd._udp. DnsDomainName.	Тоже самое, что и _kpassword._tcp. DnsDomainName только через UDP

Так же служба Net logon регистрирует CNAME ресурсную запись для репликации Active Directory.

DsaGuid._msdcs.DnsForestName.

DC Locator не использует данную запись. Фактически эта запись помогает при переименовании контроллера домена.

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

Так же у SRV записей есть дополнительные поля:

Priority	Приоритет сервера. Клиенты пытаются подключиться к серверам с меньшим приоритетом.
Weight	Используется в роли Load-balanced для серверов с одинаковым приоритетом. Клиенты рандомно выбирают сервер с вероятностью, пропорциональной весу.
Port Number	Порт, на котором сервер «слушает»
Target	FQDN сервера

Host записи для Non-SRV клиентов.

Служба Net Logon так же регистрирует ресурсные записи A-типа для LDAP клиентов, которые не поддерживают SRV записи. DC Locator не использует данные записи.

DnsDomainName.	Позволяет Non-SRV клиентам найти контроллер домена в домене, путем просмотра A-записи. Non-SRV клиенты смотрят данное имя; SRV поддерживающие клиенты ищут соответствующую SRV запись
gc._msdcs.DnsForestName.	Позволяет Non-SRV клиентам найти глобальный каталог в лесу, путем просмотра A-записи. Non-SRV клиенты смотрят данное имя; SRV поддерживающие клиенты ищут соответствующую SRV запись

Пример регистрации имен

Служба Net Logon , как мы уже говорили регистрирует необходимые для обнаружения записи. Простой пример какие записи обновляются или создаются.

DC001.inadmin.ru   A   192.168.0.3
_ldap._tcp.inadmin.ru    SRV  0 0 389 DC001.inadmin.ru
_kerberos._tcp.inadmin.ru   SRV  0 0 88 DC001.inadmin.ru
_ldap._tcp.dc._msdcs.inadmin.ru  SRV  0 0 389 DC001.inadmin.ru
_kerberos._tcp.dc._msdcs.inadmin.ru  SRV  0 0 88 DC001.inadmin.ru

Когда клиенты запрашивают к примеру _kerberos._tcp.dc._msdcs.inadmin.ru, то ему возвращается целая пачка имен и IP адресов,состоящая из контроллеров домена, которые предоставляют kerberos аутентификацию.

Хочется дополнить, что регистрируются не только DNS имена, но и NetBIOS.

• DNS имя сервера, регистрируется на DNS сервере (DC001.inadmin.ru )
• NetBIOS имя, регистрируется на WINS сервере (если он есть) (DC001)

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

• Если имя домена, в который входит клиент, DNS имя, то компьютер должен запросить DNS для поиска контроллера домена
• Если имя домена, в который входит клиент, NetBIOS имя, то компьютер должен запросить WINS (возможно использование broadcast сообщения для поиска NetBIOS имени) для поиска контроллера домена

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

Active Directory интегрированные зоны

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

1. Domain Partition. Часть раздела Active Directory, присутствующая на каждом DC в лесу. DNS зоны реплицируются на все DC в домене. Используется только для DC под управлением Windows 2000
2. Forest-wide DNS Application directory partition. Хранится в разделе приложений Active Directory. DNS зоны, хранящиеся в данном разделе, реплицируются на все DC в лесу. Этот раздел создается автоматически, когда устанавливается роль DNS сервера на первом DC в лесу под управлением Windows 2003 и выше.
3. Domain-wide DNS Application directory partition. Раздел DNS для каждого отдельного домена в лесу. Хранится в разделе приложений Active Directory и реплицируется на все DC в текущем домене. Автоматически создается при установки роли DNS сервера в домене под управлением Windows 2003 и выше. Для каждого нового домена в лесу создается новая зона и область доступности, ограниченная текущим доменом.
4. Custom DNS Application directory partition. Используется для репликации между зарание определенными DC. Хранится в разделе приложений Active Directory. Доступна во всем лесу Active Directory, на заранее определенных DC.

Примечание: Если лес Active Directory создавался в Windows 2000, то _msdcs.DnsDomainName был частью поддомена DnsDomainName. Если же лес Active Directory создавался в версиях начиная с Windows 2003, то _msdcs.DnsDomainName создавалась как новая DNS зона (рядом с DnsDomainName ) и помещалась в forest-wide DNS application directory partition.

Примечание: DNS зоны хранящиеся в application directory partitions не видны для контроллеров домена под управлением Windows 2000.

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

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

В обычной ситуации делегируют дочерние пространство DNS имен, совпадающее с именем дочернего домена Active Directory. Стоит помнить, что при делегирование разрешение имен должно происходить не только в сторону с корневого домена “вниз”, но и наоборот. То есть, DNS сервера расположенные в корневом домене должны с легкостью разрешить имена любого дочернего домена Active Directory.

Правильной работой DNS будет считаться когда пользователи из дочернего домена Sokolniki.moscow.inadmin.ru смогу разрешать имена в корневом домене Inadmin.ru и его любых дочерних доменах , к примеру SPB.inadmin.ru

Процесс Domain Controller Locator

Прежде всего алгоритм состоит из основных действий:

• Нахождение контроллеров домена зарегистрированных в DNS
• Отправка DNS запроса на нахождение контроллеров домена в определенном домене
• Отправка LDAP запроса для подтверждения работоспособности контроллера домена
• Кэширование запроса

А теперь давайте рассмотрим более подробно.

1. На клиенте, компьютере, который хочет найти контроллер домена Locator инициирует RPC для Net Logon (DsGetDcName)
2. Клиент собирает необходимую информацию для выбора контроллера домена и передает информацию службе Net Logon, используя DsGetDcName API
3. Служба Net Logon использует полученную информацию для выбора контроллера домена в домене.
   • Для DNS имени Net Logon использует DNS запросы (DNS-compatible Locator ) DnsQuery для получения SRV и A записей.
   • Для короткого имени поиск контроллера домена выпольняется с помощью NT 4.0–compatible Locator, который опирается, к примеру на WINS.

Поиск контроллера домена в ближайшем сайте

Когда DC Locator пытается найти контроллер домена, то он старается найти ближайший контроллер домена. Для этого он использует информацию, хранимую в Active Directory.

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

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

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

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

Примечание: Когда у компьютер не знает свой последний сайт (из реестра), то он будет обращаться к любому контроллеру домена. Есть вариант настроить Netmask ordering и тогда DNS будет стараться выдать IP ближайшего контроллера домена только с точки зрения IP маршрутизации.

Сайты Active Directory и Subnet

Советую прочитать данную статью. Очень хорошо Илья описал сайты и их взаимодействие. Описано просто, поэтому переписывать еще раз – нет смысла

Сайт это набор подсетей, соединенных быстрым каналом обмена данных. Служат для управления траффиком репликации.

• В Active Directory сайты определены как объекты в cn=Sites,cn=Configuration,dc=ForestRootDomain контейнере.
  • Контроллеры домена определены в cn=servers, cn=site_name, cn=Sites,cn=Configuration,dc=ForestRootDomain
• Subnet это часть сегмента сайта и представлена cn=Subnets,cn=Configuration,dc=ForestRootDomain контейнере. У каждого объекта Subnet есть siteObject атрибут, который связывает его с объектом сайта; значение siteObject – distinguished name сайта.
• Объекты транспорта представлены в CN=Inter-Site Transports,cn=Sites,cn=Configuration,dc=ForestRootDomain

Важно: Сайты могут в себе содержать одну или несколько IP сетей. Задаются в формате network/mask_bits. Администратор должен вручную определить сайты, контроллеры домена и подсети.

Примечание: Так как объекты сайтов хранятся в разделе Configuration, то они реплицируются по всему лесу Active Directory. Именно это дает возможность каждому контроллеру домена знать о расположении всех контроллеров домена в лесу и строить топологию. Служба Net Logon регистрирует так же изменения произошедшие в сайте.

Алгоритм работы:

1. Служба Net Logon смотрит на IP адрес клиента, и т.к. хранит всю информацию о сайтах и их структурах, то определяет (на основе IP адреса) откуда клиент. Возвращает ему необходимую информацию.
   • Имя сайта в котором клиент расположен или имя ближайшего для него сайта
   • Имя сайта в котором расположен контроллер домена
   • «bit», который указывает,находится ли контроллер домена (бит установлен) или не находится (бит не установлен) в том же сайте, что и клиент.
2. Клиент смотрит возвращаемые данные для определения лучшего контроллера домена.
   • Если возвращаемый контроллер домена находится в том же сайте («Bit» установлен), клиент использует этот контроллер домена
   • Если клиент пытался до этого найти контроллер домена в этом же сайте. клиент использует этот контроллер домена.
   • Если контроллер домена находится не в ближайшем для него сайте, то клиент обновляет информацию у себя. Отправляет DNS запрос для поиска нового контроллера домена в сайте. Если запрос удался , то используется новый контроллер домена, иначе используется старый.
   • Если домен, в котором происходит текущий запрос, такой же как и домен к которому подключен компьютер. Сайт, в котором находится компьютер, сохраняется в реестре.

     HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\ Netlogon\Parameters

     в ключе DynamicSiteName

     Примечание: можно перезаписать параметр DynamicSiteName на заданный вручную, для этого нужно использовать параметр SiteName (необходимо создать), при этом DynamicSiteName не будет использоваться

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

Site Coverage

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

Алгоритм Site Coverage

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

• Построить список всех целевых сайтов – в которых нету контроллеров домена для текущего домена.
• Построить список для всех сайтов – в которых есть контроллеры домена для текущего домена
• Для каждого сайта, в котором нет контроллера домена выполняются:
  1. Построить список сайтов, в которых есть контроллеры домена
  2. Из них, построить список сайтов которые имеют минимальную стоимость для сайтов из списка п.1
  3. Если больше одного, то сократить до одного кандидата, выбрав сайт с большим кол-вом контроллеров домена.
  4. Если больше одного, то оставить одного кандидата, сортирую в алфавитном порядке.
  5. Зарегистрировать SRV записи для контроллера домена в сайте.

Кэши и timeout

Кэши служат для того, что бы реже обращаться к поиску контроллеров домена. Сколько хранить данные о текущем контроллере домена. Задается в реестре поле CloseSiteTimeout. По умолчанию время установлено в 15 минут. ( минимально 1 минута, максимум 49 дней).

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

Заключение

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

Баканов Денис

MCSE+S; MCITP EA

Оригинал статьи

Проверка полного доменного имени, обратного DNS / PTR, записи MX

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

FQDN

FQDN (полное доменное имя) — это имя, присвоенное отдельной машине. Его цель — однозначно идентифицировать одну машину в Интернете. Это имя вашего сервера.

Проверка имени хоста (FQDN)

Следующие команды показывают результат для test.rtcamp.com (поддомен, который мы использовали для настройки тестового почтового сервера)

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

 имя хоста -f 

Выходы:

 тест.rtcamp.com 

Изменение имени хоста (FQDN)

Если это неверно или требуется изменение, вы можете сделать это, запустив:

 имя хоста myhost.mydomain.mytld 

Как видите, мы можем дать вашему серверу любое имя, вам может быть интересно, как работает уникальность! Вот где на сцену выходит обратный PTR.

Важно — Установите запись «A» для хоста в FQDN

Если вы задаете полное доменное имя вашего компьютера, например mail. example.com , то на example.com DNS создаст запись «A» для субдомена «mail», указывающего на IP-адрес вашего сервера.

Вы можете использовать example.com в качестве имени хоста, которое, скорее всего, уже указывает на IP-адрес вашего сервера. Технически это не полное доменное имя, но я вижу, что в основном оно работает. Тем не менее, я никогда не буду использовать или рекомендовать имя хоста, отличное от FQDN.

Обратная запись DNS / PTR

Как запись «A» помогает глобальному Интернету найти IP-адрес для домена, запись указателя (PTR) помогает вам найти домен (FQDN) для IP. Поскольку это противоположно тому, для чего обычно используется DNS, этот процесс также часто называют обратным поиском DNS.

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

Проверьте IP-адрес вашего сервера, используя следующую команду:

 хост test. rtcamp.com 

Вы увидите строки, подобные ниже:

 test.rtcamp.com имеет адрес  192.241.254.103 
Почтой test.rtcamp.com занимается 10 test.rtcamp.com. 

Если ваш сервер имеет несколько записей A, вы увидите несколько строк для IP-адресов, перечисленных по одной на строку.Для реального примера запустите хост google.com

Пожалуйста, запишите пока IP-адрес. Проверьте правильность обратного PTR для IP-адреса:

 хост 192.241.254.103 

Выходы:

 103.254.241.192.in-addr.arpa указатель доменного имени test.rtcamp.com. 

Как видите, обратный поиск DNS для IP показывает такое же имя хоста (FQDN) в приведенном выше примере.

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

Команда dig для обратного поиска DNS / PTR

Вы также можете использовать инструмент для раскопок. Просто напишите IP-адрес в октете-реверсе и добавьте in-addr.arpa в конце:

 dig + короткий ptr 103.254.241.192.in-addr.arpa 

Вы получите такой результат:

 test.rtcamp.com. 

MX записей

Запись

MX сообщает Интернету, какая машина будет получать почту для определенного домена / поддомена.

Самый простой способ проверить, занимается ли кто-то почтой для вашего домена, — это запустить снова:

 хост test.rtcamp.com 

Вы увидите строки, подобные ниже:

 test.rtcamp.com имеет адрес 192.241.254.103
Почтой test.rtcamp.com занимается 10  test.rtcamp.com.  

Как видите письма для test.rtcamp. com обрабатывается test.rtcamp.com только (тот же сервер).

Если вы используете Google Apps, вы увидите результат вроде:

 rtcamp. com почту обрабатывает 30 alt2.aspmx.l.google.com.
Почта rtcamp.com обрабатывается 10 aspmx.l.google.com.
Почта rtcamp.com обрабатывается 20 alt1.aspmx.l.google.com.
Почта rtcamp.com обрабатывается 50 aspmx3.googlemail.com.
Почта rtcamp.com обрабатывается 40 aspmx2.googlemail.com. 

Если вы не видите «почта обрабатывается» , это означает, что в вашем домене нет записи MX.

Это также нормально, если вы не хотите обрабатывать входящие электронные письма для определенного домена.Вам НЕ нужны записи MX для отправки домена из определенных писем.

Как же тогда работает несколько доменов!

Первый вопрос, который мне задали, когда мы писали эту серию статей, был — если обратное PTR в IP и IP в FQDN необходимо, как работают несколько доменов. Специально для сценария виртуального хостинга.

Короткий ответ — на виртуальном хостинге, даже если вы отправляете почту из своего домена, в заголовки писем добавляется полное доменное имя (уникальные имена компьютеров), для которых в большинстве случаев правильно работает обратный PTR. Пока FQDN и Reverse-PTR идеальны, почта, скорее всего, будет работать. Это как первая проверка, а не единственная проверка!

Полное доменное имя FQDN

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

Полное доменное имя, в отличие от имени хоста, включает все родительские домены до корневого домена включительно (как показано на рисунке 2-2), что, в свою очередь, гарантирует их уникальность в пространстве имен DNS. Ярким примером является имя хоста «www». Вероятно, существуют миллионы хостов с именами www по всему миру, но их полные доменные имена уникальны, потому что они включают весь путь в пространстве имен, начиная с имени хоста и продвигаясь вверх через SLD и TLD к корню.

Во времена Windows NT 4.0 имя NetBIOS и имя хоста DNS не были связаны друг с другом и не зависели друг от друга. Чтобы обеспечить обратную совместимость приложений в Windows 2000/2003 / XP, а также уменьшить административные издержки, имена хостов и имена NetBIOS устанавливаются одинаково. Это означает, что часть полных доменных имен в части имени хоста должна соответствовать требованиям к имени NetBIOS. Назначение одного и того же имени NetBIOS и имени хоста DNS не является обязательным, но рекомендуется, если в вашей сети все еще используются приложения, использующие имена NetBIOS.В этом случае вы должны быть уверены, что назначаете действительные имена NetBIOS, совместимые с RFC именования хостов, применимыми к DNS. Microsoft рекомендует объединить два пространства имен (присвоить одинаковые имена) или полностью избавиться от NetBIOS, когда это возможно.

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

РИСУНОК 2-2

Структура DNS-имени

Интернет-корень

Интернет-корень

srv01.sales.flexecom.com

Подчеркивания разрешены в пространстве имен NetBIOS, но они не являются допустимым символом имени хоста DNS. Подчеркивание в именах DNS разрешено только в служебных записях, но не в записях хостов (RFC DNS: 1034, 1035, 1123, 1995, 1996, 2136, 2181, 2308 и некоторые другие). Поэтому, если у вас есть существующие имена NetBIOS с подчеркиванием, их необходимо заменить дефисами. Некоторые недавние изменения стандарта DNS также сделали возможным использование языков, отличных от английского, при именовании хостов; однако эта технология не очень надежна за пределами локальной сети.

Продолжить чтение здесь: Записи ресурсов

Была ли эта статья полезной?

Ubuntu Manpage: hostname — показать или установить имя хоста системы

Предоставлено: hostname_3.20_amd64

НАИМЕНОВАНИЕ

       hostname - показать или установить имя хоста системы
       domainname - показать или установить системное доменное имя NIS / YP
       ypdomainname - показать или установить системное доменное имя NIS / YP
       nisdomainname - показать или установить системное доменное имя NIS / YP
       dnsdomainname - показать DNS-имя домена системы

 

ОБЗОР

         имя хоста  [ -a | --alias ] [ -d | --domain ] [ -f | --fqdn | --long ] [ -A | --all-fqdns ] [  -i | --ip-адрес ]
       [ -I | --all-ip-addresses ] [ -s | --short ] [ -y | --yp | --nis ]
         имя хоста  [ -b | --boot ] [ -F | --file   имя файла ] [ имя хоста ]
         имя хоста  [ -h | --help ] [ -V | --version ]

         имя домена  [ nisdomain ] [ -F   файл ]
         ypdomainname  [ nisdomain ] [ -F   file ]
         nisdomainname  [ nisdomain ] [ -F   file ]

         dnsdomainname 

 

ОПИСАНИЕ

         Имя хоста  используется для отображения DNS-имени системы, а также для отображения или установки имени хоста или
       Доменное имя NIS.  ПОЛУЧИТЬ   НАЗВАНИЕ 
       При вызове без аргументов программа отображает текущие имена:

         hostname  напечатает имя системы, возвращенное функцией  gethostname  (2).

         domainname  выведет имя домена NIS системы.  доменное имя  использует
         gethostname  (2), а  ypdomainname  и  nisdomainname  используют  getdomainname  (2). dnsdomainname  распечатает доменную часть FQDN (полностью определенное доменное имя). В
       полное FQDN системы возвращается с  hostname   --fqdn  (но см. предупреждения в
       раздел  THE   FQDN  ниже).

     НАБОР   НАЗВАНИЕ 
       При вызове с одним аргументом или с параметром  --file  команды устанавливают имя хоста или
       доменное имя NIS / YP.  hostname  использует функцию  sethostname  (2), а все три
         domainname,   ypdomainname  и  nisdomainname  используют  setdomainname  (2). Обратите внимание, что это
       действует только до следующей перезагрузки. Отредактируйте / etc / hostname для постоянного изменения.

       Обратите внимание, что только суперпользователь может изменять имена.

       Невозможно установить полное доменное имя или имя домена DNS с помощью команды  dnsdomainname 
       (см.  THE   FQDN  ниже).

       Имя хоста обычно задается один раз при запуске системы в  /etc/init.d/hostname.sh  (обычно
       путем чтения содержимого файла, содержащего имя хоста, например.грамм.  / etc / hostname ).

     THE   FQDN 
       FQDN (полное доменное имя) системы - это имя, которое преобразователь   (3)
       возвращает имя хоста, например,  ursula.example.com . Обычно это имя хоста
       за которым следует имя домена DNS (часть после первой точки). Вы можете проверить полное доменное имя
       используя  hostname   --fqdn  или имя домена, используя  dnsdomainname . Вы не можете изменить полное доменное имя с  hostname  или  dnsdomainname .

       Рекомендуемый метод установки FQDN - сделать имя хоста псевдонимом для
       полное имя с использованием  / etc / hosts , DNS или NIS. Например, если имя хоста было
       "ursula", в  / etc / hosts  может быть строка, которая гласит

              127.0.1.1 ursula.example.com урсула

       Технически: полное доменное имя - это имя , которое getaddrinfo  (3) возвращает для имени хоста, возвращаемого
         gethostname  (2).Доменное имя DNS - это часть после первой точки.

       Следовательно, это зависит от конфигурации резолвера (обычно в файле  /etc/host.conf ), как
       вы можете это изменить. Обычно файл hosts анализируется перед DNS или NIS, поэтому
       общее для изменения полного доменного имени в  / etc / hosts .

       Если машина имеет несколько сетевых интерфейсов / адресов или используется в мобильной среде,
       тогда он может иметь несколько полных доменных имен / доменных имен или вообще ни одного. Поэтому избегайте использования
         имя хоста   --fqdn ,  имя хоста   --domain  и  dnsdomainname .  hostname   --ip-address  подлежит
       те же ограничения, поэтому этого также следует избегать.

 

ОПЦИИ

         -a,   - псевдоним 
              Отображение псевдонима хоста (если используется). Эта опция устарела и должна
              больше не будет использоваться. -A,   --all-fqdns 
              Отображает все полные доменные имена машины. Эта опция перечисляет все настроенные сети
              адреса на всех настроенных сетевых интерфейсах и переводит их в домен DNS
              имена. Адреса, которые нельзя перевести (т. Е. Потому что они не имеют
              соответствующий обратный IP-адрес) пропускаются. Обратите внимание, что разные адреса могут
              разрешаются с тем же именем, поэтому выходные данные могут содержать повторяющиеся записи.Делать
              не делать никаких предположений о порядке вывода. 

         -b,   - boot 
              Всегда устанавливайте имя хоста; это позволяет файлу, указанному в  -F , быть несуществующим или
              пусто, и в этом случае будет использоваться имя хоста по умолчанию  localhost , если его еще нет
              набор.

         -d,   - домен 
              Отобразите имя домена DNS. Не используйте команду  domainname , чтобы получить
              DNS-имя домена, потому что в нем будет отображаться имя домена NIS, а не DNS-домен.
              имя.Вместо этого используйте  dnsdomainname . См. Предупреждения в разделе  THE   FQDN  выше, и
              избегайте использования этой опции.

         -f,   --fqdn,   --long 
              Отобразите полное доменное имя (полное доменное имя). Полное доменное имя состоит из короткого хоста
              имя и доменное имя DNS. Если вы не используете привязку или NIS для поиска хоста, вы
              может изменить полное доменное имя и имя домена DNS (которое является частью полного доменного имени) в
                / etc / hosts  файл. См. Предупреждения в разделе  THE   FQDN  выше и используйте  hostname   --all- 
                fqdns  вместо этого везде, где это возможно.

         -F,   --file   filename 
              Прочтите имя хоста из указанного файла. Комментарии (строки, начинающиеся с символа `# ')
              игнорируются.

         -i,   --ip-адрес 
              Отобразите сетевой адрес (а) имени хоста. Обратите внимание, что это работает, только если
              имя хоста может быть разрешено.Избегайте использования этой опции; используйте  hostname   --all-ip-addresses 
              вместо.

         -I,   - все IP-адреса 
              Показать все сетевые адреса хоста. Эта опция перечисляет все настроенные
              адреса на всех сетевых интерфейсах. Интерфейс обратной связи и локальный канал IPv6
              адреса опущены. В отличие от опции  -i , эта опция не зависит от имени
              разрешающая способность. Не делайте предположений о порядке вывода.

         -s,   -короткое 
              Отобразите короткое имя хоста. Это имя хоста, отрезанное от первой точки.

         -V,   - версия 
              Распечатать информацию о версии на стандартном выходе и успешно завершить работу.

         -y,   --yp,   --nis 
              Отобразите доменное имя NIS. Если указан параметр (или  --file   name ), то root
              также можно установить новый домен NIS. -h,   --help 
              Распечатайте сообщение об использовании и выйдите.

 

ПРИМЕЧАНИЯ

       Семейства адресов  hostname  пытается найти полное доменное имя, псевдонимы и сеть
       Адреса хоста определяются конфигурацией вашего преобразователя. Например,
       в системах GNU Libc преобразователь может получить указание сначала попробовать поиск IPv6 с помощью команды
         inet6  опция в  / etc / resolv. conf .

 

ФАЙЛЫ

         / etc / hostname  Исторически этот файл должен был содержать только имя хоста, а не
       полное каноническое FQDN. В настоящее время большая часть программного обеспечения может обрабатывать здесь полное доменное имя. Этот
       файл читается во время загрузки сценариями инициализации системы для установки имени хоста.

         / etc / hosts  Обычно здесь задают имя домена, добавляя псевдоним имени хоста к
       полное доменное имя.

 

АВТОРЫ

       Питер Тобиас, 
       Бернд Эккенфельс,  (NIS и справочная страница).
       Майкл Мескес, 
 

Изменить имя хоста и полное доменное имя (FQDN) в Ubuntu 16.04

Задайте имя хоста и полное доменное имя

Имя хоста — это имя компьютера / облачного сервера, подключенного к сети. Имя хоста используется для идентификации компьютера в сети. Это также часть полного доменного имени (FQDN), которое требуется для многих приложений.Если вы собираетесь указать полное доменное имя, например, во время установки Plesk, эта статья может вам помочь.
Обязательным условием является наличие на сервере пользователя root. В этом руководстве вы увидите, как можно установить имя хоста сервера и полное доменное имя. В этом примере мы будем использовать имя «web1.gridscale.io».

Шаг 1: Задайте имя хоста

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

  имя хоста  

Теперь вывод показывает:

  test1  

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

Откройте файл «/ etc / hostname» в любом редакторе:

  sudo nano / etc / hostname  

замените ваше текущее имя хоста на новое имя хоста по вашему выбору, мы заменим наше на «web1» . Сохраните изменения, нажав «Ctrl + O», после подтверждения имени файла нажатием «Enter» закройте nano, нажав «Ctrl + X». Изменение вступит в силу после следующего перезапуска — если вы хотите, чтобы изменения вступили в силу без перезапуска, следующая команда сделает это:

  sudo hostname web1  

Внимание: изменение имени хоста с помощью команды «sudo hostname web1» носит временный характер и будет перезаписан при перезагрузке.Чтобы сделать изменение постоянным, необходимо отредактировать файл / etc / hostname. Это не замена первого шага.
Убедитесь, что команда была успешной, набрав:

  имя хоста  

Если оно возвращает новое имя хоста, которое вы ввели, имя хоста было успешно установлено.

Шаг 2: Установите полное доменное имя (FQDN)

Чтобы установить полное доменное имя, в дополнение к вашему собственному FQDN требуется общедоступный IP-адрес сервера. В данном случае 123.123.123.123 выбрано в качестве примера.
Полное доменное имя изменено в файле / etc / hosts.
Откройте файл в любом редакторе с правами root:

  sudo nano / etc / hosts  

Файл должен выглядеть примерно так:

Теперь будут установлены следующие строки:

  123.123.123.123 web1 .gridscale.io web1  

По завершении это должно выглядеть так:

Не забудьте сохранить изменения перед проверкой полного доменного имени с помощью этой команды:

  hostname –f  

Теперь полное доменное имя было изменено. установлен успешно, и эти изменения являются постоянными.

Zurück zur Tutorial Übersicht Назад к обзору учебного курса

Настройка сервера Microsoft Exchange для использования полного доменного имени

В этой статье показано, как настроить сервер Microsoft Exchange Server для использования полного доменного имени (или FQDN). Это может потребоваться, если в вашей нынешней сети используются «внутренние имена» — необходимо будет ввести полные доменные имена, чтобы заменить или переназначить эти внутренние имена, чтобы убедиться, что ваша архитектура безопасности будет работать в условиях предстоящих изменений.

Что именно изменилось?

Сообщество интернет-безопасности постепенно отказывается от использования внутренних имен и IP-адресов в качестве основных доменных имен или альтернативных имен субъектов (SAN) в сертификатах SSL. Любые внутренние имена, которые вы настроили, необходимо будет изменить, чтобы избежать раскрытия или прерывания служб, которые вы хотите защитить.

Что такое внутреннее имя?

В этом контексте внутреннее имя — это все, что не может гарантировать уникальный идентификатор сетевого ресурса .Почтовый сервер в вашей интрасети с именем Mail использует внутреннее имя (иногда также называемое «именем интрасети»), и на него повлияет это изменение — однако тот же сервер будет работать нормально, если ему назначено полное доменное имя, например mail.mydomain. com , используя приведенные ниже инструкции.

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

Если вы используете внутреннее имя или IP-адрес для сертификата SSL, размещенного на сервере Microsoft® Exchange, вы можете выполнить рекомендации Форума по браузеру центров сертификации, перенастроив свой сервер на прием полного доменного имени (FQDN). Например, вы можете изменить внутреннее имя server.local на FQDN mail.coolexample.com .

Если вы еще этого не сделали, чтобы гарантировать, что внутреннее автообнаружение продолжает работать, вы должны создать внутреннюю зону DNS для своего доменного имени (например, autodiscover.coolexample.com ) и запись MX, которая указывает на внутренний IP-адрес вашего сервера.

Примеры кода ниже включают следующие переменные:

• Заменить mail.coolexample.com на ваше полное доменное имя
• Замените Your_Server_Name (например, Mail или EXCH-01) на фактическое имя вашего сервера

Примечание: Мы настоятельно рекомендуем, чтобы только опытные администраторы серверов использовали это процедура. Эти инструкции не применимы к Windows Server® 2012 или Microsoft Small Business Financials (SBF) Server.

Повторная настройка сервера Microsoft Exchange Server для использования полного доменного имени

1. Запустите консоль управления Exchange .
2. Чтобы изменить URL-адрес автообнаружения, введите следующую команду и нажмите Введите :

    Set-ClientAccessServer -Identity Your_Server_Name -AutodiscoverServiceInternalUri https://mail.coolexample.com/autodiscover/autodiscover.xml 

   Чтобы изменить
3. InternalUrl атрибут EWS, введите следующую команду и нажмите Введите :

    Set-WebServicesVirtualDirectory -Identity "Your_Server_NameEWS (веб-сайт по умолчанию)" -InternalUrl https: // mail.coolexample.com/ews/exchange.asmx 

4. Чтобы изменить атрибут InternalUrl для распространения автономной адресной книги через Интернет, введите следующую команду и нажмите Введите :

    Set-OABVirtualDirectory -Identity "Your_Server_Nameoab (по умолчанию Веб-сайт) "-InternalUrl https://mail. coolexample.com/oab 

5. Если вы используете службу унифицированных сообщений в Exchange Server 2007: Чтобы изменить атрибут InternalUrl веб-службы единой системы обмена сообщениями, введите следующее и нажмите . Введите :

    Set-UMVirtualDirectory -Identity «Имя_вашего_сервераunifiedmessaging (веб-сайт по умолчанию)» -InternalUrl https: // mail.coolexample.com/unifiedmessaging/service.asmx 

6. Чтобы повторно использовать пулы приложений, откройте IIS Manager .
7. Разверните локальный компьютер, а затем разверните Пулы приложений .
8. Щелкните правой кнопкой мыши MSExchangeAutodiscoverAppPool , а затем щелкните Переработать .

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

Спасибо, что выбрали SSL.com! Если у вас есть какие-либо вопросы, свяжитесь с нами по электронной почте [email protected], позвоните по телефону 1-877-SSL-SECURE или просто щелкните ссылку чата в правом нижнем углу этой страницы. Вы также можете найти ответы на многие распространенные вопросы о поддержке в нашей базе знаний.

Полное доменное имя компьютера соответствует политике получателя

• 07.07.2020
• 2 минуты на чтение

В этой статье

Применимо к: Exchange Server 2013

Содержимое этого раздела не обновлялось для Microsoft Exchange Server 2013.Хотя он еще не обновлен, он может быть применим к Exchange 2013. Если вам все еще нужна помощь, ознакомьтесь с ресурсами сообщества ниже.

Возникли проблемы? Обратитесь за помощью на форумы Exchange. Посетите форумы Exchange Server.

Установка Microsoft® Exchange Server 2007 не может быть продолжена, поскольку полное доменное имя (FQDN) локального компьютера совпадает с адресом SMTP-протокола политики получателя.

Для установки Microsoft Exchange требуется, чтобы полное доменное имя серверов в организации Exchange не совпадало с SMTP-адресами политик получателей в той же организации Exchange.

Если полное доменное имя компьютера совпадает с SMTP-адресом политики получателя, это совпадение может вызвать отказ почты по SMTP и остановку в очередях MTA.

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

Чтобы переименовать локальный компьютер

1. Откройте систему в панели управления .

2. На вкладке Имя компьютера щелкните Изменить .

3. В разделе Имя компьютера введите новое имя компьютера и нажмите ОК . Вам будет предложено ввести имя пользователя и пароль для переименования компьютера в домене.

4. Щелкните ОК , чтобы закрыть диалоговое окно Свойства системы . Вам будет предложено перезагрузить компьютер, чтобы изменения вступили в силу.

Для изменения SMTP-адреса политики получателя

1. Запустите диспетчер системы Exchange.

2. Щелкните Организация , щелкните Получатели , а затем щелкните Политики получателей .

3. Дважды щелкните политику, которую нужно изменить.

4. Щелкните вкладку Адреса электронной почты и затем измените соответствующий SMTP-адрес

Как изменить полное доменное имя (FQDN) в CentOS 7

/ VPS / Dedicated / Как изменить полное доменное имя (FQDN) в CentOS 7

Полное доменное имя (FQDN) — это полное доменное имя для определенного компьютера или хоста в Интернете. Полное доменное имя состоит из двух частей: имени хоста и имени домена. Например, полное доменное имя для гипотетического корневого сервера может быть server.domainname.com. Полное доменное имя очень важно для использования серверов. Наверное, это очень простая задача. Но очень часто мы получаем письмо поддержки по поводу установки FQDN на серверах. Следовательно, мы делаем статью об этом.

Процедура установки FQDN в CentOS 7:

Шаг 1 : Войдите на свой сервер / VPS как root или как пользователь с привилегиями root.

Шаг 2 : Проверьте текущее имя хоста:

1 имя хоста

Шаг 3 : Вы также можете узнать статус вашего сервера и его имя хоста с помощью команды hostnamectl:

1 hostnamectl status

Шаг 4 : Теперь вот волшебная команда для изменения имени хоста CentOS 7 по умолчанию без перезагрузки сервера:

1 hostnamectl set-hostname fqdn. host.name

Примечание: Пожалуйста, измените fqdn.host.name на ваше собственное полное доменное имя хоста. Пример:

1 hostnamectl set-hostname backup.vernalwebhosting.com

Итак, если вы снова выполните команду hostnamectl status, вы увидите, что она изменилась. Однако вы увидите, что это действительно изменилось, только если вы закроете текущий сеанс и снова откроете новый сеанс SSH (выйдите и войдите обратно).

Итак, ваше полное доменное имя (FQDN) установлено.

---

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

• Была ли эта статья полезной?
• да нет

Статьи по теме

.

No related posts.