RFC 8501 | Обратный DNS в IPv6 для интернет-провайдеров

Аннотация

В IPv4 поставщики интернет-услуг (ISP) обычно предоставляют своим клиентам информацию IN-ADDR.ARPA, предварительно заполняя зону одной записью PTR для каждого доступного адреса. Эта практика не масштабируется в IPv6. В этом документе анализируются различные подходы и соображения для интернет-провайдеров по управлению зоной IP6.ARPA.

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

1. Введение
1.1. Обратный DNS в IPv4
1.2. Обратный DNS Вопросы в IPv6
2. Альтернативы в IPv6
2.1. Отрицательный ответ
2.2. Подстановочный знак
2.3. Динамический DNS
2.3.1. Динамический DNS от отдельных хостов
2.3.2. Динамический DNS через жилые шлюзы
2.3.3. Автоматическое делегирование DNS
2.3.4. Генерация динамических записей
2.3.5. Заполнить с DHCP-сервера
2.3.6. Заполните с сервера RADIUS
2.4. Делегировать DNS
2.5. Динамически генерировать PTR при запросе («На лету»)
3. Ручные обновления пользователя
4. Соображения и рекомендации
5. Вопросы безопасности и конфиденциальности
5.1. Использование обратного DNS для безопасности
5.2. Безопасность DNS с динамическим DNS
5.3. Соображения по поводу другого использования DNS
5.4. Вопросы конфиденциальности
5.5. Творчество пользователя
6. Соображения IANA
7. Ссылки
7.1. Нормативные ссылки
7.2. Информационные ссылки
Подтверждения
Адрес автора

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

Этот документ не является спецификацией Internet Standards Track; опубликовано в ознакомительных целях.

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

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

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

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

1. Введение

[RFC1912] рекомендовал, чтобы «у каждого хоста, имеющего доступ к Интернету, было имя» и говорилось: «Отсутствие совпадающих записей PTR и A может привести к потере интернет-услуг, аналогично тому, что они вообще не зарегистрированы в DNS». Хотя потребность в записи PTR и для того, чтобы соответствовать спорно в качестве лучшей практики, некоторые сетевые услуги (раздел 4) до сих пор полагаются на PTR поиск, а некоторые проверки адреса источника входящих соединений и убедитесь, что PTR и А записи совпадают до предоставления услуги.

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

Администраторы интернет-провайдеров должны учитывать, нужны ли записи PTR клиента, и, если это так, оценивать способы ответа на обратные DNS-запросы в IPv6.

1.1. Обратный DNS в IPv4

Интернет-провайдеры, которые предоставляют доступ многим абонентам, обычно назначают каждому из этих пользователей один или несколько IPv4-адресов и заполняют зону IN-ADDR.ARPA одной записью PTR для каждого IPv4-адреса. Некоторые интернет-провайдеры также настраивают прямые зоны с совпадающими записями A, чтобы сопоставления соответствовали. Например, если провайдер Example.com агрегировал 192.0.2.0/24 в сетевом концентраторе в одном регионе, обратная зона может выглядеть следующим образом:

1.2.0.192.IN-ADDR.ARPA. IN PTR 1.string.region.example.com.
2.2.0.192.IN-ADDR.ARPA. IN PTR 2.string.region.example.com.
3.2.0.192.IN-ADDR.ARPA. IN PTR 3.string.region.example.com.
.
.
.
254.2.0.192.IN-ADDR.ARPA. IN PTR 254.string.region.example.com.
The conscientious Example.com might then also have a zone:
1.string.region.example.com. IN A 192.0.2.1
2.string.region.example.com. IN A 192.0.2.2
3.string.region.example.com. IN A 192.0.2.3
.
.
.
254.string.region.example.com. IN A 192.0.2.254

Многие интернет-провайдеры генерируют записи PTR для всех IP-адресов, используемых для клиентов, а многие создают соответствующую запись A.

1.2. Обратное рассмотрение DNS в IPv6

Пример записи для 2001:0db8:0f00:0000:0012:34ff:fe56:789a может быть: a.9.8.7.6.5.e.f.f.f.4.3.2.1.0.0.0.0.0.0.0.0.f.0.8.b.d.0.1.0.0.2.IP6.ARPA. IN PTR 1.string.region.example.com.

