3.1.7. Примеры настроек программы named и описания зон
В данном разделе мы рассмотрим наиболее типичные, на мой взгляд, примеры построения сервиса доменных имен:
Этот перечень можно было бы и расширить, но такое расширение будет просто комбинацией приведенных выше случаев. Более сложные случаи встречаются в практике администраторов больших сетей, и для них можно только порекомендовать обращаться за помощью к другим администраторам или разработчикам программ-серверов.
С первой ситуацией сталкивается любая организация, которая намеривается получить свой собственный домен в домене ru. О том, как его получить рассказывалось в разделе 3.1.3. В настоящее время практически нет сетей класса B, поэтому организации получают сети класса C на 254 машины и на основе этих сетей организовывают свой домен. В самом начале такой домен, как правило состоит из одной единственной зоны. В качестве главной машины в этом домене выступает один единственный компьютер с операционной системой Unix или Windows NT. Все остальные варианты рассматривать не будем в силу их неготовности для полноценной работы с сервисом доменных имен Internet. Этот компьютер одновременно является и шлюзом между локальной сетью и сетью Internet-провайдера.
Второй случай касается ситуации, когда сеть учреждения приходится разбивать на подсети. При этом на нескольких подсетях может быть определена одна и та же зона общего домена организации. Такая ситуация часто возникает при постоянных перемещениях подразделений из одного помещения в другое или даже из одного здания в другое. При этом часто подразделения либо съезжаются, либо разъезжаются. Случай типичный для растущей или стареющей организации.
Третий случай обусловлен развитием и усложнением сети или структуры организации, которую данная сеть обслуживает. Когда становится трудно управлять из одного места всеми машинами в домене, права управления частями домена делегируют туда, где изменения наиболее часты. В этом случае администратор домена снимает с себя часть обязательств по управлению доменом и передает их администраторам поддоменов. Для больших организаций - это типичный способ обеспечения сервиса доменных имен. Можно, конечно, спорить о достоинствах или недостатках такого делегирования прав, но в современных условиях это единственная возможность управлять большими разнородными сетями.
3.1.7.1. Небольшой поддомен в домене ru
В данном случае организация получила домен в домене ru и зарегистрировала его в РосНИИРОС. Primary сервер доменных имен установлен на шлюзе 194.226.43.1. Это единственная машина в сети, которая работает под управлением Unix. Все остальные машины - это персональные компьютеры сотрудников. В общем виде схему такого домена можно представить в виде рисунка 3.13:
Рис. 3.13. Структура простой локальной сети
Домен, который зарегистрировала данная организация, пусть будет называться vega.ru. Так как это домен второго уровня, то он должен иметь как минимум два сервера доменных имен: primary и secondary. Основной сервер, primary, установлен на машине-шлюзе, на размещение вторичного получено разрешение от администратора сервера ns.rekarn.ru, который расположен в другой сети, имеющей свой собственный выход в Internet.
Программа named, установленная на машине шлюзе будет иметь следующую конфигурацию, которая задается файлом named.boot:
; ; Zone vega.ru data base files. ; directory /etc/namedb primary vega.ru vega.ru primary 127.in-addr.arpa localhost primary 43.226.194.in-addr.arpa vega.rev forwarders 144.206.136.1 144.206.130.137 cаche . named.root
В этом файле определено, что директория расположения описания файлов зоны vega.ru - /etc/namedb. Это стандартная директория для операционной системы FreeBSD. Файла описания "прямой" зоны домена vega.ru - файл vega.ru будет размещен в этой директории (/etc/namedb/vega.ru). Кроме "прямой" зоны описаны еще две "обратных" зоны 127.in-adrr.arpa и 43.226.194.in-addr.arpa. Первая определяет обратное соответствие между адресом 127.0.0.1 и именем localhost, а вторая множество обратных соответствий для сети 194.226.43.0. Последним указан файл начальной загрузки cache. Символ "." в качестве первого аргумента указывает на описание домена root.
Кроме этого команда forwarders указывает IP-адреса серверов доменных имен, к которым следует обращаться в случае невозможности самостоятельно получить адрес. Это сделано для того, чтобы в начальный период функционирования сервера он мог отвечать на запросы клиентов из данной зоны, хотя сам он еще и не зарегистрирован в корневом сервере домена ru.
В принципе, можно было бы просто указать данные сервера в настройках resolver для машин данного домена, но зато потом везде нужно было бы их снова менять. Использование forwarders позволяет после регистрации домена и размещения серверов не перестраивать настройки всех компьютеров в домене. Кроме того, named сразу начинает работать как интеллектуальный кэширующий сервер, что при частом обращении к одним и тем же именам позволяет быстро получать IP-адреса или имена машин.
Файл описания "прямой" зоны для домена vega.ru будет выглядеть следующим образом (/etc/namedb/vega.ru):
@ IN SOA vega-gw.vega.ru paul.vega.ru (
101 ;serial number
86400 ;refresh
3600 ;retry
3888000 ;expire
99999999 ;minimum
)
; Name server
IN NS vega-gw.vega.ru.
IN NS ns.relarn.ru.
IN NS polyn.net.kiae.su.
IN A 194.226.43.1
IN MX 0 vega-gw.vega.ru.
IN MX 10 ns.relarn.ru.
;
localhost IN A 127.0.0.1
;
vega-gw IN A 194.226.43.1
IN MX 0 vega-gw
IN MX 10 ns.relarn.ru.
www IN CNAME vega-gw
ftp IN CNAME vega-gw
gopher IN CNAME vega-gw
;
dos1 IN A 194.226.43.2
dos2 IN A 194.226.43.3
; The rest of net should be presented below.
Запись SOA берет имя зоны из записи primary файла named.boot (символ "@"). В качестве машины, на которой установлен сервер, указана машина vega-gw.vega.ru, а в качестве администратора - paul@kiae.su. Остальные поля установлены в соответствии с описанием записи SOA.
Обратите внимание на следующее обстоятельство: имя текущей зоны будет взято из команды primary файла named.boot и использоваться для описания зоны, только в том случае если в записи SOA будет указан символ коммерческого "@". Например, в следующем примере могут возникнуть проблемы с описанием зоны:
IN SOA vega-gw.vega.ru paul.vega.ru (
101 ;serial number
86400 ;refresh
3600 ;retry
3888000 ;expire
99999999 ;minimum
)
; Name server
IN NS vega-gw.vega.ru.
IN NS ns.relarn.ru.
IN NS polyn.net.kiae.su.
IN A 194.226.43.1
IN MX 0 vega-gw.vega.ru.
IN MX 10 ns.relarn.ru.
Ни NS-записи, ни A-запись, ни MX-записи не привязаны к конкретному домену, и следовательно не используются named.
Две NS-записи определяют три машины в качестве сервера доменных имен для данной зоны: vega-gw.vega.ru, ns.relarn.ru и polyn.net.kiae.su. Первая запись типа A определяет адрес всего домена для обслуживания неполных запросов. Следующие две записи MX определяют правила пересылки почты на домен по адресам типа user@vega.ru.
За описанием зоны в нашем файле следует описание "петли", т.е. имени для адреса 127.0.0.1. В FAQ по сервису доменных имен можно найти и другие решения, но в большинстве случаев, обычно, рекомендуется определять имя localhost как localhost.domain.name, или в нашем случае - localhost.vega.ru.
Первой в домене описана машина-шлюз. На ней установлены сервисы World Wide Web, FTP и Gopher. Для каждого из них определены имена, которые должны облегчить запоминание доменного имени сервера. После записей CNAME идут записи описания других машин зоны. Так как это обычные рабочие места под управлением MS-DOS и Widows, то никаких дополнительных записей для их описания не требуется.
Как утверждается во всех руководствах по DNS, описание обратных зон для домена не является обязательным, но крайне желательно. Для нашего простого домена в файле named.boot описаны две обратные зоны: 127.in-addr.arpa и 43.226.194.in-addr.arpa.
Зона 127.in-addr.arpa описывает обратное соответствие межу адресом 127.0.0.1 и именем lo-calhost.vega.ru. Описание зоны будет располагаться в файле /etc/namedb/localhost:
@ IN SOA vega-gw.vega.ru paul.vega.ru (
101 ;serial number
86400 ;refresh
3600 ;retry
3888000 ;expire
99999999 ;minimum
)
; Localhost declaration
1 IN PTR localhost.vega.ru.
В данном случае имя зоны также, как и в предыдущем случае берется из команды primary файла named.boot:
primary 127.in-addr.arpa localhost
Согласно этому описанию символ "@" заменяется на имя 127.in-addr.arpa, которое и добавляется к цифре 1, образуя имя 1.127.in-addr.arpa. Так как сеть 127.0.0.0 - это сеть класса А, то адрес 127.1 эквивалентен адресу 127.0.0.1.
Вторая "обратная" зона описывает все остальные IP-адреса и размещается в файле /etc/namedb/vega.rev:
@ IN SOA vega-gw.vega.ru paul.vega.ru (
101 ;serial number
86400 ;refresh
3600 ;retry
3888000 ;expire
99999999 ;minimum
)
IN NS vega-gw.vega.ru.
IN NS ns.relarn.ru.
IN NS polyn.net.kiae.su.
; Reverse zone description.
1 IN PTR vega-gw.vega.ru.
2 IN PTR dos1.vega.ru.
3 IN PTR dos2.vega.ru.
; description of the other hosts should be placed below.
;
Первые две NS-записи в этом примере определяют сервера доменных имен для этой зоны. Так как "прямая" зона это зона второго уровня в домене ru, то будет логичным и для "обратной" зоны разместить дублирующий сервер в том же месте, что и дублирующий сервер для "прямой" зоны. Имя зоны берется из команды primary файла named.boot:
primary 43.226.194.in-addr.arpa vega.rev
Таким образом к единичке, указанной в записи PTR для машины vega-gw.vega.ru будет получено "обратное" имя 1.43.226.194.in-addr.arpa.
Все имена машин в поле данных записей типа PTR должны обязательно заканчиваться точкой, иначе они будут расширены именем зоны.
И последний файл, который необходим для запуска сервера доменных имен, - это файл начальной загрузки named, определенный в команде cache файла named.boot. В нашем случае этот файл имеет полное имя - /etc/namedb/named.root. Содержание этого файла приведено в примере 5. Файл просто копируется с сервера ftp.internic.net. В ряде случаев провайдеры рекомендуют пользоваться их файлом начальной загрузки, а не стандартным.
3.1.7.2. Описание "прямой" и "обратной" зон для поддомена определенного на двух подсетях
В данном примере мы рассмотрим описание домена третьего уровня polyn.kiae.su, который определен на двух подсетях сети 144.206.0.0: 144.206.160.0 и 144.206.192.0. Если в предыдущем случае мы выделяли две "обратные" зоны из-за особой роли адреса 127.0.0.1, то в данном случае нам придется выделить "обратные" зоны на каждую из подсетей. Кроме того этот сервер мы также будем использовать в качестве дублирующего для домена vega.ru. Файл named.boot в этом случае будет иметь вид:
; ; Zone polyn.kiae.su - data base files. ; directory /etc/namedb primary polyn.kiae.su polyn.kiae.su primary 127.in-addr.arpa localhost primary 160.206.144.in-add.arpa polyn primary 192.206.144.in-addr.arpa quest secondary vega.ru 194.226.43.1 vega.ru secondary 43.226.194.in-addr.arpa 194.226.43.1 vega.rev forwarders 144.206.136.1 144.206.130.3 cаche . named.rootКак видно из содержания этого файла все файлы описания зоны расположены в директории /etc/namedb (команда directory), описание зоны polyn.kiae.su находится в файле /etc/namedb/polyn.kiae.su, описание зоны 127.in-addr.arpa - в файле /etc/namedb/localhost, описание зоны 160.206.144.in-addr.arpa - в файле /etc/namedb/polyn, описание зоны 192.206.144.in-addr.arpa - в файле /etc/namedb/quest. Кроме этого, после запуска, данный сервер опрашивает primary сервер зоны vega.ru и копирует с него зоны vega.ru и 43.226.194.in-addr.arpa. Первую в файл /etc/namedb/vega.ru, а вторую в файл /etc/namedb/vega.rev. Перейдем теперь к описанию файлов зоны polyn.kiae.su.
;
; Zone -- polyn.kiae.su
$ORIGIN kiae.su.
polyn IN SOA polyn.net.kiae.su. paul.kiae.su. (
36 3600 300 9999999 3600 )
;
IN NS polyn.net.kiae.su.
IN NS ns.kiae.su.
IN A 144.206.160.32
IN MX 0 ns.polyn.kiae.su.
IN MX 10 relay.net.kiae.su.
$ORIGIN net.kiae.su.
polyn IN A 144.206.130.137
$ORIGIN kiae.su.
ns IN A 144.206.130.3
$ORIGIN polyn.kiae.su.
* IN MX 2 ns.polyn.kiae.su.
IN MX 10 relay.net.kiae.su.
;
ns IN A 144.206.160.32
www IN CNAME ns.polyn.kiae.su.
ftp IN CNAME ns.polyn.kiae.su.
;
kurm IN A 144.206.160.50
IN MX 0 kurm.polyn.kiae.su.
IN MX 10 polyn.net.kiae.su.
IN MX 20 relay.net.kiae.su.
driver IN A 144.206.160.51
lebedev IN A 144.206.160.41
;
georg IN A 144.206.192.5
olga IN A 144.206.192.2
IN MX 0 olga.polyn.kiae.su.
IN MX 10 polyn.net.kiae.su.
IN MX 20 relay.net.kiae.su.
nata IN A 144.206.192.3
kaverin IN A 144.206.192.6
temp IN A 144.206.192.254
; The rest of zone is placed below
........
Данный пример интересен тем, что в нем наглядно продемонстрировано использование "приклеенных" A-записей.
Начинается домен также, как и в предыдущем примере - с записи SOA. В данном случае зона описывается непосредственно командой $ORIGIN. В записи SOA указано имя домена без точки на конце, что означает, что оно будет расширено именем kiae.su. Следующие две записи определяют серверы доменных имен для данного домена. Но эти серверы расположены в другой зоне. В принципе named способен найти их IP-адреса, но из соображений большей надежности эти две записи сопровождаются "приклеенными" записями. При чем для каждого из серверов определяется домен (команда $ORIGIN) и за тем имя и IP-адрес по записи A. Наличие данных блоков записей заставляет администратора снова определить в качестве текущего домена домен polyn.kiae.su. После этого следует блок записей для которых указан в качестве имени символ "*". Дело в том, что в данной подсети существует несколько машин, которые поддерживают почтовые ящики пользователей, поэтому записи MX при этом символе определяют порядок прохождения почтовых сообщений внутрь домена.
Первая машина домена - ns.polyn.kiae.su. Фактически, это тоже "приклеенная" запись, т.к. это имя уже встречалось раньше. В след за ним определено несколько записей CNAME. Исторически сложилось так, что во многих страницах World Wide Web ссылки стоят на polyn.net.kiae.su, поэтому это имя также должно быть сохранено, но в новых редакциях используется синоним www.polyn.kiae.su.
Далее в домене есть две машины, которые являются почтовыми серверами для пользователей этого домена: kurm и olga.
Файлов "обратных" зон в данном случае определено два: 160.206.144.in-addr.arpa и 192.206.144.in-addr.arpa. Сделано это из-за того, что в данном случае домен определен на двух различных подсетях сети класса B. В принципе, если бы в данный домен были выделены машины не всей подсети, а только ее частей, то для адресов 144.206.160.0, 144.206.161.0, 144.206.162.0 и т.д. до 144.206.192.0 следует описывать "обратные" зоны. При этом каждую из них надо прописывать и в домене старшего уровня, которым в данном случае является 206.144.in-addr.arpa. Рассмотрим примеры описания этих доменов:
$ORIGIN 206.144.in-addr.arpa.
160 IN SOA kiae-gw.kiae.su. root.kiae-gw.kiae.su. (
22 3600 300 9999999 3600 )
IN NS polyn.net.kiae.su.
$ORIGIN net.kiae.su.
polyn IN A 144.206.160.32
IN A 144.206.130.137
$ORIGIN 206.144.in-addr.arpa.
160 IN NS ns.kiae.su.
$ORIGIN kiae.su.
ns IN A 144.206.130.3
$ORIGIN 160.206.144.in-addr.arpa.
53 IN PTR lenya.polyn.kiae.su.
40 IN PTR apollo.polyn.kiae.su.
54 IN PTR kagan.polyn.kiae.su.
; The rest of the domain should be placed below
Данный файл начинается также, как и описание "прямой" зоны, в нем присутствуют те же "приклеенные" записи для описания серверов доменных имен. Это обстоятельство заставляет снова вводить команды $ORIGIN. Весь остаток файла состоит только из записей типа PTR.
Аналогично выглядит и файл 192.206.144.in-addr.arpa:
$ORIGIN 206.144.in-addr.arpa.
192 IN SOA kiae-gw.kiae.su. root.kiae-gw.kiae.su. (
23 3600 300 9999999 3600 )
IN NS polyn.net.kiae.su.
$ORIGIN net.kiae.su.
polyn IN A 144.206.160.32
IN A 144.206.130.137
$ORIGIN 206.144.in-addr.arpa.
192 IN NS ns.kiae.su.
$ORIGIN kiae.su.
ns IN A 144.206.130.3
$ORIGIN 192.206.144.in-addr.arpa.
6 IN PTR kaverin.polyn.kiae.su.
7 IN PTR kost.polyn.kiae.su.
1 IN PTR quest.polyn.kiae.su.
33 IN PTR vovka.polyn.kiae.su.
2 IN PTR olga.polyn.kiae.su.
34 IN PTR paul.polyn.kiae.su.
3 IN PTR nata.polyn.kiae.su.
254 IN PTR temp.polyn.kiae.su.
4 IN PTR demin.polyn.kiae.su.
5 IN PTR georg.polyn.kiae.su.
Как видно из этого примера, записи вовсе не обязательно располагать в порядке нумерации, хотя это и более удобно. Более того, в файле "прямой" зоны также не надо соблюдать порядок или группировать записи по подсетям. Однако, такое группирование облегчает администратору чтение своего файла описания зоны. Важно еще посоветовать чаще использовать комментарии. Особенно если сеть распределена по различным зданиям и администратору необходимо связываться с ответственными за сеть в каждом из этих зданий. Включение телефонов, имен, отчеств и фамилий этих людей в комментарии поможет легко их найти.
3.1.7.3. Делегирование поддомена внутри домена
Рассмотрим последний пример - делегирование поддомена внутри домена. Данная ситуация возникает в том случае, когда организация растет и обслуживание всего домена становится довольно трудоемкой задачей. Собственно, проблема возникает как с администрированием - слишком много машин и пользователей, так и со скоростью ответа на запросы - слишком много запросов к одному серверу, что плохо сказывается на его реактивности.
При делегировании домена определяется машина, на которой будет установлен primary сервер для нового поддомена, определяется место размещения secondary сервера и делаются соответствующие изменения в файле настроек primary сервера вышестоящего домена.
Рассмотрим такое делегирование на следующем примере: в домене kiae.su делегируется зона kiae.su. Пример описания этой зоны мы рассматривали в предыдущем примере. Поэтому в данном примере мы рассмотрим только описание зоны kiae.su и только записи касающиеся поддомена polyn.kiae.su, т.к. полное описание домена будет занимать 23 страницы.
Пример делегирования зоны:
$ORIGIN su.
kiae IN SOA ns.kiae.su. noc.relcom.eu.net. (
3000302 28800 3600 3600000 86400 )
IN NS ns.kiae.su.
; List of NS records and MX records for domen kiae.su.
......
$ORIGIN kiae.su.
hytelnet IN A 193.125.152.10
gopher IN A 193.125.152.10
archie IN A 193.125.152.10
$ORIGIN net.kiae.su.
polyn IN A 144.206.130.137
IN A 144.206.160.32
; Other records
...
polyn IN NS polyn.net.kiae.su.
; The rest of the description of the descriptionkiae.su zone.
.....
В данном примере следует обратить внимание на следующие особенности описания. Во-первых, при описании сервисов hytelnet, goher и archie не используется записи типа CNAME. Для всех этих доменных имен указан один и тот же IP-адрес. Во-второых, при описании делегированной зоны сначала указана запись типа A для машины polyn.net.kiae.su. Это primary сервер зоны polyn.kiae.su. Для этой же зоны могут быть также указаны и secondary серверы данной зоны. Как видно из описания машины polyn.net.kiae.su, ей соответствует два IP-адреса. В данном случае это не адреса синонимы на одном и том же порте, а адреса разных интерфейсов данной машины, т.к. она является шлюзом локальной подсети.
Приведенного выше описания достаточно для того, чтобы при помощи нерекурсивных опросов серверов, resolver или сервер нашли нужный IP-адрес.
"Обратная" зона прописывается точно также. Это значит, что зона 160.206.144.in-addr.arpa должна быть прописана в зоне 206.144.in-addr.arpa. Термин "прописать" означает выполнение следующих операций: в зоне должна быть определена подзона и машина-сервер этой подзоны, т.е. указана "приклеенная" запись для этой машины, в зоне должна быть указана запись типа NS для выделяемой подзоны.
В домене vega.ru сервер зоны определялся в самой зоне vega.ru, в случае с зоной polyn.kiae.su, сервер расположен в другом домене - net.kiae.su. Однако это не мешает управлять зоной. В принципе, используя команды $ORIGIN можно опредлить зоны внутри домена и в том же файле, что и описание самого домена. Собственно в нашем примере так оно и сделано: домен net.kiae.su определен в файле описания домена kiae.su.
Теперь от примеров описания зон перейдем к средствам контроля за размещенными зонами.
3.1.8. Программа nslookup
Описать зону - это только полдела. После установки следует убедиться, что все работает нормально. Другой случай, когда необходим контроль за работой сервера DNS - жалобы пользователей. При этом смотреть свои собственные файлы дело бесполезное, т.к. в них скорее всего ошибок нет, т.к. сервер эксплуатируется уже некоторое время. Едиственный способ убедиться в том, что все работает так, как надо - проиметировать работу системы, взаимодействующей с сервером. Именно эту задачу и решает программа nslookup.
Программа может использоваться в интерактивном режиме и в режиме генерации отчета о разовом запросе. Наиболее часто используют интерактивный способ тестирования. Для интерактивного тестирования достаточно просто вызвать программу по имени при этом в качестве сервера будет взят сервер, указанный в файле конфигурации resolver:
/usr/paul>nslookup > 144.206.192.1 Server: arch.kiae.su Address: 144.206.136.10 Name: quest.polyn.kiae.su Address: 144.206.192.1 >exit
В данном конкретном примере цель запроса состояла в получении имени машины по ее IP-адресу. Возможна и обратная операция, т.е. получение IP-адреса по имени:
/usr/paul>nslookup > polyn.net.kiae.su Server: arch.kiae.su Address: 144.206.136.10 .... Address: 144.206.192.1 >exit
Однако, тестирование имен с локального сервера только проверяет как resolver работает с этим локальным сервером. Для того, чтобы проверить, как имена вашего домена разрешаются с другого сервера доменных имен, следует изменить текущий сервер доменных имен, используемый nslookup в качестве первого при разрешении доменного имени:
> server vega.ru Default Server: vega.ru Address: 194.226.43.1 >
В данном случае в качестве текущего сервера выбран сервер vega.ru. После изменения адреса текущего сервера можно снова проверить адреса имен вашего домена на доступность для сервиса доменных имен.
При помощи nslookup можно посмотреть содержание записей базы данных описания зоны. Делается это несколькими способами. Первый из них - это установка типа записей:
> set querytypa=SOA
> polyn.kiae.su
Server: vega.ru
Address: 194.226.43.1
polyn.kiae.su
origin = polyn.net.kiae.su
mail addr = paul.kiae.su
serial = 36
refresh = 3600 (1 hour)
retry = 300 (5 mins)
expire = 9999999 (115 days 17 hours 46 mins 39 secs)
minimum ttl = 3600 (1 hour)
polyn.kiae.su nameserver = polyn.net.kiae.su
polyn.kiae.su nameserver = ns.kiae.su
>
В данном случае установлен тип записи для просмотра - SOA, после этого задано имя polyn.kiae.su. В этовет на этот запрос сервер нашел другой сервер, в зону ответственности которого входит данное имя и распечатал запись SOA для этой зоны. При этом все поля распечатываются в понятном для чтения виде.
Другой способ заключается в том, чтобы исполбзовать команду ls:
>ls -t soa polyn.kiae.su .... список записей зоны ..... >
Если необходимо проконтролировать работу сервера и resolver, то в этом случае имеет смысл включить режим отладки - debug:
> set debug
> 1.192.206.144.in-addr.arpa.
Server: ns.kiae.su
Address: 144.206.130.3
------------
Got answer:
HEADER:
opcode = QUERY, id = 20, rcode = NOERROR
header flags: response, auth. answer, want recursion, recursion avail.
questions = 1, answers = 1, authority records = 0, additional = 0
QUESTIONS:
1.192.206.144.in-addr.arpa, type = ANY, class = IN
ANSWERS:
-> 1.192.206.144.in-addr.arpa
name = quest.polyn.kiae.su
ttl = 3600 (1 hour)
------------
1.192.206.144.in-addr.arpa
name = quest.polyn.kiae.su
ttl = 3600 (1 hour)
>
В данном случае запрашивается имя по "обратному" запросу. Программа транслирует сам запрос и способ его исполнения. Для более сложных запросов трасса может составлять несколько экранов.
3.1.9. DNS и безопасность
В сентябре 1996 года многие компьютерные издания Москвы опубликовали материал, в котором рассматривался случай подмены доменных адресов World Wide Web сервера агенства InfoART, что привело к тому, что подписчики этого сервиса в течении некоторого времени вместо страниц этого агенста просматривали картинки "для взрослых".
Администрирование DNS осуществляла компания Demos, поэтому пресс-конферению по поводу этого случая Demos и InfoArt проводили совместно. Разъяснения провайдера главным образом свелись к тому, что в базе данных DNS самого Demos никаких изменений не проводилось, а за состояние баз данных secondary серверов Demos ответственности не несет. Почему такое заявление вполне оправдывает провайдера?
Как было указано раньше, обслуживание запросов на получение IP-адресов по доменным именам, а именно об этом идет речь в случае InfoArt, осуществляется не одним сервером доменных имен, а множеством серверов. Все secondary серверы копируют базу данных с primary сервера, но делают они это с достаточно большими интервалами, иногда не чаще одного раза в двое суток. Запрос разрешает тот сервер, который быстрее откликается на запрос клиента. Таким образом, если подправить информацию на secondary сервере о базе данных primary сервера, то можно действительно на время между копированиями описания зоны заставить пользователей смотреть совсем не то, что нужно. Таким образом, практически все провайдеры попадают в категорию неблагонадежных. Но провайдеры также могут оказаться не при чем. В принципе, любой администратор может запустить у себя на машине named и скопировать зону с primary сервера, не регистрируя ее в центре управления сетью. Это обычная практика, т.к. разрешение имен - главный тормоз при доступе к удаленной машине, и часто по timeout прерывается работа с ресурсом из-за невозможности быстрого разрешения имени. Таким образом, все администраторы сети попадают в потенциальных злоумышленников. Но на самом деле существуют еще и другие способы. Например, кэш re-solver или сервера имен. Если время хранения записи в кэше большое, то сервер или resolver не будут обращаться к удаленному серверу вообще, а будут брать записи из кэша. Вмешаться в структуру данных кэша также возможно, а это значит, что можно и увеличить время хранения записи. Если организация- подписчик пользуется для доступа в сеть proxy-сервером, а это также обычная практика, то достаточно поправить кэш этого proxy и все пользователи этой организации будут ходить туда, куда их направит поправленная запись.
Существует несколько способов ограничения этого произвола. Первый из них - это точное знание IP-адресов ресурсов. В этом случае можно проверить состояние ресурса и выявить причину ошибки. Второй сопособ, запретить копировать описание зоны кому не поподя. Современные программы named позволяют описывать IP-адреса сетей, из которых можно копировать зоны. Правда такая политика должна быть согласована с другими владельцами зоны, в противном случае зону скопируют с secondary сервера. И наиболее мягкое средство - уменьшение времени хранения записей в кэше.
Для защиты можно использовать и фильтрацию пакетов. Зоны раздаются только по 53 порту TCP, в отличии от простых запросов. Если определить правила работы по этому порту, используя межсетевой фильтр, то можно и ограничить произвол при копировании информации с сервера доменных имен. Вообще, не стоит относиться к сервиру доменных имен легкомысленно. Следует учитывать тот факт, что используя этот сервис, можно выявить структуру вашей локальной сети.
Назад | Содержание | Вперед