RSSAC — вопросы и ответы

1. Количество корневых серверов

2. Anycast

3. DNS и сети

4. Защита целостности корневой зоны

5. DNSSEC

6. RSSAC

7. Группа подготовки документов RSSAC

8. Распространенные заблуждения

1.1 Почему существует 13 корневых DNS-серверов?

В 1985 году корневых серверов было четыре. В период с 1987 года по 1991 год их было семь, и все они были расположены в США. К 1993 году их стало восемь. На этом этапе возникла проблема. Документ RFC 1035 гласит, что «размер сообщений [DNS], передаваемых по протоколу UDP, ограничен 512 байтами». Добавление корневых DNS-серверов означало бы, что ответ на подготовительный запрос превысил бы 512 байт. В RFC 1035 не представлено обоснование этого ограничения в 512 байт, однако также важно отметить, что в те времена было распространено требование, согласно которому IP-пакеты в Интернете не должны были превышать 576 байт.

Операторы корневых серверов поняли, что для того чтобы добавлять DNS-серверы, нужно будет воспользоваться компрессией имен DNS, в связи с чем было внесено предложение присвоить корневым серверам имена в зоне домена root-servers.net. К 1995 году девять существовавших тогда корневых серверов были переименованы в a.root-servers.net, b.root-servers.net и т. д. В 1997 году было добавлено еще четыре сервера, и всего таких идентификаторов корневых серверов (RSI) стало 13.

До 1998 года операторов корневых серверов назначал Джон Постел (Jon Postel), который выполнял функции администратора IANA. После его смерти в 1998 году количество операторов не изменилось, однако некоторые из них за эти годы сменили своих владельцев.

С 1998 года ряд аспектов ландшафта изменился. Каждый корневой сервер обзавелся собственным IPv6-адресом, а ICANN перешла к подписанию зоны с использованием т. н. расширений безопасности системы доменных имен DNS, или DNSSEC. Кроме того, размер сообщений, передаваемых по протоколу UDP, удалось увеличить за счет использования протокола механизмов расширения для DNS (EDNS). Вместе эти изменения сделали проблему ограничения размера пакета UDP в 512 байт, а количества RSI в 13, менее актуальной.

В 2002 году консорциум Internet Software Consortium (сегодня он называется Internet Systems Consortium, или ISC) первым среди операторов корневых серверов развернул технологию IP Anycast, хотя эксперименты с ней проводились в рамках проекта WIDE и ранее. В дальнейшем его примеру последовали и другие операторы корневых серверов. Технология Anycast позволяет каждому оператору поддерживать работу своей службы с помощью множества отдельных реплик серверов. Собственно операторов — или RSI — и сейчас остается 13, но на самом деле по всему миру работает свыше 1500 зеркал Anycast их серверов.

Для того, чтобы лучше ознакомиться с историей системы корневых серверов (RSS), почитайте документ RSSAC023v2: История системы корневых серверов. Если вас интересует дальнейшее развитие системы корневых серверов, ознакомьтесь с документом RSSAC037: Предлагаемая модель управления системой корневых серверов DNS.

1.2 Какие расчеты лежали в основе ограничения в 13 идентификаторов корневых серверов?

В 1997 году корневые серверы также выполняли роль авторитативных серверов для зон .COM, .NET и .ORG, и эта дополнительная функциональность накладывала важное ограничение на общее возможное количество идентификаторов корневых серверов, RSI. Аналогично ограничению на размер подготовительного запроса в корневой зоне, запросы NS RRSET к зонам .COM, .NET и .ORG не должны были превышать размер в 512 байт, а поскольку эти зоны обслуживались одними и теми же серверами, к ним ко всем применялось одинаковое ограничение.

Пакет ответа на запрос к DNS также содержит в себе полный текст запроса, заданного в разделе запроса. В ответе на подготовительный запрос к корневой зоне 5 байт всегда используется для раздела запроса. На параметр QNAME приходится 1 байт, и по 2 на параметры QTYPE и QCLASS, то есть всего 5. При этом для подготовительного запроса для зоны .COM раздел запроса может быть значительно больше.