Интернет-провайдеры часто делегируют префикс IPv6 своим клиентам. Поскольку в одной / 48 зоне может быть сконфигурировано 2 ^^ 80 возможных адресов, нецелесообразно записывать зону с каждым введенным возможным адресом, даже с автоматизацией. Если бы 1000 записей могли быть записаны в секунду, зона была бы неполной через 38 триллионов лет.

Кроме того, часто невозможно связать имена хостов и адреса, так как 64 бита в части идентификатора интерфейса адреса часто назначаются с помощью автоматической конфигурации адреса без сохранения состояния (SLAAC) [RFC4862], когда хост подключается к сети, и они могут быть недолговечными.

[RFC1912] — это информационный RFC, который гласит: «Записи PTR должны указывать на действительную запись A», и далее администратор должен «убедиться, что записи PTR и A совпадают». Здесь приведены соображения о том, как следовать этому совету для записей AAAA и PTR.

2. Альтернативы в IPv6

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

2.1. Отрицательный ответ

Некоторые DNS-администраторы интернет-провайдера могут выбрать предоставление только ответа NXDOMAIN на запросы PTR для адресов абонентов. В некотором смысле это самый точный ответ, так как информация об имени хоста не известна. Однако предоставление отрицательного ответа на запросы PTR не удовлетворяет ожиданию в [RFC1912] совпадений записей. Пользователи служб, которые зависят от успешного поиска, будут иметь плохой опыт. Например, некоторые веб-службы и соединения Secure Shell (SSH) ждут ответа DNS, даже NXDOMAIN, прежде чем ответить. Поэтому для лучшего взаимодействия с пользователем важно возвращать ответ, а не время без ответа. С другой стороны, внешние почтовые серверы могут отклонять соединения, что может быть преимуществом в борьбе со спамом.

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

2.2. Подстановочный знак

Использование подстановочных знаков в DNS описано в [RFC4592], а их использование в обратном DNS IPv6 описано в [RFC4472].

Хотя запись всех возможных адресов не масштабируется, может быть возможно записать запись с подстановочными знаками для каждого префикса, назначенного клиенту. Учтите также, что «включение подстановочных знаков NS RRSets в зону не рекомендуется, но не запрещено». [RFC4592]

Это решение обычно хорошо масштабируется. Однако, поскольку ответ будет совпадать с любым адресом в диапазоне символов подстановки (/ 48, / 56, / 64 и т. Д.), Прямой поиск DNS по данному ответу не сможет вернуть одно и то же имя хоста. Таким образом, этот метод не соответствует ожиданиям в [RFC1912], что прямое и обратное совпадение будут совпадать. Масштабируемость DNSSEC [RFC4035] ограничена подписанием подстановочной зоны, что может быть удовлетворительным.

2.3. Динамический DNS

Один из способов обеспечения совпадения прямой и обратной записей состоит в том, что хосты динамически обновляют DNS-серверы после завершения настройки интерфейса (с помощью SLAAC, DHCPv6 или другими способами), как описано в [RFC4472]. Хозяева должны будут предоставлять обновления AAAA и PTR и должны знать, какие серверы будут принимать информацию.

Эта опция должна масштабироваться так же плохо, как динамический DNS (DDNS) IPv4. Динамический DNS может не эффективно масштабироваться в больших сетях интернет-провайдеров, которые не имеют единого главного сервера имен, но один главный сервер не рекомендуется. Система DNS интернет-провайдера может обеспечить точку для атак типа «отказ в обслуживании», включая множество попыток обновления DDNS. Принятие обновлений только из аутентифицированных источников может снизить этот риск, но только если сама аутентификация не требует чрезмерных накладных расходов. Никакая аутентификация динамических обновлений DNS не предусмотрена. Поэтому разработчикам следует рассмотреть возможность использования TSIG [RFC2845] или, по крайней мере, входной фильтрации, чтобы обновления принимались только из адресного пространства клиента из внутренних сетевых интерфейсов. Они также должны ограничивать количество обновлений от клиента в секунду и учитывать влияние на масштабируемость. UDP разрешен в соответствии с [RFC2136], поэтому надежность соединения не гарантируется, хотя хост должен ожидать сообщения ERROR или NOERROR от сервера; TCP обеспечивает управление передачей, но хост обновления должен быть настроен для использования TCP.

Администраторы могут захотеть рассмотреть креативность пользователей, если они предоставят имена хостов, как описано в Разделе 5.5 «Креативность пользователей».

