Ростелеком ТВ 

Назначение должно быть fqdn полным доменным именем. Установка имени хоста в Ubuntu. Ваше собственное FQDN имя

Прежде всего, я искал сайт по аналогичной теме и читал RFC 1535 и FQDN wiki, они, похоже, не отвечали на вопрос.

Позвольте мне использовать www.youtube.com в качестве примера. Я использовал скрипт Python:

Import socket for host in ["www.youtube.com"]: print(host) try: hostname, aliases, addresses = socket.gethostbyname_ex(host) fqdn = socket.getfqdn(host) print(" Aliases: ", aliases) print(" Hostname: ", hostname) print(" FQDN: ", fqdn) print("Addresses: ", addresses) except socket.error as msg: print("%15s: ERROR: %s" % (host, msg))

Aliases: www.youtube.com Hostname: youtube-ui.l.google.com FQDN: sa-in-f93.1e100.net Addresses: ["74.125.200.93", "74.125.200.190", "74.125.200.136", "74.125.200.91"]

1) Какова связь между именем хоста и FQDN?

3 ответов

Независимо от семантики термина FQDN, мы должны увидеть, что делает Python socket.getfqdn() .

socket.getfqdn()

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

Socket.gethostbyaddr(ip_address)

Верните тройку (hostname, aliaslist, ipaddrlist) где имя хоста является основным именем хоста, отвечающим на заданный ip_address, aliaslist - это (возможно, пустой) список альтернативных имен хостов для одного и того же адреса, а ipaddrlist - список адресов IPv4/v6 для одного и того же интерфейса на одном и том же хосте (скорее всего, содержит только один адрес).

Другими словами, getfqdn() ищет обратную запись PTR , независимо от того, что указала на нее запись A или CNAME . Он ищет полное доменное имя (FQDN) и просто дает вам первый подходящий, то есть первый, который заканчивается. , корень.

Таким образом, FQDN: sa-in-f93.1e100.net поступает из записи PTR для IP 74.125.200.93 .

93.200.125.74.in-addr.arpa. 86400 IN PTR sa-in-f93.1e100.net.

Здесь FQDN для этого имени хоста www имеющего домен youtube.com по сути является по определению www.youtube.com. , включая точку. Аналогично, sa-in-f93.1e100.net не является sa-in-f93.1e100.net доменным именем, так как на самом деле это должно быть sa-in-f93.1e100.net. :

  • имя хоста sa-in-f93 как субдомен для 1e100
  • sa-in-f93.1e100 как субдомен для net
  • sa-in-f93.1e100.net в подобласти для корня, . ,

Почему sa-in-f93.1e100.net. выбирается через www.youtube.com. просто происходит от того, как socket.getfqdn() предназначен для определения полного доменного имени для данного имени.

С другой стороны, каноническое имя CNAME записи СЛЕДУЕТ по дизайну (RFC 1035, 3.2.2) указать на каноническое имя, но оно обычно используется, как будто это просто псевдоним, потому что он работает как один. Кроме того, запись PTR SHOULD (RFC 1912, 2.1) дает тот же результат, что и представление канонического имени для данного IP.

Если бы это было выполнено, метод socket.getfqdn() был бы полностью уместным. Здесь CNAME youtube-ui.l.google.com. без соответствующей записи PTR (93.200.125.74.in-addr.arpa. IN PTR youtube-ui.l.google.com.) сделало это предположение ложным.

1) Это сложно, и результаты от них зависят от настроек разрешения имени системы, используемых библиотек и контекста. В типичном linux install hostname является каноническим именем, связанным с хостом, и может быть либо FQDN, либо коротким именем, но должно быть разрешено либо (если правильно настроить). Если используется нечто вроде NIS, имя хоста может быть только коротким именем, а не полным доменным именем.

Ваш пример (с использованием DNS):

$host www.youtube.com www.youtube.com is an alias for youtube-ui.l.google.com. youtube-ui.l.google.com has address 216.58.193.78

www.youtube.com имеет CNAME в ответе DNS ("C" означает канонический) youtube-ui.l.google.com поэтому "имя хоста", возвращаемое вашим вызовом библиотеки, является каноническим именем в соответствии с DNS.

Обратный запрос на IP-адрес с использованием DNS производится путем запроса записи PTR на 78.193.58.216.in-addr.arpa

