ISP`s IT Аутсорсинг
Быстрый переход: Главная блога Главная сайта Форум
Если Вы чего то недопоняли или не нашли - задайте
вопрос на нашем форуме и мы попробуем Вам помочь.
Subnets.ru Регистрация IP и Автономных систем mega-net.ru

Метки статьи: ‘DNS’

Добро пожаловать в блог! Надеемся, что Вы еще вернетесь.

От админа:
В продолжение статьи «Теория и настройка DNS сервера (bind) на FreeBSD» один из наших блогеров (vasily86) написал следующую статью, которую и представляю вам с некоторыми моими дополнениями.

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

Примеры:

  • .ru
  • .com
  • .edu

Полный список доменов первого уровня я видел здесь.

Чтобы зарегистрировать там свой домен второго уровня нужно заплатить небольшую денежку (например регистратору www.nic.ru) и вам, при условии незанятости, предоставят его, к примеру yandex.ru.

Домены первых уровней принадлежат организации ICANN, которая и следит за ними.
Наша цель — создать домен первого уровня в нашей локальной сети и заодно настроить DNS сервер.
Итак приступаем! Создадим корневую зону «.vrn«.

В системах UNIX самым популярным DNS сервером является named (bind).

За его функционирование отвечает файл named.conf, который расположен в папке /var/named/etc/namedb (или символическая ссылка /etc/namedb).

options {
         directory       "/etc/namedb";
         pid-file        "/var/run/named/pid";
         dump-file       "/var/dump/named_dump.db";
         statistics-file "/var/stats/named.stats";
         forwarders {
                    195.98.64.65;
                    195.98.64.66;
                    };
         listen-on  {
                    192.168.0.101;
                    127.0.0.1;
                    };
};

zone "." {
         type hint;
         file "named.root";
};

zone "vrn" {
         type master;
         file "vrn.zone";
};

zone "0.168.192.in-addr.arpa" {
         type master;
         file "vrn-reverse.zone";
};

В разделе options основные настроики программы,  здесь нужно изменить ip напротив forwarders вписываем DNS провайдера и listen-on — сюда ip, которые необходимо слушать.

От админа:

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

Далее описываем файлы зон:

Самая главная зона — это зона точка (.) ,  данный файл уже создан и менять его нет необходимости.

А вот следующую зону мы создаём для локальной сети, здесь она называется vrn и описана она в файле vrn.zone ниже:

$TTL 86400
vrn.    IN      SOA     ns1.vrn. n2.vrn. (
                        2009121101
                        86400
                        7200
                        8640000
                        86400 )
        IN      NS      ns1.vrn.

ns1     IN      A       192.168.0.101
ns2     IN      A       192.168.0.101

server  IN      A       192.168.0.101
kil     IN      A       192.168.0.100
roma    IN      A       192.168.0.114
nikita  IN      A       192.168.0.109
katya   IN      A       192.168.0.90
pasha   IN      A       192.168.0.10
dima    IN      A       192.168.0.50

Здесь идёт перечисление соответствия имени и ip.

На этом конфигурирование можно закончить, но для того чтобы задать обратное соответствие мы создали ещё одну зону 0.168.192.in-addr.arpa (т.е. ip следует потом вычислять в обратном направлении 192.168.0.      и последнее число прописывается в файле зоны с именем домена)

От админа:

Подробнее можно прочитать в статье: Записи типа «Pointer». Домен IN-ADDR.ARPA. Делегирование «обратных» зон. Инверсные запросы.

$TTL    3600

@       IN      SOA     ns1.vrn. ns2.vrn. (
                        2009121102
                        3600
                        900
                        3600000
                        3600 )
        IN      NS      ns1.vrn.
        IN      NS      ns2.vrn.

10      IN      PTR     pasha.vrn.
50      IN      PTR     dima.vrn.
90      IN      PTR     katya.vrn.
101     IN      PTR     server.vrn.
100     IN      PTR     kil.vrn.
109     IN      PTR     nikita.vrn.
114     IN      PTR     roma.vrn.

Обратите внимание на имена доменов с точкой!!! roma.vrn. иначе ничего не сработает.

Теперь осталось сохраниться. И пробуем запустить named

/etc/rc.d/named onestart

если на консоли не выпали ошибки, значит всё нормально, исправляем файл /etc/resolv.conf

domain vrn
nameserver 192.168.0.101

где 192.168.0.101 — это ip данной машины. И протестируем командами

ping yandex.ru

ping server.vrn

Если пинг прошёл успешно, то добавим наш named в автозагрузку /etc/rc.conf

named_enable=»YES»

и настроем DNS(указав ip данного сервера) у машин, которые находятся в локальной сети. =)

З.Ы. При копировании статьи ссылка на источник ОБЯЗАТЕЛЬНА !

Автор: vasily86

Ничего не понялТак себе...Не плохоДовольно интересноОтлично ! То что нужно ! (голосов: 6, среднее: 4,33 из 5)
Загрузка...
Отправить на почту Отправить на почту

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

В этом материале мы рассмотрим, как решается в DNS задача поиска доменного имени по IP-адресу, что из себя представляет загадочный домен IN-ADDR.ARPA, какие проблемы возникают при делегировании «обратных» зон.

Задача поиска доменного имени по IP-адресу является обратной к прямой задаче — поиску IP-адреса по доменному имени. Прямая задача решается в DNS при помощи записей типа A (Address). Обратная же задача решается при помощи записей-указателей типа PTR (Pointer), которые совместно с записями SOA и NS составляют описание так называемой «обратной» зоны.

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

На самом деле решать «обратную» задачу по «прямой» зоне неудобно. Поиск сведется к полному перебору всех зон, т.к. удобного аппарата рефералов (отсылок по NS записям) для IP-адресов в прямых зонах нет.

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

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

Вот здесь и возникает довольно логичное и простое решение, которое позволяет использовать стандартный механизм поиска доменного имени для решения «обратной» задачи, — специальный домен, структура которого совпадает со структурой IP-адресов. Называется этот домен IN-ADDR.ARPA.

Сначала немного истории. В то время когда затевалась система доменных имен (примерно 1983 год — год выхода RFC 882 и 883) под Internet подразумевалась сеть ARPA, а кроме нее еще обсуждалась возможность построения единого адресного пространства с CSNET. По этой причине кроме класса записей описания ресурсов IN — INTERNET (в то время ARPA) был еще класс описания ресурсов CS — CSNET (Computer Science Network).

В рамках этой концепции в сети ARPA вводился домен для адресов интернет (IN-ADDR — Internet ADDRess). При этом отдельно оговаривалось, что для других сетей алгоритм поиска доменного имени по IP-адресу может отличаться от того, который предложен для адресного пространства сети ARPA.

При этом доменные адреса в ARPA оканчивались словом «ARPA», вот пример из RFC 883:

..              	9999999		IN      NS      B.ISI.ARPA
                	9999999		CS      NS      UDEL.CSNET
B.ISI.ARPA 	9999999		IN      A       10.3.0.52
UDEL.CSNET 	9999999		CS      A       302-555-0000

В нем мы видим, что у записей класса IN доменное имя оканчивается на ARPA, а у всех записей класса CS — на CSNET. Таким образом домен IN-ADDR был доменном верхнего уровня в рамках Internet (ARPA) в то время.

Сейчас уже нет ни CSNET, ни более поздних CH (CHAOS) и HS(Hesiod), которые можно найти в спецификации RFC 1035. Была реорганизована и исчезла ARPA. Но задуманный для адресного пространства ARPA домен IN-ADDR.ARPA остался.

На самом деле, в апреле 2000 года между DARPA (бывшей ARPA) и ICAAN было заключено соглашение о том, что домен верхнего уровня (TLD) ARPA будет использоваться для целей поддержки инфраструктуры Интернет.

Кроме того, само слово «ARPA» следует расшифровывать как «Address and Routing Parameter Area Domain (ARPA)», и не следует его ассоциировать с сетью ARPANET.

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

Делегирование поддоменов в домене ARPA возложено на IAB (Internet Architecture Board). В настоящее время в ARPA выделено три поддомена:

  • in-addr.arpa для отображения IP-адресов IPv4 в пространство доменных имен;
  • ip6.arpa для отображения IP-адресов IPv6 в пространство доменных имен;
  • е164.arpa для отображения телефонных номеров формата Е.164.

Сама зона ARPA поддерживается корневыми серверами и серверами TLD зон, хотя в соответствии с рекомендациями RFC 2870 для ARPA желательно выделение отдельных серверов.

Имена в домене IN-ADDR.ARPA образуют иерархию цифр, которые соответствуют IP-адресам. Правда, записываются эти имена в обратном порядке относительно написания IP-адреса.

Например, машина vega-gw.vega.ru, которая имеет адрес 194.226.43.1 должна быть описана в домене in-addr.arpa как 1.43.226.194.in-addr.arpa, т.е. адрес записывается в обратном порядке.

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

Рис.1. Пример структуры части домена in-addr.arpa

Рис.1. Пример структуры части домена in-addr.arpa

Как видно из рисунка, в данном случае не играет ни какой роли тип сети или разбиение на подсети. Согласно правилам описания доменов и зон в этих доменах, разделителем в имени, который определяет подчиненное значение зоны в домене, является только символ «.».

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

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

1.0.0.10.IN-ADDR.ARPA

Пример определяет первый хост в 10-ой сети.

Поиск этого адреса занял бы поиск сервера, ответственного за 10.IN-ADDR.ARPA, а тот бы ответил именем соответствующим адресу хоста.

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

Теперь, прежде чем обсуждать проблемы поиска доменных имен в IN-ADDR.ARPA, необходимо вернуться к формату описания зон этого домена, которые принято называть «обратными».

Обратная зона состоит, главным образом из записей типа «Pointer» или PTR-записей. Формат записи имеет следующий вид:

[name][ttl] IN PTR [host]

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

$ORIGIN 43.226.194.in-addr.arpa. 1 IN PTR vega-gw.vega.ru.

По всей видимости провайдер выделили организации сетку класса С 194.226.43.0 (В нотации CIDR 194.226.43.0/24). При этом организации было также делегировано право ведения «обратной» зоны 43.226.194.in-addr.arpa. Вот в этой зоне администратор зоны и начал описывать «обратные» соответствия.

Следует признать, что соответствие обратных зон сетям — это общая практика описания «обратных» зон. Здесь точно также надо делегировать зоны из «обратного» домена. А делается это, как правило, на основе разбиения сети на подсети или сети.

В качестве примера для нашей учебной зоны в файле named.boot (BIND 4 или named.conf для BIND 8 — 9) определена «обратная» зона 43.226.194.in-addr.arpa. Ее описание будет выглядеть примерно так:

$TTL 3600
@		IN	SOA 	vega-gw.vega.ru	hostmaster.vega.ru (
				101		; serial number
				86400		; refresh within a day
				3600		; retry every hour
				3888000		; expire after 45 days
				3600 )		; negative caching
		IN	NS	vega-gw.vega.ru.
		IN	NS	ns.relarn.ru.
;
1		IN	PTR	vega-gw.vega.ru.
4		IN	PTR	dos1.vega.ru.
5		IN	PTR	dos2.vega.ru
2		IN	PTR	zone1-gw.zone1.vega.ru.
3		IN	PTR	zone2-gw.zone2.vega.ru.

Из этого примера видно, что для обратной зоны указаны те же записи описания зоны, что и для «прямой». Кроме того, обратную зону вовсе не обязательно разбивать в соответствии с разделением прямой зоны на другие зоны. Речь в данном случае идет о зонах zone1 и zone2. С точки зрения домена in-addr.apra все машины принадлежат одной зоне — 43.226.194.in-addr.arpa.

Другое дело машина с IP-адресом 127.0.0.1 (localhost). С точки зрения домена in-addr.arpa она принадлежит другой ветке иерархии, отличной от той, которой принадлежат все остальные хосты. Поэтому для домена 127.in-addr.arpa на любой машине есть отдельный файл обратной зоны, хотя localhost, которому соответствует этот IP-адрес, обычно описывается в прямой зоне домена вместе с другими хостами. Вот пример описания этой зоны:

;       From: @(#)localhost.rev 5.1 (Berkeley) 6/30/90
; $FreeBSD: src/etc/namedb/PROTO.localhost.rev,v 1.6 2000/01/10
; 15:31:40 peter Exp $
;
; This file is automatically edited by the `make-localhost' script in
; the /etc/namedb directory.
;
$TTL    3600
@       IN      SOA     generate.polyn.kiae.su. root.generate.polyn.kiae.su.  (
                                00000001        ; Serial
                                3600    ; Refresh
                                900     ; Retry
                                3600000 ; Expire
                                3600 )  ; Minimum
        IN      NS      generate.polyn.kiae.su.
