Зона прямого и обратного просмотра dns – 4.2 Служба dns (домены, зоны; зоны прямого и обратного просмотра; основные и дополнительные зоны; рекурсивный и итеративный запросы на разрешение имен).

alexxlab

Содержание

«Прямая» и «обратная» зоны для домена, определенного на двух адресных пулах типа х.х.х.х/24 или организация обратных зон на «суперсетях» класса C

В данном материале мы рассмотрим конфигурацию программы named при организации сервера домена, чьи хосты распределены по двум физическим IP-сетям класса C (в нотации CIDR x.x.x.x/24). Основное внимание будет уделено «обратным» зонам, т.к. «прямая» зона в этом случае не имеет существенных отличий от зоны, рассмотренной при описании небольшого корпоративного домена.

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

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

192.168.0.0/24 и 192.168.10.0/24

С точки зрения описания соответствия между доменным именем и IP-адресом в «прямой» зоне здесь проблем нет:

$ORIGIN ru.
test IN SOA ns.test.ru. hostmaster.test.ru (
233 3600 300 9999999 3600 )
;
IN NS ns.test.ru.
IN NS ns.privider.ru.
IN A 192.168.10.1
IN MX 10 mail.test.ru.
IN MX 20 mail.provider.ru.
;
ns IN A 192.168.10.1
mail IN A 192.168.0.1
www IN A 192.168.10.2
ftp IN A 192.168.0.2

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

Конечно, есть адреса, которые нельзя мешать. Например, нельзя мешать маршрутизируемые и немаршрутизируемые адреса. Собственно, в примере мы используем именно последние (подробнее о немаршрутизируемых адресах см. RFC 1918).

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

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

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

Выход простой — создать две обратных зоны 0.168.192.in-addr.arpa и 10.168.192.in-addr.arpa. Выглядеть это будет примерно так:

$TTL 3600
$ORIGIN 168.192.in-addr.arpa.
10 IN SOA ns.test.ru. hostmaster.test.ru. (
75 3600 300 9999999 3600 )
IN NS ns.test.ru.
IN NS ns.privider.ru.
1 IN PTR ns.test.ru.
2 IN PTR www.test.ru.

И для 0.168.192.in-addr.arpa. соответственно:

$TTL 3600
$ORIGIN 168.192.in-addr.arpa.
0 IN SOA ns.test.ru. hostmaster.test.ru. (
75 3600 300 9999999 3600 )
IN NS ns.test.ru.
IN NS ns.privider.ru.
1 IN PTR ns.test.ru.
2 IN PTR www.test.ru.

На master сервере должно быть объявлено две «обратных» зоны. В BIND 4.x в файле named.boot это будет выглядеть примерно так:

directory /etc/namedb
primary test.ru test.ru
primary localhost localhost
primary 127.in-addr.arpa localhost.rev
primary 10.168.192.in-addr.arpa 10.168.192.in-addr.arpa
primary 0.168.192.in-addr.arpa 0.168.192.in-addr.arpa
xfrnets 192.168.20.1&255.255.255.255
cаche . named.root

options no-recursion no-fetch-glue fake-iquery

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

Здесь стоит только пояснить, что в данном случае адрес 192.168.20.1 — это адрес slave сервера, которому разрешено копировать зону. Назначение остальных директив управления подробно рассмотрено в «Небольшой корпоративный домен в домене ru. Описание «прямых» зон. Описание «обратных» зон. Настройки BIND.».

Что же касается файла named.conf версий BIND 8.х и 9.х, то его содержание будет выглядеть примерно так:

options {
directory «/etc/namedb»;
allow-query {any;};
recursion no;
fake-iquery yes;
fetch-glue no;
use-id-pool yes;
};
//Root server hints
zone «.» { type hint; file «named.root»; };
// Forward Loopback
zone «localhost» {
type master;
file «localhost»;

};
// Reverse Loopback
zone «0.0.127.in-addr.arpa» {
type master;
file «localhosr.rev»;
};
// Corporative domain
zone «test.ru» {
type master;
file «test.ru»;
allow-transfer { 192.168.20.1; };
};
// Reverse corporative domain
zone «0.168.192.in-addr.arpa» {
type master;
file «0.168.192.in-addr.arpa»;
allow-transfer { 192.168.20.1; };
};
// Reverse corporative domain
zone «10.168.192.in-addr.arpa» {
type master;
file «10.168.192.in-addr.arpa»;
allow-transfer { 192.168.20.1; };
};

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

Здесь следует отметить, что несколько обратных зон появляются, например, и для сетей типа x.x.x.x/23. Вся штука в том, что, адресный пул, например, 192.168.0.0.23, объединяет два смежных блока 192.168.0.0/24 и 192.168.1.0/24. Соответствующих обратных зон, следовательно, будет две: 0.168.192.in-addr.arpa и 1.168.192.in-addr.arpa. Объединить их стандартным образом можно только на уровне 168.192.in-addr.arpa, но никак не ниже.

Из выше сказанного, следует, что владелец зоны 168.192.in-addr.arpa должен делегировать ответственность за управления двумя обратными зонами своему клиенту, если не хочет управлять ими самостоятельно.

Аналогичные замечания справедливы и для адресных пулов x.x.x.x/16 и для адресных пулов x.x.x.x.8, т.е. сетей классов B и A соответственно. Пространство доменных имен «обратных» зон построено с учетом старой классификации адресов, в то время, когда нотация CIDR широко еще не использовалась.

