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

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

Демон 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)
Загрузка...
Отправить на почту Отправить на почту
    Не найдено

В июне в Швеции был принят закон, разрешающий агентству FRA анализировать транзитный трафик других стран и обязующий операторов связи к установке специального оборудования.

Основным объектом наблюдения аналитики называют Россию, так как через кабельные сети Швеции проходит около 80% всего российского внешнего трафика. Ведущий европейский оператор связи TeliaSonera, обслуживающий большинство внешний каналов России, пытается найти другие пути передачи транзитного трафика в обход территории Швеции. Компания Google намерена перевести из Швеции размещенный там дата-центр.

Оригинал.

Ничего не понялТак себе...Не плохоДовольно интересноОтлично ! То что нужно ! (голосов: 3, среднее: 3,67 из 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)
Загрузка...
Отправить на почту Отправить на почту
    Не найдено

Google подключился к сети MSK-IX на MMTC-9 !

Приводим текст письма:

Dear MSK-IX members,

I am pleased to inform you that Google (AS15169) completed its installation in Moscow and is now peering at MSK-IX. Please read on for important details about our peering.

Google operates a restricted peering policy, for public peers we are looking for significant traffic volume, for private we expect volume and in addition peers should meet us in more than one location.

To improve our connectivity to you we are however peering with the MSK-IX route servers (AS8631). This is our preferred method of exchanging traffic unless you have more than approx 50Mb coming in from us. Please check that you are preferring our prefixes and that you are correctly classifying AS15169 as as local routes.

We are currently aware of issues in path selection for our outbound traffic, since AS8631 is included in the as-path this can result in equal or shorter length as-paths being announced to us by peers
elsewhere. We are told by MSK-IX that they are in the process of upgrading the route servers and when this is complete it will then be transparent which is very good news. However if you are peering with the route servers at MSK-IX but not seeing our traffic on your MSK-IX port you may want to consider this issue and we know that some peers have successfully used as-path prepending to manipulate which way traffic enters their network.

As mentioned above, if you wish to peer we would prefer to do so via the route server unless you have significant inbound traffic from us, in which case please feel free to drop me an email giving a little bit of detail about yourself and your estimated traffic volume and we can consider the request.

Finally, I wish you all well and hope to meet you at one of the upcoming MSK-IX hosted meetings!

С Уважением, Стив.

Steve


Global Infrastructure
Google Inc.

И действительно в трассе до google.ru и google.com теперь присутствует:
msk-ix-gw.google.com (193.232.244.232)

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

SNMP (Simple Network Management Protocol) — простой протокол управления сетью.

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

MRTG (Multi Router Traffic Grapher) — утилита позволяющая осуществлять мониторинг сетевых линков (да и не только их). MRTG на выходе генерирует HTML страницы с графиками в PNG.

Пример:

mrtg graph example

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

Что для этого нужно ?

Вам понадобятся две вещи:

  • /usr/ports/net-mgmt/mrtg
  • /usr/ports/net-mgmt/net-snmp

Сначала установим MRTG:

[root@work ~]# cd /usr/ports/net-mgmt/mrtg
[root@work /usr/ports/net-mgmt/mrtg]# make install clean

после инсталляции появится: /usr/local/bin/mrtg

Затем snmp:

[root@work ~]# cd /usr/ports/net-mgmt/net-snmp
[root@virus /usr/ports/net-mgmt/net-snmp]# make install clean

после инсталляции появится: /usr/local/sbin/snmpd

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

SNMP

Если вам необходимо мониторить что либо на другом компьютере/сервере (он будет являться «клиентом»), то после установки на нем snmp выполняем команду:

snmpconf -i -f

Запустится утилита которая поможет создать конфигурационный файл для snmp, который должен располагаться в /usr/local/share/snmp/ и называться snmpd.conf.

После запуска выбираем пункт 1 (1: snmpd.conf), затем пункт 2 (2: Access Control Setup), а затем пункт 3 (3: a SNMPv1/SNMPv2c read-only access community name).

На вопрос «The community name to add read-only access for:» отвечаем именем community на которое будет отзываться наш сервер, например pub.

На вопрос «The hostname or network address to accept this community name from [RETURN for all]:» у нас два варианта:

  1. нажать ENTER, но тогда любой хост в сети сможет «снимать» показания по SNMP с этого сервера используя community pub.
  2. четко указать IP-адрес хоста с которого будут приходить запросы. (это может быть и сам хост 127.0.0.1)

На последний вопрос об ограничениях просто жмем ENTER.

На этом конфигурирование для нас закончено, печатаем букву f, жмем ENTER, печатаем f жмем ENTER, печатаем q, жмем ENTER и программа конфигуратор завершает свою работу сообщая:

The following files were created:
snmpd.conf installed in /usr/local/share/snmp

Посмотрим как выглядит /usr/local/share/snmp/snmpd.conf

rocommunity pub 127.0.0.1

Это означает что, хост с IP-адресом 127.0.0.1 может только «читать» используя community pub (помним, что по snmp можно и «писать» (управлять)).