1       IN      PTR     localhost.polyn.kiae.su.
>

Как следует из комментария этого файла для его генерации можно использовать специальный sh-скрипт make-localhost, который входит в комплект поставки BIND. Он берет в качестве основы файл прототипа PROTO.localhost.rev подставляет в него имя хоста и имя домена.

Любопытно, что вместо пользователя hostmaster, что рекомендовано в RFC2142, в данном случае указывается пользователь root. Оно и понятно. Пользователя hostmaster может и не быть, ведь не все читают все подряд RFC, а пользователь root есть обязательно. Тем более, что это скорее всего и есть администратор локального сервера доменных имен.

Следует при этом помнить, что в файле конфигурации named.conf должен быть блок, который указывает на эту «обратную» зону:

zone "0.0.127.IN-ADDR.ARPA" {
        type master;
        file "localhost.rev";
};

На самом деле мы опустили один интересный вопрос, а как прямой IP-адрес формата IPv4 преобразуется в доменное имя, которое имеет инверсную запись цифр.

Эти функции возложены на resolver. Resolver преобразует 32-битовый адрес в текстовую строку, размещая октеты в обратном порядке, разделяя их символами «.». К полученному имени resolver через разделитель «.» добавляет суфикс «in-addr.arpa». После этого формирует PTR запрос к системе доменных имен.

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