$ host -t PTR 78.193.58.216.in-addr.arpa 78.193.58.216.in-addr.arpa domain name pointer sea15s07-in-f78.1e100.net.

Обратите внимание, что это указывает на другое имя, чем "имя хоста", которое мы получили ранее. Это связано с тем, как ISP, который владеет IP-адресом, устанавливает это и будет отличаться от хоста к хосту при использовании DNS. Довольно распространенной практикой является установление фиксированного сопоставления 1-к-1 между IP-адресами и именами для такого использования, даже если они не представляют то, что имеет хост для имени.

Другой пример (с использованием /etc/hosts):

#example hostfile 1.2.3.4 hosta hosta.example.net myothername.example.net 4.3.2.1 hostb.example.net hostb anothername

При использовании вашего кода, но с изменением "www.youtube.com" на "hosta","hostb" мы получаем:

Hosta (" Aliases: ", ["hosta.example.net", "myothername.example.net"]) (" Hostname: ", "hosta") (" FQDN: ", "hosta.example.net") ("Addresses: ", ["1.2.3.4"]) hostb (" Aliases: ", ["hostb", "anothername"]) (" Hostname: ", "hostb.example.net") (" FQDN: ", "hostb.example.net") ("Addresses: ", ["4.3.2.1"])

Таким образом, в главном файле "hostname" является первым именем после IP-адреса. Псевдонимы - это все после этого. FQDN - это первое имя с точкой.

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

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

3) Да в DNS www.youtube.com является CNAME для youtube-ui.l.google.com.

4) Для протокола HTTP 1.1 ваш клиент сообщает серверу в запросе имя сервера в строке URL, если сервер получает имя, которое он не ожидает, что он может отклонить его. Youtube рассчитывает называться www.youtube.com и сервер, обрабатывающий этот запрос, возвращает ошибку 404, если вы подключаетесь к ней и называете ее любым другим именем.

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

Полноценное доменное имя (FQDN) является специфичным для DNS термином, возвращающимся в RFC 1035, что означает доменное имя DNS, которое полностью изложено со всеми его метками компонента (в отличие от имени домена, которое оставляет некоторые ярлыки, подразумеваемые контекстом),

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

В Linux имя хоста используется многими сервисами и утилитами. Если имя хоста задано неправильно, то вы будете постоянно получать сообщения об ошибках и предупреждения. Всё зависит от того, как вы используете операционную систему. Если это обычный домашний компьютер, личный ноутбук, то можно задать любое имя и игнорировать ошибки. А если вы используете компьютер в качестве сервера, то очень важно правильно задать имя хоста (hostname).
Вот несколько причин настроить имя хоста:
  • Имя хоста отображается в подсказке Bash, сразу после символа @. Так намного проще понять на каком сервере вы залогинены.
  • MTA (message transfer agent) используют имя хоста при отправке писем (в зависимости от конфигурации MTA).

В чём разница между доменным именем и именем хоста?

Как ни странно, это не такой простой вопрос как может показаться на первый взгляд. Значение некоторых терминов может меняться в зависимости от контекста. Давайте начнем с доменного имени . Если вы знаете, как работают системы доменных имен (DNS), то вы знаете что такое доменное имя. Система доменных имен хранит запись типа A или AAAA, запись является соответсвием между доменным именем и IP-адресом. То есть, когда говорят о веб-сайте, под доменным именем обычно имеют в виду его адрес (например, "www.сайт").
Имя хоста - это символическое имя, назначенное устройству, подключенному к сети, которое может быть использовано для организации доступа к этому устройству. А какое же имя писать в качестве hostname? Здесь всё запутано, в документации к разным дистрибутивам Linux можно увидеть противоположные рекомендации . Но большинство участников дискуссий сходятся во мнении, что в качестве hostname лучше указывать короткое имя, а в файле /etc/hosts сначала следует писать доменные имена, а потом уже имя хоста.
Стоит ещё упомянуть термин Fully Qualified Domain Name (с англ. "полностью определённое имя домена"). FQDN получается если к имени хоста присоединить имя родительского домена. К примеру, есть сервер с Apache, ему назначено имя хоста websrv1. И есть сервер с базами данных, ему назначено имя dbsrv. И пусть родительским доменом для них будет example.org. Тогда полностью определенными доменными именами будут websrv1.example.org и dbsrv.example.org.
Так в чем же разница между доменным именем и именем хоста? У меня нет четкого ответа, но можно сказать, что имя хоста может зависеть от доменного имени. Наверно, можно сказать, что FQDN должно быть равно доменному имени. То есть если у вас есть сайт www.example.org, то hostname сервера может быть равен www. И в обратную сторону это правило тоже должно работать. То есть если вы в качестве имени хоста используете не www, а websrv1, то стоит добавить соответсвующую запись в DNS. При этом DNS-сервер может эту запись не распространять за пределы своей подсети, это может быть DNS-сервер для внутренних нужд.

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