Нет никакой гарантии уникальности, если несколько хостов пытаются выполнить обновление с одним и тем же именем («mycomputer.familyname.org»). Не существует стандартного способа указать хосту, на какой сервер он должен отправлять обновления DDNS; мастер, указанный в SOA, часто считается сервером DDNS, но он может не масштабироваться.

2.3.1. Динамический DNS от отдельных хостов

В простейшем случае у домашнего пользователя будет один хост, подключенный к провайдеру. Так как обычный пользователь не может настраивать адреса IPv6 или разрешать серверы имен на своих хостах, интернет-провайдер должен предоставлять информацию об адресе традиционным способом, то есть, используя свою обычную комбинацию объявлений маршрутизатора (RA), DHCP и т. д. Интернет-провайдер должен также предоставлять DNS Рекурсивный сервер имен и список поиска доменов, как описано в [RFC3646] или [RFC8106]. При определении своего полного доменного имени (FQDN) хост обычно использует домен из списка поиска доменов. Это перегрузка параметра; Можно перечислить несколько доменов, так как хостам может понадобиться искать неквалифицированные имена в нескольких доменах, не обязательно являясь членом этих доменов. При рассмотрении вопроса об использовании этой опции администраторам следует учитывать, действительно ли в списке поиска доменов указаны соответствующие суффиксы DNS. Для целей динамического DNS хост будет объединять свое локальное имя хоста (например, «hostname») плюс домены в списке поиска доменов (например, «customer.example.com»), как в «hostname.customer.example.com».

Как только он узнает свой адрес и имеет разрешающий сервер имен, хост должен выполнить поиск SOA для записи IP6.ARPA, которая будет добавлена, чтобы найти владельца и, в конечном итоге, сервер, который является полномочным для зоны (которая может принимать динамические обновления). Может потребоваться несколько рекурсивных поисков, чтобы найти самый длинный префикс, который был делегирован. Администратор DNS должен назначить основной главный сервер для самого длинного требуемого соответствия. После обнаружения хост отправляет динамические обновления AAAA и PTR с использованием определенной выше конкатенации («hostname.customer.example.com»).

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

2.3.2. Динамический DNS через жилые шлюзы

У частных клиентов может быть шлюз, который может предоставлять хостам услугу DHCPv6 с делегированного префикса. Интернет-провайдеры должны предоставить шлюзу сервер рекурсивных имен DNS и список поиска домена, как описано выше и в [RFC3646] и [RFC8106]. Существует два варианта того, как шлюз использует эту информацию. Первый вариант — шлюз отвечает на запросы DHCPv6 тем же сервером рекурсивных имен DNS и списком поиска доменов, предоставленным провайдером. Альтернативный вариант — для шлюза передавать динамические обновления DNS с хостов на серверы и в домен, предоставляемые провайдером. Поведение хоста не изменилось; хост отправляет те же динамические обновления либо на сервер интернет-провайдера (предоставляемый шлюзом), либо на шлюз для пересылки. Шлюз должен быть способен и настроен на использование динамического DNS.

2.3.3. Автоматическое делегирование DNS

Интернет-провайдер может делегировать полномочия для субдомена, такого как «customer12345.town.AW.customer.example.com» или «customer12345.example.com», шлюзу клиента. Каждый делегированный таким образом домен должен быть уникальным в пределах DNS.

Затем провайдер может также делегировать зону IP6.ARPA для префикса, делегированного клиенту, как в (для 2001:db8:f00::/48) «0.0.f.0.8.b.d.0.1.0.0.2.IP6.ARPA».

Затем клиент может предоставить обновления для своего собственного шлюза, с прямым и обратным. Однако отдельные хосты, подключенные напрямую к провайдеру, редко имеют возможность запускать DNS для себя; следовательно, интернет-провайдер может делегировать только клиентам со шлюзами, способными быть авторитетными серверами имен. Если устройство запрашивает делегирование префикса DHCPv6, это может считаться достаточно надежным показателем того, что это шлюз, а не отдельный хост. Это не обязательно показатель того, что шлюз способен предоставлять услуги DNS и, следовательно, нельзя полагаться как способ проверить, возможна ли эта опция.

Фактически, этот тип делегирования не будет работать для устройств, соответствующих [RFC6092], который включает в себя требование «По умолчанию DEFAULT входящие запросы DNS, полученные на внешних интерфейсах, НЕ ДОЛЖНЫ обрабатываться каким-либо интегрированным сервером разрешения DNS».

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

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

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

2.3.4. Генерация динамических записей

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

