Как клиентские системы обрабатывают простые общие домены верхнего уровня?
Можно получить общий TLD , например . Пример . Поиск DNS для example будет проходить через корневые серверы, которые найдут связующую запись для example и переадресуют запрос назначенному NS.привет @ пример и разместить веб-сайт по адресу , пример .
Как такие простые имена разрешаются на клиентах (клиенты DNS, это могут быть серверы или фактические конечные компьютеры)?
сервер Linux
server.foo.comс типичным разрешением добавит к такому простому запросу домен, в котором он находится - при условии, что запрос относится к хосту в его домене. Затем он запросит разрешениеexample.foo.com, что не соответствует ожидаемомуЯ считаю, что то же самое произойдет с сервером Windows (?)
на стороне конечного пользователя, ввод
пример, например, Chrome вызовет поиск словаexample, поскольку отсутствует полный адрес с точками
Это технически возможно, и некоторые реестры публикуют A или MX-записи непосредственно на уровне TLD.Например dig A ws. + short даст вам 64.70.19.33, и у вас также есть запись MX: mail.worldsite.ws
Некоторые предполагают, что стремление к новым gTLD, по крайней мере частично, вызвано тем, что люди думают что, имея такой TLD, они могли бы напрямую получать электронные письма @tld и веб-сайт, например http: // TLD / . Представьте, например, что TLD = SEARCH.
По сути, это было бы возрождением концепции ключевых слов, которые давным-давно были в моде, когда их продвигали как параллельные к пространству доменных имен.
Это могло бы создать, среди прочего, другие вещи, множество проблем в сети из-за файлов cookie и того, что в настоящее время нет автоматических механизмов для браузеров, чтобы найти административные сокращения (поскольку они не попадают идеально в разделитель «точка» DNS). То же самое для автоматического обнаружения WPAD DNS и различных других механизмов, когда приложения проходят дерево DNS вверх от корня.
Тем не менее, чаще всего это не работает должным образом, в основном из-за конфигураций по умолчанию. Системы настроены со списком поиска, поэтому, когда вы где-то используете имя, оно также пробуется с различными суффиксами. Этот список можно исправить или даже получить по DHCP.
Кроме того, ограничения ICANN (в контрактах с реестрами) запрещают практически все, что находится на вершине TLD, кроме SOA , NS , DS и RRSIG записи (для основных). Но это влияет только на gTLD, поскольку ccTLD не заключили контракт с ICANN и могут делать то, что хотят в этом вопросе (!).
У вас было много обсуждений, отчетов и решений по этим доменам без точки, см. https://features.icann.org/dotless-domains и особенно технический отчет: https://www.icann.org/en/system/files/files/sac-053- en.pdf , за которым последовал отчет IAB: https://www.iab.org/2013/07/10/iab-statement-dotless-domains-considered-harmful/
Эта статья хорошее резюме: http://www.circleid.com/posts/20130711_the_missing_link_in_dotless_domains/
И многие технические детали: https://labs.apnic.net/?p=429 с исследованиями различных резолверов на разных ОС.