Таблица 1. Распределение байтов, используемых в ответе корневого сервера на подготовительный запрос

Используется 435 байтов, 77 остается для раздела запроса QNAME. В свое время было определено, что 64 байтов должно быть достаточно для большинства запросов, отправляемых для доменов .COM, .NET и .ORG. Если добавить еще один сервер, понадобится еще 25 байтов, а поскольку 435 + 64 + 25 > 512, было решено не добавлять еще один сервер.

2.1 Почему у некоторых операторов много зеркал Anycast, а у некоторых мало?

Операторы корневых серверов (RSO) — это независимые организации, выполняющие разные мандаты и имеющие разные модели работы и источники финансирования. Этими отличиями можно объяснять разное количество зеркал Anycast, а также различия в других аспектах работы. Операторы корневых серверов обладают значительной независимостью в том, каким образом они развертывают свои сети; см. документ RSSAC042: Заявление RSSAC о независимости операторов корневых серверов. Все операторы корневых серверов обязуются предоставлять высококачественные услуги DNS.

2.2 Есть ли ограничение на количество зеркал Anycast или есть ли максимально допустимое количество?

Работа по технологии Anycast определена и описана в документах RFC 4786 «Работа по технологии Anycast» и RFC 7094 «Архитектурные аспекты использования протокола IP Anycast». Естественного предела количеству узлов в сервисе Anycast нет.

2.3 Корневые серверы выполняют репликацию и повторную публикацию авторитативной корневой зоны, а затем полученные от них данные повторно публикуются зеркалами Anycast. В чем разница между этими двумя видами повторной публикации?

Операторы корневых серверов получают данные авторитативной зоны от специалиста по обслуживанию корневой зоны (RZM). Затем каждый оператор корневого сервера использует собственную внутреннюю распределительную систему для передачи зоны на все свои сайты и зеркала Anycast.

2.4 Мы обеспечиваем хостинг зеркала Anycast одного из корневых серверов в нашем городе. Мы видим, что зеркало отвечает на запросы, поступающие со всего мира. Как сделать так, чтобы оно отвечало только на запросы из нашего региона?

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

2.5 В 2016 году имела место масштабная атака на оператора Dyn. Может ли то же самое произойти со всеми зеркалами Anycast корневых серверов?

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

2.6 Как подать запрос на размещение зеркала Anycast корневого сервера в нашей организации?

Обратитесь непосредственно к операторам корневых серверов по приведенным ниже реквизитам. Аналогично вопросу 3.4, вы также можете вместо этого рассмотреть вариант поддержания локальной копии корневой зоны, как описано в стандарте RFC 8806, и эта копия не будет считаться частью anycast-системы корневых серверов.

Также регистратура интернет-адресов стран Латинской Америки и Карибского бассейна (LACNIC) ведет проект под названием +Raices с целью способствовать созданию реплик корневого сервера Anycast в странах региона LACNIC. Дополнительная информация доступна здесь.

Таблица 2. Контактная информация для запроса реплик Anycast 

2.7 Как определить, какая реплика корневого сервера отвечает на мои запросы?

Для отправки специальных запросов к корневому серверу можно воспользоваться утилитой «dig» в компьютерной системе Unix или Mac. В ответе будет указана площадка Anycast, принявшая запрос.

Можно использовать запрос NSID и затем выполнить поиск строки NSID в разделе OPT Pseudosection вывода утилиты dig:

$ dig +nsid @a.root-servers.net
…
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1472
; NSID: 6e 33 2e 75 73 2d 77 61 73 2e 72 6f 6f 74 ("n3.us-was.root")
…

