пересматривается положение о принципах работы корневых ДНС

Pablos Vasilyev, [20.10.17 21:12]

Другие трюки

добро пожаловать

Только RFC

Только плейлисты

Ева

Поиск в этом блоге: 

RFC 8244 : Заявление о проблемах с именами заданий специального использования

Дата публикации RFC: октябрь 2017 г. RFC 

Автор (ы): Т. Лимон (Номин), Р. Дромс, У. Кумари (Google) 

Информация, 

подготовленная в рамках рабочей группы IETF dnsop

Первая редакция этой статьи о 20 октября 2017 года

RFC 6761 создан реестр из « доменных имен специального использования», где IETF записанных имен , которые могут потребовать специального обращения со стороной органов системы дозаправки топлива и разрешающими доменными именами. Примером может служить доменные имена , которые не были с помощью DNS , например, .onionв RFC 7686 . Некоторые люди высказали оговорки в отношении этого реестра, например, потому что они шли по газону, который ICANN считает своим. Этот новый , весьма противоречивый RFC список всех критических замечаний, которые были сделаныRFC 6761 и его регистр специальных имен.

Разрешение имен - начиная с имени домена и получения информации, такой как IP-адрес, - одна из важнейших функций Интернета . Поэтому принято относиться к этому очень серьезно. И имена имеют ценность для пользователей (продажа записей, похоже, такова business.com). Часто, но не всегда , эта резолюция выполняется с DNS . Но я сказал, не всегда: не путайте имена доменов (дерево организации, синтаксис, компоненты , разделенные точками , например _443._tcp.www.bortzmeyer.org., réussir-en.fr.или 7j3ncmar4jm2r3e7.onion.) и DNS, конкретный сетевой протокол (раздел 2 RFC, для терминологии). Раздел 2 этого RFC, как определено в RFC 7719 , не считает, что доменное имя обязательно использует DNS. (Задача 20 в разделе 3 повторяет этот вопрос).

Регистр специальное доменное имя было создано в 2013 году RFC 6761 . Вопреки тому, что многие считают, он не содержит только TLD (например, он также имеет a.e.f.ip6.arpaили делает example.org). С момента своего создания было добавлено несколько имен, наиболее впечатляющее из которых было .onionв 2015 году, через RFC 7686 . Было предложено много других имен, не будучи явно отвергнутым, но не принимаемым (см. « Интернет-проекты» draft-grothoff-iesg-special-use-p2p-gns и draft-chapin-additional-reserved-tlds). Эти записи шли не очень хорошо, с большим количеством криков, особенно для TLD .

Действительно, борьба всегда бушевала для управления именами в корне DNS . Существует пять типов TLD:

Те , положить в корень общественного DNS, так как .bo, .net, .guruи т.д. Вопреки тому, что RFC говорит, они не обязательно делегируются ICANN ( .deбыл создан задолго до ICANN и .suдолгое время сопротивлялся всем попыткам ICANN удалить его).

Те, которые управляются IETF «по техническим причинам» и которые иногда делегируются общественному корню, самое известное существо .arpa. Домены регистра специальных имен являются его частью. Поклонники управления заметят, что они никогда не проходят через ICANN.

Те, которые ICANN блокируют по различным причинам (см. Их правила , в частности разделы 2.2.1.2.1 или 2.2.1.4.1).

Привыкшие за пределами корневого публичного DNS, так как .eth для Эфириума или .bitдля Namecoin . Это также включает имена, которые широко используются локально как .homeили .corp.

И те, кто свободен, кого никто еще не использует. Завтра, может быть, .macronбудут использованы поклонники президента ?

Эта классификация несовершенна, как и все классификации . Например, имя может быть в черном списке ICANN и может по-прежнему использоваться местными организациями или через конкретное программное обеспечение.

Этот RFC хочет представить исчерпывающий список проблем, возникающих при регистрации этих специальных имен. Поскольку он является исчерпывающим (« нефильтрованная сборка вопросов »), он не согласен, далек от него! Многие из проблем не рассматриваются как таковые всеми, как RFC отмечает в разделах 1 и 3.

Pablos Vasilyev, [20.10.17 21:12]

Поэтому основная часть RFC - это список проблем, в разделе 3. Я не буду приводить их всех. Обратите внимание, что этот RFC описывает проблемы или воспринимается как таковые некоторыми, а не решениями. Он не предлагает реформу RFC 6761 . Также обратите внимание, что проблемы не сортируются (их порядок воздействия и количество, которое они получают, не имеют значения.)