Есть в Linux специальная команда hostname, если вызвать её без аргументов, то она выведет текущее имя хоста.
Чтобы изменить имя хоста, передайте новое имя в качестве аргумента:
  1. hostname web-srv-1
Новое имя хоста будет активно сразу после выполнения, но после перезагрузки будет восстановлено имя из файла /etc/hostname. Поэтому нужно изменить ещё и файл hostname. В других статьях пишут, что надо перезапустить сервис hostname, но в моей Ubuntu 14.04 такого сервиса нет. Так что я просто перезагрую операционную систему. Кстати, в Ubuntu есть специальная утилитка, которая меняет и текущее значение hostname и файл /etc/hostname. Называется hostnamectl. Если вызвать её без аргументов, то кроме имени хоста она покажет ещё и версию Ubuntu, версию ядра, архитектуру и тип компьютера. А чтобы установить доменное имя, нужно выполнить команду:
  1. hostnamectl set-hostname web-srv-1
После этого необходимо произвести изменения в файле /etc/hosts. IP-адрес 127.0.1.1 должен соответствовать новому имени хоста.
  1. 127.0.1.1 web-srv-1
И для завершения настройки необходимо перезапустить сеть или перезагрузить операционную систему.

Автоматизированная настройка имени хоста с помощью Fabric

Если вы не знаете, что такое Fabric, то вот документация . Я же просто приведу код функции, с помощью которой я настраиваю имя хоста.
  1. def conf_hostname (hostname , domain = None ):
  2. fqdn = hostname if domain is None else hostname + "." + domain
  4. sudo ("hostname %s " % hostname )
  5. sudo ("echo " %s " > /etc/hostname" % hostname )
  6. fabfiles . sed ("/etc/hosts" , "^(127\.0\.1\.1\s+)[-a-z0-9]+" , " \\ 1 %s %s " % (fqdn , hostname ), use_sudo = True )
  8. sudo ("reboot" )
  9. time . sleep (20 )

A fully qualified domain name (FQDN) is the complete domain name for a specific computer, or host, on the internet. The FQDN consists of two parts: the hostname and the domain name. For example, an FQDN for a hypothetical mail server might be mymail.somecollege.edu . The hostname is mymail , and the host is located within the domain somecollege.edu .

In this example, .edu is the top-level domain (TLD). This is similar to the root directory on a typical workstation, where all other directories (or folders) originate. (Within the .edu TLD, Indiana University Bloomington has been assigned the indiana.edu domain, and has authority to create subdomains within it.)

The same applies to web addresses. For example, www.indiana.edu is the FQDN on the web for IU. In this case, www is the name of the host in the indiana.edu domain.

When connecting to a host (using an SSH client, for example), you must specify the FQDN. The DNS server then resolves the hostname to its IP address by looking at its DNS table. The host is contacted and you receive a login prompt.

If you are using only the hostname (without the domain information) to connect to a server, the application you"re using may not be able to resolve the hostname. This can happen if either the DNS suffix search order in your computer"s TCP/IP properties is incorrect, or the DNS table is corrupted. In these cases, entering the host"s FQDN will allow DNS to locate the server. Also, if you are trying to connect to a remote host that is not local to your internet service provider (ISP), you will probably have to use the FQDN. For example, it"s unlikely that a DNS server at IU would have a listing for remote hosts at another university or an unrelated ISP.

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


Как вы, возможно уже знаете, при первоначальной инсталляции 3CX v15 ваш лицензионный ключ привязывается к FQDN имени, выбранном администратором в мастере первоначальной конфигурации. Поэтому продумайте удобное FQDN имя еще до начала установки!

FQDN имя от компании 3CX