В каждом корневом сервере может использоваться своя схема именования площадок Anycast, но обычно сайты именуются с использованием кодов аэропортов IATA или LOCODE/ONU. Некоторые корневые серверы размещают свои правила именования площадок в разделе «Identifiers» своих файлов YAML, доступных по адресу https://root-servers.org/.

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

Это называется «алгоритм выбора сервера». В протоколе DNS не указано, каким образом рекурсивный DNS-сервер должен выбирать один из серверов для обработки конкретного запроса. Таким образом, каждый разработчик ПО для рекурсивного сервера определяет свой собственный алгоритм выбора сервера. В некоторых реализациях резолверы привязываются к серверу с минимальным временем отклика или к одному из серверов со временем отклика, аналогичным минимальному. В некоторых реализациях резолверы каждый раз выбирают сервер случайным образом, а в некоторых — распределяют запросы между разными серверами на основе сложных формул.

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

3.2 Каким образом DNS использует порт 53 одновременно в протоколах UDP и TCP?

По умолчанию почти все клиенты DNS для всех запросов используют протокол передачи данных UDP. Однако в некоторых ситуациях вместо этого нужно использовать протокол TCP.

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

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

Кроме того, протокол TCP может использоваться в тех случаях, когда на сервер осуществляется атака. Сервер может отправлять клиентам урезанные ответы на запросы, чтобы определить, не имеет ли место фальсификация источника запроса. Клиенты, устанавливающие соединение по TCP, могут заноситься в белый список как нефальсифицированные источники. Кроме того, может использоваться методика, которая называется «замедление времени реагирования» (RRL), когда урезанные ответы рассылаются время от времени специально, чтобы легитимные клиенты могли иметь возможность получить ответы по протоколу TCP, так как клиенты, генерирующие трафик атаки, не будут повторно отправлять запрос.

Возможность передачи запросов и ответов DNS по протоколу TCP является обязательной к реализации в любом ПО для работы с DNS. Дополнительные сведения см. в документе RFC 7766.

3.3 Каким образом можно сократить время отклика между моим рекурсивным сервером и корневым сервером?

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

Проанализируйте трафик запросов, отправляемых вашим рекурсивным сервером на корневые DNS-серверы. Если трафика больше, чем ожидается, возможно, вы можете настроить конфигурацию ваших приложений или сети таким образом, чтобы они не нуждались в столь частой отправке запросов к корневым серверам. Чтобы измерить фактическое значение времени отклика, воспользуйтесь специальным ПО, например утилитой «dig». Обычно достаточно, чтобы по меньшей мере два корневых сервера выдавали время отклика не более 100 миллисекунд.

Проанализируйте сетевой маршрут между вашим рекурсивным сервером и используемыми им корневыми серверами с помощью специальных утилит, например «traceroute». Если при этом обнаружатся какие-либо аномалии (например, маршрутизация через расположенные далеко узлы), попросите своего интернет-провайдера оптимизировать маршрутизацию.

Более подробную информацию об измерении качества обслуживания DNS можно получить из материалов проекта мониторинга качества предоставления услуг корневой зоны DNSMON, который осуществляется в рамках программы Atlas Организации европейских IP-сетей RIPE. Время отклика большинства серверов, измеряемое сотнями т. н. «якорей» RIPE Atlas, не превышает 60 мс.

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

3.4 Можно ли развернуть у себя корневой сервер самостоятельно, загрузив файл корневой зоны и самостоятельно выполнив валидацию подписи?

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

3.5 Насколько долго рекурсивный сервер кэширует информацию?

У каждой DNS-записи есть параметр времени существования (TTL), значение которого задается оператором зоны. Этот параметр определяет период, в течение которого рекурсивный DNS-сервер имен или другой клиент должен кэшировать данные для повторного использования. По истечении этого срока рекурсивный DNS-сервер имен должен снова обратиться к авторитативному серверу за свежими данными.

В отношении корневой зоны у некоторых записей задано время существования (TTL) продолжительностью 24 часа, а у некоторых — 48 часов. Некоторые резолверы имеют ограничение на максимальную продолжительность кэширования данных, обычно это 24 часа.

