История системы доменных имен | «GZpromo» продвижение сайтов

Руководство для системных администраторов

1. Основы

История системы доменных имен

В семидесятых годах сеть ARPAnet представляла собой тесное сообщество из нескольких сотен узлов. Всю информацию по узлам, в частности необходимую для взаимных преобразований имен и адресов узлов ARPAnet, содержал единственный файл HOSTS.TXT. Известная UNIX-таблица узлов, /etc/hosts, прямо унаследовала свою структуру от файла HOSTS.TXT (в основном с помощью удаления ненужных на UNIX-системах полей).

За файл HOSTS.TXT отвечал Сетевой информационный центр (NIC, Network Information Center) Стэнфордского исследовательского института (SRI, Stanford Research Insitute). В тот период времени единственным источником, распространявшим файл, являлся узел SRI-NIC.1 Администраторы ARPAnet, как правило, просто посылали изменения электронной почтой в NIC и периодически синхронизировали свои файлы HOSTS.TXT с копией на узле SRI-NIC с помощью протокола FTP.

Присылаемые ими изменения добавлялись в файл HOSTS.TXT один или два раза в неделю. Однако по мере роста сети ARPAnet эта схема стала неработоспособной. Размер файла рос пропорционально количеству узлов ARPAnet. Еще быстрее рос информационный поток, связанный с необходимостью обновления файла на узлах: появление одного нового узла приводило не только к добавлению строки в HOSTS.TXT, но и к потенциальной необходимости синхронизации данных каждого узла с данными SRI-NIC.

После перехода ARPAnet на протоколы TCP/IP рост сети стал взрывным. Появился гордиев узел проблем, связанных с файлом HOSTS.TXT:

Информационные потоки и нагрузка

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

Конфликты имен

Никакие два узла, описанные в файле HOSTS.TXT, не могли носить одинаковые имена. Организация NIC могла контролировать присваивание адресов способом, гарантирующим их уникальность, но не имела никакого влияния на имена узлов. Не было способа предотвратить добавление узла с уже существующим именем, при том что такое действие нарушало работу всей схемы. Так, добавление узла с именем, идентичным имени одного из крупных почтовых концентраторов, могло привести к нарушению работы почтовых служб большей части сети ARPAnet.

Синхронизация

Синхронизация файлов в масштабах быстро растущей сети становилась все более сложной задачей. К тому моменту, когда обновленный файл HOSTS.TXT достигал самых далеких берегов выросшей ARPAnet, адреса отдельных узлов успевали измениться или же появлялись новые узлы.

Основная проблема заключалась в том, что схема с файлом HOSTS.TXT не поддавалась масштабированию. По иронии судьбы, успех ARPAnet как эксперимента вел к моральному устареванию и провалу механизма HOSTS.TXT.

Административные советы ARPAnet начали исследование, которое должно было привести к созданию замены HOSTS.TXT. Целью его было создание системы, которая решила бы проблемы, присущие сводной таблице узлов. Новая система должна была позволить локальное управление данными, но делать эти данные доступными всем. Децентрализация администрирования решила бы проблемы с трафиком и нагрузкой, непосильными для единственного узла. Локальное управление данными упростило бы задачу обновления и синхронизации информации. В новой системе следовало использовать иерархическое пространство имен для присваивания идентификаторов узлам, что позволило бы гарантировать уникальность каждого отдельного имени.

Ответственным за разработку архитектуры новой системы стал Пол Мокапетрис, работавший тогда в Институте информационных наук (Information Sciences Institute). В 1984 году он издал документы RFC 882 и 883, в которых описывалась система доменных имен (Domain Name System, или DNS). Эти RFC-документы были обновлены документами RFC 1034 и 1035, которые и являются в настоящее время действующей спецификацией DNS.1 RFC 1034 и 1035 к настоящему времени дополняются многими другими подобными документами, в которых описаны потенциальные проблемы DNS с точки зрения сетевой безопасности, возможные трудности реализации, проблемы административного плана, механизмы динамического обновления DNS-серверов, обеспечение безопасности зональных данных и многое другое.

.se — Википедия

Материал из Википедии — свободной энциклопедии

Текущая версия страницы пока не проверялась опытными участниками и может значительно отличаться от версии, проверенной 1 мая 2015; проверки требуют 2 правки. Текущая версия страницы пока не проверялась опытными участниками и может значительно отличаться от версии, проверенной 1 мая 2015; проверки требуют 2 правки. У этого термина существуют и другие значения, см. Se.

.se
Введение	1986
Тип домена	национальный домен верхнего уровня
Статус	действующий
Регистратура	NIC-SE
Организатор	II-Stiftelsen
Назначение	организации, связанные со Швецией
Использование	популярный домен в Швеции
Ограничения регистрации	свободная регистрация доменов второго уровня, условия регистрации доменов третьего уровня варьируются в зависимости от доменов второго уровня
Структура	допускается регистрация доменов второго уровня, а также третьего уровня в некоторых доменах второго уровня, включая домены ленов
Документы	Общие условия регистрации
Разрешение споров	Правила разрешения споров
DNSSEC	Есть
Веб-сайт	NIC-SE

