зачем нужна обратная зона dns

Зачем нужна обратная зона dns

Добрый день, уважаемые читатели и постоянные подписчики, IT блога Pyatilistnik.org. В прошлый раз мы разобрали, что такое DNS-сервер, его принципы работы, основные записи и много другое. Кто пропустил заметку, советую ознакомиться. В сегодняшней публикации я хочу рассмотреть вопрос, о обратных зонах и их применении.

Обратный запрос DNS — особая доменная зона, предназначенная для определения имени узла по его IPv4-адресу c помощью PTR-записи. Адрес узла AAA.BBB.CCC.DDD переводится в обратной нотации и превращается в DDD.CCC.BBB.AAA.in-addr.arpa. Благодаря иерархической модели управления именами появляется возможность делегировать управление зоной владельцу диапазона IP-адресов. Для этого в записях авторитетного DNS-сервера указывают, что за зону CCC.BBB.AAA.in-addr.arpa (то есть за сеть AAA.BBB.CCC.000/24) отвечает отдельный сервер.

PTR-запись (от англ. pointer – указатель) связывает IP хоста с его каноническим именем. Запрос в домене in-addr.arpa на IP хоста в обратной форме вернёт имя данного хоста. Например, (на момент написания), для IP адреса 192.0.34.164: запрос записи PTR 164.34.0.192.in-addr.arpa вернет его каноническое имя referrals.icann.org.in-addr.arpa

in-addr.arpa — специальная доменная зона, предназначенная для определения имени хоста по его IPv4-адресу, используя PTR-запись. Адрес хоста AAA.BBB.CCC.DDD транслируется в обратной нотации и превращается в DDD.CCC.BBB.AAA.in-addr.arpa. Благодаря иерархической модели управления именами появляется возможность делегировать управление зоной владельцу диапазона IP адресов. Для этого в записях авторитативного DNS-сервера указывают, что за зону CCC.BBB.AAA.in-addr.arpa (то есть за сеть AAA.BBB.CCC/24) отвечает отдельный сервер.

Использование

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

Источник

Пространства имен DNS

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

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

Зоны прямого просмотра

Зоны прямого просмотра (forward lookup zone), как не трудно догадаться по их названию, создаются для выполнения прямого просмотра в базе данных DNS. Другими словами, зоны этого типа предусматривают реализацию преобразования имен в IP-адреса и предоставле­ние информации о ресурсах. Например, если пользователь пожелает обратиться к серверу del.company.com и запросит его IP-адрес в зоне прямого просмотра, DNS возвратит ему значение 172.16.1.11, т.е. IP-адрес данного ресурса.

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

Зоны обратного просмотра

Зоны обратного просмотра (reverse lookup zone) выполняют прямо противоположную операцию той, что выполняют зоны прямого просмотра. Они предусматривают сопостав­ление IP-адресов с обычным именем. Эта похоже на поиск телефонного номера, когда сам номер известен, а имя того, кому он принадлежит, нет. Зоны обратного просмотра обычно создаются вручную и вовсе необязательно присутствуют в каждой реализации. За счет при­менения мастера настройки сервера DNS (Configure a DNS Server), как описывалось ранее в главе, процесс создания такой зоны может быть автоматизирован. Как правило, зоны обратного просмотра заполняются записями PTR, которые служат для указания запросу обратного просмотра на соответствующее имя.

Источник

Зачем нужна обратная зона dns

Основные сведения о DNS

Служба DNS (Domain Name System) предназначена для преобразования имен хостов в IP-адреса. Для ее функционирования используется два компонента: DNS-клиент и DNS-сервер. В Windows 2000 первый является частью стека протоколов TCP/IP и устанавливается на любой компьютер, сконфигурированный для использования этого протокола.

Правила именования доменов

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

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

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

Типы зон
Все DNS-зоны можно разделить на зоны прямого и обратного просмотра. Кроме того, каждая из них может быть:

Зона прямого просмотра
Зоны прямого просмотра (forward lookup zone) служат для преобразования доменных имен в IP-адреса. Для работы службы DNS-сервера на Windows 2000 необходимо наличие на нем как минимум одной такой зоны.