3.6 По прошествии соответствующего времени данные в кэше становятся неактуальными, как обновляется резолвер для отображения правильной информации DNS?

Если вы подозреваете, что данные в кэше рекурсивного DNS-сервера имен устарели, вы можете выполнить сброс кэша или перезапустить процесс сервера.

3.7 Что такое подготовительные запросы к DNS и ответы на них?

Рекурсивные резолверы DNS должны снабдить свой кэш конкретными данными из корневой зоны, прежде чем резолвер сможет отвечать на обычные запросы. В RFC 8109 описываются запросы, которые отправляют рекурсивные резолверы, а также ответы, которые они ожидают от корневых серверов.

3.8 Какую роль играет EDNS в современных DNS-запросах и как они влияют на работу корневых серверов?

EDNS — или механизмы расширения для DNS — определенные в RFC 6891 , расширяют возможности протокола DNS, сохраняя при этом обратную совместимость . Они критически важны для современных DNS-запросов и позволяют получать более объемные ответы, например, с данными DNSSEC или дополнительными записями.

3.9 Какое влияние оказывает неправильная конфигурация одного корневого сервера на всю экосистему DNS? 

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

4.1 Каким образом обеспечивается надлежащая репликация корневой зоны?

Передача файла корневой зоны от специалиста по обслуживанию корневой зоны (RZM) отдельным операторам корневых серверов (RSO) осуществляется по протоколам передачи зоны DNS (протокол AXFR, определенный в RFC 5936, и протокол IXFR, определенный в RFC 1995). Эти сообщения о передаче зоны защищаются посредством использования ресурсных записей TSIG согласно стандарту RFC 2845. Это надежные протоколы, случаи искажения данных неизвестны. Более того, поскольку корневая зона подписывается, неправильные или фальсифицированные ответы могут обнаруживаться валидаторами DNSSEC. Комитет RSSAC призывает использовать DNSSEC-валидацию во всех возможных случаях.

RZM использует операционный код DNS NOTIFY, описанный в RFC 1996 для своевременного уведомления о внесении изменений в зону, чтобы сообщить операторам корневых серверов, что для копирования или передачи доступна новая зона (напр. последняя версия).

4.2 Что такое запись ZONEMD и каким образом она обеспечивает защиту данных корневой зоны?

Поскольку никакой канал передачи не позволяет полностью исключить возможность повреждения данных, резолверы должны производить валидацию всех полученных ответов при помощи DNSSEC (см. Раздел 5). Также дополнительно развернуты другие механизмы, которые обеспечивают передачу данных каждой развернутой реплики корневого сервера максимально качественным образом. Как уже упоминалось, использование TSIG операторами корневых серверов и специалистами по обслуживанию корневой зоны позволяет проследить за отсутствием повреждений данных записи во время передачи.

В RFC 8976 описан механизм обеспечения целостности файла корневой зоны DNS с помощью записи ZONEMD, которая «содержит дайджест криптографических сообщений для данных зоны DNS в состоянии покоя». Текущая корневая зона содержит запись ZONEMD, содержащую цифровую подпись корневой зоны.

Запись ZONEMD даст возможность получателям полной корневой зоны проверять содержимое зоны на предмет целостности данных и подлинности их происхождения. DNSSEC обеспечивает подлинность ответов, получаемых конечными пользователями данных с подписью DNS (включая корневую зону), независимо от маршрута их передачи и того, какие серверы обрабатывали данные на этапе передачи.

4.3 На какой стадии находится сейчас внедрение ZONEMD в работе корневых серверов?

ZONEMD (Zone Message Digest, дайджест сообщений зоны) — это технология, предназначенная для усиления проверки целостности данных зоны DNS. Хотя в настоящее время операторы корневых серверов не обязаны следить за выполнением валидации ZoneMD, они наблюдают за ее развитием и внедрением. На данном этапе происходит тестирование ZONEMD в реальных сценариях, анализ его влияния на производительность и решение эксплуатационных сложностей. 