В документе RFC 1519 подробно разбирается отображение адресного пространства CIDR на «суперсети» сетей класса C, т.е. пулов адресов, которые составлены из подсетей сетей класса B и A. Провайдер в этом случае должен делегировать соответствующие обратные зоны клиентам, а те обеспечить их поддержку способом, похожим на случай 192.168.0.0/23, рассмотренный выше.


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

  1. Альбитц П., Ли К.. DNS и BIND. — Пер. с англ. — СПб: Символ-Плюс, 2002. — 696 с.
  2. P. Mockapetris. RFC-1034. DOMAIN NAMES — CONCEPTS AND FACILITIES. ISI, 1987. (http://www.ietf.org/rfc/rfc1034.txt?number=1034)
  3. P. Mockapetris. RFC-1035. DOMAIN NAMES — IMPLEMENTATION AND SPECIFICATION. ISI, 1987. (http://www.ietf.org/rfc/rfc1035.txt?number=1035)
  4. BIND 9 Administrator Reference Manual. (http://www.nominum.com/resources/documentation/Bv9ARM.pdf)
  5. BIND Configuration File Guide (8.3.4) (ftp://ftp.isc.org/isc/bind/src/8.3.4/bind-doc.tar.gz)
  6. Y. Rekhter, B. Moskowitz, D. Karrenberg, G. J. de Groot. RFC 1918. Address Allocation for Private Internets. 1996. (http://www.ietf.org/rfc/rfc1918.txt?number=1918)
  7. Y. Rekhter, T. Li. RFC 1518. An Architecture for IP Address Allocation with CIDR. 1993. (http://www.ietf.org/rfc/rfc1518.txt?number=1518)
  8. V. Fuller, T. Li, J. Yu, K. Varadhan. RFC 1519. Classless Inter-Domain Routing (CIDR): an Address Assignment and Aggregation Strategy. 1993. (http://www.ietf.org/rfc/rfc1519.txt?number=1519)


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

  1. http://www.isc.org/products/BIND/bind8.html — страничка BIND 8.
  2. http://www.isc.org/products/BIND/bind4.html — страничка BIND 4.9.11
  3. http://www.acmebw.com/resources/papers/securing.pdf — Securing an Internet Name Server. CERT Coordination Center. Carnegie Mellon University. 2002. Довольно подробный и обстоятельный обзор возможных проблем безопасности серверов доменных имен с рекомендациями по их (серверов) конфигурации.

info.nic.ru

Общие сведения о обратных DNS в Azure — Azure DNS

  • Время чтения: 4 мин

В этой статье

Из этой статьи вы узнаете, как работает обратная зона DNS и как ее можно использовать в Azure.This article gives an overview of how reverse DNS works, and the reverse DNS scenarios supported in Azure.

Обратные записи DNSWhat is reverse DNS?

Обычные записи DNS позволяют сопоставить DNS-имя (например, www.contoso.com) с IP-адресом (например, 64.4.6.100).Conventional DNS records enable a mapping from a DNS name (such as ‘www.contoso.com’) to an IP address (such as 64.4.6.100). Обратная же зона DNS преобразовывает IP-адрес (64.4.6.100) в имя (www.contoso.com).Reverse DNS enables the translation of an IP address (64.4.6.100) back to a name (‘www.contoso.com’).

Записи обратной зоны DNS используются в разных ситуациях.Reverse DNS records are used in a variety of situations. Например, обратные записи DNS широко используются для борьбы с нежелательными электронными сообщениями путем проверки отправителя сообщения.For example, reverse DNS records are widely used in combating e-mail spam by verifying the sender of an e-mail message. Принимающий почтовый сервер извлекает запись обратной зоны DNS из IP-адреса отправляющего сервера и определяет, авторизован ли этот узел для отправки электронной почты из исходного домена.The receiving mail server retrieves the reverse DNS record of the sending server’s IP address, and verifies if that host is authorized to send e-mail from the originating domain.

Принцип работы обратных записей DNSHow reverse DNS works

Записи обратной зоны DNS размещены в специальных зонах DNS, известных как зоны ARPA.Reverse DNS records are hosted in special DNS zones, known as ‘ARPA’ zones. Параллельно с обычной иерархией, в которой размещены домены, такие как contoso.com, эти зоны образуют отдельную иерархию DNS.These zones form a separate DNS hierarchy in parallel with the normal hierarchy hosting domains such as ‘contoso.com’.

Например, DNS-запись www.contoso.com получена на основе DNS-записи А с именем www в зоне contoso.com.For example, the DNS record ‘www.contoso.com’ is implemented using a DNS ‘A’ record with the name ‘www’ in the zone ‘contoso.com’. Эта запись А указывает на соответствующий IP-адрес. В этом случае — 64.4.6.100.This A record points to the corresponding IP address, in this case 64.4.6.100. Обратный поиск реализуется отдельно с помощью записи PTR с именем «100» в зоне «6.4.64.in-addr. arpa» (Обратите внимание, что IP-адреса отменяются в зонах ARPA). Эта запись типа PTR, если она была настроена правильно, указывает на имя «www.contoso.com».The reverse lookup is implemented separately, using a ‘PTR’ record named ‘100’ in the zone ‘6.4.64.in-addr.arpa’ (note that IP addresses are reversed in ARPA zones.) This PTR record, if it has been configured correctly, points to the name ‘www.contoso.com’.

При назначении организации блока IP-адресов она получает права на управление соответствующей зоной ARPA.When an organization is assigned an IP address block, they also acquire the right to manage the corresponding ARPA zone. Корпорация Майкрософт размещает зоны ARPA, соответствующие блокам IP-адресов, используемым Azure, а также управляет ими.The ARPA zones corresponding to the IP address blocks used by Azure are hosted and managed by Microsoft. Поставщик услуг Интернета может разместить зону ARPA для ваших блоков IP-адресов или разрешить вам разместить зону ARPA в любой службе DNS, например DNS Azure.Your ISP may host the ARPA zone for your own IP addresses for you, or may allow you to host the ARPA zone in a DNS service of your choice, such as Azure DNS.

Примечание

Прямые и обратные запросы DNS реализуются в отдельной параллельной иерархии DNS.Forward DNS lookups and reverse DNS lookups are implemented in separate, parallel DNS hierarchies. Обратный запрос для www.contoso.com размещен не в зоне contoso.com, а в зоне ARPA для соответствующего блока IP-адресов.The reverse lookup for ‘www.contoso.com’ is not hosted in the zone ‘contoso.com’, rather it is hosted in the ARPA zone for the corresponding IP address block. Для блоков адресов IPv4 и IPv6 используются отдельные зоны.Separate zones are used for IPv4 and IPv6 address blocks.

IPv4IPv4

Имя зоны обратного просмотра IPv4 должно быть представлено в формате <IPv4 network prefix in reverse order>.in-addr.arpa.The name of an IPv4 reverse lookup zone should be in the following format: <IPv4 network prefix in reverse order>.in-addr.arpa.

Предположим, вы создаете обратную зону для записей узлов с IP-адресами в префиксе 192.0.2.0/24. Чтобы создать имя зоны, вам нужно отделить сетевой префикс адреса (192.0.2), записать его в обратном порядке (2.0.192) и добавить суффикс .in-addr.arpa.For example, when creating a reverse zone to host records for hosts with IPs that are in the 192.0.2.0/24 prefix, the zone name would be created by isolating the network prefix of the address (192.0.2) and then reversing the order (2.0.192) and adding the suffix .in-addr.arpa.

Класс подсетиSubnet classСетевой префиксNetwork prefixОбратный сетевой префиксReversed network prefixСтандартный суффиксStandard suffixИмя обратной зоныReverse zone name
Класс AClass A203.0.0.0/8203.0.0.0/8203203.in-addr.arpa.in-addr.arpa203.in-addr.arpa
Класс BClass B198.51.0.0/16198.51.0.0/1651.19851.198.in-addr.arpa.in-addr.arpa51.198.in-addr.arpa
Класс CClass C192.0.2.0/24192.0.2.0/242.0.1922.0.192.in-addr.arpa.in-addr.arpa2.0.192.in-addr.arpa

Бесклассовое делегирование IPv4Classless IPv4 delegation

Иногда диапазон IP-адресов, выделенных для организации, меньше, чем диапазон класса C (/24).In some cases, the IP range allocated to an organization is smaller than a Class C (/24) range. В таком случае диапазон IP-адресов не попадает в границы зоны в иерархии зоны .in-addr.arpa и не может быть делегирован как дочерняя зона.In this case, the IP range does not fall on a zone boundary within the .in-addr.arpa zone hierarchy, and hence cannot be delegated as a child zone.

Вместо этого используется другой механизм для передачи управления отдельными записями обратного просмотра (записи типа PTR) выделенной зоне DNS.Instead, a different mechanism is used to transfer control of individual reverse lookup (PTR) records to a dedicated DNS zone. Этот механизм делегирует дочернюю зону для каждого диапазона IP-адресов, а затем отдельно сопоставляет каждый IP-адрес в диапазоне с этой дочерней зоной при помощи записей CNAME.This mechanism delegates a child zone for each IP range, then maps each IP address in the range individually to that child zone using CNAME records.

Предположим, поставщик услуг Интернета предоставил организации диапазон IP-адресов 192.0.2.128/26.For example, suppose an organization is granted the IP range 192.0.2.128/26 by its ISP. В этот диапазон входят 64 IP-адреса — с 192.0.2.128 по 192.0.2.191.This represents 64 IP addresses, from 192.0.2.128 to 192.0.2.191. Обратная зона DNS для этого диапазона реализуются следующим образом:Reverse DNS for this range is implemented as follows:

  • Организация создает зону обратного просмотра с именем 128-26.2.0.192.in-addr.arpa.The organization creates a reverse lookup zone called 128-26.2.0.192.in-addr.arpa. Префикс «128-26» представляет сегмент сети, присвоенный организации в диапазоне класса C (/24).The prefix ‘128-26’ represents the network segment assigned to the organization within the Class C (/24) range.
  • Поставщик услуг Интернета создает записи NS, чтобы настроить делегирование DNS для указанной выше зоны из родительской зоны класса C.The ISP creates NS records to set up the DNS delegation for the above zone from the Class C parent zone. Кроме того, в родительской зоне обратного просмотра (класс C) создаются записи CNAME с сопоставлением каждого IP-адреса в диапазоне с новой зоной, созданной в организации.It also creates CNAME records in the parent (Class C) reverse lookup zone, mapping each IP address in the IP range to the new zone created by the organization:
$ORIGIN 2.0.192.in-addr.arpa
; Delegate child zone
128-26    NS       <name server 1 for 128-26.2.0.192.in-addr.arpa>
128-26    NS       <name server 2 for 128-26.2.0.192.in-addr.arpa>
; CNAME records for each IP address
129       CNAME    129.128-26.2.0.192.in-addr.arpa
130       CNAME    130.128-26.2.0.192.in-addr.arpa
131       CNAME    131.128-26.2.0.192.in-addr.arpa
; etc
  • После этого организация управляет отдельными записями типа PTR в дочерней зоне.The organization then manages the individual PTR records within their child zone.
$ORIGIN 128-26.2.0.192.in-addr.arpa
; PTR records for each UIP address. Names match CNAME targets in parent zone
129      PTR    www.contoso.com
130      PTR    mail.contoso.com
131      PTR    partners.contoso.com
; etc

При обратном просмотре IP-адреса «192.0.2.129» отправляется запрос на запись типа PTR с именем «129.2.0.192.in-addr.arpa».A reverse lookup for the IP address ‘192.0.2.129’ queries for a PTR record named ‘129.2.0.192.in-addr.arpa’. Этот запрос поступает через CNAME в родительской зоне в запись типа PTR в дочерней зоне.This query resolves via the CNAME in the parent zone to the PTR record in the child zone.

IPv6IPv6

Имя зоны обратного просмотра IPv6 должно быть представлено в формате <IPv6 network prefix in reverse order>.ip6.arpaThe name of an IPv6 reverse lookup zone should be in the following form: <IPv6 network prefix in reverse order>.ip6.arpa

Предположим,For example,. вы создаете обратную зону для записей узлов с IP-адресами в префиксе 2001:db8:1000:abdc::/64. Чтобы создать имя зоны, вам нужно отделить сетевой префикс адреса (2001:db8:abdc::).When creating a reverse zone to host records for hosts with IPs that are in the 2001:db8:1000:abdc::/64 prefix, the zone name would be created by isolating the network prefix of the address (2001:db8:abdc::). Далее нужно развернуть сетевой префикс IPv6, удалив сжатие за счет нулей (если оно использовалось для сокращения префикса адреса IPv6 (2001:0db8:abdc:0000::)).Next expand the IPv6 network prefix to remove zero compression, if it was used to shorten the IPv6 address prefix (2001:0db8:abdc:0000::). Запишите префикс в обратном порядке, используя точку как разделитель между каждым шестнадцатеричным числом, чтобы сформировать обратный сетевой префикс (0.0.0.0.c.d.b.a.8.b.d.0.1.0.0.2), и добавьте суффикс .ip6.arpa.Reverse the order, using a period as the delimiter between each hexadecimal number in the prefix, to build the reversed network prefix (0.0.0.0.c.d.b.a.8.b.d.0.1.0.0.2) and add the suffix .ip6.arpa.

Сетевой префиксNetwork prefixРазвернутый обратный сетевой префиксExpanded and reversed network prefixСтандартный суффиксStandard suffixИмя обратной зоныReverse zone name
2001:db8:abdc::/642001:db8:abdc::/640.0.0.0.c.d.b.a.8.b.d.0.1.0.0.20.0.0.0.c.d.b.a.8.b.d.0.1.0.0.2.ip6.arpa.ip6.arpa0.0.0.0.c.d.b.a.8.b.d.0.1.0.0.2.ip6.arpa
2001:db8:1000:9102::/642001:db8:1000:9102::/642.0.1.9.0.0.0.1.8.b.d.0.1.0.0.22.0.1.9.0.0.0.1.8.b.d.0.1.0.0.2.ip6.arpa.ip6.arpa2.0.1.9.0.0.0.1.8.b.d.0.1.0.0.2.ip6.arpa

Поддержка обратных записей DNS в AzureAzure support for reverse DNS

Azure поддерживает два отдельных сценария, касающихся обратных записей DNS:Azure supports two separate scenarios relating to reverse DNS:

Размещение зоны обратного просмотра, соответствующей блоку ваших IP-адресов.Hosting the reverse lookup zone corresponding to your IP address block. Службу Azure DNS можно использовать для размещения зоны обратного просмотра и управления записями типа PTR для каждой операции обратного просмотра DNS как для IPv4, так и для IPv6.Azure DNS can be used to host your reverse lookup zones and manage the PTR records for each reverse DNS lookup, for both IPv4 and IPv6. Процедура создания зоны обратного просмотра (ARPA), настройки делегирования и конфигурирования записей типа PTR будет такой же, как и для обычных зон DNS.The process of creating the reverse lookup (ARPA) zone, setting up the delegation, and configuring PTR records is the same as for regular DNS zones. Отличие заключается лишь в том, что делегирование настраивается с помощью поставщика услуг Интернета, а не регистратора DNS, при этом должен использоваться только один тип записей PTR.The only differences are that the delegation must be configured via your ISP rather than your DNS registrar, and only the PTR record type should be used.

Настройка записи обратной зоны DNS для IP-адреса, присвоенного вашей службе Azure.Configure the reverse DNS record for the IP address assigned to your Azure service. Azure позволяет настроить обратный просмотр для IP-адресов, выделенных вашей службе Azure.Azure enables you to configure the reverse lookup for the IP addresses allocated to your Azure service. Служба Azure настраивает эту обратную запись DNS как запись типа PTR в соответствующей зоне ARPA.This reverse lookup is configured by Azure as a PTR record in the corresponding ARPA zone. Эти зоны ARPA, соответствующие всем используемым в Azure диапазонам IP-адресов, размещаются корпорацией Майкрософт.These ARPA zones, corresponding to all the IP ranges used by Azure, are hosted by Microsoft

Дополнительная информацияNext steps

Дополнительные сведения см. в статье Википедии об обратном просмотре DNS.For more information on reverse DNS, see reverse DNS lookup on Wikipedia.
Узнайте, как разместить зону обратного просмотра для диапазона IP-адресов, присвоенного поставщиком услуг Интернета, в службе Azure DNS.Learn how to host the reverse lookup zone for your ISP-assigned IP range in Azure DNS.
Узнайте, как управлять записями обратной зоны DNS для служб Azure.Learn how to manage reverse DNS records for your Azure services.

docs.microsoft.com

Прямая и обратная зона dns. Создание и настройка зон DNS

В данном материале мы рассмотрим конфигурацию программы named при организации сервера домена, чьи хосты распределены по двум физическим IP-сетям класса C (в нотации CIDR x.x.x.x/24). Основное внимание будет уделено «обратным» зонам, т.к. «прямая» зона в этом случае не имеет существенных отличий от зоны, рассмотренной при описании небольшого корпоративного домена.

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

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

192.168.0.0/24 и 192.168.10.0/24

С точки зрения описания соответствия между доменным именем и IP-адресом в «прямой» зоне здесь проблем нет:

$ORIGIN ru.
test IN SOA ns.test.ru. hostmaster.test.ru (
233 3600 300 9999999 3600)
;
IN NS ns.test.ru.
IN NS ns.privider.ru.
IN A 192.168.10.1
IN MX 10 mail.test.ru.
IN MX 20 mail.provider.ru.
;
ns IN A 192.168.10.1
mail IN A 192.168.0.1
www IN A 192.168.10.2
ftp IN A 192.168.0.2

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

Конечно, есть адреса, которые нельзя мешать. Например, нельзя мешать маршрутизируемые и немаршрутизируемые адреса. Собственно, в примере мы используем именно последние (подробнее о немаршрутизируемых адресах см. RFC 1918).

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

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

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

Выход простой — создать две обратных зоны 0.168.192.in-addr.arpa и 10.168.192.in-addr.arpa. Выглядеть это будет примерно так:

$TTL 3600

10 IN SOA ns.test.ru. hostmaster.test.ru. (
75 3600 300 9999999 3600)
IN NS ns.test.ru.
IN NS ns.privider.ru.
1 IN PTR ns.test.ru.
2 IN PTR www.test.ru.

И для 0.168.192.in-addr.arpa. соответственно:

$TTL 3600
$ORIGIN 168.192.in-addr.arpa.
0 IN SOA ns.test.ru. hostmaster.test.ru. (
75 3600 300 9999999 3600)
IN NS ns.test.ru.
IN NS ns.privider.ru.
1 IN PTR ns.test.ru.
2 IN PTR www.test.ru.

На master сервере должно быть объявлено две «обратных» зоны. В BIND 4.x в файле named.boot это будет выглядеть примерно так:

directory /etc/namedb
primary test.ru test.ru
primary localhost localhost
primary 127.in-addr.arpa localhost.rev
primary 10.168.192.in-addr.arpa 10.168.192.in-addr.arpa
primary 0.168.192.in-addr.arpa 0.168.192.in-addr.arpa
xfrnets 192.168.20.1&255.255.255.255
cаche . named.root
options no-recursion no-fetch-glue fake-iquery

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

Здесь стоит только пояснить, что в данном случае адрес 192.168.20.1 — это адрес slave сервера, которому разрешено копировать зону. Назначение остальных директив управления подробно рассмотрено в «Небольшой корпоративный домен в домене ru. Описание «прямых» зон. Описание «обратных» зон. Настройки BIND.».

Что же касается файла named.conf версий BIND 8.х и 9.х, то его содержание будет выглядеть примерно так:

options {
directory «/etc/namedb»;
allow-query {any;};
recursion no;
fake-iquery yes;
fetch-glue no;
use-id-pool yes;
};
//Root server hints
zone «.» { type hint; file «named.root»; };
// Forward Loopback
zone «localhost» {
type master;
file «localhost»;
};
// Reverse Loopback
zone «0.0.127.in-addr.arpa» {
type master;
file «localhosr.rev»;
};
// Corporative domain
zone «test.ru» {
type master;
file «test.ru»;

};

zone «0.168.192.in-addr.arpa» {
type master;
file «0.168.192.in-addr.arpa»;
allow-transfer { 192.168.20.1; };
};
// Reverse corporative domain
zone «10.168.192.in-addr.arpa» {
type master;
file «10.168.192.in-addr.arpa»;
allow-transfer { 192.168.20.1; };
};

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

Здесь следует отметить, что несколько обратных зон появляются, например, и для сетей типа x.x.x.x/23. Вся штука в том, что, адресный пул, например, 192.168.0.0.23, объединяет два смежных блока 192.168.0.0/24 и 192.168.1.0/24. Соответствующих обратных зон, следовательно, будет две: 0.168.192.in-addr.arpa и 1.168.192.in-addr.arpa. Объединить их стандартным образом можно только на уровне 168.192.in-addr.arpa, но никак не ниже.

Из выше сказанного, следует, что владелец зоны 168.192.in-addr.arpa должен делегировать ответственность за управления двумя обратными зонами своему клиенту, если не хочет управлять ими самостоятельно.

Аналогичные замечания справедливы и для адресных пулов x.x.x.x/16 и для адресных пулов x.x.x.x.8, т.е. сетей классов B и A соответственно. Пространство доменных имен «обратных» зон построено с учетом старой классификации адресов, в то время, когда нотация CIDR широко еще не использовалась.

В документе RFC 1519 подробно разбирается отображение адресного пространства CIDR на «суперсети» сетей класса C, т.е. пулов адресов, которые составлены из подсетей сетей класса B и A. Провайдер в этом случае должен делегиро

offlink.ru

Доменные имена в обратной зоне DNS (reverse DNS) в работе почтового сервера

Система доменных имён — основа современного интернета. Люди не желают затруднять себя запоминанием набора цифр 63.245.217.105, а хотят чтобы по имени mozilla.org компьютер соединил их с указанным узлом. Этим и занимаются DNS-серверы: переводят запросы людей в понятный им цифровой формат. Однако в некоторых случаях может потребоваться обратное (reverse) преобразование IP-адрес → DNS-имя. О таких именах и пойдёт речь ниже.

Обратные доменные имена (reverse DNS) и их место в работе почтового сервера

Для чего нужно?

Наличие корректно настроенного rDNS адреса совершенно необходимо, чтобы отправлять сообщения с вашего собственного сервера корпоративной почты. Практически все почтовые серверы отвергнут приём сообщения ещё на стадии начала сессии, если у IP-адреса вашего сервера отсутствует запись в обратной зоне DNS. Причина отказа удалённым почтовым сервером будет, скорее всего, указана такой:
550-«IP address has no PTR (address to name) record in the DNS, or when the PTR record does not have a matching A (name to address) record. Pls check and correct your DNS record.»

или
550-There’s no corresponding PTR for your IP address (IP-address), which is 550 required. Sorry, bye.

или просто
550 Your IP has no PTR Record

Число 550 во всех трёх случаях является стандартным кодом почтового SMTP сервера, сообщающего о критической ошибке, которая непреодолимо препятствует дальнейшей работе в рамках данной почтовой сессии. Надо сказать, что вообще все ошибки серии 500 являются критическими и продолжение передачи почты после их появления невозможно. Текст же поясняет причину отказа более подробно и сообщает, что администратор почтового сервера-получателя настроил его на проверку наличия у почтового сервера-отправителя записи в обратной зоне DNS (rDNS) и в случае её отсутствия сервер-получатель обязан отказывать отправителю в соединении (SMTP-ошибки серии 5XX).

Как настроить и использовать?

Правами на настройку обратной зоны DNS (reverse DNS) обладает лишь владелец соответствующего блока IP-адресов, которой эта зона соответствует. Как правило этим владельцем оказывается провайдер, владеющий собственной автономной системой. Подробнее о регистрации своей автономной системы (AS) и блока IP-адресов можно прочитать в этой статье. Если кратко, то оператору блока IP-адресов для регистрации обратной зоны DNS необходимо зарегистрировать в своём личном кабинете на сайте RIPE объект типа «domain», указать адрес DNS-серверов, которые будут поддерживать зону rDNS и настроить поддержку зоны вида 3.2.1.in-addr.arpa на них. За ресурсы в обратной зоне отвечает указатель (pointer) — запись типа PTR. К ней-то и идут запросы о разрешении IP-адреса в имя хоста.

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

Примеры хороших имён для сервера почты:

mail.domain.ru
mta.domain.ru
mx.domain.ru

Примеры плохих имён:

host-192-168-0-1.domain.ru
customer192-168-0-1.domain.ru
vpn-dailup-xdsl-clients.domain.ru

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

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

  • так для почтового сервера Postfix необходимо включить опцию
    reject_unknown_client
  • в другом популярном почтовом сервере Exim
    verify = reverse_host_lookup
  • MS Exchange Server
    В оснастке Exgange Server перейти в раздел Servers далее выбрать сервер в развернутом списке, выбрать Protocols, далее протокол SMTP, в правом окне выделить SMTP сервер и по клику правой клавишей мыши выбрать из списка Properties. Далее закладка Delivery → Perform reverse DNS lookup on incoming messages

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

    www.tendence.ru

    Просмотр записей ресурсов DNS для зоны DNS

    • Время чтения: 2 мин

    В этой статье

    Относится к: Windows Server (Semi-Annual Channel), Windows Server 2016Applies to: Windows Server (Semi-Annual Channel), Windows Server 2016

    Этот раздел можно использовать для просмотра записей ресурсов DNS для зоны DNS в консоли клиента IPAM.You can use this topic to view DNS resource records for a DNS zone in the IPAM client console.

    Для выполнения этой процедуры необходимо быть членом группы Администраторы или пользователем с аналогичными правами.Membership in Administrators, or equivalent, is the minimum required to perform this procedure.

    Просмотр записей ресурсов DNS для зоныTo view DNS resource records for a zone

    1. В диспетчер сервера щелкните IPAM.In Server Manager, click IPAM. Откроется консоль клиента IPAM.The IPAM client console appears.

    2. В области навигации в окне мониторинг и управлениещелкните зоны DNS.In the navigation pane, in MONITOR AND MANAGE, click DNS Zones. Панель навигации разделяется на верхнюю панель навигации и нижнюю панель навигации.The navigation pane divides into an upper navigation pane and a lower navigation pane.

    3. В нижней области навигации щелкните прямой поиск, а затем разверните список домены и зона, чтобы найти и выбрать зону, которую нужно просмотреть.In the lower navigation pane, click Forward Lookup, and then expand the domain and zone list to locate and select the zone you want to view. Например, если имеется зона с именем Dublin, щелкните элемент Dublin.For example, if you have a zone named dublin, click dublin.

    4. В области отображения представлением по умолчанию являются DNS-серверы для зоны.In the display pane, the default view is of the DNS servers for the zone. Чтобы изменить представление, щелкните Текущее представление, а затем — записи ресурсов.To change the view, click Current view, and then click Resource Records.

    5. Отобразятся записи ресурсов DNS для зоны.The DNS resource records for the zone are displayed. Чтобы отфильтровать записи, введите текст, который нужно найти в поле Фильтр.To filter the records, type the text you want to find in Filter.

    6. Чтобы отфильтровать записи ресурсов по типу записи, области доступа или другим критериям, нажмите кнопку Добавить условие, а затем выберите в списке критерий и нажмите кнопку Добавить.To filter the resource records by record type, access scope, or other criteria, click Add criteria, and then make selections from the criteria list and click Add.

    См. такжеSee Also

    Управление зоной DNSDNS Zone Management
    Управление IPAMManage IPAM

    docs.microsoft.com

    Файлы и записи зон DNS

    Файл зоны

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

    ;
    ; Database file test.fio.ru.dns for test.fio.ru zone.
    ; Zone version: 1;
    @ IN SOA mcio-08kwa653t4.fio.ru. admin.fio.ru. (
    1 ; serial number
    900 ; refresh
    600 ; retry
    86400 ; expire
    3600 ) ; minimum TTL;
    ; Zone NS records
    ;
    @ NS mcio-08kwa653t4.fio.ru.
    ;
    ; Zone records
    ;

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

    Любой файл зоны должен содержать как минимум следующее:

    • одну запись Start Of Authority (SOA), содержащую параметры зоны;
    • не менее одной записи Name Server (NS), содержащей адреса DNS-серверов, ответственных за хранение и обслуживание зоны;
    • не менее одной записи Host (A), содержащей информацию о соответствии имени DNS-сервера, указанного в каждой записи NS, его IP-адресу.

    Записи зон

    При создании и изменении зоны вы чаще всего будете использовать следующие типы записей:

    Тип записиНазначение записи
    Start Of Authority (SOA)Описывает зону и ее параметры. В файле зоны встречается однократно и не требует редактирования вручную
    Name Server (NS)Описывает один DNS-сервер
    Host (A)Описывает соответствие имени хоста его IP-адресу. Используется часто
    Canonical Name (CNAME)Описывает альтернативное имя для уже существующего хоста
    Mail Exchanger (MX)Описывает почтовый хост, обрабатывающий электронную почту домена
    Pointer (PTR)Описывает соответствие IP-адреса имени хоста. Используется в зонах обратного просмотра
    Service Location (SRV)Описывает сервисы, предоставляемые хостами

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

    Внимание!

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

    Общий синтаксис записей зон

    Любая DNS-запись имеет следующий вид:

    владелец [класс] [TTL] тип данные

    Описание полей DNS-записи приведено в таблице.

    Поле Описание
    владелецОтносительное или полное имя записи. Если значение этого поля совпадает с именем зоны, то вы можете использовать символ @ вместо полного имени зоны
    классОпределяет класс, к которому принадлежит запись. Например, IN указывает, что запись принадлежит к классу записей Интернет-ресурсов. Это единственный класс записей, поддерживаемых DNS-сервером, входящим в состав Windows 2000. В связи с этим в любой записи поле класса может быть опущено, хотя стандарт DNS требует обязательного указания класса записи
    TTLОпределяет время жизни конкретной записи в кэше других DNS-серверов. Является необязательным для большинства типов записей. Если поле TTL у записи опущено, то берется соответствующее значение из параметров зоны (запись SOA). Для того, чтобы предотвратить кэширование записи указывайте значение 0 в качестве TTL
    типОбязательное поле, содержащее один из стандартных текстовых идентификаторов, определяющих тип записи
    данныеОбязательное поле, содержащее данные переменной длины. Формат данных определяется типом записи

    Поля записи разделяются любым количеством пробелов или символов табуляции.

    Служебные записи (SOA и NS)

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

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

    Синтаксис записи NS
    Название Name Server
    Определена в RFC 1035
    Описание Запись, указывающая один из серверов, обслуживающих зону. В виде NS-записей указываются все сервера (основной и дополнительные). Тот сервер, который указан в SOA-записи, считается основным, все остальные — дополнительными.
    Синтаксис владелец [класс] [TTL] NS хост
    Параметры Полное DNS-имя сервера, который должен быть определен в DNS. Допускается определение серверов в той же зоне, которую они обслуживают.
    Пример @ NS mcio-08kwa653t4.fio.ru @ NS host1.test.fio.ru
    Синтаксис SOA-записи
    Название Start Of Authority
    Определена в RFC 1035
    Описание Запись, описывающая зону ответственности.
    Синтаксис владелец класс SOA первичный_сервер ответственный (редакция обновление повтор устаревание TTL)
    Параметры Первичный сервер — полное имя сервера, содержащего основную копию зоны.Ответственный — почтовый адрес лица, ответственного за управление зоной. Символ @ в почтовом адресе заменяется на точку.Редакция — число, указывающее порядковый номер редакции зоны. При внесении любых изменений вручную необходимо увеличивать это число, т. к. дополнительные DNS-серверы определяют необходимость копирования зоны именно по этому параметру. При изменении зоны через Консоль управления это число увеличивается автоматически.Обновление — интервал в секундах, в течение которого дополнительные DNS-серверы ожидают, прежде чем отправить запрос об изменении зоны. По истечении этого интервала дополнительный DNS-сервер запрашивает запись SOA с основного, проверяет в ней поле Редакция и определяет необходимость загрузки файла зоны. По умолчанию — 900 секунд (15 минут).Повтор — интервал в секундах, в течение которого дополнительные DNS-серверы ожидают, прежде чем произвести повторную попытку обновления зоны с основного сервера в случае неудачи предыдущей попытки. По умолчанию — 600 секунд (10 минут).Устаревание — интервал в секундах, по истечении которого информация зоны считается устаревшей. Этот параметр используется дополнительными серверами, которые перестают отвечать на запросы после того, как пройдет указанное количество времени с момента последнего успешного обновления. По умолчанию — 86 400 секунд (24 часа).TTL — минимальное время жизни записей зоны, для которых не указано индивидуальное значение. Используется для указания другим DNS-серверам и DNS-клиентам, в течение какого периода времени они могут кэшировать записи зоны. По умолчанию — 3 600 секунд (1 час).
    Пример @ IN SOA mcio-08kwa653t4.fio.ru. admin.fio.ru. ( 1 900 600 86400 3600)
    Пример служебных записей зоны:

    ; Database file test.fio.ru.dns for test.fio.ru zone.
    ; Zone version: 2541744385
    ;
    @ IN SOA ns1.test.fio.ru. admin.fio.ru. (
    2541744385 ; serial number
    10800 ; refresh
    3600 ; retry
    604800 ; expire
    86400 ) ; minimum TTL
    ;
    ; Zone NS records
    ;
    @ NS ns1.test.fio.ru.
    @ NS ns2.test.fio.ru.
    @ NS ns2.fio.ru.
    ;
    ; Zone records
    ;
    ns1 A 195.34.17.1
    ns2 A 213.128.193.119

    Записи хостов (A и PTR)

    Для установления соответствия между именем хоста и его IP-адресом используется запись A, для обратного соответствия — запись PTR. Для одного и того же IP-адреса допустимо использование нескольких имен хостов, однако для одного IP-адреса рекомендуется использовать только одну запись PTR. Записи A используются в зонах прямого просмотра, PTR — в зонах обратного просмотра.

    Синтаксис записи A
    Название Host Address
    Определена в RFC 1035
    Описание Запись, устанавливающая соответствие имени определенному IP-адресу.
    Синтаксис владелец [класс] [TTL] A IP_адрес
    Параметры IP-адрес хоста.
    Пример host1 IN A 192.168.0.1
    Синтаксис AAAA-записи
    Название IPv6 Host Address
    Определена в RFC 1886
    Описание Запись, устанавливающая соответствие имени определенному IP-адресу версии 6.
    Синтаксис владелец [класс] [TTL] AААА IP_адрес_v6
    Параметры IP-адрес версии 6 хоста.
    Пример host2 IN AAAA 4321:0:1:2:3:4:567:89ab
    Синтаксис PTR-записи
    Название Pointer
    Определена в RFC 1035
    Описание Запись, устанавливающая соответствие IP-адреса доменному имени. Используется в зонах обратного просмотра
    Синтаксис владелец [класс] [TTL] PTR имя
    Параметры Полное DNS-имя хоста, соответствующего указанному IP-адресу.
    Пример 1.0.168.192.in-addr.arpa PTR host1.test.fio.ru

    Записи A и PTR могут быть добавлены в зону следующим образом:

    • можно вручную создать необходимые записи (A и PTR) для компьютеров со статическими IP-адресами;
    • компьютеры, работающие под управлением Windows 2000 и использующие динамические IP-адреса, самостоятельно добавляют или изменяют необходимые записи (A и PTR) в зоне;
    • для компьютеров, работающих под управлением более ранних версий Windows и использующих динамические IP-адреса, добавление или изменение необходимых записей (A и PTR) осуществляется DHCP-сервером из состава Windows 2000 Server.

    Примечание

    Записи A и PTR не требуются для всех компьютеров. Они необходимы только для компьютеров, предоставляющих свои ресурсы в совместное использование. Тем не менее при использовании домена Active Directory Windows 2000 создает запись A для каждого компьютера в домене.

    Записи альтернативных имен (CNAME)

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

    Синтаксис CNAME-записи
    Название Canonical Name
    Определена в RFC 1035
    Описание Указывает, что владелец записи является альтернативным именем, для DNS-имени, указываемого как параметр.
    Синтаксис владелец [класс] [TTL] CNAME имя
    Параметры Полное или относительное DNS-имя хоста.
    Пример alias CNAME host1.test.fio.ru alias2 CNAME host2

    Альтернативные имена используются для:

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

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

    • cоздайте запись A с новым именем, указывающую на IP-адрес хоста;
    • cоздайте запись CNAME со старым именем, указывающую на новое имя хоста;
    • удалить запись A хоста со старым именем.

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

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

    Рассмотрим это на примере.

    Изначально в сети существовал хост, предоставляющий Web- и FTP-сервисы. Соответствующие записи зоны имели следующий вид:

    host-a IN A 10.0.0.20

    www IN CNAME host-a

    ftp IN CNAME host-a

    Со временем было принято решение переместить FTP-сервер на отдельный хост. За счет использования записей CNAME это было сделано прозрачно для пользователей:

    host-a IN A 10.0.0.20

    host-b IN A 10.0.0.21

    www IN CNAME host-a

    ftp IN CNAME host-b

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

    host-a IN A 10.0.0.20

    host-b IN A 10.0.0.21

    host-c IN A 10.0.0.22

    www IN CNAME host-a

    www IN CNAME host-c

    ftp IN CNAME host-b

    Внимание!

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

    Записи почтовых хостов (MX)

    Записи почтовых хостов домена используются почтовыми серверами и программами для определения хоста, на который должна быть отправлена почта. При этом почтовый сервер пытается найти запись MX в домене, имя которого получается отсечением от почтового адреса имени пользователя и символа @. Например, при отправке почты на адрес [email protected], поиск записи MX будет проводиться в домене fio.ru. Записи почтовых хостов указывают серверы, которые занимаются обработкой входящей почты для соответствующего домена. При наличии нескольких записей MX почтовый сервер пытается сначала использовать запись с наименьшим приоритетом.

    Синтаксис записи MX
    Название Mail eXchanger
    Определена в RFC 1035
    Описание Запись, указывающая на сервер, осуществляющий обработку и доставку входящей почты.
    Синтаксис владелец [класс] [TTL] MX приоритет хост
    Параметры Приоритет — число от 0 до 65535, определяющее приоритет сервера при наличии в зоне нескольких MX записей с одним именем. Обработка начинается с сервера с наименьшим приоритетом.Хост — полное или относительное имя хоста почтового сервера, который должен быть определен в DNS.
    Пример test.fio.ru MX 10 host1.test.fio.ru @ MX 20 host1.test.fio.ru

    Рассмотрим пример:

    @ IN MX 10 mailserver1

    @ IN MX 20 mailserver2

    Здесь будет сначала использован сервер mailserver1, а при невозможности отправить почту через него — mailserver2. Если и второй сервер будет недоступен, автору сообщения будет отправлено уведомление о невозможности доставки почты.

    Записи сервисов (SRV)

    Записи сервисов — это новая возможность, не так давно используемая в DNS. Однако в Windows 2000 они используются очень активно, в основном для обеспечения работы Active Directory. Вся информация о доменах AD, контроллерах доменов, серверах глобального каталога и прочих сервисах, необходимых для ее функционирования, хранится в DNS в виде записей SRV.

    Синтаксис записи SRV
    Название Service locator
    Определена в RFC 2052
    Описание Запись, определяющая сервера, предоставляющие определенные сервисы.
    Синтаксис сервис.протокол.имя [класс] [TTL] SRV приоритет вес порт хост
    Параметры Сервис — символьное имя сервиса. Имена для стандартных сервисов (_telnet, _smtp и т. п.) определены в RFC 1700.Протокол — символьное имя протокола. Обычно используются _tcp и _udp, хотя может быть использован любой протокол, определенный в RFC 1700 .Имя — доменное имя, которое будет использовано для поиска информации о сервисах.Приоритет — число от 0 до 65535, определяющее приоритет сервера, указываемого в поле хост , при использовании нескольких записей SRV с одинаковым именем.Вес — число от 1 до 65535, которое в дополнение к приоритету используется для балансировки нагрузки между несколькими серверами. Значение этого поля учитывается при использовании нескольких записей SRV с одинаковыми приоритетами. Если балансировка нагрузки не используется, в качестве веса указывается 0.Порт — число от 0 до 65535, определяющее номер порта сервера, через который предоставляется указанный сервис. Соответствие портов стандартным сервисам определено в RFC 1700 , хотя можно использовать другие невостребованные номера портов.Хост — полное или относительное имя хоста сервера, который предоставляет указанный сервис. Хост должен быть определен в DNS. Вместо имени хоста может быть указана точка, значит указанный сервис не предоставляется в соответствующем домене
    Пример _ldap._tcp.ms-dcs SRV 0 0 389 host1.test.fio.ru_ldap._tcp.ms-dcs SRV 10 0 389 host1.test.fio.ru

    Так как все необходимые записи SRV создаются системой автоматически, вряд ли вам понадобится добавлять или настраивать их вручную. Для работы Active Directory используются динамически обновляемые зоны, все обновления в которые система вносит самостоятельно. Если ваша зона обслуживается сервером, не поддерживающим DDNS (допустим, старые версии DNS-серверов для платформы UNIX), можно добавить все необходимые записи SRV в зону из файла %systemroot%system32Confignetlogon.dns. Он обновляется каждый раз при внесении изменений в конфигурацию AD.

    www.oslogic.ru

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

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