Network Working Group H. Eidnes
Request for Comments: 2317 SINTEF RUNIT
BCP: 20 G. de Groot
Category: Best Current Practice Berkeley Software Design, Inc.
P. Vixie
Internet Software Consortium
March 1998
Бесклассовое делегирование IN-ADDR.ARPA
Статус данного меморандума
Этот документ определяет текущую лучшую практику Интернета для
интернет-сообщества и запрашивает обсуждение и предложения по
улучшениям. Распространение этого меморандума не ограничено.
Уведомление об авторских правах
Copyright (C) The Internet Society (1998). Все права защищены.
2. Введение
Этот документ описывает способ выполнять делегирование IN-ADDR.ARPA на
границах, не кратных октету, для адресных пространств, охватывающих
менее 256 адресов. Таким образом, предлагаемый метод должен устранить
одно из возражений против подсетей на границах, не кратных октету, но,
возможно, более существенно — сделать возможным назначение IP-адресного
пространства блоками меньшего размера, чем 24-битные префиксы, не теряя
возможности делегировать полномочия для соответствующих отображений
IN-ADDR.ARPA. Предлагаемый метод полностью совместим с исходными
механизмами DNS-поиска, определёнными в [1], то есть нет необходимости
изменять используемый алгоритм поиска и не должно быть необходимости
изменять какое-либо программное обеспечение, выполняющее DNS-поиск.
В документе также рассматриваются некоторые эксплуатационные аспекты,
чтобы дать рекомендации по реализации этого метода.
3. Обоснование
С распространением технологии бесклассовой маршрутизации стало
возможным назначать адресное пространство на границах, не кратных
октету. В случае очень небольшой организации, имеющей лишь несколько
хостов, назначение полного 24-битного префикса (того, что традиционно
называлось «сетевым номером класса C») часто приводит к неэффективному
использованию адресного пространства.
Одна из проблем, возникающих при назначении более длинного префикса
(меньшего адресного пространства), состоит в том, что такой организации,
по-видимому, невозможно автономно поддерживать собственную обратную
зону («IN-ADDR.ARPA»). При использовании описанного ниже метода
обратного делегирования можно устранить наиболее важное возражение
против назначения более длинных префиксов несвязанным организациям.
Предположим, что мы назначили адресные пространства трём различным
сторонам следующим образом:
192.0.2.0/25 организации A
192.0.2.128/26 организации B
192.0.2.192/26 организации C
При классическом подходе это привело бы к единственной зоне следующего
вида:
$ORIGIN 2.0.192.in-addr.arpa.
;
1 PTR host1.A.domain.
2 PTR host2.A.domain.
3 PTR host3.A.domain.
;
129 PTR host1.B.domain.
130 PTR host2.B.domain.
131 PTR host3.B.domain.
;
193 PTR host1.C.domain.
194 PTR host2.C.domain.
195 PTR host3.C.domain.
Администрирование этой зоны проблематично. Полномочия для этой зоны
можно делегировать лишь один раз, и обычно это означает: «эта зона может
администрироваться только одной организацией». Следовательно, другие
организации, адресное пространство которых соответствует записям этой
зоны, должны были бы зависеть от другой организации в вопросе
преобразования их адресов в имена. При использовании предлагаемого
метода этой потенциальной проблемы можно избежать.
4. Бесклассовое делегирование IN-ADDR.ARPA
Поскольку единственную зону можно делегировать лишь один раз, для
решения указанной выше проблемы нам требуется больше точек, в которых
можно выполнять делегирование. Эти дополнительные точки делегирования
можно ввести, расширив дерево IN-ADDR.ARPA вниз, например, используя
первый адрес либо первый адрес и длину маски сети (как показано ниже) в
соответствующем адресном пространстве для формирования первого
компонента имени зон.
Следующие четыре файла зон показывают, как с помощью этого метода можно
было бы решить проблему из раздела обоснования.
$ORIGIN 2.0.192.in-addr.arpa.
@ IN SOA my-ns.my.domain. hostmaster.my.domain. (...)
;...
; <<0-127>> /25
0/25 NS ns.A.domain.
0/25 NS some.other.name.server.
;
1 CNAME 1.0/25.2.0.192.in-addr.arpa.
2 CNAME 2.0/25.2.0.192.in-addr.arpa.
3 CNAME 3.0/25.2.0.192.in-addr.arpa.
;
; <<128-191>> /26
128/26 NS ns.B.domain.
128/26 NS some.other.name.server.too.
;
129 CNAME 129.128/26.2.0.192.in-addr.arpa.
130 CNAME 130.128/26.2.0.192.in-addr.arpa.
131 CNAME 131.128/26.2.0.192.in-addr.arpa.
;
; <<192-255>> /26
192/26 NS ns.C.domain.
192/26 NS some.other.third.name.server.
;
193 CNAME 193.192/26.2.0.192.in-addr.arpa.
194 CNAME 194.192/26.2.0.192.in-addr.arpa.
195 CNAME 195.192/26.2.0.192.in-addr.arpa.
$ORIGIN 0/25.2.0.192.in-addr.arpa.
@ IN SOA ns.A.domain. hostmaster.A.domain. (...)
@ NS ns.A.domain.
@ NS some.other.name.server.
;
1 PTR host1.A.domain.
2 PTR host2.A.domain.
3 PTR host3.A.domain.
$ORIGIN 128/26.2.0.192.in-addr.arpa.
@ IN SOA ns.B.domain. hostmaster.B.domain. (...)
@ NS ns.B.domain.
@ NS some.other.name.server.too.
;
129 PTR host1.B.domain.
130 PTR host2.B.domain.
131 PTR host3.B.domain.
$ORIGIN 192/26.2.0.192.in-addr.arpa.
@ IN SOA ns.C.domain. hostmaster.C.domain. (...)
@ NS ns.C.domain.
@ NS some.other.third.name.server.
;
193 PTR host1.C.domain.
194 PTR host2.C.domain.
195 PTR host3.C.domain.
Для каждого блока размером 256 адресов, разделённого с использованием
этого метода, требуется установить около 256 записей CNAME в родительской
зоне. Некоторые могут счесть это некрасивым; мы не будем оспаривать этот
конкретный довод. Однако, если известен способ разделения адресного
пространства, записи ресурсов CNAME в родительской зоне довольно легко
автоматически сгенерировать раз и навсегда.
Преимущество этого подхода перед другими предложенными подходами к
решению данной проблемы состоит в том, что не должно быть необходимости
изменять какое-либо уже развёрнутое программное обеспечение. В
частности, механизм поиска в DNS не требуется изменять для поддержки
такого разделения ответственности за преобразование адресов IPv4 в имена
на границах, «не разделённых точками». Кроме того, этот метод применялся
в течение нескольких лет во многих установках, по-видимому, без вредных
последствий.
Как обычно, запись ресурса вида
$ORIGIN 2.0.192.in-addr.arpa.
129 CNAME 129.128/26.2.0.192.in-addr.arpa.
может быть удобно сокращена до
$ORIGIN 2.0.192.in-addr.arpa.
129 CNAME 129.128/26
Некоторые реализации DNS неблагожелательно относятся к специальным
символам в доменных именах, например к «/», используемому в приведённых
выше примерах. Как ясно указывает [3], они допустимы, хотя некоторым они
могут показаться неэстетичными. Поскольку это не имена хостов, ограничение
[2] не применяется. Современные клиенты и серверы имеют возможность
действовать либеральным и корректным образом.
В приведённых здесь примерах используется «/», поскольку было сочтено,
что он более заметен, а педантичные рецензенты полагали, что довод «это
не имена хостов» нужно повторить. Мы советуем вам не быть столь
педантичными и не копировать приведённые выше примеры в точности,
например замените «/» более консервативным символом, таким как дефис.
5. Эксплуатационные аспекты
Этот метод предназначен для использования при делегировании адресных
пространств, охватывающих менее 256 адресов. Для делегирований,
охватывающих более крупные блоки адресов, вместо него можно использовать
традиционные методы (множественные делегирования).
5.1 Рекомендуемая вторичная служба имён
Некоторые старые версии программного обеспечения серверов имён не будут
предпринимать попыток найти и вернуть имя, на которое указывает запись
CNAME, если это имя уже не известно локально как кэшированные либо
авторитетные данные. Это может вызывать некоторую путаницу в резолверах,
поскольку в ответе будет возвращена только запись CNAME. Во избежание
этой проблемы рекомендуется, чтобы все авторитетные серверы имён для
делегирующей зоны (зоны, содержащей все записи CNAME) работали как
подчинённые (вторичные) серверы имён для делегированных «дочерних» зон,
на которые указывают записи CNAME.
5.2 Альтернативные соглашения об именовании
В результате применения этого метода местоположение зоны, содержащей
фактические записи PTR, более не предопределено. Это даёт гибкость, и
здесь будет приведено несколько примеров.
Альтернативой использованию первого адреса либо первого адреса и длины
маски сети в соответствующем адресном пространстве для именования новых
зон является использование некоторого другого (нечислового) имени. Таким
образом, также возможно указывать на совершенно иную часть дерева DNS
(то есть вне дерева IN-ADDR.ARPA). Необходимо было бы использовать один
из этих альтернативных методов, если бы две организации каким-либо
образом совместно использовали одну и ту же физическую подсеть (и
соответствующее IP-адресное пространство) без «аккуратного» выравнивания
адресов, но всё же хотели администрировать собственные отображения
IN-ADDR.ARPA.
Следующий короткий пример показывает, как можно указать за пределы
дерева IN-ADDR.ARPA:
$ORIGIN 2.0.192.in-addr.arpa.
@ IN SOA my-ns.my.domain. hostmaster.my.domain. (...)
; ...
1 CNAME 1.A.domain.
2 CNAME 2.A.domain.
; ...
129 CNAME 129.B.domain.
130 CNAME 130.B.domain.
;
$ORIGIN A.domain.
@ IN SOA my-ns.A.domain. hostmaster.A.domain. (...)
; ...
;
host1 A 192.0.2.1
1 PTR host1
;
host2 A 192.0.2.2
2 PTR host2
;
etc.
Таким образом, данные отображения имя->адрес и (целевые) данные
отображения адрес->имя фактически могут оказаться в одном файле зоны —
некоторые могут счесть это дополнительным преимуществом, поскольку не
требуется отдельный набор вторичных серверов для обратной зоны. Однако
обратите внимание, что обход через дерево IN-ADDR.ARPA всё равно будет
выполняться, поэтому вставленные туда записи CNAME должны указывать в
правильном направлении, чтобы это работало.
Ниже схематично показан альтернативный подход, использующий то же
решение:
$ORIGIN 2.0.192.in-addr.arpa.
@ SOA my-ns.my.domain. hostmaster.my.domain. (...)
; ...
1 CNAME 1.2.0.192.in-addr.A.domain.
2 CNAME 2.2.0.192.in-addr.A.domain.
$ORIGIN A.domain.
@ SOA my-ns.A.domain. hostmaster.A.domain. (...)
; ...
;
host1 A 192.0.2.1
1.2.0.192.in-addr PTR host1
host2 A 192.0.2.2
2.2.0.192.in-addr PTR host2
Очевидно, что существует много возможностей, которые можно адаптировать
к конкретным требованиям рассматриваемой ситуации.
5.3 Другие эксплуатационные вопросы
Обратите внимание, что нельзя дважды предоставлять перенаправления CNAME
для одного и того же адресного пространства, то есть нельзя выделить
префикс /25 одной организации и вести IN-ADDR.ARPA таким способом, а
затем позволить организации разделить /25 на подсети с более длинными
префиксами и попытаться применить тот же метод, чтобы предоставить каждой
подсети контроль над её собственным номерным пространством. Это привело
бы к записи CNAME, указывающей на запись CNAME, что в целом может быть
менее надёжным.
К сожалению, некоторые старые бета-выпуски популярной реализации сервера
имён DNS BIND 4.9.3 содержали ошибку, вызывавшую проблемы при обнаружении
записи CNAME во время выполнения обратного поиска. Затронутые бета-выпуски
с тех пор устарели, и эта проблема устранена в выпущенном коде. Некоторые
производители программного обеспечения включили дефектный бета-код в свои
продукты. В немногочисленных известных нам случаях исправления от
производителей для замены соответствующего устаревшего бета-кода доступны
либо запланированы.
6. Соображения безопасности
При этой схеме «конечным площадкам» потребуется полагаться на ещё одну
площадку, корректно обеспечивающую их службу имён DNS, по сравнению с
ситуацией, когда они имеют собственное выделение /24; это может добавить
дополнительный компонент, который должен работать для надёжного
разрешения имён.
Помимо этого, авторам не известно о каких-либо дополнительных проблемах
безопасности, вносимых этим механизмом.
7. Заключение
Предлагаемая схема обеспечивает большую гибкость при делегировании полномочий
в домене IN-ADDR.ARPA, тем самым позволяя эффективнее распределять адресное
пространство без утраты возможности делегировать полномочия DNS в отношении
соответствующих сопоставлений адресов с именами.
8. Благодарности
Некоторое время назад Glen A. Herrmannsfeldt описал этот приём в
comp.protocols.tcp-ip.domains. Alan Barrett и Sam Wilson представили
ценные замечания в этой группе новостей.
Мы хотели бы поблагодарить Rob Austein, Randy Bush, Matt Crawford, Robert
Elz, Glen A. Herrmannsfeldt, Daniel Karrenberg, David Kessens, Tony
Li, Paul Mockapetris, Eric Wassenaar, Michael Patton, Hans Maurer,
и Peter Koch за рецензирование и конструктивные замечания.
9. Ссылки
[1] Mockapetris, P., "Domain Names - Concepts and Facilities",
STD 13, RFC 1034, November 1987.
[2] Harrenstien, K., Stahl, M., and E. Feinler, "DoD Internet Host
Table Specification", RFC 952, October 1985.
[3] Elz, R., and R. Bush, "Clarifications to the DNS
Specification", RFC 2181, July 1997.
10. Адреса авторов
Havard Eidnes
SINTEF RUNIT
N-7034 Trondheim
Norway
Phone: +47 73 59 44 68
Fax: +47 73 59 17 00
EMail: Havard.Eidnes@runit.sintef.no
Geert Jan de Groot
Berkeley Software Design, Inc. (BSDI)
Hendrik Staetslaan 69
5622 HM Eindhoven
The Netherlands
Phone: +31 40 2960509
Fax: +31 40 2960309
EMail: GeertJan.deGroot@bsdi.com
Paul Vixie
Internet Software Consortium
Star Route Box 159A
Woodside, CA 94062
USA
Phone: +1 415 747 0204
EMail: paul@vix.com
11. Полное заявление об авторском праве
Copyright (C) The Internet Society (1998). All Rights Reserved.
Этот документ и его переводы могут копироваться и предоставляться другим
лицам, а производные работы, которые комментируют или иным образом объясняют
его либо содействуют его реализации, могут подготавливаться, копироваться,
публиковаться и распространяться, полностью или частично, без каких-либо
ограничений при условии, что приведённое выше уведомление об авторском праве
и настоящий абзац включены во все такие копии и производные работы. Однако
сам этот документ не может быть каким-либо образом изменён, например путём
удаления уведомления об авторском праве или ссылок на The Internet Society
или другие интернет-организации, кроме случаев, когда это необходимо для
разработки интернет-стандартов, при которой должны соблюдаться процедуры
защиты авторских прав, определённые в процессе разработки Internet Standards,
либо когда это требуется для перевода документа на языки, отличные от
английского.
Предоставленные выше ограниченные разрешения являются бессрочными и не будут
отозваны The Internet Society либо её правопреемниками или цессионариями.
Этот документ и содержащаяся в нём информация предоставляются на условиях
"КАК ЕСТЬ", И THE INTERNET SOCIETY И THE INTERNET ENGINEERING TASK FORCE
ОТКАЗЫВАЮТСЯ ОТ ВСЕХ ЯВНЫХ ИЛИ ПОДРАЗУМЕВАЕМЫХ ГАРАНТИЙ, ВКЛЮЧАЯ, В ТОМ
ЧИСЛЕ, ЛЮБУЮ ГАРАНТИЮ ТОГО, ЧТО ИСПОЛЬЗОВАНИЕ СОДЕРЖАЩЕЙСЯ ЗДЕСЬ ИНФОРМАЦИИ
НЕ НАРУШИТ КАКИХ-ЛИБО ПРАВ, ЛИБО ЛЮБЫЕ ПОДРАЗУМЕВАЕМЫЕ ГАРАНТИИ ТОВАРНОЙ
ПРИГОДНОСТИ ИЛИ ПРИГОДНОСТИ ДЛЯ ОПРЕДЕЛЁННОЙ ЦЕЛИ.