5.1 Делает ли DNSSEC конфиденциальными запросы или ответы DNS?

Нет, DNSSEC только добавляет еще один уровень безопасности в инфраструктуру DNS за счет проверки происхождения и защиты данных DNS.

5.2 Усложняет ли DNSSEC процедуру передачи копии корневой зоны в локальной сети?

Нет, передача локальной копии корневой зоны просто значит, что используются актуальные копии корневой зоны без каких бы то ни было изменений. Корневая зона поступает от специалиста по обслуживанию корневой зоны (RZM) со всеми необходимыми подписями DNSSEC.

6.1 Открыты ли заседания RSSAC для всех?

RSSAC периодически проводит телеконференции и заседания в ходе конференций ICANN. Протоколы заседаний и телеконференций (при наличии) доступны здесь. Чтобы принять участие в телеконференции или рабочем заседании RSSAC в качестве наблюдателя, обращайтесь за информацией об участии в удаленном режиме по адресу [email protected].

Большинство заседаний RSSAC на конференциях ICANN открыто для наблюдателей, за исключением заседаний, отмеченных в повестке дня ICANN как закрытые. Также RSSAC проводит открытые заседания в рамках конференций ICANN, на которых члены сообщества могут задавать вопросы.

6.2 Как друг с другом связаны RSSAC и SSAC?

RSSAC и Консультативный комитет по безопасности и стабильности (SSAC) — консультативные комитеты сообщества ICANN преимущественно технической направленности, но сферы их деятельности различаются. RSSAC занимается только «управлением, обслуживанием, безопасностью и целостностью системы корневых серверов», а SSAC занимается «вопросами, связанными с безопасностью и целостностью систем распределения имен и адресов интернета».

Сферы деятельности этих двух групп имеют точки пересечения. Для осведомленности о работе друг друга, SSAC назначает в RSSAC своего представителя. Также SSAC и RSSAC проводят совместные заседания на конференциях ICANN.

Деятельность SSAC описана в разделе 12.2(b) Устава ICANN. Дополнительная информация доступна здесь.

6.3 Как друг с другом связаны RSSAC и RZERC? Является ли RZERC частью RSSAC?

Консультативный комитет системы корневых серверов (RSSAC) и комитет по анализу изменений корневой зоны (RZERC) — это два разных комитета в составе ICANN, но они обмениваются между собой представителями, а некоторые индивидуальные члены могут входить в состав обоих комитетов.

Согласно уставу RSSAC, комитет
«...предоставляет Правлению и сообществу ICANN рекомендации в отношении обслуживания, безопасности и целостности системы корневых серверов, а также управления этой системой». Подробнее о роли RSSAC см. в документе RSSAC033: Заявление RSSAC о различиях между RSSAC и Root-Ops.

В уставе RZERC записано, что он
«...занимается анализом предлагаемых архитектурных изменений содержания корневой зоны DNS, систем (включая их аппаратное обеспечение и программные компоненты), используемых для внесения изменений в корневую зону DNS, и механизмов, применяемых для распространения корневой зоны DNS».

На схеме ниже поясняется роль каждого из этих комитетов.

6.4 Есть ли какой-то срок, к которому мы сможем узнать, сколько корневых серверов необходимо по мнению RSSAC? Когда будет проведена оценка необходимости того или иного количества буквенных серверов?

У RSSAC нет никакого сложившегося мнения о том, сколько должно быть корневых серверов или их операторов. Текущее ограничение количества операторов обусловлено техническими, а не административными соображениями.

6.5 Где можно ознакомиться с публикациями RSSAC?

Публикации RSSAC доступны на странице публикаций RSSAC. Желающим узнать больше о системе корневых серверов будут особенно интересны документы RSSAC023v2: История системы корневых серверов и RSSAC026v2: Глоссарий RSSAC.