Первая упомянутая проблема, координация с ICANN . Пять категорий названий TLD, упомянутых выше, сосуществуют в одном пространстве имен. Если их два .macron, возникнет проблема (см., Например, отчет SAC 090 , но помните, что ICANN является самозащитой). У IETF и ICANN есть механизм взаимной информации, но нет формального бюрократического процесса координации. Если IETF хочет зарезервировать .home ( RFC 7788), нет официального механизма для передачи этого решения ICANN и получения подтверждения от ICANN о том, что имя иначе не забронировано. (См. 4.1.4, который возвращается к этому механизму - « связь » на английском языке.)

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

Задача 2 - это определение «по техническим причинам», введенное в RFC 2860 , которое устанавливает право IETF на резервирование TLD без прохождения проверки ICANN (« присвоения доменных имен»). Для технических целей см. Раздел 4 "). Проблема в том, что эти технические причины нигде не определены, и никто не знает, что это значит.

Проблемы 3 и 4 заключаются в том, что нет начальника Интернета. Ни ICANN, ни IETF (и, разумеется, МСЭ ) не признаются ни по закону, ни по сути, как имеющие какие-либо полномочия (журналистский ярлык для представления ICANN как «глобального регулятора Интернет "смехотворно ложно). Представьте себе, что разработчик создает новое программное обеспечение, которое использует TLD .zigzagдля его именования, и транслирует данное программное обеспечение: никто не может его предотвратить, даже если ICANN страдает от потери потенциального дохода, даже если он мрачен IETF шумно шепчет, что он сидит на корточках(см. также начало раздела 4). К счастью, это « беспроблемная инновация », которая так важна для успеха Интернета. Другим примером является, конечно же, проект .42 , который теперь оставлен, но иллюстрирует эту децентрализованную сторону Интернета.

В определении проблемы 5 отмечается, что организации или отдельные лица используют TLD (или любые домены, но в основном на TLD, которые фокусируют обсуждение), не следуя процедурам. У них есть несколько причин для этого:

Pablos Vasilyev, [20.10.17 21:12]

Они не знают, что есть процедуры (это, вероятно, самый распространенный случай).

Они смутно знают, что есть процедуры, но они говорят, что для чисто местного использования это не важно. С другой стороны, трафик на корневых серверах имен показывает, что важны утечки: локальные имена не остаются. Не говоря уже о риске «столкновений» между якобы чисто локальным именем и распределением ICANN: .corp и .homeявляются очень популярными местными TLD, и есть приложения (в настоящее время де-факто замороженные ) для этих TLD в ICANN

Процедуры существуют, организация знает их, но она не открыта. Так обстоит дело, например, с TLD ICANN, для которых в настоящее время нет цикла приложений, а следующий не ожидается до 2019 года или 2020 года.

Процедуры существуют в ICANN, организация знает их, она открыта, но цена падает (185 000 долларов США до предыдущего цикла ICANN и только для файла).

Процедуры существуют в IETF, организация знает их, она открыта, но организация намеренно отказывается участвовать (случай похож на CARP ).

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

Тогда проблема 6: существует несколько протоколов разрешения имен, а DNS - только основной. В отсутствие метаданных, указывающих протокол, который будет использоваться (например, в URL-адресах ), использование TLD в качестве «реферала» является заманчивым решением ( if tld == "onion" then use Tor elsif tld == "gnu" then use GnuNet else use DNS...)

Регистр специальных доменных имен - это, по сути, свободный текст, без формальной грамматики . Это означает, что конкретный код, который может понадобиться для обработки всех этих специальных доменов (например, распознаватель должен знать, что .onionDNS не использует его, и поэтому бесполезно отправлять его в корневой каталог) должен быть сделан вручную, он не может быть автоматически получен из регистра (проблема 7). В результате, когда новый домен добавляется в этот реестр, он будет обрабатываться «нормально» с помощью программного обеспечения, которое не обновляется, и в течение довольно долгого времени. Например, запросы будут отправляться в корневой каталог, что создает проблемы конфиденциальности (см. RFC 7626 ).

Как отмечалось выше, некоторые кандидаты на специальное доменное имя обеспокоены временем, которое потребуется для рассмотрения их заявления и риска отклонения (выпуск 8). Они не ошибаются. Запись .local( RFC 6762 ) заняла десять лет, и усилия Кристиана Гротоффа по записи .gnuзастряли в толстых слоях бюрократии. Возможно, это не совпадение, что Apple закончила свою .local(не без зла), в то время как бесплатные программные проекты, такие как GNUnet, были закрыты.

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

Pablos Vasilyev, [20.10.17 21:12]

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

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

Убеждение, что пространство имен «принадлежит» IETF и / или ICANN, и что те, кто резервирует TLD без прохождения официальных процедур, являются вульгарными скваттерами .

Не говоря уже о риске, если есть простой и бесплатный способ зарегистрировать TLD через IETF, что никто не кормит средства ICANN.

И, наконец, юридический риск: если Сер Давос подал в суд на IETF против регистрации .onion, это может занять много времени и денег. ICANN несет тот же риск, но у нее есть адвокаты в количестве и деньги, чтобы заплатить за них.

Проблема 11 больше связана с самой RFC 6761 . Этот RFC иногда неправильно понимал, как и для записи ipv4only.arpa ( RFC 7050 ), и особенно .home( RFC 7788 , который цитировал RFC 6761, но не выполнил ни одного из своих обязательств). См. Также проблему 16.

Проблемы 12 и 13 связаны с существующими TLD (в том смысле, что они используются), но официально не зарегистрированы (см., Например, отчет ICANN о «столкновениях» ). Было бы хорошо документировать это использование где-нибудь, чтобы, например, убедиться, что они не делегированы ICANN. Но пока это не сработало.

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

Проблема заключается в различии между записью использования и ее утверждением. С правилом, «управляемым IETF для технического использования» RFC 2860 , невозможно зарегистрировать имя без какой-либо «одобрения». (Многие из статей о регистрации, .onion таким образом, неправильно заявили, что «официально утвержденный IETF Tor »).

Проблема 17 является хорошим примером того, что список Prevert этого RFC действительно «нефильтрован» и что любые замечания были сделаны независимо от его достоинств. Он состоит в том, что использование регистра специальных имен является непоследовательным, потому что записи предоставляют разные правила в соответствии с именем. Это не противоречиво, оно было с самого начала задумано RFC 6761 (раздел 5): нет причин для лечения таким же образом .onion(который вообще не использует DNS) и .bit(шлюз между DNS и Namecoin ).

Проблема возникает из-за того, что имена доменов не являются чистыми техническими идентификаторами, как, например, MAC-адреса . Они имеют смысл для пользователей. Хотя, технически говоря, разработчики Tor могли выбрать имя .04aab3642f5или onion.torproject.org как суффикс для луковых сервисов , они предпочли однокомпонентное имя и понятны .onion. Это желание вполне понятно (предложение IETF заключается в том, чтобы отменить все специальные имена под будущим TLD.alt, который, вероятно, не будет успешным, даже если он будет создан один день). Но это вызывает повышенное давление на корень доменных имен: если резервируются два проекта .zigzag, какое из двух видов использования должно быть зарегистрировано?

Наконец, последняя проблема, 21-го, более техническая: она касается DNSSEC . Если TLD зарегистрирован как специальный домен, должен ли он быть добавлен в корень DNS, и если да, то должна ли эта делегация быть подписана? Если нет делегирования, TLD будет считаться недействительным с помощью проверяющих разрешителей. Например, если я сделаю запрос quelquechose.zigzag, корень DNS ответит:

% dig @ k.root-servers.net В чем-то.zigzag

; « » DiG 9.10.3-P4-Debian « » @ k.root-servers.net В чем-то.zigzag

; (Найдено 2 сервера)

;; глобальные параметры: + cmd

;; Получил ответ:

;; - » HEADER « - код операции: QUERY, статус: NXDOMAIN, id: 7785

;; flags: qr aa rd; QUERY: 1, ОТВЕТ: 0, АВТОРИТЕТ: 6, ДОПОЛНИТЕЛЬНО: 1

;; ПРЕДУПРЕЖДЕНИЕ: запрошенная рекурсия, но недоступна

Pablos Vasilyev, [20.10.17 21:12]

;; ОПТИМИЗАЦИЯ ОПТ:

; EDNS: версия: 0, flags: do; udp: 4096

;; РАЗДЕЛ ВОПРОСА:

; Quelquechose.zigzag. IN A

;; РАЗДЕЛ АВТОРИТЕТА:

Ноль. 86400 IN NSEC zip. NS DS RRSIG NSEC

Ноль. 86400 В RRSIG NSEC 8 1 86400 (

    20171017050000 20171004040000 46809.

    wyKfrNEygGCbDscCu6uV / DFofs5DKYiV + jJd2s4xkkAT

    ...

, 86400 В НСЕК гг. NS SOA RRSIG NSEC DNSKEY

, 86400 В RRSIG NSEC 8 0 86400 (

    20171017050000 20171004040000 46809.

    kgvHoclQNwmDKfgy4b96IgoOkdkyRWyXYwohW mpfG + R

    ...

, 86400 В SOA a.root-servers.net. nstld.verisign-grs.com. (

    2017100400; последовательный

    1800; обновить (30 минут)

    900; повторить попытку (15 минут)

    604800; истекает (1 неделя)

    86400; минимум (1 день)

    )

, 86400 IN RRSIG SOA 8 0 86400 (

    20171017050000 20171004040000 46809.

    GnTMS7cx XB + + + EmbMFWt yEAg29w17HJfUaOqvPsTn0eJ

    ...

;; Время запроса: 44 мс

;; СЕРВЕР: 2001: 7fd :: 1 # 53 (2001: 7fd :: 1)

;; КОГДА: Ср. Oct 04 12:58:12 CEST 2017

;; MSG SIZE rcvd: 1036

И запись NSEC докажет, что между .zeroи не существует ничего и .zip, заставляя проверяющий распознаватель считать, что .zigzagне может существовать. Если имя должно было обрабатываться DNS (и, например, разрешено локально, как в RFC 6303 , это правильный ответ: запрос не должен был идти в корень). В других случаях это может быть неловко. В любом случае дебаты довольно теоретические: IETF не имеет власти над корнем DNS и не может добавить имя.

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

Давайте начнем с RFC 2826 о необходимости использования одного корня. Это документ IAB и поэтому не затрагивает IETF, хотя он часто упоминается как священный текст. Его главный тезис состоит в том, что он принимает один корень, а значит .zigzag, .pmили .exampleдолжен иметь одинаковый смысл во всем мире, под угрозой значительной путаницы у пользователя. Это не запрещает имена для локального использования при условии, что они остаются локальными. Поскольку пользователи не будут иметь значения, эти локальные имена неизбежно будут течь рано или поздно. (Например, пользователь, который смотрит наhttp://something.corp/не поймут, что это имя работает только с помощью решений компании и будет пытаться получить к нему доступ из дома. Другим примером может быть пользователь, пытающийся ввести ping 7j3ncmar4jm2r3e7.onionиз командной строки, не понимая, что ping не знает Tor .)

Короче говоря, RFC 2826 четко заявляет, что необходим один корень, а локальные имена - челюсти.

Второй RFC для чтения, очевидно, является RFC 6761 , который создал реестр специальных доменных имен . Он является документом IETF на Chemin des Normes. Некоторые вещи, которые часто забывают читатели RFC 6761, заслуживают повторения :

Некоторые специальные имена на самом деле не так и фиксируются DNS обычным способом ( in-addr.arpaнапример, это так, и помните, что специальные доменные имена не обязательно TLD).

Иногда, специальные имена разрешается DNS , но необычно, поскольку 10.in-addr.arpa (для IP - адресов в RFC 1918 ), которые должны быть обработаны распознавателем, никогда не подвергая сомнению корня (см RFC 6303 ).

Другие специальные имена имеют особое значение и вообще не должны использовать DNS. Они служат в качестве «переключателей», чтобы указать библиотеку разрешения имен (например, GNU libc на Ubuntu или Mint ), которые вам необходимо изменить. В этом случае .onion(который должен использовать Tor ) или .local(который должен использовать mDNS , RFC 6762 ).

И все эти случаи действительны и нормальны (хотя некоторые традиционалисты в IETF неохотно делают это).

Обратите внимание, что в настоящее время все имена, зарегистрированные как специальные доменные имена, являются TLD или разрешены DNS.

Pablos Vasilyev, [20.10.17 21:12]

Третий RFC читает абсолютно, прежде чем говорить глупости о специальных доменных именах, RFC 2860 , который устанавливает рамки для сложных отношений между IETF и ICANN. В принципе, правило по умолчанию заключается в том, что добавление (или удаление) TLD к корню является прерогативой ICANN, за исключением «доменных имен для технического использования» (неопределенное понятие ...), где IETF решает , Обратите внимание, что этот документ касается только отношений между IETF и ICANN. Если W3C или разработчик программного обеспечения ZigZag хочет создать TLD, что произойдет? Это не рассматривается в RFC 2860 . Некоторые экзегеты считают, что это означает, что эти третьи стороны неявно исключены.

Существуют и другие документы, но менее важные. RFC 6762 , который стандартизирует MDNS это тот , кто забронирован .localтак что это пример успешной регистрации (но были кропотливым, требовалось более двенадцати лет развития, в Приложении Н RFC 6762 ).

Другой удачный пример, то RFC 7686 на .onion. .onionбыл использован в течение длительного времени, когда RFC 6761 создал регистр специальных доменных имен. Запись пост был успешным, несмотря на энергичную оппозицию , но обратите внимание , что IETF грубого консенсус способствовали решению CA / B Forum не больше не выделять сертификаты для внутреннего TLD .

Еще один RFC для чтения, RFC 6303 , который описывает имена, которые в идеале должны быть локально устранены, то есть с помощью распознавателя пользователя, без запроса авторитетных серверов. Так обстоит дело, например, с in-addr.arpa соответствующими частными IPv4-адресами в RFC 1918 . Бесполезно просить корень записи PTR из 3.2.1.10.in-addr.arpa : IP - адрес чисто локальный, он не может быть умным корень ответа. 10.in-addr.arpa Поэтому имена должны быть разрешены локально, а также «специальные доменные имена». К минусам, в отличие от .localили к .onion, они разрешаются DNS.

Не устал? Все еще хотите читать? Существует также исследование Interisle о «столкновениях». За этим сенсационным именем, предназначенным для напугания, существует реальная проблема - риск того, что недавний TLD маскирует или замаскирует ДВУ, размещенный локально, не думая (например .dev). Исследование показало, например, что именно .homeэто создает наибольший риск.

По аналогичной теме есть также исследование ККБС , комитет ICANN .

Ранее было сказано, что «специальные» доменные имена не обязательно являются TLD. Это, например , случай имя , используемое для некоторых операций IPv6 , ipv4only.arpaсозданного RFC 7050 , но из - за путаницы в процессе, не была добавлена в регистр специальных доменных имен , Слишком плохо: это имя, не являющееся ДВУ и не имеющее особой ценности, не было проблемой и было принято быстро.

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

Если на данный момент у вас нет головной боли, вы все равно можете прочитать раздел 5, в котором упоминается мучительная история этой концепции специальных доменных имен. Когда DNS был произведен ( RFC 882 и RFC 883 ) для замены старой системы HOSTS.TXT ( RFC 608 ), переход не был безболезненным, поскольку сосуществовали несколько систем разрешения (наиболее серьезным из которых является, вероятно, желтый Страницы в Unix , но также была служба имен NetBIOS / WINS , которая не была запущена только в Windows ). Даже сегодня старые системы разрешения все еще работают. HOSTS.TXTсохраняется в виде /etc/hostsUnix (и его эквивалента Windows ). В операционных системах , как правило , имеют «переключатель» , который может сказать , что разрешение механизм использовать любое имя. Вот пример /etc/nsswitch.confмашины Debian для разрешения имени домена, будут использовать последовательно /etc/hosts, LDAP и DNS:

Pablos Vasilyev, [20.10.17 21:12]

хосты: файлы ldap dns

Концепция частного ДВУ, известная только локально, была (ошибочно) рекомендована некоторыми компаниями, такими как Sun или Microsoft . Он пережил исчезновение технологий, которые использовали его, как « Желтые страницы» . Сегодня это источник бесконечных проблем, и многие сетевые администраторы проклинают своего предшественника для создания всей локальной сети, зажигания бомбы, которая взорвалась бы, когда «частный» TLD оказался делегировать.

Обсуждение в IETF, особенно в его рабочей группе DNSOP, было очень жарким. Был разработан первый документ, draft-adpkja-dnsop-special-names-problemа затем был составлен предок этого RFC, первый документ был отброшен (это было очень близко к мнению ICANN, что только ICANN должна иметь возможность создавать TLD, другие актеры - всего лишь скверные сквоттеры).

Загрузить RFC 8244

PDF-версию этой страницы (но вы также можете распечатать из своего браузера, для этого есть таблица стилей)

XML-источник этой страницы (эта страница распространяется в соответствии с условиями лицензии GFDL )

Pablos Vasilyev, [20.10.17 21:12]

WTF ?(:

tvoi kotik, [20.10.17 21:12]

Эм

Pablos Vasilyev, [20.10.17 21:13]

очен просто поменяют принципы....

tvoi kotik, [20.10.17 21:13]

Это с конференции сетевиков?

Pablos Vasilyev, [20.10.17 21:15]

нет- это с переписки глобальной администрации И-нета за сегодня

Pablos Vasilyev, [20.10.17 21:15]

вот и куда с этим идтм ?

Pablos Vasilyev, [20.10.17 21:15]

идти