Добавляем в /etc/rc.conf:

snmpd_enable=»YES»

Запускаем командой:

/usr/local/etc/rc.d/snmpd start

Смотрим на месте ли процесс snmp:

[root@work ~]# ps -ax | grep snmp
927 ?? S 0:23.01 /usr/local/sbin/snmpd -p /var/run/snmpd.pid
76815 p0 S+ 0:00.00 grep snmp
[root@work ~]# sockstat | grep :161
root snmpd 927 13 udp4 *:161 *:*

Все в порядке, процесс на месте и «слушает» порт udp 161.

Проверить доступность «чтения» данных по SNMP c любого устройства можно командой:

snmpwalk -v2c -c pub 127.0.0.1

Где pub это community, а 127.0.0.1 IP-адрес хоста с которого мы хотим получить данные.

Если после запуска snmpwalk вы не получили в ответ:

Timeout: No Response from 127.0.0.1

а «поехали» данные то все ОК, если timeout, то проверьте, что процесс запущен и слушает порт udp 161, а также что IP-адрес хоста, с которого вы пытаетесь получить эти данные, присутвует в /usr/local/share/snmp/snmpd.conf с запрашиваемым вами community.

Если вам необходимо снимать данные по SNMP с сетевого устройства (коммутатор (свич), маршрутизатор, etc.), который так же будет являться «клиентом», то настройте SNMP на нем, также указав хосты и community на RO (Read Only).

Пример настройки SNMP на Cisco Catalyst:

snmp-server community pub RO
snmp-server location server-farm
snmp-server contact my-cool-provider
snmp-server host 10.3.1.1 pub
snmp-server host 10.3.1.2 pub

Пример настройки SNMP на D-link DES 3526:

create snmp group pub v2c read_view CommunityView notify_view CommunityView
create snmp community pub view CommunityView read_only
create snmp host 10.3.1.1 v2c pub
create snmp host 10.3.1.2 v2c pub

MRTG

Конфигурационные файлы MRTG по умолчанию находятся в /usr/local/etc/mrtg/.

Файл mrtg.conf:

Language: russian1251

WorkDir: /usr/local/www/mrtg
background[_]: #FBEDD0
Options[_]: Bits
Forks: 4

#Пример получения графика по порту №1 cisco catalyst 3560G

Title[cat_1]: Traffic for Cisco 3560 (Port 1)
PageTop[cat_1]: <h1><B>Cisco 3560: Port 1 </B></h1>
Target[cat_1]: 10101:pub@10.3.1.10:::::2
RouterUptime[cat_1]: pub@10.3.1.10
MaxBytes[cat_1]: 250000000

Где 10.3.1.10 — IP адрес утсройства, pub — community, 10101 — номер первого порта в дереве SNMP.

Как я узнал, что 10101 это первй порт ? Запускаем:

snmpwalk -v2c -c pub 10.3.1.10

Видим:

…………………………

IF-MIB::ifDescr.10101 = STRING: GigabitEthernet0/1
IF-MIB::ifDescr.10102 = STRING: GigabitEthernet0/2
IF-MIB::ifDescr.10103 = STRING: GigabitEthernet0/3
IF-MIB::ifDescr.10104 = STRING: GigabitEthernet0/4

…………………………

IF-MIB::ifDescr.10127 = STRING: GigabitEthernet0/27
IF-MIB::ifDescr.10128 = STRING: GigabitEthernet0/28
………………………….