Начиная с 3CX v15, при условии, что у вас активна подписка на обновления , вы можете воспользоваться DNS сервером 3CX. DNS 3CX (фактически, это DNS инфраструктура Google) предоставляет следующие возможности:

  • Поддерживает публичное FQDN имя вашего сервера в одном из принадлежащих 3CX доменов верхнего уровня.
  • Реализует функцию Dynamic DNS, то есть, при смене публичного IP адреса сервера, изменение DNS записи происходит автоматически.

Кроме сервиса DNS, 3CX предоставляет бесплатные доверенные SSL сертификаты безопасности от организации Let’s Encrypt , которые используются для подключений клиентов к серверу, видеоконференции и других важных функций.


Как было сказано, выбранное имя сервера привязывается к лицензионному ключу. Если вы получили бесплатный ключ PBX Edition Key и хотите просто протестировать 3CX, не выбирайте ваше основное имя (например, имя вашей компании), а используйте тестовое. Например, test-company.3cx.ru , а не company.3cx.ru .


C другой стороны, домен верхнего уровня изменить можно. Т.е. вы можете “переехать” с FQDN company.3cx.eu на company.3cx.ru . Имя хоста должно быть уникально в выбранном домене. Поэтому, если имя company.3cx.ru уже занято, вам придется выбирать другое. Имена резервируются по принципу первой заявки, поэтому поспешите с переходом на 3CX v15, чтобы успеть получить красивое имя.


Внимание: 3CX оставляет за собой право отменить регистрацию любого FQDN имени, если оно нарушает патентные права или содержит оскорбительные слова. Также 3CX не может переназначить имя для вас, если оно уже зарегистрировано на другую компанию.

Ваше собственное FQDN имя

Если вы планируете использовать собственное имя сервера, например, хост в вашем корпоративном домене, заранее подготовьте доверенный SSL сертификат для этого имени. Вы укажете его в мастере первоначальной настройки системы. В этом случае 3CX не выдает и не поддерживает для вас сертификат Let’s Encrypt.


Затем ваш лицензионный ключ будет привязан к собственному FQDN имени. Однако, тут есть одна особенность, связанная с работой сервиса 3CX Webmeeting: если ваше FQDN имя имеет вид pbx.company.com , портал Webmeeting автоматически генерирует для вас URL pbxcompany.3cx.*. Убедитесь, что такое имя еще не занято другим пользователем!

Изменение FQDN имени

Чтобы изменить FQDN имя сервера, необходимо сперва убедиться, что новое выбранное имя свободно, а затем отвязать старое имя от вашего лицензионного ключа. Это делается через пользовательский портал https://erp.3cx.com .


Для коммерческих и бесплатных лицензий – зайдите в портал с вашими учетными данными и нажмите Release. Ключ будет отвязан от FQDN.



Для NFR лицензий – откройте заявку в техподдержке 3CX https://erp.3cx.com и укажите в ней ваш NFR ключ и текущее FQDN имя сервера.

Заключение

Повторим основные принципы использования FQDN имени в инсталляциях 3CX:

  1. Первоначальная настройка системы привязывает FQDN сервера к лицензионному ключу
  2. Если оказалось, что выбранное имя уже кем-то занято:
    • Появится ошибка Error creating FQDN: FQDN already in use. Please choose another one.
    • Выберите другое свободное FQDN имя
  3. Последующие инсталляции системы (переустановки) с данным лицензионным ключом требуют указания того же FQDN
  4. Если FQDN не соответствует ключу:
    • Появится ошибка Error creating FQDN: License key already bound to another FQDN.
    • Зайдите в портал erp.3cx.com и проверьте, какое FQDN соответствует вашему ключу, либо отвяжите FQDN от ключа, как показано выше.
Январь 5, 2018 12:20 пп 1 025 views | Комментариев нет

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

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

Читайте также :

