RFC 6303 | Локально обслуживаемые DNS-зоны

Аннотация

Опыт работы с Системой доменных имен (DNS) показал, что существует ряд зон DNS, которые должны автоматически обслуживаться всеми итеративными распознавателями и рекурсивными серверами имен, если не указано иное. В RFC 4193 указано, что это должно происходить для D.F.IP6.ARPA. Этот документ расширяет практику, чтобы охватить зоны IN-ADDR.ARPA для адресного пространства RFC 1918 и другие известные зоны с аналогичными характеристиками.

Скачать оригинальный документ на английском языке RFC 6303 PDF

 

Оглавление

1. Введение
1.1. Зарезервированные слова
2. Влияние на сайты с использованием адресов RFC 1918
3. Изменения в итеративном поведении резольвера
4. Списки покрытых зон
4.1. Зоны RFC 1918
4.2. Зоны RFC 5735 и RFC 5737
4.3. Локальные IPv6-адреса одноадресной рассылки
4.4. IPv6 локально назначенные локальные адреса
4.5. IPv6-локальные адреса
4.6. Пример префикса IPv6
5. Зоны, которые выходят за рамки
6. Соображения IANA
7. Вопросы безопасности
8. Благодарности
9. Ссылки
9.1. Нормативные ссылки
9.2. Информационные ссылки
Адрес автора

 

Статус этой заметки

Эта памятка документирует лучшую текущую практику Интернета.

Этот документ является продуктом Инженерной рабочей группы по Интернету (IETF). Он представляет собой консенсус сообщества IETF. Он получил общественное обозрение и был одобрен для публикации Руководящей группой по Интернет-разработкам (IESG). Дополнительная информация о ПП доступна в Разделе 2 RFC 5741.

Информацию о текущем состоянии этого документа, любых ошибках и способах предоставления отзывов о нем можно получить по адресу http://www.rfc-editor.org/info/rfc6303.

 

Уведомление об авторских правах

Copyright (c) 2011 IETF Trust и лица, указанные в качестве авторов документа. Все права защищены.

