Что мешает организации создавать и владеть любым неиспользуемым конкретным доменом, i.e..edu


Недавно мы получили электронное письмо на работе с сайта .edu, который, похоже, был фишинговым. Однако я не хотел игнорировать возможное законное электронное письмо от клиента без должной осмотрительности. Я начал думать о возможных способах, которыми это может быть ложное электронное письмо, чтобы определить, следует ли игнорировать электронное письмо или попытаться связаться с организацией, связанной с этим письмом, каким-либо другим способом. Это в конечном итоге привело к кроличьей норе к вопросу, который я не смог найти точный ответ для:

Что мешает очень хорошо финансируемой организации создать любой неиспользуемый домен сайта, который они выбирают (т. е. something.edu ) и возможность его поиска/использования во Всемирной паутине без прохождения через такую организацию, как IANA

Прочитав Google и Википедию, я получил очень общее представление о том, что существуют организации, в которых хранятся базы данных пространств имен и доменов (я полагаю, ICANN), и есть регулирующие органы, которые авторизуйте, кто может получить какие домены (т. е. IANA, часть ICANN), аккредитованные в рДВУ. Однако я не нашел конкретно , как регулируются домены и что заставляет организации получать домены от этих организаций. Также было бы интересно узнать, как глубокая сеть вписывается/не вписывается во все это.

Author: Stephen Ostermiller, 2017-07-20

2 answers

Что мешает очень хорошо финансируемой организации создать любой неиспользуемый домен сайта, который они выбирают (т. е. something.edu ) и возможность его поиска/использования во Всемирной паутине без прохождения через такую организацию, как IANA?

Ответ, который вы ищете, - это сама система доменных имен Интернета (DNS).

IP-адреса и доменные имена

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

С помощью системы DNS Интернета мы можем (в настоящее время) ввести http://216.58.216.174 в браузер и перейдите к https://www.google.com .

Но как нам перейти от 216.58.216.174 к google.com?

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

    google.com.    IN A    216.58.216.174

Этот файл соответствует IP-адресу Google и его доменному имени в Интернете и это то, что в конечном итоге сообщает браузеру, с каким компьютером связаться google.com.

Разбивка Доменных Имен

Следующая часть головоломки - "как мы получим эту запись?"

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

  1. Мы хотим связаться с давно потерянной тетей Долорес в Талсе, хорошо. Но у нас нет ее номера телефона.
  2. Мы называем Центральную информацию и вежливо спрашиваем какой у нее номер.
  3. Центральная информация не знает, поэтому они связали нас с Информацией Оклахомы.
  4. Информация Оклахомы не знает, поэтому они связали нас с информацией Талсы.
  5. В информации Талсы есть номер тети Долорес, и они дают его нам.
  6. Наконец мы вешаем трубку и звоним тете Долорес напрямую с ее номером телефона.

Чтобы применить приведенный выше пример к доменному имени в Интернете, возьмите нашу предыдущую запись для google.com:

    google.com.    IN A    216.58.216.174

Обратите внимание на период в конце google.com . Это важно, но обычно не отображается в браузере.

Чтобы разбить запрос на google.com в терминах, аналогичных примеру нашей тети Долорес:

  1. Мы пытаемся запросить IP-адрес google.com . Доменные имена фактически анализируются в обратном порядке (справа налево, а не слева направо). Это означает, что google.com становится .com.google.
  2. Наш запрос направлен в Корневые серверы, управляемые IANA (Центральная информация). Эти корневые серверы обозначаются символом "." (точка, также называемая пустой строкой) в системе DNS Интернета.
  3. Далее мы отправляемся на серверы, на которых размещен правильный Домен верхнего уровня (TLD). В этом случае TLD - это .com. Эти серверы управляются различными организациями, известными как Реестры доменных имен. В нашем примере одним из них была бы информация об Оклахоме.
  4. Затем нас направляют к серверы, на которых размещен фактический файл, содержащий наш пример записи DNS в Интернете, перечисленных выше (эквивалентно информации Tulsa).
  5. Как только мы получим соответствие этой записи DNS 216.58.216.174 к google.com , теперь наш компьютер может напрямую использовать эту информацию для связи с этим сайтом, используя его IP-адрес за кулисами (мы все еще видим google.com в браузере).

На шаге 4 "Информация о Талсе" - это системные пользователи сервера имен, которые обычно подумайте о том, когда они говорят о "настройке DNS" для домена (например, ns1.domain.tld, ns2.domain.tld).

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

Как Насчет Регистраторов Доменов?

В этой иерархии для DNS Интернета, которая контролируется IANA и реестры доменов верхнего уровня, только Регистраторам доменов разрешено обновлять информацию непосредственно в центральном реестре. Регистраторы доменов могут быть отдельной организацией (например, GoDaddy), самим Реестром доменных имен или использовать смешанную систему.

В любом случае это означает, что вы должны пройти через них, чтобы получить, например, example.com поскольку они единственные, кому доверяют добавлять эту информацию в правильные базы данных (те, которые контролируются Реестрами доменных имен на шаге 3 выше).

Сторонние регистраторы часто встречаются с Общими ДВУ, такими как .com, .net, . org и т.д. Это компании, с которыми большинство людей привыкло иметь дело.