Основные термины DNS

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

  • DNS, или система доменных имен – это сетевая система, которая позволяет разрешать удобочитаемые доменные имена на уникальные адреса.
  • Доменное имя – это удобочитаемое имя, которое используется для связи с интернет-ресурсом. Например, «google.com» является доменным именем. URL-адрес «google.com» связан с серверами, принадлежащими Google Inc. Система доменных имен позволяет получить доступ к серверам Google при вводе «google.com» в браузер.
  • IP-адрес – это сетевой адрес. Каждый IP-адрес должен быть уникальным в своей сети. Когда речь идет о веб-сайтах, под сетью подразумевается весь интернет.
  • IPv4, наиболее распространенная форма адресов, записывается в виде четырех наборов чисел, каждый из которых имеет до трех цифр, и каждый набор разделяется точкой. Например, «111.222.111.222» может быть IP-адресом IPv4. DNS сопоставляет домен с адресом, чтобы пользователям не приходилось запоминать сложный набор цифр для каждого сайта.
  • Домен верхнего уровня (или TLD) является самым высоким уровнем после корневого домена. Домен верхнего уровня находится после точки. Популярными доменами верхнего уровня являются com, net, org, gov, edu и io. Домены верхнего уровня находятся в верхней части иерархии с точки зрения доменных имен. Некоторым сторонам ICANN (Internet Corporation for Assigned Names and Numbers) предоставляет корпоративный контроль над доменами верхнего уровня. Затем эти стороны могут распространять доменные имена под TLD, как правило, через регистраторы доменов.
  • Хосты ссылаются на отдельные компьютеры или сервисы, доступные через определенный домен. Например, большинство владельцев доменов делают свои веб-серверы доступными через голый домен (example.com), а также через определение хостов (www.example.com). В общем домене можно иметь и другие определения хостов. Получить доступ к API можно через хост api (api.example.com), а доступ к ftp – через хост ftp или files (ftp.example.com или files.example.com). Имена хостов могут быть произвольными, поскольку они уникальны для домена.
  • Поддомены (субдомены) – это домены, которые являются частью домена более высокого уровня. DNS работает как иерархия. TLD могут иметь много поддоменов. Например, в домене «com» есть поддомен «google.com» и «ubuntu.com». Поддомен – это по сути любой домен, который является частью домена высшего уровня. В этом случае «ubuntu.com» можно назвать субдоменом «com». Обычно часть «ubuntu» называется SLD, или доменом второго уровня. Каждый домен может управлять своими поддоменами. Например, у школы может быть субдомен для отдела истории www.history.school.edu (где history является субдоменом).
  • Разница между именем хоста и субдоменом заключается в том, что хост определяет компьютер или ресурс, а субдомен расширяет родительский домен — это метод разбиения самого домена.
  • Работая с субдоменами и хостами, вы можете заметить, что слева в домене располагаются уточняющие части, а справа – общие. Так работает DNS: читая слева направо, вы двигаетесь от узких к общим компонентам домена.
  • FQDN (fully qualified domain name, или полное доменное имя) – это имя, которое также является абсолютным доменным именем. Домены в системе DNS могут сопоставляться относительно друг друга и быть несколько неоднозначными. Полное доменное имя является абсолютным именем, определяющим его местоположение по отношению к абсолютному корню системы доменных имен. Это означает, что FQDN определяет каждый родительский домен, включая TLD. Правильный FQDN заканчивается точкой, указывающей корень иерархии DNS. Примером FQDN является «mail.google.com.». Иногда программное обеспечение, требующее полного доменного имени, не учитывает конечную точку, но по стандартам ICANN она необходима.
  • Сервер имен – это компьютер, предназначенный для перевода доменных имен в IP-адреса. Эти серверы выполняют большую часть работы в системе DNS. Поскольку общее количество переводов домена слишком велико для одного сервера, каждый сервер может перенаправить запрос на другие серверы имен или передать ответственность за поднабор поддоменов. Серверы имен могут быть авторитетными; такие серверы обслуживают запросы о доменах, находящихся под их контролем. Также серверы имен могут указывать на другие серверы или обслуживать кешированные копии данных других серверов имен.
  • Файл зоны – это простой текстовый файл, который содержит сопоставления между именами доменов и IP-адресами. Таким образом система DNS узнает, с каким IP-адресом следует связаться, когда пользователь запрашивает определенное доменное имя. Файлы зон хранятся на серверах имен и обычно определяют ресурсы, доступные по определенному домену, или место, где можно получить эту информацию. Записи хранятся в файлах зон. В своей простейшей форме запись – это одно сопоставление между ресурсом и именем. Они могут сопоставлять доменное имя с IP-адресом, определять серверы имен или почтовые серверы для доменов и т. д.