На данный документ распространяется действие ПП 78 и Правовые положения IETF Trust, относящиеся к документам IETF (http://trustee.ietf.org/license-info), действующие на дату публикации этого документа. Пожалуйста, внимательно ознакомьтесь с этими документами, так как они описывают ваши права и ограничения в отношении этого документа. Компоненты кода, извлеченные из этого документа, должны включать в себя текст упрощенной лицензии BSD, как описано в разделе 4.e Правил доверия, и предоставляются без гарантии, как описано в упрощенной лицензии BSD.

Этот документ может содержать материалы из Документов IETF или Вкладов IETF, опубликованных или обнародованных до 10 ноября 2008 года. Лица, контролирующие авторские права на некоторые из этих материалов, возможно, не предоставили Доверие IETF право разрешать модификации таких материалов. вне процесса стандартизации IETF. Без получения адекватной лицензии от лица (лиц), контролирующих авторские права на такие материалы, этот документ не может быть изменен вне процесса стандартизации IETF, и его производные работы не могут быть созданы вне процесса стандартизации IETF, кроме как для форматирования его для публикация в качестве RFC или перевод на другие языки, кроме английского.

 

1. Введение

Опыт работы с Системой доменных имен (DNS, [RFC1034] и [RFC1035]) показал, что существует ряд зон DNS, которые СЛЕДУЕТ автоматически обслуживать всем итеративным распознавателям и рекурсивным серверам имен, если специально не настроено иначе. Эти зоны включают, но не ограничиваются ими, зоны IN-ADDR.ARPA для адресного пространства, выделенного [RFC1918], и зоны IP6.ARPA для локально назначенных уникальных локальных адресов IPv6, определенных в [RFC4193].

Эта рекомендация сделана потому, что данные показали, что происходит значительная утечка запросов для этих пространств имен, несмотря на инструкции по их ограничению, и потому что поэтому возникла необходимость развертывания жертвенных серверов имен для защиты непосредственных родительских серверов имен для этих зон от чрезмерного, непреднамеренного запроса загрузить [AS112] [RFC6304] [RFC6305]. Можно ожидать, что нагрузка на запрос продолжит увеличиваться, если не будут предприняты шаги, описанные здесь.

Кроме того, запросы от клиентов за плохо настроенными межсетевыми экранами, которые разрешают исходящие запросы для этих пространств имен, но отбрасывают ответы, создают значительную нагрузку на корневые серверы (настроены прямые зоны, но не обратные зоны). Они также вызывают операционную нагрузку для операторов корневых серверов, поскольку они должны отвечать на запросы о том, почему корневые серверы «атакуют» этих клиентов. Изменение конфигурации по умолчанию решит все эти проблемы для зон, перечисленных в разделе 4.

[RFC4193] рекомендует обрабатывать запросы для D.F.IP6.ARPA локально. Этот документ расширяет рекомендацию, чтобы охватить зоны IN-ADDR.ARPA для [RFC1918] и другие известные зоны IN-ADDR.ARPA и IP6.ARPA, для которых запросы не должны появляться в общедоступном Интернете.

Есть надежда, что таким образом количество жертвенных серверов [AS112] не нужно будет увеличивать, а со временем можно будет уменьшить.

Эта рекомендация также должна помочь в реагировании на DNS для сайтов, которые используют адреса [RFC1918], но не следуют последнему параграфу в Разделе 3 [RFC1918].

1.1. Зарезервированные слова

Ключевые слова «ОБЯЗАН — MUST», «НЕ ОБЯЗАН — MUST NOT», «ТРЕБУЕТСЯ — REQUIRED», «ДОЛЖЕН — SHALL», «НЕ ДОЛЖЕН — SHALL NOT», «СЛЕДУЕТ — SHOULD», «НЕ СЛЕДУЕТ — SHOULD NOT», «РЕКОМЕНДУЕТСЯ — RECOMMENDED», «НЕ РЕКОМЕНДУЕТСЯ — NOT RECOMMENDED», «ВОЗМОЖЕН — MAY» и «ДОПОЛНИТЕЛЬНО — OPTIONAL» в этом документе интерпретироваться как описано в [RFC2119].

2. Влияние на сайты с использованием адресов RFC 1918

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

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

Наиболее значительное влияние будет ощущаться на сайтах, которые используют делегирование для адресов [RFC1918] и которые заполнили эти зоны. Этим сайтам потребуется переопределить конфигурацию по умолчанию, указанную в этом документе, чтобы продолжить разрешение. Как правило, такие сайты будут полностью отключены от Интернета и будут иметь свои собственные корневые серверы для своего собственного DNS-дерева вне Интернета.

3. Изменения в итеративном поведении резольвера

Если не указано иное, итеративный распознаватель теперь будет возвращать достоверные (AA = 1) ошибки имени (RCODE = 3) для запросов в зонах в Разделе 4, с очевидным исключением запросов для самого имени зоны, где SOA, NS и » Нет данных «ответы будут возвращены в зависимости от типа запроса. Один общий способ сделать это все сразу — это обслуживать пустые (только SOA и NS) зоны.

Реализация этой рекомендации ДОЛЖНА предоставлять механизм для отключения этого нового поведения, и СЛЕДУЕТ разрешать это решение на основе зон по зонам.

При использовании пустых зон НЕ СЛЕДУЕТ использовать те же записи NS и SOA, которые используются на общедоступных интернет-серверах, так как это затруднит обнаружение происхождения ответов и, следовательно, любую утечку на общедоступные интернет-серверы. РЕКОМЕНДУЕТСЯ, чтобы в записи NS по умолчанию использовалось имя зоны, а в SOA MNAME по умолчанию указывалось имя единственной цели NS RR (Resource Record). SOA RNAME ДОЛЖЕН по умолчанию «nobody.invalid». [RFC2606]. Реализациям СЛЕДУЕТ предоставлять механизм для установки этих значений. Для сервера имен не нужно предоставлять адресные записи.

Ниже приведен пример общей пустой зоны в формате основного файла. Это даст отрицательный кэш Time to Live (TTL) в 3 часа.

@ 10800 IN SOA @ nobody.invalid. 1 3600 1200 604800 10800
@ 10800 IN NS @

SOA RR необходим для поддержки отрицательного кэширования [RFC2308] ответов об ошибках имен и для указания клиентов на основной мастер для динамических обновлений DNS.

Особо важными значениями SOA являются MNAME, TTL SOA RR и значение negTTL. Оба значения TTL ДОЛЖНЫ совпадать. Остальные значения таймера SOA МОГУТ быть выбраны произвольно, поскольку они не предназначены для управления какой-либо активностью передачи зоны.

Требуется NS RR, поскольку некоторые клиенты UPDATE [RFC2136] используют запросы NS для обнаружения зоны, подлежащей обновлению. Ожидается, что отсутствие адресных записей для сервера имен прервет обработку UPDATE на клиенте.

 

4. Списки покрытых зон

Следующие подразделы являются начальным содержимым реестра IANA, как описано в разделе «Вопросы IANA». После предостережения в этом разделе список содержит только обратные зоны, соответствующие постоянно назначенному адресному пространству. Имя зоны — это субъект, который должен быть зарегистрирован.

4.1. Зоны RFC 1918

Следующие зоны соответствуют адресному пространству IPv4, зарезервированному в [RFC1918].

10.IN-ADDR.ARPA
16.172.IN-ADDR.ARPA
17.172.IN-ADDR.ARPA
18.172.IN-ADDR.ARPA
19.172.IN-ADDR.ARPA
20.172.IN-ADDR.ARPA
21.172.IN-ADDR.ARPA
22.172.IN-ADDR.ARPA
23.172.IN-ADDR.ARPA
24.172.IN-ADDR.ARPA
25.172.IN-ADDR.ARPA
26.172.IN-ADDR.ARPA
27.172.IN-ADDR.ARPA
28.172.IN-ADDR.ARPA
29.172.IN-ADDR.ARPA
30.172.IN-ADDR.ARPA
31.172.IN-ADDR.ARPA
168.192.IN-ADDR.ARPA

4.2. Зоны RFC 5735 и RFC 5737

Следующие зоны соответствуют диапазонам адресов из [RFC5735] и [RFC5737], которые не должны появляться в качестве адресов источника или назначения в общедоступном Интернете; как таковые, нет глобально уникальных имен, связанных с адресами в этих диапазонах.

Рекомендация по обслуживанию пустой зоны 127.IN-ADDR.ARPA не является попыткой препятствовать какой-либо практике предоставлять PTR RR для 1.0.0.127.IN-ADDR.ARPA локально. Фактически, должно существовать реальное обратное отображение, но точная настройка выходит за рамки этого документа. Аналогичная логика применима к обратному отображению для :: 1 (раздел 4.3). Приведенные здесь рекомендации просто предполагают, что никакого другого покрытия для этих доменов не существует.

0.IN-ADDR.ARPA (IPv4 «THIS» NETWORK)
127.IN-ADDR.ARPA (IPv4 Loopback NETWORK)
254.169.IN-ADDR.ARPA (IPv4 LINK LOCAL)
2.0.192.IN-ADDR.ARPA (IPv4 TEST-NET-1)
100.51.198.IN-ADDR.ARPA (IPv4 TEST-NET-2)
113.0.203.IN-ADDR.ARPA (IPv4 TEST-NET-3)
255.255.255.255.IN-ADDR.ARPA (IPv4 BROADCAST)

4.3. Локальные IPv6-адреса одноадресной рассылки

Обратные сопоставления ([RFC3596], раздел 2.5 («Домен IP6.ARPA»)) для неуказанных (: 🙂 и Loopback (:: 1) адресов IPv6 ([RFC4291], разделы 2.4, 2.5.2 и 2.5. 3) покрыты этими двумя зонами:

• 0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.\ 0.0.0.0.0.0.0.0.0.0.0.0.IP6.ARPA
• 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.\ 0.0.0.0.0.0.0.0.0.0.0.0.IP6.ARPA

Примечание: разрывы строк и экранирование (’\’) были вставлены выше для удобства чтения и для соблюдения ограничений ширины линии. Они не являются частью названий зон.

4.4. IPv6 локально назначенные локальные адреса

Раздел 4.4 [RFC4193] уже требует особого отношения к:

D.F.IP6.ARPA

4.5. IPv6-локальные адреса

Локальные IPv6-адреса, как описано в [RFC4291], раздел 2.5.6, охватываются четырьмя различными обратными зонами DNS:

• 8.E.F.IP6.ARPA
• 9.E.F.IP6.ARPA
• A.E.F.IP6.ARPA
• B.E.F.IP6.ARPA

4.6. Пример префикса IPv6

Пример префикса IPv6 [RFC3849].

8.B.D.0.1.0.0.2.IP6.ARPA

Примечание: 8.B.D.0.1.0.0.2.IP6.ARPA здесь не используется в качестве примера.

5. Зоны, которые выходят за рамки

Локальные адреса сайтов IPv6 (не рекомендуется, см. [RFC4291], разделы 2.4 и 2.5.7) и нелокально назначенные локальные адреса IPv6 ([RFC4193]) здесь не рассматриваются.
Ожидается, что локальные адреса IPv6 будут самокорректироваться, так как реализации IPv6 удаляют поддержку локальных адресов сайта. Однако жертвенные серверы для зон от C.E.F.IP6.ARPA до F.E.F.IP6.ARPA, возможно, все же потребуется развернуть в краткосрочной перспективе, если трафик станет чрезмерным.

Для локально назначенных IPv6 локальных адресов (L = 0) [RFC4193] не было принято решения о том, будут ли региональные интернет-реестры (RIR) предоставлять делегирования в этом пространстве или нет. Если этого не произойдет, необходимо добавить C.F.IP6.ARPA в список в разделе 4.4. Если они это сделают, то реестры должны будут предпринять шаги, чтобы обеспечить наличие серверов имен для этих адресов.

IP6.INT когда-то использовался для обеспечения обратного сопоставления для IPv6. IP6.INT устарел в [RFC4159], а делегирование удалено из зоны INT в июне 2006 года. Хотя возможно, что устаревшее программное обеспечение продолжает отправлять запросы на имена в домене IP6.INT, в этом документе не указывается, что IP6.INT считаться локальной зоной.

Этот документ также намеренно игнорирует имена непосредственно в корневом домене. Несмотря на то, что существует подмножество запросов к корневым серверам имен, которые могут быть адресованы с использованием описанных здесь методов (например, адресов .local, .workgroup и IPv4), существует также огромный объем трафика, который требует другой стратегии (например, поиск неквалифицированных имен хостов, адресов IPv6).

 

6. Соображения IANA

IANA создала реестр зон, которые требуют такого поведения по умолчанию. Начальное содержимое этого реестра определено в разделе 4. Разработчикам рекомендуется периодически проверять этот реестр и корректировать свои реализации, чтобы отразить в нем изменения.

Этот реестр может быть изменен через «Обзор IETF» согласно [RFC5226]. В рамках этого процесса обзора следует отметить, что после добавления зоны она фактически добавляется постоянно; как только диапазон адресов начнет настраиваться как локальная зона в системах в Интернете, будет невозможно отменить эти изменения.

IANA следует координировать свои действия с RIR, чтобы гарантировать, что, поскольку DNS Security (DNSSEC) развернута в обратном дереве, делегирование для этих зон осуществляется способом, описанным в разделе 7.

7. Вопросы безопасности

На начальном этапе развертывания, особенно когда используются адреса [RFC1918], могут быть некоторые клиенты, которые неожиданно получают ошибку имени, а не запись PTR. Это может привести к некоторым сбоям в обслуживании, пока их рекурсивные серверы имен не будут переконфигурированы.

Поскольку DNSSEC развертывается в пространствах имен IN-ADDR.ARPA и IP6.ARPA, перечисленные выше зоны необходимо будет делегировать как небезопасные делегирования или находиться в небезопасных зонах. Это позволит выполнить проверку DNSSEC для запросов в этих пространствах, несмотря на отсутствие ответа от делегированных серверов.

Рекомендуется, чтобы сайты, активно использующие эти пространства имен, защищали их с помощью DNSSEC [RFC4035] путем публикации и использования якорей доверия DNSSEC. Это защитит клиентов от случайного импорта неподписанных ответов из Интернета.

8. Благодарности

Эта работа была поддержана Национальным научным фондом США (исследовательский грант SCI-0427144) и DNS-OARC.

9. Ссылки

9.1. Нормативные ссылки

[RFC1034] Mockapetris, P., «DOMAIN NAMES — CONCEPTS AND FACILITIES», STD 13, RFC 1034, November 1987.

[RFC1035] Mockapetris, P., «DOMAIN NAMES — IMPLEMENTATION AND SPECIFICATION», STD 13, RFC 1035, November 1987.

[RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G., and E. Lear, «Address Allocation for Private Internets», BCP 5, RFC 1918, February 1996.

[RFC2119] Bradner, S., «Key words for use in RFCs to Indicate Requirement Levels», BCP 14, RFC 2119, March 1997.

[RFC2136] Vixie, P., Ed., Thomson, S., Rekhter, Y., and J. Bound, «Dynamic Updates in the Domain Name System (DNS UPDATE)», RFC 2136, April 1997.

[RFC2308] Andrews, M., «Negative Caching of DNS Queries (DNS NCACHE)», RFC 2308, March 1998.

[RFC2606] Eastlake 3rd, D. and A. Panitz, «Reserved Top Level DNS Names», BCP 32, RFC 2606, June 1999.

[RFC3596] Thomson, S., Huitema, C., Ksinant, V., and M. Souissi, «DNS Extensions to Support IP Version 6», RFC 3596, October 2003.

[RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, «Protocol Modifications for the DNS Security Extensions», RFC 4035, March 2005.

[RFC4159] Huston, G., «Deprecation of «ip6.int»», BCP 109, RFC 4159, August 2005.

[RFC4193] Hinden, R. and B. Haberman, «Unique Local IPv6 Unicast Addresses», RFC 4193, October 2005.

[RFC4291] Hinden, R. and S. Deering, «IP Version 6 Addressing Architecture», RFC 4291, February 2006.

[RFC5226] Narten, T. and H. Alvestrand, «Guidelines for Writing an IANA Considerations Section in RFCs», BCP 26, RFC 5226, May 2008.

9.2. Информационные ссылки

[AS112] «AS112 Project», <http://www.as112.net/>.

[RFC3849] Huston, G., Lord, A., and P. Smith, «IPv6 Address Prefix Reserved for Documentation», RFC 3849, July 2004.

[RFC5735] Cotton, M. and L. Vegoda, «Special Use IPv4 Addresses», BCP 153, RFC 5735, January 2010.

[RFC5737] Arkko, J., Cotton, M., and L. Vegoda, «IPv4 Address Blocks Reserved for Documentation», RFC 5737, January 2010.

[RFC6304] Abley, J. and W. Maton, «AS112 Nameserver Operations», RFC 6304, July 2011.

[RFC6305] Abley, J. and W. Maton, «I’m Being Attacked by PRISONER.IANA.ORG!», RFC 6305, July 2011.

Адрес автора

Mark P. Andrews
Internet Systems Consortium
950 Charter Street
Redwood City, CA 94063
US

EMail: marka@isc.org