Зона обратного просмотра
Зоны обратного просмотра (reverse lookup zone) позволяют генерировать обратные запросы на поиск имени по IP-адресу. Эти зоны необязательны для функционирования системы DNS, но нужны для нормальной работы различных диагностических утилит (например, ping, tracert и т. п.). Зоны обратного просмотра регистрируются в домене in-addr.arpa. Поддоменам присваиваются имена, соответствующие IP-адресам сетей, причем порядок октетов в адресе изменяется на противоположный. То есть сети 192.168.0.0 соответствует домен 0.168.192.in-addr.arpa.

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

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

Динамическое обновление зоны

Функция динамического обновления позволяет клиентам вносить изменения в зоны путем посылки определенных запросов DNS-серверу. В Windows 2000 динамическое обновление зон необходимо для нормальной работы Active Directory и автоматической регистрации DHCP-хостов в DNS. Динамические обновления должны поддерживаться обслуживающим зону сервером. Согласно стандарту RFC 2136, возможно изменение зоны не только вручную администратором сервера, но и автоматически приложениями, поддерживающими этот стандарт. DNS-сервер из состава Windows 2000 поддерживает Dynamic DNS (DDNS).

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

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

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

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

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

Любая DNS-запись имеет следующий вид:
владелец [класс] [TTL] тип данные Описание полей DNS-записи приведено в таблице.

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

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

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

Синтаксис записи NS

@ 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)

Синтаксис записи A

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

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

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

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

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

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

Придерживаясь этой практики, вы позволите обращаться к хосту и по старому, и по новому имени, а когда надобность в старом имени отпадет, достаточно удалить запись 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 в домене, имя которого получается отсечением от почтового адреса имени пользователя и символа @. Например, при отправке почты на адрес user1@fio.ru, поиск записи MX будет проводиться в домене fio.ru. Записи почтовых хостов указывают серверы, которые занимаются обработкой входящей почты для соответствующего домена. При наличии нескольких записей MX почтовый сервер пытается сначала использовать запись с наименьшим приоритетом.

Синтаксис записи MX

@ IN MX 10 mailserver1
@ IN MX 20 mailserver2

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

Синтаксис записи SRV

Источник

Давайте уже разберемся в DNS

Внимательный читатель найдет на этой картинке IPv6

Люди часто озадачены доменами. Почему мой сайт не работает? Почему эта хрень поломана, ничего не помогает, я просто хочу, чтобы это работало! Обычно, вопрошающий или не знает про DNS, или не понимает фундаментальных идей. Для многих DNS — страшная и непонятная штука. Эта статья — попытка развеять такой страх. DNS — это просто, если понять несколько базовых концепций.

Что такое DNS

DNS расшифровывается как Domain Name System. Это глобальное распределенное хранилище ключей и значений. Сервера по всему миру могут предоставить вам значение по ключу, а если им неизвестен ключ, то они попросят помощи у другого сервера.

Базовые штуки

Давайте взглянем на маппинг между именем и адресом:

Здесь есть только одна интересная деталь: информация о самом запросе. Говорится, что мы запросили запись и получили ровно один ответ. Вот:

Оставшаяся часть ответа описывает сам ответ:

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

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

Другие типы

Что не так с CNAME

Запросы к другим серверам

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

Типичные ситуации

Давайте рассмотрим типичные ситуации, знакомые многим веб-разработчикам.

Редирект домена на www

Этот IP принадлежит Namecheap’у, и там крутится маленький веб-сервер, который просто делает перенаправление на уровне HTTP на адрес http://www.iskettlemanstillopen.com :

CNAME для Heroku или Github

Wildcards

Заключение

Надеюсь, теперь у вас есть базовое понимание DNS. Все стандарты описаны в документах:

Есть еще пара интересных RFC, в том числе 4034, который описывает стандарт DNSSEC и 5321, который описывает взаимосвязь DNS и email. Их интересно почитать для общего развития.

Источник

Зачем нужна обратная зона 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-адресов. Разделителем в иерархии именования доменов является символ «.», следовательно, границы байтов в адресе будут соответствовать границам вложенности доменов.

$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 это будет выглядеть примерно так:

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

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

options <
directory «/etc/namedb»;
allow-query ;
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, рассмотренный выше.

Источник