Как работает DNS?

Теперь, когда вы знаете основные термины, можно посмотреть, как работает система DNS.

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

Корневые серверы DNS

Ранее уже говорилось, что DNS по своей сути является иерархической системой. В верхней части этой системы находятся так называемые «корневые серверы». Эти серверы контролируются различными организациями и передают полномочия ICANN.

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

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

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

К примеру, если запрос на www.wikipedia.org отправлен на корневой сервер, корневой сервер не найдет результат в своих записях. Он проверит свои файлы зон и попробует найти запись, которая соответствует «www.wikipedia.org». Но не не найдет ее. Вместо этого он найдет запись для «org» и предоставит запрашивающей организации адрес сервера имен, ответственного за адреса «org».

TLD-серверы

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

Например, он отправил бы запрос серверу имен, ответственному за домены «org», чтобы узнать, где находится www.wikipedia.org.

Новый сервер также будет искать www.wikipdia.org в своих файлах зон. Он не найдет эту запись в своих файлах, однако он найдет запись с IP-адресом сервера имен, ответственным за «wikipedia.org».

Серверы имен доменов

На этом этапе инициатор запроса имеет IP-адрес сервера имен, который отвечает за IP-адрес ресурса. Он отправляет новый запрос серверу имен, снова спрашивая, может ли он разрешить www.wikipedia.org.

Сервер имен проверяет свои файлы зон и обнаруживает, что у него есть файл зоны, связанный с «wikipedia.org». Внутри этого файла есть запись для хоста «www». Эта запись сообщает IP-адрес, где находится этот хост. Сервер имен возвращает окончательный ответ инициатору запроса.

Что такое разрешающий сервер имен?

В приведенном выше примере упоминается инициатор запроса. Что это такое?

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

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

Когда вы вводите URL-адрес в адресной строке браузера, компьютер сначала смотрит, может ли он узнать локально, где находится ресурс. Он проверяет файл hosts и несколько других мест. Затем он отправляет запрос на разрешающий сервер имен и ждет ответа, чтобы получить IP-адрес ресурса.

Затем разрешающий сервер имен проверяет свой кэш. Если он не найдет в кэше ответ, он выполнит описанные выше действия.

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

Файлы зон

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

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

Чем больше файлов зон имеет сервер имен, тем больше запросов он сможет авторитетно обслужить.

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

$ORIGIN – это параметр, который определяет максимальный авторитет зоны по умолчанию.

Поэтому, если файл зоны используется для настройки домена «example.com.», параметр $ORIGIN будет иметь значение «example.com.».

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

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

Типы записей

Файлы зон могут содержать записи разных типов. Рассмотрим самые распространенные из них.

SOA-записи

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

Начало SOA-записи выглядит примерно так:

domain.com. IN SOA ns1.domain.com. admin.domain.com. (
12083 ; serial number
3h ; refresh interval
30m ; retry interval
3w ; expiry period
1h ; negative TTL
)

  • domain.com. – это корень зоны. Указывает файл зоны для domain.com.domain. Часто вы будете видеть, что эта часть заменена на @ (это просто заполнитель, который заменяет содержимое переменной $ORIGIN).
  • IN SOA: часть «IN» означает Интернет (и будет присутствовать во многих записях). SOA является индикатором того, что это запись Start of Authority.
  • ns1.domain.com определяет основной сервер имен для этого домена. Серверы имен могут быть как ведущими, так и ведомыми. Если настроен динамический DNS, один сервер должен быть «ведущим мастером». Если вы не настроили динамический DNS, этот параметр просто определит один из основных серверов имен.
  • admin.domain.com – адрес электронной почты администратора этой зоны. Символ «@» в адресе электронной почты заменяется точкой. Если в самом адресе электронной почты есть точка, она заменяется символом «\» (например, [email protected] преобразуется в your\name.domain.com).
  • 12083 – серийный номер файла зоны. Каждый раз, когда вы редактируете файл зоны, вы должны увеличить этот номер. Ведомые серверы будут проверять, увеличился ли серийный номер главного сервера зоны. Если это так, они запросят новый файл зоны, а если нет – продолжат обслуживать исходный файл.
  • 3h – интервал обновления зоны. Это время ожидания ведомого устройства до запроса изменений файла зоны с мастер-сервера
  • 30m – интервал повторного подключения для этой зоны. Если ведомый сервер не может подключиться к ведущему устройству для обновления, он повторить попытку спустя заданное в этом параметре время.
  • 3w – время истечения срока действия. Если подчиненный сервер имен не смог связаться с мастером в течение этого времени, он больше не будет возвращать ответы в качестве авторитетного сервера этой зоны.
  • 1h – количество времени, в течение которого сервер имен будет кэшировать ошибку, если он не может найти запрошенное имя в этом файле.