Существуют также ДВУ с кодом страны , которые представляют собой двухбуквенные домены для конкретной страны (например, .de для Германии), где авторизованный реестр часто является регистратором (, но не всегда - некоторые используют смешанный подход).

[Ш]шляпа должна запретить другой организации размещать базу данных с доменами верхнего уровня, такими как .edu, и подключать к ней других пользователей?

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

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

Кроме того, это, скорее всего, нарушит возможность доступа к существующим доменам, что означает, что люди, вероятно, все равно не захотят его использовать.

Тем не менее, этот общий тип действий иногда выполняется в гораздо меньших масштабах хакерами, которые не заботятся о том, чтобы атака была широко распространенный.

Зачем нам вообще нужно проходить через [какую-то другую организацию] для создания доменов верхнего уровня?

Технически, вы этого не делаете. Любая система DNS может гипотетически создать любой "TLD", который она пожелает. Но вы сталкиваетесь с проблемой "распространения" выше. ДВУ полезны только для систем, которые настроены на их распознавание.

Например, я могу настроить систему дома, в которой я могу использовать DNS для доступа к своим локальным компьютерам, например домен1.pop, домен2.pop, домен3.pop и т.д. Но поскольку никакая другая служба DNS не настроена для распознавания моего вымышленного домена .pop, это в основном бесполезно при попытке установить соединение с другим компьютером за пределами моей локальной сети.

А как насчет глубокой паутины?

Глубокая сеть - это, по сути, все, что недоступно широкой публике. То, о чем вы, вероятно, думаете, более точно называется Темной паутиной.

Это состоит из таких вещей, как Tor и I2P, сетей, которые используют IP-адреса (как они должны), но обычно обходят любую форму DNS для подключения (включая систему DNS Интернета).

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


[...] Я не нашел конкретного способа регулирования доменов.

ICANN и ЯНА

  • ICANN осуществляет надзор за общими доменами верхнего уровня (рДВУ) и связанными с ними организациями. Это включает в себя общие Реестры доменных имен и аккредитованных ICANN Регистраторов доменов.
  • IANA делегирует Домены верхнего уровня с кодом страны (ccTLD) национальным реестрам доменных имен.
  • Спонсируемые домены верхнего уровня (STLD) обычно подпадают под сферу компетенции либо ICAAN, либо IANA.

IANA также отвечает за некоторые особые вещи в Интернете Система DNS , такая как .зона arpa и другие критические зоны (например, root-servers.net).

Реестры Доменных имен

  • Реестры доменных имен управляют отдельными ДВУ и отвечают за повседневные операции. Они также несут ответственность за соблюдение любых руководящих принципов ICANN, IANA или других агентств, которые могут к ним применяться.
  • Для рДВУ Реестры доменных имен обычно являются частными компаниями (либо коммерческими, либо некоммерческими) и являются подотчетен ICANN.
  • Для ccTLD Реестрами доменных имен являются национальные реестры, такие как DENIC в Германии и Nominet в Соединенном Королевстве. Что касается надзора, то задействованные учреждения сильно различаются.
  • Для доменов верхнего уровня реестры доменных имен и подотчетность являются смешанными. Например, IANA управляет реестром .int для межправительственных организаций.

Что касается конкретно ICANN, теоретически любой человек может потенциально подать заявку в ICANN, чтобы станьте реестром, контролируемым ими, и запустите новый рДВУ. Но это длительный и дорогостоящий процесс, и ICANN может не принять заявку (действительно, в настоящее время они не принимают заявки в настоящее время).

Регистраторы доменов

  • Регистраторы доменов - это организации, уполномоченные взаимодействовать с Реестрами доменных имен для управления доменными именами в Интернете (например, example.com ). Как отмечалось ранее, это может быть сторонняя организация или сам реестр.
  • Домен Регистраторы рДВУ, как правило, подотчетны ICANN.
  • Регистраторы доменов для ccTLD, вероятно, подотчетны самим национальным реестрам, но, как уже отмечалось, агентства, участвующие в управлении ccTLD, сильно различаются.
  • Регистраторы доменов для доменов верхнего уровня, вероятно, будут подотчетны одному или нескольким из вышеперечисленных агентств.
 3
Author: Anaksunaman, 2017-07-28 03:23:23

Короче говоря, ничто никому не запрещает создавать новые ДВУ. Это часто случалось в прошлом, с тем, что называлось "альтернативными корнями". Поскольку создание TLD не является проблемой, проблема заключается в доступе к ним. Вы либо зарегистрировали их в одном глобальном корневом каталоге, управляемом ICANN (см. https://www.icann.org/resources/pages/unique-authoritative-root-2012-02-25-en ) или вы находите способ побудить людей переключиться на ваш альтернативный корень.

Проблема с последним вариантом заключается в том, что что в настоящее время это означает необходимость изменения конфигурации каждого компьютера, который может пожелать получить доступ к этим альтернативным ДВУ. В прошлом эти усилия никогда не увенчались успехом по различным техническим и нетехническим причинам. Другие попытки использовали, например, "плагин Internet Explorer" для людей, думающих, что Интернет - это только сеть.

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

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

 2
Author: Patrick Mevzek, 2017-07-27 20:59:04