6.6 В чем состоит роль RSSAC в общем процессе разработки политик ICANN?

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

6.7 Как индивидуальные лица или организации могут предоставлять обратную связь и взаимодействовать с RSSAC?

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

Информацию о Группе подготовки документов RSSAC см. на главной странице сайта группы.

7.1 В чем разница между членом RSSAC и членом Группы подготовки документов RSSAC?

В состав RSSAC входят назначенные представители и дублеры всех операторов корневых серверов, а также представители других групп. В состав Группы подготовки документов RSSAC входят эксперты в области DNS, которые интересуются работой системы корневых серверов. Большую часть рекомендаций (но не все), публикуемых RSSAC, готовит Группа подготовки документов RSSAC. RSSAC представляет собой официальный консультативный комитет, который окончательно утверждает публикации для передачи Правлению и сообществу ICANN.

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

7.2 Открыты ли заседания Группы подготовки документов RSSAC для всех?

Группа подготовки документов RSSAC проводит общие собрания во время ежегодных общих собраний ICANN и на каждом четном мероприятии IETF. Все эти общие собрания открыты для наблюдателей. Рабочие собрания Группы подготовки документов RSSAC закрыты для наблюдателей.

Все члены Группы подготовки документов RSSAC могут принимать участие во всех общих собраниях Группы подготовки RSSAC и рабочих собраниях Группы подготовки документов RSSAC.

7.3 Есть ли какое-либо ограничение на количество членов Группы подготовки документов RSSAC?

Нет.

7.4 Сколько времени должны уделять члены Группы подготовки документов RSSAC участию в работе?

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

7.5 Как Группа подготовки документов RSSAC участвует в разработке публикаций и рекомендаций RSSAC?

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

Для того, чтобы ознакомиться с DNS, см. материал Объяснение принципов работы системы доменных имен интернета для неспециалистов, автор Даниэль Карренберг (The Internet Domain Name System Explained for Non-Experts by Daniel Karrenberg).

8.1 Определяют ли корневые серверы, куда будет направлен сетевой трафик?

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

8.2 Большинство DNS-запросов обрабатываются корневыми серверами?

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

8.3 Имеют ли какие-либо из идентификаторов корневых серверов какое-то особое значение?

Ни один из идентификаторов корневых серверов не является особенным.

8.4 Корневых серверов всего 13?

По всему миру расположено свыше 1500 серверов, которые соответствуют всего 13 идентификаторам корневых серверов (RSI), каждый из которых использует один IPv4-адрес и один IPv6- адрес, а также Anycast-маршрутизацию.

8.5 Операторы корневых серверов работают независимо друг от друга?

Да, операторы корневых серверов работают независимо друг от друга, но они тесно координируют работу между собой через комитет RSSAC и прочие форумы. Подробнее см. документ RSSAC042: Заявление RSSAC о независимости операторов корневых серверов.

8.6 Корневые серверы получают только ту часть DNS-запроса, которая касается TLD?

В настоящее время корневые серверы (и на самом деле все серверы DNS) обычно получают в составе DNS-запроса полное запрашиваемое имя (Query Name). Однако сейчас ведется работа над новой функцией DNS, которая будет передавать корневым серверам при необходимости только ту часть доменного имени, которая касается TLD.

В документе RFC 9156 изложено, каким образом рекурсивные серверы DNS могут передавать только минимально необходимую часть Query Name. Это т. н. минимизация запрашиваемого имени, или QNAME Minimization. Техника QNAME Minimization сводится к тому, что рекурсивные серверы DNS передают на запрашиваемые ими серверы только необходимые части доменного имени. Рекурсивные DNS-серверы, использующие технику QNAME Minimization, должны передавать корневым серверам только ту часть запроса, которая касается домена верхнего уровня. Это позволяет сократить объем передаваемой информации и тем самым обеспечить больший уровень конфиденциальности для пользователей, обращающихся к системе DNS.