Записи А и АААА

Обе эти записи сопоставляют хост с IP-адресом. Запись A используется для сопоставления хоста с IP-адресом IPv4, а запись AAAA используется для сопоставления хоста с IPv6-адресом.

Общий формат этих записей таков:

host IN A IPv4_address
host IN AAAA IPv6_address

Так как SOA-запись определила ns1.domain.com как основной сервер, его нужно сопоставить с IP-адресом, поскольку ns1.domain.com находится в зоне domain.com.

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

ns1 IN A 111.222.111.222

Обратите внимание: тут не нужно указывать полное имя. Вы можете просто предоставить хост, без FQDN, а DNS-сервер заполнит остальные поля значением $ORIGIN. Но при желании вы можете так же легко использовать FQDN:

ns1.domain.com. IN A 111.222.111.222

В большинстве случаев здесь определяется веб-сервер как www:

www IN A 222.222.222.222

Также нужн указать, куда разрешается базовый домен. Сделать это можно так:

domain.com. IN A 222.222.222.222

@ IN A 222.222.222.222

Специальный символ * позволяет разрешить все, связанное с этим доменом, что не определено явно на этом сервере.

* IN A 222.222.222.222

Аналогичным образом создаются и записи AAAA для адресов IPv6.

CNAME-записи

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

Например, если запись A определяет хост server1, вы можете использовать «www» в качестве псевдонима для этого хоста:

server1 IN A 111.111.111.111
www IN CNAME server1

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

MX-записи

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

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

IN MX 10 mail.domain.com.

Обратите внимание, в начале нет имени хоста.

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

Запись MX обычно указывает на хост, определенный записью A или AAAA, а не на хост CNAME.

Итак, допустим, у вас есть два почтовых сервера. Для этого нужны примерно такие записи:

IN MX 10 mail1.domain.com.
IN MX 50 mail2.domain.com.
mail1 IN A 111.111.111.111
mail2 IN A 222.222.222.222

В данной настройке хост mail1 имеет более высокий приоритет.

Эти записи можно создать так:

IN MX 10 mail1
IN MX 50 mail2
mail1 IN A 111.111.111.111
mail2 IN A 222.222.222.222

NS-записи

Этот тип записи определяет серверы имен, которые используются для этой зоны.

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

Как и записи MX, эти параметры распространяются на всю зону, поэтому они также не принимают хосты. В целом эти записи выглядят так:

IN NS ns1.domain.com.
IN NS ns2.domain.com.

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

Включите сопоставление хостов с записями A или AAAA:

IN NS ns1.domain.com.
IN NS ns2.domain.com.
ns1 IN A 111.222.111.111
ns2 IN A 123.211.111.233

PTR-записи

Записи PTR используются для определения имени, связанного с IP-адресом. Записи PTR являются инверсией записи A или AAAA. PTR уникальны тем, что они начинаются с корня.arpa и передаются владельцам IP-адресов. Региональные интернет-регистраторы (RIR) управляют передачей IP-адресов. Региональные интернет-регистраторы – это APNIC, ARIN, RIPE NCC, LACNIC и AFRINIC.

Вот пример записи PTR для 111.222.333.444:

444.333.222.111.in-addr.arpa. 33692 IN PTR host.example.com.

Этот пример записи PTR для IPv6-адреса показывает полубайтовый формат обратного DNS-сервера Google IPv6 2001:4860:4860::8888.

8.8.8.8.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.6.8.4.0.6.8.4.1.0.0.2.ip6.arpa. 86400IN PTR google-public-dns-a.google.com.

Инструмент командной строки dig с флагом -x можно использовать для поиска обратного DNS-имени IP-адреса.

Вот пример команды dig.

dig -x 8.8.4.4 +short

Эта команда вернет домен в записи PTR:

google-public-dns-b.google.com.

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

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