Таким же образом можно описать в /usr/local/etc/mrtg/mrtg.conf и остальные порты catalyst`а.

Пример получение загрузки CPU cisco catalyst по snmp.

В /usr/local/etc/mrtg/mrtg.conf дописываем:

Title[cpu3560]: Cisco 3550 CPU Usage
Target[cpu3560]: 1.3.6.1.4.1.9.2.1.58.0&1.3.6.1.4.1.9.2.1.58.0:pub@10.3.1.10:::::2
LegendI[cpu3560]: Load CPU
LegendO[cpu3560]:
YLegend[cpu3560]: CPU load, %
MaxBytes[cpu3560]: 100
AbsMax[cpu3560]: 100
ShortLegend[cpu3560]: %
PageTop[cpu3560]: <h1><B>Средняя загрузка процессора Cisco 3560</B></h1>
Options[cpu3560]: Absolute, nopercent, gauge
Legend1[cpu3560]: Средняя загрузка процессора

Пример получение использование памяти cisco catalyst по snmp.

В /usr/local/etc/mrtg/mrtg.conf дописываем:

Title[mem3560]: Memory Usage
MaxBytes[mem3560]: 256000000
AbsMax[mem3560]: 256000000
Target[mem3560]: 1.3.6.1.4.1.9.9.48.1.1.1.5.1&1.3.6.1.4.1.9.9.48.1.1.1.6.1:pub@10.3.1.10:::::2
LegendI[mem3560]: Used mem
LegendO[mem3560]: Free mem
YLegend[mem3560]: Mem usage, Mb
ShortLegend[mem3560]: b
PageTop[mem3560]: <h1><B>Среднее использование памяти Cisco 3560</B></h1>
Options[mem3560]: Absolute, nopercent, gauge, nobanner
Legend1[mem3560]: Used mem
Legend2[mem3560]: Free mem

Пример получение загрузки CPU с сервера.

В /usr/local/etc/mrtg/mrtg.conf дописываем:

Pagetop[srv01_cpu]: <h1><B>CPU Сервер-01</B></h1>
Title[srv01_cpu]: CPU Сервер-01
PNGTitle[srv01_cpu]: CPU Сервер-01
MaxBytes[srv01_cpu]: 100
AbsMax[srv01_cpu]: 100
Target[srv01_cpu]: .1.3.6.1.4.1.2021.11.9.0&.1.3.6.1.4.1.2021.11.9.0:pub@10.3.1.11 + .1.3.6.1.4.1.2021.11.10.0&.1.3.6.1.4.1.2021.11.10.0:pub@10.3.1.11
RouterUptime[srv01_cpu]: pub@10.3.1.11
LegendI[srv01_cpu]: CPU
LegendO[srv01_cpu]: CPU
YLegend[srv01_cpu]: Usage CPU, %
ShortLegend[srv01_cpu]: %
Legend1[srv01_cpu]: CPU
Legend2[srv01_cpu]: CPU

Пример получение загрузки сетевой карты сервера с IP-адресом 10.10.10.1.

В /usr/local/etc/mrtg/mrtg.conf дописываем:

Pagetop[srv01_net1]: <h1><B>Сетевая карта с IP 10.10.10.1</B></h1>
Title[srv01_net1]: Сетевая карта с IP 10.10.10.1
PNGTitle[srv01_net1]: Сетевая карта с IP 10.10.10.1
MaxBytes[srv01_net1]: 250000000
Target[srv01_net1]: -/10.10.10.1:pub@10.3.1.12
RouterUptime[
srv01_net1]: pub@10.3.1.12

Будем считать что файл /usr/local/etc/mrtg/mrtg.conf вы подготовили.

Проверяем конфиг

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

/usr/local/bin/mrtg /usr/local/etc/mrtg/mrtg.conf

Если строчек «ERROR: CFG Error in» нет, то все ОК, если есть исправляем ошибки.

Запускаемся

Добавляем в файл /etc/crontab:

*/5 * * * * root /usr/local/bin/mrtg /usr/local/etc/mrtg/mrtg.conf

Теперь ждем 5-ть минут и смотрим в папку /usr/local/www/mrtg, которая обозначена в нашем конфиге как WorkDir, куда и будут складываться HTML страницы с графиками. Не пугайтесь если графики по началу пусты, подождите хотябы 30-ть минут, что бы появилось достаточно данных для того, чтобы вы увидели рабочий график.

Благодаря crontab`у график будет обновляться каждые 5-ть минут и вы будете видеть графики отображающие среднее за 5-ть минут значение. Делать меньше 5-ти минут не рекомендую.

С помощью MRTG можно строить графики на любых данных. Главное всегда придоставлять для MRTG 4-ре строки. Пример:

В /usr/local/etc/mrtg/mrtg.conf дописываем:

Pagetop[srv01_hdd]: HDD Сервер-01<br>
Title[srv01_hdd]: HDD Сервер-01
PNGTitle[srv01_hdd]: HDD use
MaxBytes[srv01_hdd]: 1250000
AbsMax[srv01_hdd]: 1250000
Target[srv01_hdd]: `/bin/cat /usr/monitor/SRV-01.log`
LegendI[srv01_hdd]: /usr
LegendO[srv01_hdd]: /var
YLegend[srv01_hdd]: Used space, Mb
ShortLegend[srv01_hdd]: Mb
Legend1[srv01_hdd]: /usr
Legend2[srv01_hdd]: /var

При этом в файле /usr/monitor/SRV-01.log (который, например, может формировать perl скрипт):

HDD: /usr and /var
1713067
686879
14 days, 06:33:17

Где 1-ая строка — описание, 2-ая — кол-во занято в разделе /usr, 3-я -кол-во занято в разделе /var, 4-ая время uptime данного сервера.

Используя этот пример можно «налепить» любых графиков 😉

Вам в помощь может пригодится программа cfgmaker, которая устанавливается вместе с mrtg (идет вместе с mrtg), обычно находится тут: /usr/local/bin/cfgmaker

Пример запуска:

cfgmaker pub@127.0.0.1 > myrouter.conf

После завершения выполнения в файле myrouter.conf будет конфиг mrtg для хоста 127.0.0.1

Отдельные файлы конфигов (как например myrouter.conf) можно «включать» в глобальный конфиг /usr/local/etc/mrtg/mrtg.conf с помощью include, дописав в файле mrtg.conf строчку:

include: /usr/local/etc/mrtg/myrouter.conf

Рекомендую полистать до полного просветления:

  • man snmpwalk
  • man smnpget
  • man snmpset
  • man snmpconf
  • man cfgmaker

(P.S. команда man выполняется в консоле сервера)

Ссылки:

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

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