На самом деле, никто кроме владельца адресного пула не знает, как распределено адресное пространство. Отдать кому-то ведение «обратной» зоны — это значит, во-первых, не обеспечить оперативность управления этой зоной, если только нет средств удаленного управления, как, например, в nic.ru, а, во-вторых, такая услуга стоит денег. По этим причинам обратную зону лучше вести самим.

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

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

Прежде всего, следует знать, что первоначально все адреса, которые мы используем в RuNet, получают RIPE Network Coordination Centre (RIPE — это Reseaux IP Europeens), который является одним из трех региональных интернет регистраторов поддерживающих глобальную инфраструктуру Интернет.

Из предыдущего абзаца важно только то, что все блоки адресов в нотации CIDR xxxx.xxxx.xxxx.xxxx/16 и xxxx.xxxx.xxxx.xxxx/24 выдаются этой организацией локальным интернет регистраторам (Local Internet Registres — LIR). А вот уж они и распределяют эти адреса между своими клиентами.

В обычной классификации сетей Интернет это означает, что RIPE NCC отвечает за делегирование в зоне IN-ADDR.ARPA не только сетей класса B, но и сетей класса C. Сети класса B сейчас почти не выдают, поэтому смело можно остановиться на сетях класса C.

Если Вы не являетесь LIR, а Вам выделена сетка класса C, то направить заявку на делегирование обратной зоны в RIPE NCC Вы напрямую все равно не сможете. Сделать это сможет только провайдер, имеющий статус LIR, который, собственно, эту сетку в RIPE NCC получил. Следовательно, нужно связываться с ним и выяснять все вопросы делегирования обратной зоны. Если Вам выделен пул адресов из сетки класса B, то все вопросы по делегированию обратной зоны нужно также направлять своему провайдеру, т.к. именно ему делегировано право управления обратной зоны этой сети.

Тем не менее следует знать, что для делегирования зоны необходимо три вещи:

  1. получить адресный блок;
  2. обеспечить поддержку зоны /16 или /24 в соответствии с требованиями RIPE NCC;
  3. направить заявку в RIPE NCC на делегирование домена.

Адресный блок получают в соответствии с документом RIPE «IPv4 Address Allocation and Assignment Policies in the RIPE NCC Service Region».

Требования по поддержке зоны заключаются в том, что параметры записи SOA зоны должны соответствовать RFC 1912. при этом серийный номер зоны следует записывать в виде YYYYMMDDnn.

Для зон /24 LIR должен организовать два сервера (один у себя, а другой желательно у другого провайдера, во всяком случае, должно быть обеспечено независимое подключение). Для зон /16 должно быть обеспечено 3 сервера, причем один из них дожен быть сервер RIPE NCC ns.ripe.net. Он должен выполнять функцию slave (secondary) для зоны.

Заявка на делегирование зоны, которая посылается в RIPE NCC роботу регистрации на адрес auto-inaddr@ripe.net, должна выглядеть примерно так:

domain: 65.35.80.in-addr.arpa
descr:     Reverse delegation for Bluelight 2nd /24
admin-c: JJ231-RIPE
tech-c:    JAJA1-RIPE
zone-c: WF2121-RIPE
nserver: ns.bluelight.nl
nserver: ns2.bluelight.nl
mnt-by: BLUELIGHT-MNT
changed: jan@bluelight.nl 19991110
source: RIPE

О назначении полей и правилах их заполнения лучше всего справиться у вашего LIR, либо в nic.ru, либо в RIPE.


Комментарий:
Вы можете изменить данные в БД RIPE и другим методом. Прочтите описание объекта domain, так же в статье описан ещё один метод обновления информации в БД RIPE.


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

Отдельно обратим внимание на то, что для каждой «обратной» зоны, которая соответствует сети класса C (адреса в CIDR xxxx.xxxx.xxxx/24) нужно свое собственное описание зоны. Нельзя в один файл мешать несколько зон данного типа. Мешать их может только в файле, описывающем родительскую зону типа xxxx.xxxx/16, например, в зоне 206.144.in-addr.arpa могут быть записи типа PTR для зон 160.206.144.in-addr.arpa и 192.206.144.in-addr.arpa, и то, только при условии, что данные зоны не делегированы на другой сервер.

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

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

Но на самом деле для небольших компаний гораздо более серьезной проблемой становится делегирование обратных зон для пулов адресов, меньших, чем сеть класса С. Рассмотрим эту проблему более подробно. Все примеры будем брать из RFC 2317, т.к. именно оно рекомендовано RIPE NCC для решения нашей проблемы. Именно этот способ поддерживается в самом RIPE NCC.

Сначала о существе проблемы. Провайдер «нашинковал» в сети класса С (пул адресов в нотации CIDR /24) на несколько частей. Таким образом границы пулов адресов не приходятся на границы октетов.

Пусть мы имеем дело с сетью 192.0.2.0/24. Провайдер разделил адресное пространство следующим образом:

192.0.0/25 - организация А
192.0.128/26 - организация Б
192.0.192/26 - организация С

Классическое описание обратной зоны может выглядеть примерно так:

$ORIGIN 2.0.192.in-addr.arpa.
;
1	PTR	host1.a.ru.
2	PTR	host2.a.ru.
3	PTR	host3.a.ru.
;
129	PTR	host1.b.ru.
130	PTR	host2.b.ru.
131	PTR	host3.b.ru.
;
193	PTR	host1.c.ru.
194	PTR	host2.c.ru.

195	PTR	host3.c.ru.

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

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

$ORIGIN 2.0.192.in-addr.arpa.
@		IN	SOA	ns.provider.ru. hostmaster.provider.ru. (…)
;
; 0-127 /25
;
0/25		IN	NS		ns.a.ru.
0/25		IN	NS		ns.slave.ru.
;
1		IN	CNAME	1.0/25.2.0.192.in-addr.arpa.
2		IN	CNAME	2.0/25.2.0.192.in-addr.arpa.
3		IN	CNAME	3.0/25.2.0.192.in-addr.arpa.
;
; 129-191 /26
;
128/26		IN	NS		ns.b.ru.
128/26		IN	NS		ns.slave.ru.
;
129		IN	CNAME	129.128/26.2.0.192.in-addr.arpa.
130		IN	CNAME	130.128/26.2.0.192.in-addr.arpa.
131		IN	CNAME	131.128/26.2.0.192.in-addr.arpa.
;
; 193-255 /26
;
192/26		IN	NS		ns.c.ru.
192/26		IN	NS		ns.slave.ru.
;
193		IN	CNAME	193.192/26.2.0.192.in-addr.arpa.
194		IN	CNAME	194.192/26.2.0.192.in-addr.arpa.
195		IN	CNAME	195.192/26.2.0.192.in-addr.arpa.

Сами организации при это обязаны зависти зоны следующего содержания:

$ORIGIN 0/25.2.0.192.in-addr.arpa.
@	IN	SOA	ns.a.ru	hostmaster.a.ru (…)
	IN	NS	ns.a.ru.
	IN	NS	ns.slave.ru.
;
1	IN	PTR	host1.a.ru.
2	IN	PTR	host2.a.ru.
3	IN	PTR	host3.a.ru.

Для блока 128/26 соответственно последовательность «0/25» следует заменить на «128/26», а сервер ns.a.ru на сервер ns.b.ru. Для блока 192/26 нужно также будет выполнить соответствующие замены.

Идея данного метода заключается в том, что, попадая в зону 2.0.192.in-addr.arpa, локальный сервер доменных имен или resolver на свой запрос доменного имени получают CNAME, т.е. сервер зоны говорит, что имя, которое ему было сообщено не является каноническим именем хоста, указанным в адресной записи. Это лишь синонимом канонического имени. При этом каноническое имя сообщается в качестве ответа на запрос. Обращаясь по каноническому имени, локальный сервер доменных имен или resolver получают в ответ ссылку на другой сервер, т.к. в нашей зоне указан NS для поддержки зон с каноническими именами. Переходя на новый сервер, локальный сервер доменных имен или resolver получают уже обычную PTR запись ресурсов и могут сообщить доменное имя приложению, которое инициировало запрос к обратной зоне.

Может показаться накладным набивать большое количество CNAME в зонах типа 2.0.192.in-addr.arpa. Но здесь можно воспользоваться директивой управления $GENERATE, которая существенно сократит число набираемых вручную записей описания ресурсов.

Следует также обратить внимание на то, что имена зон в 2.0.192.in-addr.arpa могут быть любыми допустимыми именами, а не только «0/25» или «192/26», как это указано в примере. Более того, имена могут указывать на зоны из совершенно других доменов, не входящих в in-addr.arpa. Правда, зоны должны содержать соответствующие PTR записи описания ресурсов.

Мы в самом начале этого материала упоминали об инверсных запросах, которые не следует путать со стандартными запросами к серверам домена IN-ADDR.ARPA. Какова их судьба?

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

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

И в заключении о том, зачем вообще нужно искать доменные имена по IP_адресам. Этому есть несколько причин.

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

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

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

Любопытно, что на 1999 год по данным RIPE NCC из 163124 зон, которые могли бы быть делегированы (зарегистрированые IP-адреса), реально было делегировано только 85352 или примерно 52%.

И еще одно замечание. Мы здесь вообще не рассматривали «обратное» отображение в рамках такой «экзотики», как адресное пространство IPv6. На самом деле современные версии BIND прекрасно справляются с этой задачей, но об этом как-нибудь в другой раз.

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

Ссылки по теме:

Ничего не понялТак себе...Не плохоДовольно интересноОтлично ! То что нужно ! (голосов: 9, среднее: 5,00 из 5)
Загрузка...
Отправить на почту Отправить на почту

Демон BIND (процесс named) позволяет поднять на FreeBSD свой DNS сервер.

В этой статье приводится настройка DNS сервера и создание зоны для домена.

Теория

DNS (Domain Name System — система доменных имён) — распределённая система (распределённая база данных), способная по запросу, содержащему доменное имя хоста (компьютера или другого сетевого устройства), сообщить IP адрес или (в зависимости от запроса) другую информацию. DNS работает в сетях TCP/IP. Как частный случай, DNS может хранить и обрабатывать и обратные запросы, определения имени хоста по его IP адресу: IP адрес по определённому правилу преобразуется в доменное имя, и посылается запрос на информацию типа «PTR«.

Вы зарегистрировали/купили свой домен в зоне ru (net, com, org, su, и т.д.), что дальше ? Теперь Вам нужен DNS сервер который будет отвечать за зону Вашего домена.

У Вас два варианта:

  1. использовать чужой DNS сервер, например: nic.ru предоставляет услугу поддержки DNS или разместить зону Вашего домена на DNS серверах Вашего провайдера
  2. Поднять собственный DNS сервер (при условии наличия внешнего IP-адреса)

Зона — файл в котором описано соответствие хостов домена и их IP-адресов.

В файле зоны могут быть описаны следущие типы:

  • SOA
  • NS
  • MX
  • A
  • PTR

В SOA входит:

Origin — доменное имя определенной оператором zone в named.conf. Это доменное имя является ключем к сокращениям в файле зоны и является суффиксом по умолчанию для всей информации в файле зоны. Суффикс по умолчанию добавляется ко всем именам в файле зоны, которые не зканчиваются точкой, и поскольку каждый файл описывает отдельную зону, суффиксы по умолчанию в разных файлах различны.
mail addr — Тут записан email адрес ответственного за зону.
SerialСерийный номер версии файла зоны; должен увеличиваться при каждом изменении в зоне — по нему вторичный сервер обнаруживает, что надо обновить информацию (заново скачать копию файла зоны). Обычно пишется в виде <год><месяц><число><номер изменения>.
Refresh — Временной интервал в секундах, через который вторичный сервер будет проверять необходимость обновления информации.
Retry — Временной интервал в секундах, через который вторичный сервер будет повторять обращения при неудаче.
Expire — Временной интервал в секундах, через который вторичный сервер будет считать имеющуюся у него информацию устаревшей.
Minimum — Значение времени жизни информации на кэширующих серверах ((ttl) в последующих записях ресурсов).

Пример SOA:

$TTL    3600
@       IN      SOA     ns.subnets.ru. root.subnets.ru.   (
                                     2008071001; Serial
                                     3600    ; Refresh
                                     900     ; Retry
                                     360000 ; Expire
                                     3600 )  ; Minimum

Где @, в начале SOA, является сокращением, т.к. доменное имя совпадает с суффиксом по умолчанию, без сокращения SOA был бы вида:

subnets.ru.     IN      SOA     ns.subnets.ru. root.subnets.ru.   (

ns.subnets.ru — это имя первичного мастер-сервера DNS зоны subnets.ru

root.subnets.rumail address человека отвечающего за зону (символ «@», в mail адресе, в файле зоны опускается).

Далее идут:

NS — Сервер Имен, описывает DNS-сервера содержащие (отвечающие за) данную зону.
A — Адрес, содержит адрес указанного имени.
CNAME (Canonical Name) — Каноническое имя, указывает псевдоним для официального имени хоста
MX (Mail Exchange) — Почтовый Сервер, такие записи используются для обозначения списка хостов, которые сконфигурированы для приема почты посланной на это доменное имя. Помимо адреса почтового сервера содержат числовое значение обозначающее приоритет, т.е. более низкие числа показывают более высокий приоритет, а приоритеты одинаковые отправители должны использовать в произвольном порядке хосты MX для равномерного распределения нагрузки.
TXT — Текст, содержит текстовые данные любого вида. Применяется редко и специфичным образом.
HINFO — Информация о Хосте, содержит некоторую информацию о машине, обычно — тип процессора и операционной системы, крайне редко используется.
PTR — Pointer — указатель, служит для выполнения обратного преобразования IP-адресов в имена хостов.

Пример зоны прямого просмотра:

$TTL    3600
@       IN      SOA     ns.subnets.ru. root.subnets.ru.   (
                                     2008071001; Serial
                                     3600    ; Refresh
                                     900     ; Retry
                                     360000 ; Expire
                                     3600 )  ; Minimum
                 IN      NS      ns.subnets.ru.
                 IN      NS      ns2.subnets.ru.
                 IN      MX      10 mail

localhost       IN      A       127.0.0.1
subnets.ru.     IN      A       217.172.16.77
                HINFO   "INTEL P4" "FreeBSD"
ns              IN      A       217.172.16.77
ns2             IN      A       217.172.16.1
mail            IN      A       217.172.16.77
www             IN      A       217.172.16.77


Вы можете заметить, что у некоторых записей в конце стоит символ «.» (точка). Точка в конце имени означает, что к этому имени не будет дописываться имя домена указанного в этой зоне.

Например:

Запись ns.subnets.ru (без точки) будет и интерпретироваться DNS сервером как ns.subnets.ru.subnets.ru, но если в конце поставить точку (ns.subnets.ru.), то сервер уже не будет дописывать имя домена subnets.ru в конец имени. Таким образом запись www (в примере выше) «превращается» в www.subnets.ru, т.к. символа точки после www нет.


Важное замечание

Любой файл зоны должен оканчиваться пустой строкой ! Иначе в логах вы будете видеть подобное:

master/zone-name.ru:30: file does not end with newline

И данная зона обслуживаться DNS сервером не будет.


Так же отметим два понятия:

  1. Зоны прямого просмотра
  2. Зоны обратного просмотра

Зона прямого просмотра — когда на основе имени выдается IP-адрес, пример:

Воспользуемся командой: nslookup subnets.ru

Server: XXX.XXX.XXX.XXX
Address: XXX.XXX.XXX.XXX#53

Non-authoritative answer:
Name: subnets.ru
Address: 217.172.16.77

Зона обратного просмотра — когда на основе IP-адреса выдается имя, пример:

Воспользуемся командой: nslookup 217.172.16.77

Server: XXX.XXX.XXX.XXX
Address: XXX.XXX.XXX.XXX#53

Non-authoritative answer:
77.16.172.217.in-addr.arpa name = mega-net.ru.

Обращаю ваше внимание на тот факт, что имя прямого и обратного просмотра могут отличаться.

Пример зоны обратного просмотра (reverse):

$TTL    3600
@       IN      SOA     ns.mydomain.ru. root.domain.ru.   (
                                     2008071001; Serial
                                     3600    ; Refresh
                                     900     ; Retry
                                     360000 ; Expire
                                     3600 )  ; Minimum
                 IN      NS      ns.mydomain.ru.
                 IN      NS      ns2.mydomain.ru.

77              IN      PTR     subnets.ru.
;Если вся остальная зона состоит и примерно одинаковых имен, то можно также воспользоваться директивой $GENERATE
$GENERATE 1-76 $.16.172.217.in-addr.arpa. PTR host-217-172-17-$.mydomain.ru.
$GENERATE 78-254 $.16.172.217.in-addr.arpa. PTR host-217-172-17-$.mydomain.ru.

При этом в сама зона 16.172.217.in-addr.arpa почти не отличается от зон прямого просмотра, также будет присутствовать запись SOA, перечисление NS, а далее PTR записи, например:

1 IN PTR myname

или на примере 217.172.16.77:

77 IN PTR mega-net.ru.

Если вы хотите сделать почти идентичные записи по хостам в зоне обратного просмотра и вам лень описывать каждый хост самому, то можно воспользоваться возможностями BIND и сделать это такой строкой, на примере зоны 16.172.217.in-addr.arpa:

$GENERATE 1-254 $.16.172.217.in-addr.arpa. PTR host-217-172-16-$.mydomain.ru.

Из чего будет следовать, что обратный посмотр для IP адресов из диапазона 217.172.16.1 — 217.172.16.254 будет выглядеть как:

host-217-172-16-XXX.mydomain.ru

Где XXX это последний октет IP-адреса.

DNS работает на порту udp 53 — обслуживает запросы и на порту tcp 53 — обменивается зонами с другими DNS серверами.

DNS сервера (применительно к зонам) бывают двух типов:

  1. master
  2. slave

master — первичный DNS сервер отвечающий за зону. Именно на нем располагается файл зоны и на нам же делаются все изменения. Сначала все обращаются к первичному, но если он не отвечает (недоступен), то вступает slave.

Пример секции конфига (named.conf) для master DNS зоны mydomain.ru:

zone "mydomain.ru" {
       type master;
       file "master/mydomain.ru.zone";
};

slave — вторичный DNS сервер отвечающий за зону. Зону скачивает с первичного DNS сервера и сохраняет у себя копию.

Пример секции конфига (named.conf) для slave DNS зоны mydomain.ru:

zone "mydomain.ru" {
       type slave;
       file "slave/mydomain.ru.zone";
       masters{IP-ADDRESS-MASTER-DNS;};
};

Где IP-ADDRESS-MASTER-DNS это IP-адрес первичного (master) DNS сервера для зоны mydomain.ru.

Пример секции конфига (named.conf) для master DNS обратной зоны 16.172.217.in-addr.arpa:

zone "16.172.217.in-addr.arpa" {
    type master;
    file "master/217.172.16.rev";
};

Секция конфига (named.conf) для slave DNS сервера обратной зоны ничем не отличается от прямой:

zone "16.172.217.in-addr.arpa" {
    type slave;
    file "slave/217.172.16.rev";
    masters{IP-ADDRESS-MASTER-DNS;};
};

Зоны обратного просмотра (IP-адрес в DNS имя) обычно находятся на DNS серверах вашего провайдера, т.е. у того кому принадлежат данные IP-адреса. Вы сможете исправить «обратное» имя попросив своего провайдера сделать это или если, провайдер делегировал вам эту возможность, сделать этот самим. «По умолчанию» действует первый вариант. На каких DNS серверах располагается зона обратного просмотра для интересующих вас IP-адресов можно так (составив соответствующий запрос в БД RIPE).

Резолв (resolve) — преобразование из имени в IP-адрес и наборот.

Технология Round robin в DNS:

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


mycoolsite         IN            A         192.168.1.15
mycoolsite         IN            A         172.16.18.6

В этом случае первому обратившемуся за резолвом имени mycoolsite будет дан IP 192.168.1.15, следующему 172.16.18.6, следующему 192.168.1.15 и так по кругу. Можно указать 3-ий и 4-ый и т.д. IP-адреса, все они будут выдаваться по кругу.

Многие называют это «балансировкой нагрузки», но это не совсем верно, т.к. раные клиенты могут давать разную нагрузку. Как говорится: «Клиент клиенту рознь».

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

Практика

Поднимаем не кеширующий DNS сервер.

И опять два варианта:

  1. Вопользоваться уже имеющимся в системе демоном (/usr/sbin/named)
  2. Установить из портов более свежую версию

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

/usr/sbin/named -v

Для тех кто все же решил установить bind из портов:

cd /usr/ports/dns/bind9
make rmconfig
make install clean

При установке ставим галочку «REPLACE_BASE Replace base BIND with this version«, что бы заменить уже имеющимся в системе версию той, что мы устанавливаем.

Если вылезла ошибка:

make: don’t know how to make /usr/ports/dns/bind9/work/.build_done.bind9._usr_local. Stop
*** Error code 2

Не пугайтесь, просто запускайте make install clean ещё раз.

Текущая, на момент написания статьи, версия в портах bind-9.3.5-P1, в которой исправлена ошибка о которой говорится тут. Её же можно взять тут.

Приступаем к настройке.

По умолчанию директория bind это /var/named/etc/namedb/ или /etc/namedb/ которая является симлинком (символической ссылкой) на первую (далее я буду использовать /etc/namedb/).

Итак, переходим в директорию /etc/namedb/. Основной конфигурационный файл это named.conf.

Простейший пример файла named.conf:

options {
          directory       "/etc/namedb";
          pid-file        "/var/run/named/pid";
          dump-file       "/var/dump/named_dump.db";
          statistics-file "/var/stats/named.stats";
          listen-on       {
               127.0.0.1;
194.87.0.50;
          };
          allow-recursion{
               127.0.0.1;
               192.168.0.0/16;
          };
          recursive-clients 30000;
};

acl "trusted-dns"{
    127.0.0.1;
194.58.241.26;
};

logging {
    category lame-servers { null; };
};

zone "." {
    type hint;
    file "named.root";
};

zone "0.0.127.IN-ADDR.ARPA" {
    type master;
    file "master/localhost.rev";
};

// RFC 3152
zone "1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.IP6.ARPA" {
     type master;
     file "master/localhost-v6.rev";
};

zone "mydomain.ru" {
     type master;
     file "master/mydomain.ru.zone";
     allow-transfer { trusted-dns;};
};

Как мы видим файл состоит из блоков/секций. Блоки:

  • options
    • listen-on
    • allow-recursion
  • acl
  • logging
  • zone

Разберем некоторые:

listen-on — IP-адреса интерфейсов сервера на котором будет запущена служба named.

allow-recursion — список IP-адресов и/или подсетей которым разрешена рекурсия. По умолчанию DNS сервер обслуживает запросы любых клиентов для любых доменов, но если вы не хотите, чтобы кто то использовал Ваш DNS сервер (бережете трафик или ресурсы машины) необходимо использовать эту директиву, которая «скажет» DNS серверу о том, что для IP-адресов которых нет в списке allow-recursion отвечать только на запросы касаемые зон которые прописаны на данном DNS сервере.

Пример поведения без allow-recursion:

Клиент «А» (IP-адрес 192.168.15.9) запрашивает IP-адрес для имени www.ya.ru. Сервер ему ответит:

www.ya.ru canonical name = ya.ru.
Name: ya.ru
Address: 213.180.204.8

Что означает что www.ya.ru ссылается* на имя ya.ru, а оно уже имеет IP-адрес 213.180.204.8

* при такой ситуации запись CNAME в конфиге зоны для домена ya.ru будет выглядеть примерно так:

ya.ru.        IN           A              213.180.204.8
www         IN           CNAME       ya.ru.

Клиент «Б» (IP-адрес 10.4.15.45) запрашивает IP-адрес для имени www.ya.ru. Сервер ему ответит то же самое, что ответил клиенту «А» с IP-адресом 192.168.15.9

Пример поведения с allow-recursion:

Как мы видим из примера файла named.conf в секции allow-recursion описан хост 127.0.0.1 (localhost) и подсеть 192.168.0.0/16 (которая означает диапазон адресов)

Итак опять же берем двух клиентов «А» и «Б». Для клиента «А» нечего не изменится, т.к. его IP-адрес входит в подсеть 192.168.0.0/16 которая описана в секции allow-recursion, а вот для клиента «Б» возникнет ситуация когда сервер на его запрос ответит:

*** Can’t find www.ru: No answer

потому что рекурсия для хоста 10.4.15.45 (или подсети 10.0.0.0/8) не разрешена. Но при этом если клиент «Б» обратится с запросом о имени mydomain.ru он получит ответ о IP-адресе данного имени, т.к. DNS сервер всегда будет отвечать на запросы о тех доменах которые прописаны в его конфигурации (named.conf), те домены за которые он как первичный или вторичный DNS сервер отвечает.

recursive-clients — максимальное кол-во одновременно обслуживаемых рекурсивных запросов от клиентов

acl — секция позволяющая создать access control list из IP-адресов, дабы потом не перечеслять их каждый раз в других секциях. acl «trusted-dns» в данном случае описывает IP-адреса доверительных DNS серверов которым позволено скачивать зоны полностью с нашего DNS сервера, т.к. по умолчанию скачать копию вашей зоны с вашего master DNS сервера сможет любой желающий указав с своем конфиге IP-адрес вашего master DNS сервера как первичного для вашей зоны. Если вы собираетесь вводить ограничения не скачивание файла зоны, то не забудьте в acl указать IP-адрес(а) вторичного(ных) DNS сервера(ов).

zone — собственно секция отвечающая за поддержку нашего тестового домена mydomain.ru данный сервер является мастером (master) для данной зоны. Внутри секции zone идет «ссылка» на «trusted-dns», это, как вы должны помнить, acl смысл которого описан чуть выше. Секция zone обязательно должна описывать: тип (type) зоны (master или slave), путь до файла (file) зоны. В случаее если это тип slave доавляется обязательный параметр masters:

masters { IP-ADDRESS; };

где IP-ADDRESS это адрес первичного DNS сервера для данной зоны.

зона «0.0.127.IN-ADDR.ARPA» это зона обратного просмотра для localhost. Если в папке master у вас нет файлов localhost.rev и localhost-v6.rev, то в /etc/namedb есть файл make-localhost и выполнив команду:

sh make-localhost

эти два файла будут созданы автоматически.

Для начала с named.conf закончили. Теперь создадим файл зоны для нашего домена.

Переходим в папку /etc/namedb/master. Создаем файл mydomain.ru.zone (зона прямого просмотра) следущего содержания:

$TTL    3600
@       IN      SOA     ns.mydomain.ru. root.mydomain.ru.   (
                                     2008071001; Serial
                                     3600    ; Refresh
                                     900     ; Retry
                                     360000 ; Expire
                                     3600 )  ; Minimum

                 IN      NS      ns.mydomain.ru.
                 IN      NS      ns2.mydomain.ru.
                 IN      MX      10 mail

localhost       IN      A       127.0.0.1
mydomain.ru.    IN      A       194.87.0.51
                HINFO   "INTEL P4" "FreeBSD"
ns              IN      A       194.87.0.50
ns2             IN      A       194.58.241.26
mail            IN      A       194.87.0.51
www             IN      A       194.87.0.51

Сохраняем файл зоны. Получили:

  • Первичный DNS сервер зоны mydomain.ru это ns.mydomain.ru и он имеет IP-адрес 194.87.0.50
  • Вторичный DNS сервер ns2.mydomain.ru имеет IP-адрес 194.58.241.26
  • Mail сервер домена располагается по имени mail.mydomain.ru и имеет IP-адрес 194.87.0.51
  • WWW сервер по имени www.mydomain.ru имеет IP-адрес 194.87.0.51
  • «Корень домена» — имя mydomain.ru.** располагается за адресом 194.87.0.51

** Обратите внимание на точку в конце имени, если вы забыли что она означает — вернитесь назад


ВАЖНО!!! Не забываем, что Serial — Серийный номер версии файла зоны; должен увеличиваться при КАЖДОМ изменении в файле зоны, по нему ваш вторичный (slave) DNS сервер обнаруживает, что надо обновить информацию (заново скачать копию файла зоны). Обычно пишется в виде <год><месяц><число><номер изменения>.


На первый взгяд все. Named мы настроили, файл зоны создали, но давайте позаботимся о собственном удобстве.

RNDC

Утилита позволяющая управлять демоном named. Проста в установке. Запустим команду

rndc-confgen

На экран будет выведен текст (который будет нужен для двух файлов):

# Start of rndc.conf
key "rndc-key" {
    algorithm hmac-md5;
    secret "328Sa3UFyO+MbLriage+Cw==";
};

options {
    default-key "rndc-key";
    default-server 127.0.0.1;
    default-port 953;
};
# End of rndc.conf

# Use with the following in named.conf, adjusting the allow list as needed:
# key "rndc-key" {
#       algorithm hmac-md5;
#       secret "328Sa3UFyO+MbLriage+Cw==";
# };
#
# controls {
#       inet 127.0.0.1 port 953
#               allow { 127.0.0.1; } keys { "rndc-key"; };
# };
# End of named.conf

То что между # Start of rndc.conf и # End of rndc.conf кладем в созданный файл rndc.conf (он располагается в той же директории, что и named.conf)

То что между # Use with the following in named.conf… и # End of named.conf дописываем в наш файл named.conf, но символ комментария «#» убираем, вот что в итоге дописываем в самый конец файла named.conf:

key "rndc-key" {
          algorithm hmac-md5;
          secret "328Sa3UFyO+MbLriage+Cw==";
};

controls {
      inet 127.0.0.1 port 953
      allow { 127.0.0.1; } keys { "rndc-key"; };
};

Благодаря этому нам станут доступны команды (но только с этого сервера, т.к. прописан 127.0.0.1 в кач-ве разрешенного IP адреса, секция controls):

rndc
Usage: rndc [-c config] [-s server] [-p port]
[-k key-file ] [-y key] [-V] command

command is one of the following:

reload        Reload configuration file and zones.
reload zone [class [view]]
Reload a single zone.
refresh zone [class [view]]
Schedule immediate maintenance for a zone.
retransfer zone [class [view]]
Retransfer a single zone without checking serial number.
freeze zone [class [view]]
Suspend updates to a dynamic zone.
thaw zone [class [view]]
Enable updates to a frozen dynamic zone and reload it.
reconfig      Reload configuration file and new zones only.
stats         Write server statistics to the statistics file.
querylog      Toggle query logging.
dumpdb [-all|-cache|-zones] [view ...]
Dump cache(s) to the dump file (named_dump.db).
stop          Save pending updates to master files and stop the server.
stop -p       Save pending updates to master files and stop the server
reporting process id.
halt          Stop the server without saving pending updates.
halt -p       Stop the server without saving pending updates reporting
process id.
trace         Increment debugging level by one.
trace level   Change the debugging level.
notrace       Set debugging level to 0.
flush         Flushes all of the server's caches.
flush [view]  Flushes the server's cache for a view.
flushname name [view]
Flush the given name from the server's cache(s)
status        Display status of the server.
recursing     Dump the queries that are currently recursing (named.recursing)
*restart      Restart the server.

* == not yet implemented
Version: 9.3.4-P1

Т.е. перезапуск named можно произвести легким

rndc reload

или получить статистику

rndc status

number of zones: 3
debug level: 0
xfers running: 0
xfers deferred: 0
soa queries in progress: 0
query logging is OFF
recursive clients: 0/30000
tcp clients: 0/100
server is up and running

Дамп кеша в файл (debug проблем резолва какого либо домена в интернете)

rndc dumpdb

Полный сброс кеша вашего DNS сервера:

rndc flush

Подготовка к запуску

Открываем файл /etc/rc.conf (для автозапуска после ребута) и дописываем в него:

named_enable="YES"
named_program="/usr/sbin/named"
named_flags="-u bind -c /etc/namedb/named.conf"

Откроем файл /etc/syslog.conf (логи, куда же без них) и допишем в него:

!named
*.* /var/log/named.log

Создадим пустой файл /var/log/named.log

touch /var/log/named.log

выставим на этот файл права

chown bind:bind /var/log/named.log

Перезапустим процесс syslogd для того чтобы он перечитал конфиг

/etc/rc.d/syslogd restart

Запускаемся

Выполняем команду

/usr/sbin/named -t /var/named -u bind -c /etc/namedb/named.conf

смотрим, что у нас в логах

tail -F /var/log/named.log

Если мы видим сообщение:

loading configuration from ‘/etc/namedb/named.conf’
zone mydomain.ru/IN: loaded serial 2008071001
zone mydomain.ru/IN: sending notifies (serial 2008071001)

То значит вы нигде не ошиблись и named успешно запущен и зона mydomain.ru загружена.

Если вы видите сообщение:

config: none:0: open: /etc/namedb/named.conf: permission denied
general: reloading configuration failed: permission denied

Это означает что named (из-за отсутствия прав) не может прочесть конфиг. Исправим это:

cd /var
chown -R bind:bind named

тем самым изменили права на папку named установив владельца (owner) bind, группу (group) bind

Проверить наличие владельца с именем bind можно

команда
результат

Проверяем наличие в системе пользователя bind:

id -P bind
bind:*:53:53::0:0:Bind Sandbox:/:/usr/sbin/nologin

Проверяем наличе в системе группы bind:

cat /etc/group | grep bind
bind:*:53:

Или узнаем и то и то одной командой:

id bind
uid=53(bind) gid=53(bind) groups=53(bind)

Точно убедиться что named запущен:

ps -ax | grep named
/usr/sbin/named -t /var/named -u bind -c /etc/namedb/named.conf

sockstat | grep :53
bind named 67664 20 udp4 194.87.0.50:53 *:*
bind named 67664 21 tcp4 194.87.0.50:53 *:*
bind named 67664 22 udp4 127.0.0.1:53 *:*
bind named 67664 23 tcp4 127.0.0.1:53 *:*

Проверить наличие резолва можно командой:

nslookup mydomain.ru
Server: 127.0.0.1
Address: 127.0.0.1#53

Name: mydomain.ru
Address: 194.87.0.51

Если IP-адрес выдается, то вы все сделали правильно.

Командой nslookup можно проверять любые домены, эта команда есть даже в Windows 🙂

Прочтите man nslookup

Named не стартует и в логах тишина…. Что делать ?

Воспользоваться debug режимом. Для этого нужно запустить named с ключами -g -d9

/usr/sbin/named -t /var/named -u bind -c /etc/namedb/named.conf -g -d9

Иерархия DNS:

Практически повсеместно корневой домен (root) обозначают символом «.», на самом деле точка — разделитель компонентов доменного имени, а т. к. у корневого домена нет обозначения, то полное доменное имя кончается точкой. Тем не менее, это обозначение достаточно прочно закрепилось в литературе в качестве обозначения корневого домена. Далее по иерархии идут домены верхнего уровня (TLD, Top Level Domain), за ними домены второго уровня, далее третьего и т. д., друг от друга они отделяются точками. Общая структура представлена на рисунках:

dns.gif

dns2.gif

Иллюстрация работы:

dns3.gif

З.Ы. При копировании статьи ссылка на источник ОБЯЗАТЕЛЬНА !

Автор: Николаев Дмитрий (virus (at) subnets.ru)
Ничего не понялТак себе...Не плохоДовольно интересноОтлично ! То что нужно ! (голосов: 22, среднее: 4,91 из 5)
Загрузка...
Отправить на почту Отправить на почту

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

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

Проблеме присвоен максимальный уровень опасности, рекомендуется как можно скорее установить обновление. Частичным утешением может выступить тот факт, что полное описание новой техники DNS спуффинга будет опубликовано Дэном Каминским на конференции «Black Hat», которая состоится 7 августа.

Организация ISC уже выпустила обновление BIND 9.5.0-P1, BIND 9.4.2-P1 и BIND 9.3.5-P1, а также опубликовала специальный пресс-релиз, в котором подчеркнута серьезность проблемы и необходимость скорейшего обновления. К сожалению исправление существенно понижает производительность сервера, что особенно начинает проявляться при нагрузке в 10 тыс. запросов в секунду и выше. В бета версиях 9.5.1b1/9.4.3b2 начато тестирование оптимизированного варианта исправления, который должен частично решить возникшие проблемы с производительностью. Тем не менее, полную защиту от данного вида атак может обеспечить только использование DNSSEC.

Проверить DNS сервер на уязвимость можно на данной странице. Доступность исправлений для различных платформ можно узнать здесь. Кроме BIND, в настоящий момент уязвимость подтверждена в Cisco IOS, Juniper JunOS, Microsoft Windows DNS Server. Проблема отсутствует в PowerDNS (резолвер выделен в отдельный продукт PowerDNS Recursor, об уязвимости которого ничего не сообщается).

Оригинал

Статья с http://www.securitylab.ru:

Краткое предисловие

DNS является одним из самых критичных компонентов сети Интернет, поэтому уязвимости в серверах имен всегда вызывали повышенный интерес у злоумышленников. 8-9 июля многие производители выпустили исправления, устраняющие фунаментальную ошибку, которая позволяет злоумышленнику произвести спуфинг атаку. Дэн Камински в своем блоге http://www.doxpara.com/?p=1165 опубликовал более подробное описание уязвимости и сделал доступным эксплоит.

В чем заключается уязвимость?

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

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

BIND 9.4.1-9.4.2 Remote DNS Cache Poisoning Flaw Exploit (meta)
BIND 9.x Remote DNS Cache Poisoning Flaw Exploit (py)
Утилита http://www.onzra.com/CacheAudit-Latest.tgz

Насколько опасна уязвимость?

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

В тестах, которые проводил Камински, ему удалось отравить кеш сервера имен приблизительно за 5-10 секунд. Эта уязвимость позволяет атакующему перезаписать данные, которые уже находятся в кеше сервера. Сервера имен, которые являются только авторитетными, не подвержены этой уязвимости. Установка высокого значения TTL для ваших хостов на авторитетном сервере не помешает злоумышленнику отравить кеш уязвимых резолверов, так как атака обходит защиту TTL.

Уязвимость затрагивает также и клиентские библиотеки (рабочие станции и сервера, которые обращаются к вышестоящим серверам имен) и может быть проведена против одиночного хоста. Также, некоторые МСЭ с функционалом трансляции адресов, рассчитанные на домашний сектор, используют предсказуемые номера для порта источника запросов, что позволяет злоумышленнику удачно произвести атаку, даже если было установлено исправление на сервер имен или клиент.

Итак, подытожим:

  1. Отравление кеша DNS сервера можно произвести довольно быстро (5-10 секунд)
  2. Злоумышленник может изменить данные, которые уже находятся в кеше сервера
  3. Уязвимость может использоваться как против сервера имен, так и против рабочей станции.
  4. Сервера и рабочие станции, которые находятся за бюджетными МСЭ с включенным NAT, подвержены уязвимости не зависимо от установленных исправлений.
  5. Эксплоит находится в публичном доступе.
  6. Целью атаки может стать любой промежуточный DNS сервер на пути к авторитетному серверу или DNS клиент. Это означает, что если вышестоящий DNS сервер уязвим, то не зависимо от наличия исправлений на ваших серверах, вы можете стать жертвой атаки.

Векторы атаки

Как я уже писал выше, спуфинг атака – атака, направлена на клиента, а не на сервер. Злоумышленник может:

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

Исправления

Для устранения уязвимости необходимо установить исправления не только на хосты, которые находятся под вашим контролем, но и на все сервера имен, которые участвуют в обмене данными, иначе всегда будет существовать возможность спуфинг атаки.
Исправления доступны для Windows, Linux, UNIX и других систем. Для получения исправления обратитесь к соответствующему производителю. Список производителей доступен по адресу: http://www.kb.cert.org/vuls/id/800113

Выводы

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

Ссылки:

Ничего не понялТак себе...Не плохоДовольно интересноОтлично ! То что нужно ! (голосов: 3, среднее: 5,00 из 5)
Загрузка...
Отправить на почту Отправить на почту

DNS server

В сети MSK-IX размещены локальный узел корневого cервера F.root доменной системы имен (DNS) и локальный узел корневого DNS-сервера зоны RU.

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

Узел корневого DNS-cервера F.root находится под управлением Internet Systems Consortium. Для доступа к корневому DNS-cерверу F.root участнику MSK-IX необходимо установить пиринговое взаимодействие с автономной системой AS30124. Техническую информацию, необходимую для установления взаимодействия, можно найти по адресу http://www.isc.org/ops/peering/.

Узел корневого DNS-сервера зоны RU находится под управлением РосНИИРОС, выполняющего функции Технического центра домена RU. Для доступа к корневому DNS-серверу зоны RU участнику MSK-IX необходимо установить пиринговое взаимодействие с автономной системой AS43832. Техническую информацию, необходимую для установления взаимодействия, можно найти по адресу https://registry.ripn.net/dnsru1.php.

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

Ничего не понялТак себе...Не плохоДовольно интересноОтлично ! То что нужно ! (голосов: 1, среднее: 5,00 из 5)
Загрузка...
Отправить на почту Отправить на почту