.se — национальный домен верхнего уровня для Швеции. Ответственная организация, поддерживающая функционирование домена, — NIC-SE. Она, однако, не занимается регистрацией новых доменов, это могут делать только авторизованные регистраторы. Регистраторы получают первый платёж при регистрации нового домена. Последующие платежи получает NIC-SE. Максимальный срок, на который может быть оплачена регистрация, — один год.

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

Частные лица имели право зарегистрировать всего лишь один домен в домене второго уровня .pp.se (англ. pp, private person, частное лицо). Компании, зарегистрированные только в одном лене Швеции, имели право регистрировать домен лишь только в соответствующем домене второго уровня .код лена.se. Такие строгие правила привели к популяризации альтернативных доменов первого уровня — .nu и .com.

Новые правила позволили организациям и частным лицами регистрировать неограниченное количество любых доменов с небольшими ограничениями. В октябре 2003 г. NIC-SE начал регистрацию доменов, имена которых могут включать буквы å, ä, ö, ü и é.

.cx — Википедия

Материал из Википедии — свободной энциклопедии

Текущая версия страницы пока не проверялась опытными участниками и может значительно отличаться от версии, проверенной 7 июля 2019; проверки требуют 2 правки. Текущая версия страницы пока не проверялась опытными участниками и может значительно отличаться от версии, проверенной 7 июля 2019; проверки требуют 2 правки.

.cx
Введение	1997
Тип домена	национальный домен верхнего уровня
Статус	действующий
Регистратура	Christmas Island Internet Administration (CIIA)
Организатор	Christmas Island Internet Administration (CIIA)
Назначение	Объекты, связанные с Островом Рождества
Использование	Используется разными сайтами, в основном не на Острове Рождества
Ограничения регистрации	Нет
Структура	Регистрируется непосредственно второй уровень; некоторые имена третьего уровня существуют для сайтов Острова Рождества, таких как правительственные на .gov.cx
Документы	Регистрационное соглашение
Разрешение споров	Разрешение споров CoCCA UDP
DNSSEC	есть
Веб-сайт	nic.cx
Whois-сервер	whois.nic.cx

Карта доменов верхнего уровня

.cx — национальный домен верхнего уровня для острова Рождества (Австралия)^[1]. Регистратор домена — некоммерческая организация «Интернет-администрация острова Рождества» (англ. Christmas Island Internet Administration Limited — CIIA, США), управляющая также единственным интернет-провайдером на острове. Регистрировать домены .cx могут граждане и организации любой страны без ограничений.

Утверждён 24 апреля 1997 года. Первоначально был в ведении компании Planet Three Limited с офисами в Великобритании и Австралии. 10 января 2006 года после банкротства компании и прекращения её деятельности добровольно передан в управление компании Dot CX Limited (ныне CIIA)^[2].

История домена —

Перед тем как купить новый домен обязательно изучите его историю. Как известно, у него могло быть «черное» прошлое, связанное с продажей ссылок, АГС и т.д.

Что нужно проверить:

1. историю регистрации домена
2. что из себя представлял ресурс в прошлом
3. проверка индексации сайта, его ТИЦ и PR.

Для примера возьмем сайт leclan.ru и проверим его историю.

1. Проверяем историю регистрации домена

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

Здесь мы прописываем интересующий нас домен.

Нажимаем «найти» и вот, что мы видим:

С 2010-ого года по 2011-ый год домен принадлежал одному владельцу, что хорошо. Есть надежда на то, что сайт был не ГС.

С 2011- по настоящее время — неизвестно кому он принадлежит, так как данные скрыты. Может тому же человеку, а может и нет. В общем, пока всё не так плохо и домен принадлежал 2-м или одному человеку.

2. Изучаем прошлое сайта

Теперь нам неплохо бы узнать, что из себя представлял данный интернет-ресурс в прошлом. Для этого мы переходим на WayBackMachine. И вводим данные.

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

2010 год

2011

2012

В общем, сайт был посвящен сплетнях из мира звезд, о жизни, в общем обо всем. Качество статей не самое лучшее, но в принципе ресурс не вызывает особых подозрений.

Что особо радует, так это счетчик посещаемости:) Всё не так плохо. Пока.

3. Проверяем индексацию сайта, ТИЦ и PR

А теперь самое интересное:) Чтобы узнать данную информацию о домене, нам нужно посетить сервис RDS. Но чтобы начать пользоваться им, нужно зарегистрироваться.

Идем в «Историю параметров» и вбиваем нужный домен.

А вот здесь картина не такая уж красочная. В 2010 году в индексе было 111 страниц, к 2012-ому их стало 356, и потом 509. Это говорит о том, что ресурс процветал и нравился людям и поисковику. Но к 2013-ому из индекса вылетело 377 страниц! Можно предположить, что такой огромный вылет страниц из индекса мог быть по причине продажи ссылок или других нарушений. Скорее всего сайт попал под АГС.

ТИЦ сайта вообще не менялся.

PR с 2010-2012 был 1, а потом мы видим -1.

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

Вот таким образом вы можете проверить историю домена и сделать выводы.