База данных DNS
Категория: Система доменных имен | Автор: admin | 30-04-2010, 03:22 | Просмотров: 3626

База данных DNS для каждого домена представляет собой набор текстовых файлов, которые системный администратор ведет на главном сервере имен этого домена. Часто их называют зонными файлами. В них содержатся элементы двух типов: директивы синтаксического анализатора (например, $ORIGIN и $TTL) и записи о ресурсах. Первые не являются частью базы данных, а предназначены для упрощения ввода записей.

В этом разделе мы сначала познакомимся с форматами записей о ресурсах, которые регламентируются документами RFC882, 1035, 1183, 2065, 2181, 2308 и 2535.

 

Записи о ресурсах

 

С каждой зоной в иерархии DNS связан набор записей о ресурсах (он может быть пустым). Вот базовый формат записи:

[имя]   [ttl]   [класстип данные

 

Поля разделяются знаками табуляции или пробелами и могут содержать специальные символы (табл. 16.8).

Таблица 16.8. Специальные символы, используемые в записях о ресурсах

Символ

Назначение

;

Начало комментария

@

Имя текущего домена

()

Позволяет данным занимать несколько строк

*

Метасимвол1 (только в поле имя)

1   Дополнительно об этом метасимволе будет рассказываться при описании записей MX.

 

Поле имя обозначает объект (обычно узел или домен), к которому относится данная запись. Если несколько последовательно расположенных записей ссылаются на один и тот же объект, то после первой записи поле имя можно опустить. Данное поле должно начинаться в первой колонке, если она присутствует.

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

Например, в домене cs.colorado.edu имя anchor будет проинтерпретировано как "anchor.cs.colorado.edu.". Если же ввести имя anchor.cs.colorado.edu, то отсутствие точки в конце также будет подразумевать относительное имя к которому следует добавить стандартный домен, что в итоге даст имя "anchor.cs.colorado.edu.cs.colorado.edu.". Такие ошибки встречаются очень часто и могут оставаться необнаруженными довольно долго.

В поле ttl (Time То Live — время жизни) задается время (в секундах), в течение которого элемент данных может оставаться в кэше и при этом считаться достоверным. Это поле часто опускают, но оно обязательно присутствует в файле, содержащем корневые "подсказки". Стандартное значение поля задается директивой $TTL, размещаемой в начале зонного файла. В BIND 9 эта директива обязательна. В BIND 8, если она отсутствует поле ttl определяется отдельно для каждой зоны на основании значения, задаваемого в записи SOA.

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

В поле класс задается тип сети. Распознаются три значения: IN (Internet i СН (Chaos) и HS (Hesiod). Класс Chaos обозначает ChaosNet — почти исчезнувший сетевой протокол, ранее применявшийся на Lisp-машинах фирмы Symbolics. Hesiod — это информационная служба, являющаяся надстройкой пакета BIND. Класс IN установлен по умолчанию, но даже несмотря на это, он, как правило, явно указывается в зонных файлах. В настоящее время лишь один элемент данных скрыт в пределах класса Chaos: номер версии демона named, который можно узнать с помощью программы dig (см. параграф 16.6).

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

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

 

Содержимое поля данные зависит от типа записи (табл. 16.9).

 

Таблица 16.9. Типы записей DNS

 

Тип

Содержимое/назначение

Зонные

SOA

NS

Определение DNS-зоны

Определение серверов зоны, делегирование полномочий поддоменам

Базовые

А

АААА

А6

PTR

DNAME

 

MX

Преобразование имени в адрес

Устарела и не должна использоваться

Преобразование имени в адрес IPv6 (только в BIND 9)

Преобразование адреса в имя

Передача полномочий при обратном преобразовании адресов IPv6 (только в BIND 9)

Маршрутизация электронной почты

Аутентификационные

KEY

NXT

 

SIG

Открытый ключ шифрования для DNS-имени

Указание на следующую запись зонной базы данных при обработке отрицательных ответов в протоколе DNSSEC

Сигнатура зоны

Факультативные

CNAME

LOC

RP

SRV

TXT

Дополнительные имена узла

Географическое местоположение и физический размер DNS-объекта1

Контактная информация для связи с администратором узла

Местоположение известных сервисов в пределах домена

Комментарии или нестандартная информация

1   Существуют проблемы с поддержкой записи LOC в NT (запрос к записи LOC приводит к краху сервера NT).

 

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

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

Подробно описывая все типы записей о ресурсах, мы рассмотрим в качестве примера записи из базы данных домена cs.colorado.edu. Поскольку домен по умолчанию — cs.colorado.edu, то имя машины anchor в действительности означает anchor.cs.colorado.edu.

 

Запись SOA

 

Запись SOA отмечает начало зоны — группы записей о ресурсах, расположенных в одной области пространства имен DNS. Этот узел дерева DNS также называют точкой делегирования. Как будет показано ниже, домен DNS обычно соответствует минимум двум зонам; одна служит для преобразования имен компьютеров в IP-адреса, а остальные — для обратного преобразования.

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

 

; Начало зоны для домена cs.colorado.edu

@         IN   SOA   ns.cs.colorado.edu.    admin.cs.colorado.edu.   (

1999121501          ;Порядковый номер

21600               ;Период обновления, 6 часов

1800                ;Интервал между попытками, 30 минут

1209600             ;Период устаревания, 2 недели

7200 )              ;Минимальное время жизни, 2 часа

 

 

Поле имя содержит символ @, обозначающий имя текущей зоны. В данном примере можно было вместо этого символа использовать cs.colo-rado.edu. Текущее имя задается в инструкции zone файла named.conf и может быть изменено в зонном файле посредством директивы $ORIGIN (см. описание записи DNAME).

В показанном фрагменте поле ttl отсутствует. Класс зоны — IN (Internet), тип записи — SOA, а остальные элементы составляют поле данные.

Имя "ns.cs.colorado.edu." ссылается на главный сервер имен этой зоны. Имя "admin.cs.colorado.edu." указывает адрес электронной почты для контактов с администратором домена. Адрес дан в формате "пользователь.узел." (а не пользователь@узел). Если необходимо отправить сообщение администратору, просто замените первую точку знаком @ и уберите хвостовую точку. Вместо реального регистрационного имени часто используется псевдоним, например admin или hostmaster.

Круглые скобки позволяют растянуть запись SOA на несколько строк. Их размещение не произвольно в BIND 4 и 8: мы попробовали укоротить первую строку, разделив ее перед контактным адресом, но демон named не смог распознать такую запись. В некоторых реализациях круглые скобки распознаются только в записях SOA и ТХТ В BIND 9 улучшенный модуль синтаксического анализа, поэтому круглые скобки могут использоваться везде.

Первый числовой параметр — это порядковый номер конфигурационных данных зоны. С его помощью подчиненные серверы определяют, когда следует брать новые данные. Порядковым номером может быть любое 32-разрядное целое число, причем оно должно увеличиваться при каждом изменении зонного файла. Во многих организациях в этот номер зашифровывается дата последней модификации файла. Например, 2000123101 означает, что первое изменение в зонном файле было сделано 31-го декабря 2000 г.

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

Существует три способа решения этой проблемы. В BIND 4.9 и BIND 8 есть прием, который позволяет сбросить порядковый номер в нуль на один интервал обновления, а затем заново начать нумерацию. Нулевой номер всегда вызывает обновление, поэтому не забудьте присвоить ему нормальное значение после того, как все подчиненные серверы загрузят зонные данные. Более утомительный способ — изменить порядковый номер на главном сервере, уничтожить процессы named на подчиненных серверах, удалить их резервные базы данных, а затем перезапустить их. При отсутствии кэша подчиненные серверы вынуждены будут повторно загрузить базы данных с главного сервера. Третий способ — воспользоваться особенностями последовательного пространства, из которого выбираются порядковые номера. Суть заключается в том, что к имеющемуся номеру добавляется "магическое" число, все подчиненные серверы обновляют свои данные, после чего устанавливается требуемый номер. Подробнее об этом рассказывается в документе RFC 1982.

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

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

Первый элемент — период обновления данных. Он показывает, как часто подчиненные серверы должны связываться с главным сервером и проверять, не изменился ли порядковый номер конфигурации зоны. Если зонные данные изменились, подчиненные серверы должны обновить свои копии базы данных. Общепринятые значения для данного интервала — от одного до шести часов (3600 — 21600 секунд).

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

Если подчиненный сервер пытается узнать порядковый номер у главного сервера, а тот не отвечает, то по истечении определенного интервала будет сделана повторная попытка. Наш опыт показывает, что наиболее подходящее значение для второго элемента — от 20 до 60 минут (1200 — 3600 секунд).

Если главный сервер длительное время отключен, то подчиненные серверы будут многократно пытаться обновить свои данные, однако безуспешно. В конце концов все подчиненные серверы решат, что главный сервер не включится никогда и его данные наверняка устарели. Период устаревания определяет, как долго подчиненные серверы будут продолжать обслуживать домен в отсутствие главного сервера. Система должна просуществовать, даже если главный сервер не работает неделю, поэтому третьему элементу следует присваивать большое значение. Мы рекомендуем выбирать интервал от недели до месяца.

До появления BIND 8.2 четвертый элемент задавал стандартное время жизни записей о ресурсах. Он включался в каждую запись и использовался для проверки устаревания записей на неавторитетных серверах. В BIND 8.2 значение этого параметра в записи SOA изменилось. Теперь он определяет длительность нахождения в кэше отрицательных ответов. Время жизни положительных ответов (т.е. собственно записей) устанавливается директивой $TTL в начале зонного файла. Как свидетельствует практика, значение $TTL должно быть от нескольких часов до нескольких дней, а минимальное время жизни — один-два часа (предельное значение — три часа).

Значение $TTL, период устаревания и минимальное время жизни в конечном итоге заставляют всех пользователей DNS удалять старые данные. Изначально архитектура DNS основывалась на том факте, что данные об узлах относительно стабильны и меняются нечасто. Но с появлением протокола DHCP и портативных компьютеров все перевернулось. Теперь разработчики пакета BIND отчаянно пытаются угнаться за временем, внедряя механизмы инкрементных зонных пересылок и динамического обновления (описаны в параграфе 16.12).

 

Записи NS

 

Записи NS описывают серверы имен, которые авторитетны для данной зоны (т.е. все главные и подчиненные серверы), а также делегируют полномочия по управлению поддоменами другим организациям. Обычно эти записи следуют за записью SOA. Их формат таков:

зона [ttl]   IN   NS   имя_узла
 

 

Например:

 

cs.colorado.edu.    IN   NS   ns.cs.colorado.edu.

cs.colorado.edu.    IN   NS   anchor.cs.colorado.edu.

cs.colorado.edu.    IN   NS   nc.cs.utah.edu.

 

 

Если имя зоны совпадает с полем имя записи SOA, которая идет перед записями NS, поле зона можно оставить пустым. Поэтому строки

 

IN   NS     ns.cs.colorado.edu.

IN   NS     anchor.cs.colorado.edu.

IN   NS     nc.cs.utah.edu.

 

 

стоящие после записи SOA для зоны cs.colorado.edu, будут эквивалентны приведенным выше.

Следует указывать все авторитетные серверы имен домена cs.colorado.edu. причем это нужно делать как в зонном файле данного домена, так и в файле родительской зоны, т.е. colorado.edu. Кэширующие серверы не могут быть авторитетными, поэтому их приводить не нужно. В записи NS нет ключевого слова, которое указывало бы тип сервера (главный или подчиненный). Эта информация находится в файле named.conf.

На основании записей NS зоны демон named находит подчиненные серверы, когда ему нужно разослать уведомления об изменении зонных данных. Те же самые записи, присутствующие в описании родительской зоны (colorado.edu), определяют поддомен "cs" и передают полномочия по его управлению серверам имен факультета вычислительной техники. Если список серверов имен в описании родительской зоны не совпадает с аналогичным списком самой зоны, то любой новый сервер становится невидимкой и не используется для ответов на запросы из внешнего мира. Подобные ситуации иногда возникают вследствие ошибок проектирования, иногда — из-за забывчивости.

Беглый взгляд на информацию о делегировании в нашей собственной сети позволил обнаружить крупный сервер домена colorado.edu, о котором домен "edu" ничего не знал. Иногда стоит проверять информацию о делегировании с помощью программы nslookup или dig, чтобы убедиться в наличии правильного набора серверов.

 

 

Записи А

 

Записи А являются основной частью базы данных DNS. Они обеспечивают перевод имен компьютеров в IP-адреса (процедура, ранее выполнявшаяся в файле /etc/hosts). Для каждого из сетевых интерфейсов компьютера должна существовать одна запись А. Эта запись имеет следующий формат:

имя_узла [ttl]  IN А IP-адрес
 

 

Например:

anchor     IN   A    128.138.243.100

 

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

 

Записи PTR

 

Записи PTR выполняют обратное преобразование IP-адресов в доменные имена. Как и в случае с записями А, для каждого сетевого интерфейса компьютера должна быть сделана одна запись PTR. Но прежде чем знакомиться с этими записями, давайте немного отвлечемся и поговорим о специальном домене верхнего уровня, который называется in-addr.arpa.

Полностью определенные имена компьютеров можно рассматривать как структуру, в которой наиболее "значащая" часть стоит справа. Например, в имени anchor.cs.colorado.edu узел anchor принадлежит домену "cs", последний находится в домене "colorado", а тот — в домене "edu". С другой стороны, в IP-адресах самая "значащая" часть стоит слева. В адресе 128.138.243.100 узел 100 находится в подсети 243, которая является частью сети 128.138.

Домен in-addr.arpa был создан с той целью, чтобы и для прямых, и для обратных преобразований использовался один и тот же набор программных модулей и единое дерево имен. Домены в ветви in-addr.arpa именуются как IP-адреса с обратным порядком следования байтов. Например, зона для нашей подсети 243 называется 243.138.128.in-addr.arpa.

Общий формат записи PTR таков:

адрес [ttl] IN PTR имя_узла

 

Запись PTR в зоне 243.138.128.in-addr.arpa, соответствующая приведенной выше записи А для узла anchor, будет иметь такой вид:

100     IN    PTR   anchor.cs.colorado.edu.

 

Имя 100 не заканчивается точкой и потому является относительным. Вопрос: относительно чего? Ни в коем случае не относительно домена "cs.colorado.edu.". Для того чтобы эта запись была точной, домен по умолчанию должен называться "243.138.128.in-addr.arpa.".

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

100.243    IN    PTR   anchor.cs.colorado.edu.

 

с доменом 138.128.in-addr.arpa по умолчанию. В некоторых организациях все записи обратного преобразования помещаются в один файл, а задание подсети осуществляется посредством директивы $ORIGIN. Обратите внимание на то, что имя anchor.cs.colorado.edu должно оканчиваться точкой, иначе к нему будет добавлена строка 138.128.in-addr.arpa.

Поскольку cs.colorado.edu и 243.138.128.in-addr.arpa — разные области пространства имен DNS, они составляют две отдельные зоны. У каждой из этих зон должна быть своя запись SOA и свои записи о ресурсах. Помимо определения зоны in-addr.arpa для каждой реальной сети, нужно также задать зону, которая заботилась бы об интерфейсе обратной связи, 127.0.0.0.

Описанные привязки прекрасно работают, когда маски подсетей проходят по границе байтов. Но как выполнять обратные преобразования для такой подсети, как 128.138.243.0/26? В документе RFC2317 описан красивый прием, основанный на применении записей CNAME; подробнее об этом речь пойдет ниже.

Обратные преобразования, выполняемые записями PTR, используются всеми программами, которые аутентифицируют входящий сетевой трафик. Например, демон sshd допускает удаленную регистрацию без пароля, если исходная машина указана по имени в пользовательском файле ~/.shosts. Когда машина-адресат получает запрос на установление соединения, она знает машину-отправитель только по IP-адресу. Пользуясь услугами DNS, она преобразовывает IP-адрес в имя, которое сравнивается с содержимым соответствующего файла. Программы netstat, tcpd, sendmail, sshd, syslogd, fingerd, ftpd, rlogind — все они получают имена компьютеров из IP-адресов с помощью обратного преобразования.

Важно, чтобы записи А соответствовали записям PTR. Несовпадение и отсутствие последних приводит к ошибкам аутентификации и тайм-аутам, в результате чего система замедляет работу. Это само по себе неприятно, но еще хуже то, что появляется почва для атак типа "отказ от обслуживания", направленных на любое приложение, требующее соответствия записям А или А6 при обратном преобразовании.

 

Записи MX

 

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

 

 

Запись MX имеет следующий формат:

имя [ttl]  IN  MX  приоритет узел ...

 

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

 

piper       IN   MX   10   piper

            IN   MX   20   mailhub

            IN   MX   50   boulder.colorado.edu.

xterml      IN   MX   10   mailhub

            IN   MX   20   anchor

            IN   MX   50   boulder.colorado.edu.

 

 

Сначала опрашиваются узлы с низким приоритетом (наиболее предпочтительный приоритет — 0; самый нежелательный — 65535). В данном случае почта, адресованная пользователю bob@xterml, будет маршрутизироваться следующим образом. Если доступен концентратор mailhub, почта отправляется туда; в противном случае она посылается на машину anchor. Если оба отключены, почта направляется на узел boulder. При этом имя узла boulder должно быть полностью определенным, поскольку он не является членом стандартного домена (в данном примере — "cs.colorado.edu.").

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

Записи MX полезны во многих ситуациях, например:

  • если в системе есть центральный концентратор почты;
  • если машина-адресат выключена;
  • если адресат не подключен к Internet;
  • если машина-адресат не понимает протокол SMTP;
  • если локальный системный администратор лучше знает, куда следует посылать сообщения.

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

Если компьютер не подключен к Internet, у него не может быть записи А в DNS, но могут быть записи MX. Система sendmail не способна установить непосредственное соединение с адресатом, но может переслать почту поближе к нему, связавшись с одним из узлов, указанных в записях MX. Такой узел, вероятно, напрямую подключен к машине-адресату или знает, как получить к нему доступ (к примеру, через брандмауэр или по протоколу UUCP).

В конце концов, записи MX могут применяться просто потому, что локальные системные администраторы гораздо лучше знают организацию почтовой системы, чем те, кто присылает в организацию письма. За администраторами остается право определять, по каким каналам распространяются почтовые потоки.

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

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

У самого домена должна быть запись MX для узла-концентратора, чтобы можно было посылать почту по схеме пользователь@домен. Естественно, такая конфигурация требует наличия уникальных пользовательских имен на всех компьютерах данного домена. Чтобы иметь возможность посылать почту пользователю evi@cs.colorado.edu, нам нужна либо машина cs, либо записи MX в домене cs.colorado.edu:

 

cs      IN   MX    10   mailhub.cs.colorado.edu.

        IN   MX    20   anchor.cs.colorado.edu.

        IN   MX    50   boulder.colorado.edu.

 

 

Компьютер, принимающий почту для другого узла, должен содержать его имя в файлах конфигурации sendmail. В параграфе 19.8 будет рассказываться о средстве use_cw_file и файле local-host-names, используемых в sendmail для этих целей.

В базе данных DNS иногда можно встретить метазаписи MX:

*       IN   MX    10   mailhub.cs.colorado.edu.

 

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

Следовательно, нельзя использовать звездочку с целью задания какого-либо стандартного значения для всех своих компьютеров. Можно — что неправильно — задать посредством нее маршрут для "чужих" машин. В результате на концентратор будет поступать масса почтовых сообщений, тут же отвергаемых по той причине, что имя узла, обозначенное звездочкой, не принадлежит данному домену. Посему следует избегать употребления метасимвола в записях MX.

 

Записи CNAME

 

Записи CNAME позволяют назначать узлу дополнительные мнемонические имена. Псевдонимы широко применяются для закрепления за компьютером какой-либо функции либо просто для сокращения имени. Реальное имя иногда называют каноническим. Вот несколько примеров:

 

ftp    IN    CNAME    anchor

Kb     IN    CNAME    kibblesnbits

 

 

Запись CNAME имеет следующий формат:

псевдоним  [ttl]   IN CNAME имя_узла

 

Когда DNS-модуль обнаруживает запись CNAME, он перестает посылать запросы по мнемоническому имени и переключается на реальное имя. Если у компьютера есть запись CNAME, то другие записи для данного узла (А, MX, NS и др.) должны ссылаться на его реальное имя, а не на мнемоническое. Например, строки

 

colo-gw    IN     А        128.138.243.25

moogie     IN     CNAME    colo-gw

www        IN     CNAME    moogie

 

 

являются правильными. Но если связать адрес или почтовый приоритет (посредством записей А и MX) с именем www или moogie, то это будет неверно.

В BIND длина цепочки записей CNAME не должна быть больше восьми. Цепочка — это ситуация, когда одна запись CNAME ссылается на другую, та — на третью и т.д. Последним, восьмым элементом должна быть реальная запись А.

В некоторых организациях делается попытка посредством записей CNAME обеспечить распределение нагрузки. Открытое имя Web-сервера связывается с несколькими компьютерами:

 

www    IN    CNAME    webl

www    IN    CNAME    web2

www    IN    CNAME    web3

 

 

Подобное применение записей CNAME является нестандартным. По сути, оно запрещено, так как противоречит спецификации. В BIND 8 есть специальный параметр, разрешающий данный механизм. Пакет BIND 9 более требователен, поэтому лучше не пользоваться множественными записями CNAME. Лучше создать для Web-сервера несколько записей А, ссылающихся на разные компьютеры.

 

Специальное применение записей CNAME

 

С помощью записей CNAME можно организовать поддержку зон обратного преобразования для сетей, где маски подсетей не проходят по границе байтов. До того как протокол CIDR получил широкое распространение, такая организация подсетей не применялась или, по крайней мере, "неправильные" подсети существовали в рамках одной организации, поэтому управлять зонами обратного преобразования было несложно. Например, если сеть 128.138 класса В разделить на группу подсетей класса С, то каждая подсеть займет свое строго оговоренное место в домене in-addr.arpa. Зоной обратного преобразования для подсети 243 будет 243.138.128.in-addr.arpa.

 

 

Но что произойдет, если подсеть 243 разделить еще, допустим, на четыре подсети /26? Если все они находятся в пределах одной организации, то это не проблема: такие подсети по-прежнему описываются в одном файле, содержащем все их записи PTR. Но может быть так, что подсеть 243 принадлежит провайдеру Internet, который делегирует подсети /26 разным клиентам. В этом случае решение будет более сложным. Провайдер должен либо управлять записями зон обратного преобразования на стороне каждого клиента, либо найти способ разделить третий байт IP-адреса (в данном примере — 243) на четыре разных элемента, каждый из которых делегируется независимо.

Когда административная граница проходит посередине байта, приходится быть изворотливым. Нужно также тесно взаимодействовать с доменом, находящимся выше или ниже в иерархии. Решение может быть следующим: для каждого возможного адреса узла в зоне in-addr.arpa следует добавить запись CNAME, которая переводит операцию поиска в зону, управляемую владельцем соответствующей подсети. Подобная схема приводит к образованию громоздких зонных файлов в родительском домене, но она же позволяет передавать полномочия реальным пользователям каждой подсети.

Рассмотрим описываемый процесс детальнее. Родительская организация (в нашем случае — провайдер) создает для каждого возможного IP-адреса записи CNAME со специальным искусственным компонентом (отделяется точкой), представляющим подсеть. Например, для первого из четырех блоков адресов подсети /26 дополнительный компонент будет называться "0-63", для второго — "64-127" и т.д.. Вот как это выглядит:

 

$ORIGIN 243.138.128.in-addr.arpa.

1    IN    CNAME    1.0-63

2    IN    CNAME    2.0-63

...

63   IN    CNAME    63.0-63

64   IN    CNAME    64.64-127

65   IN    CNAME    65.65-127

...

 

 

Чтобы передать управление адресами 0-63 зоны обратного преобразования клиенту, за которым закреплена эта подсеть, нужно добавить следующие записи NS:

 

0-63      IN   NS   nsl.customerl.com.

0-63      IN   NS   ns2.customerl.com.

 

 

На узле customerl.com будет создан зонный файл, содержащий привязку для зоны обратного преобразования 0-63.243.138.128.in-addr.arpa. Например

 

1      IN    PTR       hostl.customerl.com.

2      IN    PTR       host2.customerl.com.

 

 

Добавив дополнительный компонент, мы тем самым создали новую точку передачи полномочий. Когда, например, кто-то попытается найти доменное имя, соответствующее адресу 128.138.243.1, запись CNAME в точке 1.243.138.128.in-addr.arpa перенаправит поиск в точку 1.0-63.243.138.128.in-addr.arpa, а этим именем уже управляет реальный клиент.

Клиентские зонные файлы не содержат ничего лишнего; со всеми конфигурационными записями приходится иметь дело провайдеру. Ситуация усложняется, если клиент сам является провайдером и дальше делит свое адресное пространство. Однако непреодолимых препятствий не существует в BIND поддерживаются цепочки записей CNAME длиной до восьми элементов, а поскольку в байте, как известно, восемь битов, превышения допустимого предела не произойдет. Различные документы RFC не одобряют но и не запрещают применение таких цепочек. К негативным последствиям можно отнести то, что скорость распознавания имен замедляется, так как модуль распознавания должен пройти по каждому звену цепочки, послав соответствующее число запросов серверу.

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

Когда данная схема стала достаточно популярной, набор команд, понимаемых демоном named, пополнился директивой $GENERATE (о ней речь будет идти далее), которая упрощает создание записей о ресурсах в родительской зоне. Например, чтобы сгенерировать все необходимые записи для первой подсети, достаточно следующих строк:

 

$ORIGIN 243.138.128.in-addr.arpa.

SGENERATE  0-63  $ CNAME $.0-63

0-63       IN   NS  nsl.customerl.com.

0-63       IN   NS  ns2.customerl.com.

 

 

Метасимвол $ в директиве $GENERATE является счетчиком цикла и приводит к созданию 64-х различных записей CNAME. Остальные три подсети /26 обрабатываются аналогичным образом.

Рассмотренное применение записей CNAME поддерживается в BIND S и 9. В некоторых старых модулях распознавания пакета BIND 4 не предполагается получения записей CNAME в ответ на запрос к записям PTR. поэтому такие запросы потерпят неудачу. Это одна из причин, по которой не рекомендуется применять старые версии пакета.

 

Записи LOC

 

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

 

 

Формат записи таков:

имя [ttl] IN LOC широта долгота [высота [разм [гор_точн [верт_точн]]]]

 

Широта и долгота задаются в градусах, минутах и секундах (разделяются пробелами), после которых следует обозначение N (north — север), S (south — юг), Е (east — восток) или W (west — запад). Секунды можно опустить, допускается также указывать только градусы.

Последующие поля задаются в сантиметрах (по умолчанию) или в метрах (суффикс m). Аргумент высота — это высота объекта над уровнем моря, разм — это диаметр воображаемой сферы, окружающей объект, гор_точн — горизонтальная точность измерения, а верт_точн — вертикальная точность. По умолчанию размер равен одному метру, горизонтальная точность — 10 метров, а вертикальная — 10 километров.

Вот пример для узла caida.org, расположенного в Сан-Диего, штат Калифорния:

caida.org.    IN    LOC    32 53 01 N 117 14 25 W 107m 30m 18m 15m

 

Многие утилиты визуализации, написанные организацией CAIDA (Cooperative Association for Internet Data Analysis — совместная ассоциация по анализу данных в сети Internet), требуют наличия данных о широте и долготе, поэтому администраторам Web-узлов рекомендуется включать соответствующую информацию в свои базы данных DNS. Но не все заинтересованы в том, чтобы кто угодно знал их местоположение. В таких ситуациях можно использовать неточные значения. Они все равно представляют определенную ценность для людей, занимающихся сетевым анализом, и в то же время обеспечивают некоторую анонимность.

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

 

Записи SRV

 

Запись SRV определяет расположение сервисов в пределах домена. К примеру, эта запись может позволить запросить удаленный домен и узнать имя его FTP-сервера. Раньше в подобной ситуации приходилось действовать наугад. Можно было лишь надеяться, что администратор удаленного домена, следуя традиционной практике, добавил запись CNAME для имени "ftp" в базу данных DNS.

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

Записи SRV напоминают обобщенные записи MX с дополнительными полями, которые позволяют локальному администратору DNS управлять внешними соединениями и распределять нагрузку на сервер. Формат записей таков:

сервис.протокол.имя [ttl]  IN SRV приоритет вес порт сервер

 

Аргумент сервис — это имя сервиса, определенное в базе данных IANA (Internet Assigned Numbers Authority — агентство по выделению имен и уникальных параметров протоколов Internet); получить дополнительную информацию можно в параграфе 13.3 или по адресу www.iana.org/num-bers.htm. Аргумент протокол должен быть равен либо tcp, либо udp. Аргумент имя — это домен, на который ссылается запись SRV. Аргумент приоритет имеет тот же смысл, что и в записи MX. Аргумент вес используется для распределения нагрузки между несколькими серверами, порт — это номер порта, на котором выполняется сервис, а сервер — это имя сервера предоставляющего данную услугу. В ответ на запрос к записи SRV обычно возвращается запись А сервера. Имя сервера, равное означает, что сервис недоступен на данном узле. Если вес равен 0, то специального распределения нагрузки не требуется.

Ниже показан пример, взятый из документа RFC2052 (где определена запись SRV) и адаптированный для домена cs.colorado.edu:

 

ftp.tcp   SRV   О   0   21     ftp-server.cs.colorado.edu.

 

; доступ к сервису Finger закрыт  (имя сервера = .)

finger.tcp     SRV   О    0    79      .

 

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

; а три четверти — новым

ssh.tcp   SRV   0    1    22     old-slow-box.cs.colorado.edu.

          SRV   0    3    22     new-fast-box.cs.colorado.edu.

 

; основной сервер доступен через порт 80,

; а резервный — через порт 8000 на новом компьютере

http.tcp   SRV   0    0    80     www-server.cs.colorado.edu.

           SRV   10   0    8000   new-fast-box.cs.colorado.edu.

 

;в адресной строке можно указывать как attp://www.cs. Colorado.edu,

;так и http://cs.colorado.edu

http.tcp.www   SRV   0    0    80     www-server.cs.Colorado.edu.

               SRV   10   0    8000   new-fast-box.cs.colorado.edu.

 

;все остальные сервисы блокированы

*.tcp   SRV    0  0  0  .

*.udp   SRV    0  0  0  .

 

 

В этом примере демонстрируется применение как аргумента вес (сервис SSH), так и аргумента приоритет (сервис HTTP). Будут задействованы оба сервера SSH, причем нагрузка между ними распределяется в соответствии с производительностью серверов. Резервный сервер HTTP используется только в том случае, когда основной сервер не функционирует. Сервис finger не доступен на данном узле, как и все остальные сервисы, имена которых не упомянуты явно. Тот факт, что демон finger отсутствует в базе данных DNS, не означает, что он не выполняется; просто его нельзя найти средствами DNS.

Раньше в базе данных DNS существовала запись WKS (well-known services — известные сервисы). Вместо того чтобы переадресовывать запрашивающего на узел, который предоставляет указанный сервис в рамках домена, она содержала список всех сервисов, поддерживаемых заданным узлом. Эта запись является практически бесполезной и, к тому же, считается рискованной с точки зрения безопасности, поэтому она не получила распространения.

Компания Microsoft использует в Windows 2000 стандартные записи SRV, но способ их внедрения в базу данных DNS является нестандартным и несовместимым с документацией.

 

Записи ТХТ

 

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

IN       ТХТ    "University of СО,  Boulder Campus,  CS Dept"

 

Эта запись непосредственно следует за записями SOA и NS зоны "cs.colo-rado.edu.", наследуя таким образом от них поле имя.

Записи ТХТ используются также в сочетании с записью RP, которая содержит контактную информацию для связи с человеком, отвечающим за функционирование узла (в записи SOA указан лишь его электронный адрес).

Запись ТХТ имеет такой формат:

имя [ttl]   IN ТХТ информация ...

 

Все информационные элементы должны быть заключены в кавычки. Это может быть как одна строка, так и несколько строк, каждая из которых заключена в кавычки. Будьте предельно внимательны — пропущенная закрывающая кавычка может привести к разрушению базы данных DNS.

У записей ТХТ нет внутреннего порядка. Следовательно, не стоит пытаться добавить в базу данных единый информационный блок, представленный в виде нескольких записей ТХТ: в ответ на запрос демон named может возвращать их в произвольном порядке.

 

Записи ресурсов IPv6

 

IPv6 — это новая версия протокола IP. Процесс принятия спецификации длится уже более десяти лет. Своим появлением протокол IPv6 обязан существовавшей в то время острой потребности в дополнительных IP-адресах. Однако решения этой проблемы, считавшиеся временными, — протокол CIDR, система NAT и строгий административный контроль над адресным пространством — оказались столь успешными, что массовый переход к стандарту IPv6 вряд ли произойдет в скором будущем. Если не появится какое-нибудь суперпопулярное приложение, работающее только с IPv6 (или компания Microsoft не сделает этот протокол стандартным в Windows), то в ближайшие несколько лет системные администраторы не захотят иметь дело с иным форматом адресов. Ряд аналитиков полагает, что чаша весов склонится в пользу IPv6 благодаря новому поколению мобильных телефонов, имеющих IP-адреса.

Хотя мы не ожидаем широкого распространения протокола IPv6, будет все же полезно описать влияние 128-разрядных IP-адресов на DNS. Изменению подвергнутся записи А и PTR, но это относительно простые перемены в сравнении с задачей внедрения совершенно новой концепции: совместного владения адресами.

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

В IPv6 эквивалент записи А первоначально назывался АААА, поскольку адреса IPv6 в четыре раза длиннее, чем простые IP-адреса. Когда появилась схема разделенного управления адресами, организация IETF стандартизировала два новых типа записей: А6 (для перевода имен компьютеров в адреса и DNAME (для передачи частей адреса другим организациям). Прототипом для записи DNAME послужила запись CNAME, с помощью которой, как было показано выше, обеспечивалась поддержка сетевых масок, не проходящих по границе байтов. Запись А6 задает адрес, но при этом учитывается что часть старших битов должна быть получена из другого источника.

Мы не будем подробно рассматривать механизмы поиска имен в IPv6 поскольку они еще недостаточно четко определены организацией IETF, л: и у нас не очень большой опыт работы с ними. В следующих двух разделах излагается лишь суть этой совершенно новой методики.

 

Записи А6

 

Формат записи А6 таков:

имя_узла [ttl]  IN А6 число_отложенных_битов IP-адрес ссылка

 

Например:

 

anchor   IN    А6    0      3ffe:8050:201:9:а00:20ff:fe81:2b32.

anchor   IN    A6    48    ::9:a00:20ff:fe81:2b32 prefix.myisp.net.

 

 

Обе записи задают один и тот же адрес IPv6 для узла anchor. В первом случае адрес полностью определен, а во втором — 48 префиксных битов делегируются узлу prefix.myisp.net. Обратите внимание на то, что в первой записи в качестве ссылочного аргумента указана точка. Она означает, что никаких дальнейших ссылок не требуется.

Модулю распознавания может потребоваться обратиться ко многим серверам имен, чтобы собрать полный 128-разрядный адрес по цепочке записей А6. Например, во второй из показанных выше записей на следующем уровне могут оказаться отложенными 47 битов, далее — 46 и т.д. Для получения ответов придется сделать 48 запросов. Добавьте эквивалентное число запросов DNSSEC, требуемых для проверки каждого компонента адреса, и получится 100-кратное увеличение DNS-трафика при распознавании одного единственного имени! Как видите, официальные спецификации не всегда просты и эффективны.

На практике из сорока восьми возможных уровней переадресации останутся два или три, но сама концепция открывает интересное поле для атак вида "отказ от обслуживания". Более подробная (и менее предвзятая документация содержится в каталоге doc пакета BIND 9.

 

Записи DNAME

 

Обратное преобразование адресов IPv6 в доменные имена основано на использовании традиционных записей PTR и записей нового типа — DNAME. Записи PTR связывают локальные биты адреса IPv6 с конкретным сетевым именем, а записи DNAME определяют, какие из оставшихся частей адреса каким организациям принадлежат.

В IPv4 зоны обратного преобразования располагались в домене in-addr.arpa, а зоны прямого преобразования — в других ветвях дерева доменов (например, в доменах "com" или "edu"). В IPv6 информация об обратном преобразовании более рассредоточена. Часть ее находится в домене in6.arpa, а часть хранится в зонах прямого преобразования.

Компоненты имен в домене in-addr.arpa представляют собой байты IP-адреса. В IPv6 эта схема обобщена, и компонентам имени разрешается представлять произвольные части адреса. Такие адресные секции могут быть длиной от 1 до 128 битов; они известны как битовые строки.

Битовые строки записываются посредством специального синтаксиса. Рассмотрим его на конкретном примере. Все однонаправленные адреса IPv6 начинаются с трехбитового префикса 001. Чтобы записать этот префикс языком битовых строк, нужно взять двоичное число 001 и дополнить его незначащим битом, чтобы длина цепочки была кратна четырем: 0010. В результате получаем шестнадцатеричную цифру 2; у нее три бита значащих и один — незначащий. Финальная строка записывается так:

[x2/3]

 

Обратная косая черта, квадратные скобки и литера х ограничивают каждую битовую строку. Содержательная часть строки — это последовательность шестнадцатеричных цифр (в данном случае одна цифра — 2) и спецификатор длины (/3). Последний указывает, сколько битов, представленных шестнадцатеричными цифрами, нужно учитывать. Это необязательный компонент. Если он отсутствует, длина битовой строки вычисляется на основании количества шестнадцатеричных цифр, умноженного на 4 (в данном случае длина строки составляет 4 бита).

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

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

Поскольку все однонаправленные адреса IPv6 имеют общий префикс 001, самый верхний домен в ветви обратного преобразования — [x2/3].ip6.arpa.

А вот более сложный пример. Ниже записано три разных представления одного адреса: первый раз — в цельном виде, второй — с разделением на три части (3/45/80), третий — на четыре (3/13/32/80). По мере перераспределения блоков их шестнадцатеричное представление полностью меняется, хотя в основе остаются те же самые биты. Чтобы получить двоичное представление чисел, воспользуйтесь утилитой bc.

 

[X3ffe8050020100090a0020fffe812b32/128].ip6.arpa.

[x00090a0020fffe812b32/80].[xfff402801008/4 5].[х2/3].ip6.arpa.

[x00090a0020fffe812b32/80].[х80500201/32]Л[xfff0/13]

.[х2/3].ip6.arpa.

 

 

Как и в случае зон домена in-addr.arpa в IPv4, отдельные числа читаются слева направо, а компоненты адреса (блоки, разделенные точками) — справа налево. Первый компонент второй и третьей из показанных выше строк — это локальная часть адреса. Он представляет младшие 80 битов адреса и состоит из шестнадцатеричных цифр 00090a0020fffe812b32. Приведем еще раз те же самые строки с выделенной локальной частью адреса:

 

[x3ffe8050020100090a0020fffe812b32/128]. ip6.arpa

[x00090a0020fffe812b32/80].[xfff402801008/45].[x2/3].ip6.arpa. [x00090a0020fffe812b32/80] Л [x80500201/32 ] A[xfff0/13]

.[x2/3].ip6.arpa.

 

 

Спецификатор /4 5 во второй строке говорит о том, что в шестнадцатеричной цепочке fff402801008 45 битов из 48-ми являются значащими. Очевидно, разработчики стандартов считают, что для нас это развлечение — вбивать все эти фрагменты в DNS-файлы без ошибок.

Записи DNAME делегируют адресные секции другим серверам имен. Формат записей имеет следующий вид:

битовая_строка  [ttl]  IN DNAME целевой_домен

 

Идея состоит в том, что разными частями адреса управляют разные организации. Вам принадлежат 80 битов, вашему провайдеру — собственный блок, его провайдеру — свой и т.д. Процесс делегирования иллюстрируется на примере показанных ниже фрагментов. Здесь используется четырехблоковое представление приводившегося выше адреса, при котором цепочка делегирования проходит от корневого сервера к серверу провайдера и далее к серверу искомого домена.

В данном примере директивы $ORIGIN задают контекст каждой записи. Эти фрагменты взяты из зонных файлов трех разных организаций: корневого сервера домена ip6.arpa, сервера my-isp.net и сервера my-domain.com. Таким образом, они не относятся к единой конфигурации какого-то одного узла.

Корневой сервер домена ip6.arpa — [x2/3].ip6.arpa — делегирует заданный 13-битовый адрес серверу my-isp.net, для чего в зонный файл включаются следующие строки:

 

;передача адресного префикса серверу my-isp.net $ORIGIN

[х2/3].ip6.arpa.

[xfff0/13]   IN    DNAME    ip6.my-isp.net.

 

 

При этом создается нечто вроде псевдонима для заданного адреса [xfff0/13].[х2/3]ip6.arpa, и этот псевдоним указывает на строку "ip6.my-isp.net.". Провайдер, в свою очередь, передает 32-битовый сегмент адреса серверу my-domain.com, помещая такие строки в файл своей зоны ip6.my-isp.net:

 

; передача адресного префикса серверу my-iomain.net $ORIGIN

; ip6.my-isp.net.

[х80500201/32]     IN    DNAME    ip6.my-domain.net.

 

 

Здесь формируется имя "[х80500201/32].ip6.my-isp.net.", которое, раскрываясь из предыдущей записи DNAME, образует 48-битовый префикс адреса IPv6. Эти 48 битов являются синонимом имени ip6.my-domain.com.

В зонных файлах домена ip6.my-domain.com посредством записи PTR устанавливается привязка для оставшейся части адреса:

 

$ORIGIN ip6.my-domain.net.

[x00090a0020fffe812b32/80]    IN   PTR   host.my-domain.net.

 

 

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

Протокол IPv6 еще относительно молод, по крайней мере с точки зрения ввода его в эксплуатацию. Адресные канцелярии только начинают распределять адреса. Локальная часть адреса IPv6 никогда не меняется, и это прекрасно. С другой стороны, большинство организаций так же редко меняет своего провайдера, поэтому биты, получаемые от провайдера, можно смело включать в зонные файлы. Напишите небольшой сценарий на Perl, который поменяет префикс всех адресов, если вы решите перейти к другому провайдеру.

 

Команды в файлах зон

 

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

 

$ORIGIN имя_домена

$INCLUDE иыя_файла

$TTL стандартное_значение

$GENERATE аргументы

 

 

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

Когда демон named читает зонный файл, он добавляет стандартное имя домена ("источник") к любому имени, которое не является полностью определенным. Первоначально источником служит домен, указанный в соответствующей инструкции zone в файле named.conf. Эту установку можно изменить в зонном файле посредством директивы $ORIGIN.

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



 (голосов: 0)
Версия для печати | Комментариев: 0
Информация
Посетители, находящиеся в группе Гости, не могут оставлять комментарии в данной новости.


 
Логин
Пароль
 

 
Locations of visitors to this page