Этот метод также зависит от способности хостов предоставлять динамические обновления DNS, что не является поведением по умолчанию для многих хостов.

2.3.5. Заполнить с DHCP-сервера

Сервер DHCPv6 интернет-провайдера может заполнять прямую и обратную зоны при получении запроса DHCP, если запрос содержит достаточно информации [RFC4704].

Однако этот метод будет работать только для одного адреса хоста (IA_NA); DHCP-сервер провайдера не будет иметь достаточно информации для обновления всех записей для делегирования префикса. Если полномочия зоны делегируются домашнему шлюзу, который использовал этот метод, шлюз может обновлять записи для жилых хостов. Чтобы реализовать эту альтернативу, жилые шлюзы пользователей должны будут поддерживать опцию FQDN DHCP и должны либо настраивать зоны, либо отправлять сообщения DDNS на сервер имен ISP.

2.3.6. Заполните с сервера RADIUS

Пользователь может получить адрес или префикс от сервера RADIUS [RFC2865], подробности которого могут быть записаны с помощью данных учета RADIUS [RFC2866]. Интернет-провайдер может заполнить прямую и обратную зоны из учетных данных, если он содержит достаточно информации. Это решение позволяет интернет-провайдеру заполнять данные, относящиеся к выделенным префиксам в соответствии с разделом 2.2 (подстановочные знаки) и конечными точками абонентского оборудования (CPE). Однако, как и в разделе 2.3.5, он не позволяет интернет-провайдеру заполнять информацию об отдельных хостах.

2.4. Делегировать DNS

Для клиентов, которые могут запускать свои собственные DNS-серверы, таких как коммерческие клиенты, часто лучшим вариантом является делегирование им обратной зоны DNS, как описано в [RFC2317] (для IPv4). Тем не менее, поскольку большинство пользователей в жилых помещениях не имеют ни оборудования, ни опыта для работы с DNS-серверами, этот метод недоступен для бытовых интернет-провайдеров.

Это общий случай конкретного случая, описанного в разделе 2.3.3. Все те же соображения все еще применяются.

2.5. Динамически генерировать PTR при запросе («На лету»)

Обычной практикой в IPv4 является предоставление записей PTR для всех адресов, независимо от того, использует ли хост адрес в действительности. В IPv6 интернет-провайдеры могут генерировать записи PTR для всех адресов IPv6, когда запрашиваются записи. Несколько DNS-серверов способны на это.

ISP, использующий эту опцию, должен сгенерировать запись PTR по требованию и кэшировать или предварительно заполнить запись пересылки (AAAA) на время времени жизни PTR. Аналогично, провайдер предварительно заполняет PTR после запроса AAAA. Чтобы уменьшить подверженность атаке типа «отказ в обслуживании», состояние или хранилище должны быть ограничены. Альтернативно, если алгоритм используется для генерации уникального имени, его можно использовать на лету в обоих направлениях. Этот параметр имеет преимущество, заключающееся в обеспечении совпадения прямой и обратной записей, в то время как он проще, чем динамический DNS. Администраторы должны учитывать, является ли недостаток указанных пользователем имен хостов недостатком. Может быть возможно разрешить определенные пользователем имена хостов для некоторых записей и генерировать другие на лету; поиск записи перед генерацией на лету может замедлить реакцию или может плохо масштабироваться.

DNSSEC [RFC4035] подписание записей на лету может увеличить нагрузку; неподписанные записи могут указывать, что эти записи менее надежны, что может быть приемлемо.

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

3. Ручные обновления пользователя

Можно создать пользовательский интерфейс, такой как веб-страница, который позволил бы конечным пользователям вводить имя хоста для связи с адресом. Такой интерфейс должен быть аутентифицирован; только авторизованный пользователь может добавлять / изменять / удалять записи. Если провайдер изменит префиксы, назначенные клиентам, интерфейсу потребуется указать только биты хоста. Следовательно, серверная часть должна быть интегрирована с назначением префикса, чтобы при назначении нового префикса клиенту служба DNS искала созданные пользователем имена хостов, удаляла старую запись и создавала новую.

Соображения по поводу того, что некоторые записи являются статическими, а другие динамическими или динамически генерируемыми (Раздел 2.5) и творческий подход пользователей (Раздел 5.5), все еще применимы.

4. Соображения и рекомендации

Существует шесть распространенных вариантов использования поиска PTR:

Отклонение почты (Rejecting mail): PTR с определенной строкой может указывать «Этот хост не является почтовым сервером», что может быть полезно для отклонения вероятного спама. Отсутствие PTR приводит к желаемому поведению.
Показ рекламы (Serving ads): «Этот хост, вероятно, находится в town.province.» Интернет-провайдер, который не предоставляет PTR-записи, может повлиять на чью-либо геолокацию (см. Также соображения конфиденциальности о местоположении).
Принятие соединений SSH (Accepting SSH connections): Наличие PTR может означать «У этого хоста есть администратор с достаточным количеством подсказок для настройки прямого и обратного DNS». Это плохой вывод.
Файлы журналов (Log files): Многие системы записывают PTR удаленных хостов в свои файлы журналов, чтобы упростить последующее чтение журналов и посмотреть, какую сеть использует удаленный хост.
Трассировка маршрута (Traceroute): способность идентифицировать интерфейс и имя любого промежуточного узла или маршрутизатора важна для устранения неполадок.
Обнаружение службы (Service discovery): [RFC6763] определяет «Обнаружение службы на основе DNS», а в разделе 11 конкретно описывается, как используются PTR.

В качестве общего руководства, когда присвоение адреса и имя находятся под одним и тем же полномочием или когда хост имеет статический адрес и имя, записи AAAA и PTR должны существовать и совпадать. Для бытовых пользователей, если эти варианты использования важны для интернет-провайдера, администратор должен будет рассмотреть, как предоставить записи PTR.

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

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

Интернет-провайдер не знает имен хостов своих постоянных пользователей и поэтому может предоставить либо шаблонный ответ, либо динамически сгенерированный ответ. Действительный отрицательный ответ (такой как NXDOMAIN) является действительным ответом, если четыре вышеупомянутых случая не являются существенными; следует избегать делегирования, где не существует сервера имен.

5. Вопросы безопасности и конфиденциальности

5.1. Использование обратного DNS для безопасности

Некоторые люди думают, что наличие обратных записей DNS или сопоставление прямых и обратных записей DNS предоставляет полезную информацию о хостах с этими записями. Например, можно сделать вывод, что администратор сети с правильно настроенными записями DNS был лучше информирован и, как следствие, более ответственен, чем администратор менее тщательно сконфигурированной сети. Например, большинство провайдеров электронной почты не будут принимать входящие соединения через порт 25, если не совпадают прямые и обратные записи DNS. Если они совпадают, но информация, находящаяся выше в стеке (например, источник почты), не согласована, пакет сомнителен. Однако эти записи могут быть легко подделаны, если DNSSEC или другие меры не будут приняты. Строка выводов сомнительна и может стать ненужной, если в IPv6 преобладают другие средства оценки достоверности (например, положительная репутация).

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

5.2. Безопасность DNS с динамическим DNS

Вопросы безопасности для использования динамического DNS описаны в [RFC3007]. Расширения безопасности DNS описаны в [RFC4033].

Взаимодействие с DNSSEC описано в этом документе.

5.3. Соображения по поводу другого использования DNS

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

5.4. Вопросы конфиденциальности

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

5.5. Творчество пользователя

Хотя это не совсем соображение безопасности, администраторы могут решить, какой домен будет содержать записи и кто будет предоставлять имена. Если подписчики предоставляют имена хостов, они могут предоставлять неподходящие строки. Рассмотрим «ihate.example.com» или «badword.customer.example.com» или «celebrityname.committed.illegal.acts.example.com».

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

В этом документе нет действий IANA.

7. Ссылки

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

[RFC1912] Barr, D., «Common DNS Operational and Configuration Errors», RFC 1912, DOI 10.17487/RFC1912, February 1996, <https://www.rfc-editor.org/info/rfc1912>.

[RFC2136] Vixie, P., Ed., Thomson, S., Rekhter, Y., and J. Bound, «Dynamic Updates in the Domain Name System (DNS UPDATE)», RFC 2136, DOI 10.17487/RFC2136, April 1997,
<https://www.rfc-editor.org/info/rfc2136>.

[RFC2845] Vixie, P., Gudmundsson, O., Eastlake 3rd, D., and B. Wellington, «Secret Key Transaction Authentication for DNS (TSIG)», RFC 2845, DOI 10.17487/RFC2845, May 2000,
<https://www.rfc-editor.org/info/rfc2845>.

[RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, «Remote Authentication Dial In User Service (RADIUS)», RFC 2865, DOI 10.17487/RFC2865, June 2000,
<https://www.rfc-editor.org/info/rfc2865>.

[RFC2866] Rigney, C., «RADIUS Accounting», RFC 2866, DOI 10.17487/RFC2866, June 2000,
<https://www.rfc-editor.org/info/rfc2866>.

[RFC3007] Wellington, B., «Secure Domain Name System (DNS) Dynamic Update», RFC 3007, DOI 10.17487/RFC3007, November 2000,
<https://www.rfc-editor.org/info/rfc3007>.

[RFC3646] Droms, R., Ed., «DNS Configuration options for Dynamic Host Configuration Protocol for IPv6 (DHCPv6)», RFC 3646, DOI 10.17487/RFC3646, December 2003,
<https://www.rfc-editor.org/info/rfc3646>.

[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, «DNS Security Introduction and Requirements», RFC 4033, DOI 10.17487/RFC4033, March 2005,
<https://www.rfc-editor.org/info/rfc4033>.

[RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, «Protocol Modifications for the DNS Security Extensions», RFC 4035, DOI 10.17487/RFC4035, March 2005,
<https://www.rfc-editor.org/info/rfc4035>.

[RFC4592] Lewis, E., «The Role of Wildcards in the Domain Name System», RFC 4592, DOI 10.17487/RFC4592, July 2006,
<https://www.rfc-editor.org/info/rfc4592>.

[RFC4704] Volz, B., «The Dynamic Host Configuration Protocol for IPv6 (DHCPv6) Client Fully Qualified Domain Name (FQDN) Option», RFC 4704, DOI 10.17487/RFC4704, October 2006, <https://www.rfc-editor.org/info/rfc4704>.

[RFC4862] Thomson, S., Narten, T., and T. Jinmei, «IPv6 Stateless Address Autoconfiguration», RFC 4862, DOI 10.17487/RFC4862, September 2007,
<https://www.rfc-editor.org/info/rfc4862>.

[RFC4941] Narten, T., Draves, R., and S. Krishnan, «Privacy Extensions for Stateless Address Autoconfiguration in IPv6», RFC 4941, DOI 10.17487/RFC4941, September 2007,
<https://www.rfc-editor.org/info/rfc4941>.

[RFC6763] Cheshire, S. and M. Krochmal, «DNS-Based Service Discovery», RFC 6763, DOI 10.17487/RFC6763, February 2013,
<https://www.rfc-editor.org/info/rfc6763>.

[RFC8106] Jeong, J., Park, S., Beloeil, L., and S. Madanapalli, «IPv6 Router Advertisement Options for DNS Configuration», RFC 8106, DOI 10.17487/RFC8106, March 2017,
<https://www.rfc-editor.org/info/rfc8106>.

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

[RFC2317] Eidnes, H., de Groot, G., and P. Vixie, «Classless IN-ADDR.ARPA delegation», BCP 20, RFC 2317, DOI 10.17487/RFC2317, March 1998,
<https://www.rfc-editor.org/info/rfc2317>.

[RFC4472] Durand, A., Ihren, J., and P. Savola, «Operational Considerations and Issues with IPv6 DNS», RFC 4472, DOI 10.17487/RFC4472, April 2006,
<https://www.rfc-editor.org/info/rfc4472>.

[RFC6092] Woodyatt, J., Ed., «Recommended Simple Security Capabilities in Customer Premises Equipment (CPE) for Providing Residential IPv6 Internet Service», RFC 6092, DOI 10.17487/RFC6092, January 2011,
<https://www.rfc-editor.org/info/rfc6092>.

[RFC8117] Huitema, C., Thaler, D., and R. Winter, «Current Hostname Practice Considered Harmful», RFC 8117, DOI 10.17487/RFC8117, March 2017,
<https://www.rfc-editor.org/info/rfc8117>.

Подтверждения

Автор хотел бы поблагодарить Алена Дюранда, JINMEI Tatuya, Дэвида Фридмана, Эндрю Салливана, Криса Гриффитса, Даррила Таннера, Эд Льюиса, Джона Бржозовского, Криса Донли, Уэса Джорджа, Джейсона Вейля, Джона Спенса, Теда Лемона, Стефана Лагерхольма, Стейнара Хауга Марк Эндрюс, Крис Рузенраад, Фернандо Гонт, Джон Левин и многие другие, которые обсуждали и предоставляли предложения для этого документа.

Адрес автора

Lee Howard
Retevia
Fairfax, VA 22032
United States of America
Email: lee.howard@retevia.net