домен поиска что это
Домен: что это, для чего нужен и как выбрать
Что такое домен
Домен — это адрес сайта в интернете. Когда пользователь указывает в поисковой строке доменное имя, компьютер понимает, по какому адресу нужно отправить запрос, чтобы сайт открылся.
Домен.com был одним из первых на момент внедрения системы доменных имен в январе 1985 года. Он управлялся Министерством обороны США, но затем ведомство передало эти полномочия компании SRI International, создавшей центр DDN-NIC (Network Information Center — сетевой информационный центр). Первый домен в зоне.com появился 15 марта 1985 года в американском штате Массачусетс. Это был сайт компании Symbolics Inc., производящей компьютеры и программное обеспечение.
Во втором квартале 2021 года в мире было зарегистрировано около 370 млн доменных имен.
Доменные имена формируются в соответствии с правилами и процедурами Доменной системы названий (DNS). Внутри DNS существует иерархия доменных имен. Она также обеспечивает связь ПК с мировой сетью, безопасность и своевременное обновление.
Надо отметить, что доменное имя и единый указатель ресурса (URL) — это не одно и то же. URL содержит как доменное имя сайта, так и другую информацию, включая протокол передачи (http, https и так далее) и путь (все, что после доменного имени).
Для чего нужен домен
Фактический адрес веб-сайта представляет собой сложный числовой IP-адрес (например, 103.21.244.0), и домены нужны для удобства. К примеру, trends.rbc.ru проще запомнить, чем IP-адрес — 80.68.253.7.
Домены также используют для настройки почты. При покупке адреса, например, rbc.ru, его можно использовать для организации корпоративной почты и работы сервиса email-рассылок.
Домены нужны и для переадресации, чтобы направлять посетителей на другой сайт или страницу. К примеру, когда компания переезжает на новый сайт, она может настроить переадресацию, и при указании старого доменного имени пользователи будут автоматически переходить на новый.
После регистрации домена его привязывают к хостингу. Это услуга аренды дискового пространства на сервере для хранения файлов и данных ресурса. Хостинг поддерживает работу сервера сайта, защищает его от вредоносных атак и обеспечивает трафик данных.
Архитектура доменного имени
Доменные имена обычно делятся на две или три части, которые отделяются точками. При чтении справа налево идентификаторы в доменных именах меняются от общих к конкретным. Например, в доменном имени trends.rbc.ru последний раздел справа от точки — это домен верхнего уровня (TLD),.ру.
Регистрацию доменов первого уровня контролирует международная организация Internet Corporation for Assigned Names and Numbers (ICANN). В России таким органом является Координационный центр доменов.RU /.РФ.
Подробный перечень доменов первого уровня указан на сайте администрации интернет-адресов (IANA).
Посередине доменного имени находится домен второго уровня (2LD) — rbc. Он должен иметь уникальное сочетание букв и цифр. Сначала выбранный домен второго уровня проверяют на уникальность, а потом уже регистрируют. Этим занимается регистратор доменов, который аккредитован ICANN.
Первым располагается домен третьего уровня (3LD) — trends. Если 2LD указывает на организацию (СМИ), которая зарегистрировала домен, то 3LD уточняет ее конкретное подразделение (редакцию). Владелец домена второго уровня вправе создавать неограниченное число доменов третьего уровня, а также расширять иерархию до четвертого уровня и далее.
В даркнете используют собственные DNS, домены и адресное пространство. Там не работают регистраторы.
Как выбрать домен
Домен может содержать от 2 до 63 символов, включать латинские или кириллические символы (в зонах.ру и.рус), а также цифры и дефисы.
В доменное имя можно добавить ключевые слова, которые соответствуют тематике сайта, что поможет в привлечении целевой аудитории.
Хороший домен оценивают по следующим показателям:
Как купить и зарегистрировать домен
Продлевать аренду нужно за 30–60 дней до срока ее завершения. Также, если аренда домена закончилась, то у владельца сайта есть еще 30 дней на ее продление. Однако в этот период сайт и почта на домене перестают работать, а доменное имя выпускают на аукцион, и другие пользователи могут делать на него ставки, чтобы потом приобрести.
Домены в зонах.рф,.ru,.su удаляют на следующий день после окончания периода преимущественного продления. Международные домены удаляют спустя 1–5 дней.
У любого регистратора домена существует система проверки выбранных названий через Whois-сервис, который показывает основные сведения о доменном имени.
Через сервис можно узнать информацию о дате и месте регистрации, регистраторе, администраторе и его контактные данные. Она пригодится, если владелец домена хочет пожаловаться на его неправомерное использование. Сведения полезны также при покупке нового доменного имени — так, чем оно старше, тем проще домен вывести в топ поисковиков.
В случае с перекупкой домена важно также проверить содержание старого сайта, например, в Web-archive. Доменное имя могло в прошлом использоваться для сайта сомнительного содержания или компании с плохой репутацией.
Некоторым покупателям важно, чтобы выбранный ими домен был доступен для использования в соцсетях. Проверить доступность выбранного названия в соцсетях можно на сервисе KnowEm.
Существуют также бесплатные доменные имена, которые предлагают разработчики веб-сайтов, такие как WordPress.com, Squarespace, Weebly и другие. Они используют имя своего веб-сайта в домене компании. Например, вместо businessbooks.com домен будет выглядеть как businessbooks.wordpress.com. Бесплатные домены не подходят для долгосрочных бизнес-целей или построения уникального бренда, поскольку уже включают название другой компании.
После того, как доменное имя было зарегистрировано, регистратор должен уведомить владельца, когда срок действия его домена истекает, и дать ему возможность продлить его без потери имени. Недобросовестные регистраторы могут скупать домены сразу после истечения срока их действия, а затем продавать их обратно первоначальному регистранту по непомерно высокой цене. Поэтому важно выбрать честного и надежного регистратора. Существуют рейтинги проверенных регистраторов. Кроме того, домен можно купить на аукционе, не связанном с регистраторами.
Что такое домен и зачем он нужен: определение доменного имени простыми словами
Большинство юзеров из числа тех, кто не разбирается в устройстве компьютеров и процессов в них происходящих, не имеют об этом ни малейшего представления. В действительности, каждый из нас, кто хотя бы однажды открывал окно браузера и переходил на какой-либо сайт, сталкивался с этим понятием. Постараемся разобраться, что же это за явление в современных информационных технологиях. Домен сайта в интернете и доменное имя: что это такое и зачем нужно, определение простыми словами — тема нашей сегодняшней статьи. Далее поговорим подробнее об основных вспектах, связанных с данным понятием.
Что такое домен
Это название сайта. Чтобы было понятнее, представьте себе какое-нибудь здание (объект), куда вам необходимо попасть. Например, в салон сотовой связи определенного оператора, в котором вы еще ни разу не были. Чтобы добраться туда, нужно знать адрес, по которому этот пункт располагается. То есть, потребуются точные координаты: улица, номер дома, корпуса, а возможно и офиса. В противном случае вы не достигнете цели. Невозможно отправиться наобум в любом направлении и прийти в место назначения.
То же самое происходит в отношении сайтов. Каждый из них наделен собственным местом — сетевым IP-адресом. Это обеспечивает полноценное функционирование и дает возможность ресурсам не конфликтовать в рабочем режиме.
Домен способен содержать от 2 до 63 символов. Чаще всего владельцы веб-сайтов предпочитают прописывать его самостоятельно и впоследствии арендовывать. Названия продают на созданных специально для этого площадках. На них же всем желающим доступна функция проверки на предмет совпадения с уже имеющимися.
Создавая название, надлежит соблюдать определенные условия:
В некоторых случаях имеют место дополнительные ограничения, устанавливаемые администрацией ресурса, на котором осуществляется продажа и регистрация доменов.
Из чего состоит
В основе их устройства лежит иерархия в виде подразделения на части. Так, имена третьей ступени базируются на названиях второй, наименования второй, в свою очередь, на основании первой. Подразделяются они на следующие виды.
Домен и хостинг: в чём разница
Мы уже выяснили, что доменом называется имя веб-сайта, содержащее минимум два уровня. Хостинг же представляет собой определенные услуги, благодаря которым сайт находится на сервере и отображается в сети. Соответственно, компании, которые их оказывают — это хостинг-провайдеры.
Хостинг — весьма непростой и продолжительный процесс. Ведь для каждой папки с файлами (а их на одном сайте может быть огромное количество) нужно подобрать собственное место на сервере, чтобы обеспечить бесперебойное функционирование.
Что такое уровень домена
На схематичном примере это выглядит так:
Таким образом, без труда прослеживается расположение по значимости. В первую очередь прописывается домен (это, как правило, территориальное обозначение). Если название веб-сайта заканчивается на KZ — перед вами страница из Казахстана. Следом наблюдается взятое в аренду имя, придуманное самим пользователем (владельцем ресурса). Последняя же категория предназначена для создания сайтов, находящихся внутри других сайтов. Чтобы понять, что к чему, представьте себе крупный интернет-магазин, в котором функционирует целая сеть маленьких магазинчиков.
Отдельно стоит отметить, что оплата имени второго уровня производится один раз в год. По истечении времени его необходимо снова зарегистрировать (продлить). Если этого не сделать, название могут перекупить другие пользователи.
Зоны доменных имен
В каких случаях выбирать территориальную
Зоны принято прописывать согласно географическому расположению стран. У каждого государства своя собственная. Так, в Казахстане — это KZ, в России — RU, в Беларуси — BY, в Японии — JP и т.д. Выкупить такую зону не представляется возможным, но ее можно выбрать из имеющихся.
Пользователями в нашей стране проще воспринимать и запоминать имена в зоне ru. Поэтому все компании, осуществляющие свою деятельность в сетевом пространстве Российской Федерации, стараются осуществить регистрацию названия именно в ней. Нередки случаи, когда определенный домен занят, тогда организации прибегают к решению проблем другими путями.
В каких случаях выбирать тематическую
Когда можно использовать территориальную зону в качестве тематической
Существуют имена, которые перекликаются с сокращенными определениями в различных сферах. Именно поэтому их зачастую задействуют при прописывании тематических.
В качестве примеров подобной переклички стоит продемонстрировать несколько.
Подходящие зоны обычно подбирают на специальных сервисах. Проверка названия на предмет занятости производится всего в несколько кликов. Достаточно просто вбить его в поисковую систему и дождаться результатов.
Что такое домен компьютера
Отыскать необходимый ПК по имеющемуся индивидуальному адресу, представленному в виде буквенно-цифрового сочетания в разы проще, чем запомнить для его обнаружения 2 – 3 десятка цифр.
Регистрацию и обслуживание компьютерных доменов осуществляет специализированная служба DNS — Доменная система названий. В ее компетенцию входит обеспечение связи ПК с мировой сетью, безопасность, своевременное обновление и организация бесперебойной работы машин.
Домены в DNS
Домены в быту
Каждый юзер без исключения мечтает получить звучное имя для своего веб-сайта. Но его форма нисколько не влияет на отношение к нему доменной системы названий. Она имеет значение разве что для попадающих на сайт пользователей. Если имя выразительное и звучное, хорошо запоминается и отображает в себе основную тематику ресурса, велика вероятность, что оно понравится посетителям. Ведь домен — это совокупность запоминающегося имени и заданной тематики.
Регистрация
История доменного имени оказывает огромное влияние на успешное продвижение сайта. Если когда-то по данному адресу располагалась низкокачественная площадка (что весьма распространенное явление в сети), хороших результатов добиться не удастся, как ни старайся. Происходит это потому, что поисковые системы хранят данные довольно продолжительное время в своих базах. Так, если вы обзаведетесь доменом, где раньше находился посредственный ресурс, на котором публиковались ссылки на запрещенные сайты, назойливые рассылки — ждите неприятностей. Чтобы избежать подобного развития событий, следует проверять адрес еще до оформления.
Как проверить домен перед регистрацией
Выяснить подробности истории можно посредством специального проекта archiv.org, существующего в сети. Он хранит информацию практически обо всех веб-сайтах в мире, которые не закрываются от его робота.
Нужно всего лишь вбить заинтересовавший вас адрес и кликнуть ввод. Вас перебросит на календарь хранящихся копий, где останется только посмотреть, как выглядел сайт раньше.
В данном примере мы имеем дело с чистым адресом, ненадлежащих негативных элементов в нем нет. Анализируя данные, можно прийти к выводу, что дальше взятия домена дело не продвинулось. Арендный период названия или хостинга завершился, веб-сайт за это время так и не наполнили контентом. Как вариант, стоящее привлекательное имя могли зарегистрировать с целью последующей перепродажи. Есть в сети пользователи, промышляющие таким видом заработка. Но в целом приобрести на определенный срок и задействовать по своему разумению данный адрес — хорошая идея.
Можно посмотреть пример страницы из архива поисковой системы Яндекс за 2005 год.
Примечательно, что все ссылки на активны, если произвести проверку в сервисе.
Проверять надлежит не только доменный адрес, но и IP. Сделать это можно при помощи специализированного сервиса www.dnsbl.info. Так удастся без труда определить нелегальную рассылку, присутствие в черных списках. Если по каким-то причинам, не зависящим от вас (до приобретения), адрес попал в блек-лист, есть возможность его очистить. Для этого предстоит обратиться к провайдеру и в точности соблюдать все данные им инструкции.
Почему важно выбрать хорошее доменное имя
Домен влияет на продвижение вашего сайта
Не только доменное название способствует успешному функционированию ресурса, немаловажную роль также играет правильный подбор зоны. Так, например, наименование определенной марки продукции и ключевые слова в нем непосредственно ведут к повышению позиций в поисковой выдаче.
Поменять домен в будущем будет проблемой
Все время, пока вы активно используете адрес, он формирует свою репутацию в поисковых системах. Именно она имеет большое значение в росте или снижении позиций. Поэтому к вопросам что такое domain и как правильно его подобрать, надлежит отнестись со всей тщательностью.
Как создать подходящее доменное имя
Помните о целевом назначении названия. Оно должно не только привлекать своим удобством и звучностью, но и способствовать эффективному функционированию ресурса. Оптимальнее всего задействовать наименование торговой марки, аббревиатуру, сокращения и, конечно, ключи. Так удастся сделать бренд и саму организацию узнаваемыми, благодаря высоким позициям в поисковой выдаче.
Whois: практическое руководство пользователя
Статья рассказывает о работе whois протокола, о существующих клиентских решениях и об особенностях коммуникации с различными whois серверами (а также о выборе правильного whois сервера). Ее основная задача — помочь в написании скриптов для получения whois информации для IP адресов и доменов.
Что такое whois?
Что такое и для чего нужен whois можно прочитать, например, здесь: http://en.wikipedia.org/wiki/Whois.
В нескольких словах, whois (от английского «who is» — «кто такой») – сетевой протокол, базирующийся на протоколе TCP. Его основное предназначение – получение в текстовом виде регистрационных данных о владельцах IP адресов и доменных имен (главным образом, их контактной информации). Запись о домене обычно содержит имя и контактную информацию «регистранта» (владельца домена) и «регистратора» (организации, которая домен зарегистрировала), имена DNS серверов, дату регистрации и дату истечения срока ее действия. Записи об IP адресах сгруппированы по диапазонам (например, 8.8.8.0 — 8.8.8.255) и содержат данные об организации, которой этот диапазон делегирован.
Часто whois используется для проверки, свободно ли доменное имя или уже зарегистрировано. Теоретически, это можно сделать просто открыв домен в браузере, однако на практике зарегистрированное имя не всегда используется.
Стоит отметить, что все контактные данные вводятся в момент регистрации, и со временем они могут устареть. Каждый регистратор имеет свою собственную процедуру их обновления, кроме того, сам процесс может занять некоторое время (хотя обычно это происходит в течение суток).
Протокол подразумевает клиент-серверную архитектуру и используется для доступа к публичным серверам баз данных (как правило, самих регистраторов IP адресов и доменных имен). В некоторых случаях, whois сервер для определенного домена верхнего уровня содержит полную базу данных обо всех зарегистрированных доменах. В других случаях, такой whois сервер содержит лишь самую базовую информацию и отсылает к whois серверам конкретных регистраторов.
Остальные детали будут рассмотрены по ходу самой статьи. Информации, на самом деле, очень много, поэтому специально для тех, кто хочет получить лишь общее представление, не углубляясь в технические детали, есть ее «выжимка»: можете сразу переходить к последнему разделу статьи, который называется «Короткие итоги«.
Небольшая предыстория
Есть программный продукт, Интернет-портал, который предоставляет различные сведения об IP адресах и доменах, в том числе whois информацию. Испокон веков для этих целей использовалась сторонняя утилита jwhois, в работу которой никто не вникал. Однако после миграции продукта на новую версию FreeBSD неожиданно оказалось, что jwhois перестал работать: для большинства доменов начала выдаваться абсолютно нелогичная ошибка «Unable to connect to remote host». Google не помог, и я уже был готов начинать дебажить C-шный код, как вдруг оказалось, что jwhois нам вообще не подходит из-за своей лицензии (GPL v3). В общем, встала задача поиска какого-то альтернативного решения.
К моему удивлению, каких-либо вменяемых альтернатив в наличии не оказалось. Большинство форумов как раз и рекомендовали использовать тот самый jwhois. Несколько программ, конечно, нашлось (в том числе несколько библиотек на родном для нашего продукта языке Python), однако большинство из них были забракованы уже буквально после первого же теста на домен в зоне «ua». В целом, все решения выглядели откровенно написанными «на коленке» и абсолютно неподходящими для серьезного продукта. Единственная библиотека, которая на тот момент вызывала доверие, была написана на Ruby (что совсем нам не подходило) и имела пугающий размер исходников и различных конфигурационных файлов для каждого конкретного whois сервера.
Оставалась еще стандартная Unix-овая утилита, так и называющаяся «whois», однако и ее работа оставляла желать лучшего.
В общем, единственным вариантом было садиться читать спецификации по протоколу и писать решение самому.
Результатом этого стал модуль на языке Python на 1000 строк кода, в процессе написания которого я последовательно наступил на все сопутствующие грабли, и, в конечном итоге, данная статья, которая про все эти «грабли» и рассказывает (да, если что, то код проприетарный).
Забегая наперед, замечу, что с высоты приобретенного опыта и jwhois, и Ruby Whois (http://www.ruby-whois.org) теперь также выглядят «оставляющими желать лучшего».
В чем, собственно, проблема?
Вся работа whois описана в RFC 3912 (http://tools.ietf.org/html/rfc3912) и занимает целых 4 страницы. В нескольких словах, все сводится к следующему: откройте TCP соединение на порт 43 к нужному whois серверу, пошлите запрос в определенном формате (который для конкретного whois сервера может быть каким угодно), закончите его «\r\n» и получите результат, формат которого для конкретного whois сервера также может быть каким угодно. Закрытие сервером соединения означает окончание результата. Все! Иными словами, каждый whois сервер определяет формат коммуникации по собственному усмотрению. Это уже не говоря о том, что абсолютно неочевидно, откуда взять нужный whois сервер для конкретного домена или IP адреса.
Я, конечно, наивно рассчитывал, что найду в Интернете море практических статей, в которых все это будет детально расписано, однако в результате не нашел ни одной. В основном, все сводилось лишь к пережевыванию скудной информации из RFC и названиям нескольких самых известных whois серверов. Хотя некоторую разрозненную информацию все-таки удалось найти.
В общем, пришлось смотреть код Unix-ового whois, а также jwhois и Ruby Whois — их принцип работы и будет рассмотрен далее.
Unix-овый whois
Итак, что собой представляет работа Unix-ового whois?
Кроме того, часто результат получается не совсем такой, как мы ожидаем. Например:
Оказывается, whois сервер знает про целый ряд доменов, похожих на «google.com» и не знает, какой из них выбрать.
Как видим, IP адрес сначала был делегирован одной организации в рамках определенного диапазона, а позднее переделегирован другой организации в рамках уже меньшего поддиапазона. И whois сервер снова не знает, какая именно информация нас интересует.
Иными словами, программа полагается на самый общий принцип работы whois протокола и абсолютно не готова к каким-либо исключениям. Для «дискавери» доменных whois серверов используется whois-servers.net, что в настоящее время отнюдь не самый эффективный способ.
jwhois
Теперь посмотрим, как работает самая популярная whois утилита. В отличие от Unix-ового whois она не делает никакого «дискавери», а всецело полагается на километровый конфигурационный файл (около тысячи строк!), в котором захардкоджены whois серверы для всех известных доменов верхнего уровня, для ряда специфических доменов второго уровня (которые имеют собственные whois серверы) и даже для конкретных диапазонов IP адресов. Стоит ли говорить, что в современном быстро меняющемся мире этот конфигурационный файл будет требовать ежедневных обновлений и все равно вряд ли когда-нибудь будет на 100% актуальным? В шапке файла есть ссылка на репозиторий, с которого можно скачивать последнюю версию, и оказалась, что она датирована апрелем 2011-го года! За это время появилось множество новых whois серверов, а часть старых уже не работает. Уверен, что делегирован и целый ряд новых IP диапазонов — особенно для IPv6.
Кроме собственно названий whois серверов, в файле в специальном формате описаны все известные исключения для форматов запросов, а также формат ссылок на другие whois серверы (намного больше, чем в Unix-овом whois).
Также обнаружилась еще одна интересная функциональность. Для многих доменов верхнего уровня whois серверов на самом деле нет, или доступ к ним ограничен, однако whois информация доступна через веб на их сайте. Так вот, jwhois умеет посылать GET-ом или POST-ом нужный запрос, получать результат и потом выкусывать из HTML необходимую информацию. Адреса страниц, имена параметров формы и формат результата для каждого конкретного случая также захардкоджены в конфигурационном файле. Естественно, во многих случаях эти данные уже устарели, и «scraping» не работает. Некоторые сайты просто добавили в свои формы каптчу — возможно, как раз против подобных программ.
Возвращаясь к примерам выше, jwhois корректно выдает результат для «google.com», но с «8.8.8.8» он ничем не лучше Unix-ового whois.
В общем, как оказалось, jwhois не такая уж и хорошая программа, как думалось. Полагаться только на захардкодженный список серверов (даже если бы он регулярно обновлялся) явно не самая лучшая идея.
Ruby Whois
Если бы эта программа анализировала древнеегипетские папирусы, то, безусловно, имело бы смысл детально описать формат всех известных видов документов каждой из династий фараонов. Но вот делать это для whois серверов, которые меняются чуть ли не каждый день, наверно, не самое благодарное занятие. Как-то прямо жалко авторов проекта — поддерживать его явно задача не из легких.
На тот момент у меня уже были в наличии названия нескольких «хитрых» whois серверов (и понимание того, откуда их можно взять) — в конфигурации Ruby Whois никакой информации про них не было.
Я не имел возможности (да и особого желания) запускать Ruby Whois, поэтому не знаю, справился бы он с «8.8.8.8» или нет.
pwhois
despair/Net-Whois-Raw-2.43/. Последнее обновление датировано августом 2012 года.
Программа использует все тот же метод хардкода: есть огромный конфигурационный файл (на этот раз, на две тысячи строк), в котором зашиты названия whois серверов и все остальное.
Основной недостаток тот же самый: всего не захардкодить. Многих whois серверов в конфигурации нет, соответственно о целом ряде доменов получить информацию невозможно. Ну и с «8.8.8.8» программа также не справилась.
Что дальше?
К этому времени у меня уже были определенные идеи касательно того, как должен работать «правильный» whois, и я взялся за разработку начальной версии. Все дальнейшие «знания» были почерпнуты экспериментальным путем в результате множества разнообразных whois запросов и анализа их результатов. К счастью, многое из этого можно было автоматизировать.
Также хочется упомянуть сайт http://whois.domaintools.com — лучший whois веб сервис, который мне удалось найти. Естественно, я не имел возможности видеть его исходный код, однако во многих случаях сравнение его результатов с моими служило хорошей «наводкой». Не буду озвучивать предположения касательно того, как он работает, однако по факту он показывал намного лучшие результаты, чем вышеупомянутые программы (как я уже упоминал, о возможностях Ruby Whois я сужу только по коду).
Работу с whois я бы свел к решению трех принципиальных задач:
Как определить правильный whois сервер для домена?
Для начала несколько замечаний.
Whois информацию возможно получить не для всех доменов верхнего уровня. Некоторые страны whois информацию для своих доменов не предоставляют в принципе (например, КНДР). Кроме того, своих whois серверов не имеют и некоторые африканские страны (возможно, у них просто нет денег или всех программистов съели).
Для некоторых доменов верхнего уровня whois информацию возможно получить только на сайте регистратора. В некоторых случаях для этого необходимо ввести каптчу, в остальных это можно реализовать программно. Тем не менее, я полностью отказался от идеи «scraping-а». Его корректная работа требует хардкода большого количества информации (адрес страницы, имена полей формы, формат полученной HTML страницы и т.п.), чего я всячески хотел избежать. Кроме того, эта информация требует постоянного обновления, так как она может меняться даже чаще, чем имена whois серверов.
Ну и, самое главное, если whois информация будет отображаться посетителям сайта, то можно просто предоставить ссылку на сайт регистратора и дать возможность пользователю заполнить форму самому. В большинстве случаев, whois форма представлена или на заглавной странице, или на страницу с ней можно перейти в один клик. Это намного более надежный способ, чем полагаться на «scraping», который в любом случае не сможет справиться с каптчей. Где взять ссылку на сайт регистратора будет рассказано ниже.
Также некоторые whois серверы могут банить IP адреса пользователей, которые посылают слишком много запросов.
Итак, где же взять название правильного whois сервера?
Взять его можно из нескольких источников:
1. Есть такой замечательный whois сервер whois.iana.org, принадлежащий IANA (http://en.wikipedia.org/wiki/Internet_Assigned_Numbers_Authority). Он содержит самую свежую информацию обо всех доменах верхнего уровня. Например (здесь и далее все примеры с использованием Unix-ового whois):
Обратим внимание на следующие строки:
Это собственно и есть whois сервер и сайт регистратора! Для большинства доменов верхнего уровня IANA возвращает вполне актуальное название whois сервера. Я специально проверял изменения в Ruby Whois за несколько последних месяцев, и все они были взяты именно с whois.iana.org.
В моем модуле я кэширую результат с IANA на 24 часа (на больший промежуток времени особого смысла нет, да и данные могут поменяться).
Несмотря на все сказанное выше, для некоторых доменов верхнего уровня IANA информацию о whois серверах почему-то не предоставляет. Возможно, регистраторы некоторых стран специально их не афишируют. Но не страшно, у нас есть и другие способы.
2. Если присмотреться, для очень многих доменов верхнего уровня названия их whois серверов выглядят или как whois.nic. (более распространено), или как whois. (менее распространено). Например:
Таким образом, если IANA нам ничего не вернула, для любого домена верхнего уровня мы легко получаем названия двух потенциальных whois серверов:
Довольно часто, если мы ищем домен третьего уровня (например, russia.edu.ru), то whois сервер, ответственный за домен верхнего уровня, нужной информации не содержит. Например:
Это происходит из-за того, что за многие домены второго уровня (в нашем примере, edu.ru) ответственна совершенно другая организация, которая имеет свой собственный whois сервер.
В подобных случаях jwhois и Ruby Whois педантично хардкодят название whois сервера для каждого известного им домена второго уровня с собственным сервером. Естественно, уследить за всеми доменами второго уровня абсолютно нереально, тем более что никакого централизованного источника подобной информации нет.
Но опять таки, если присмотреться, большинство таких whois серверов имеют вид whois. (более распространено) или whois.nic. (менее распространено). Например:
В некоторых случаях, когда IANA возвращает только сайт регистратора без whois сервера, название, построенное по этой схеме, оказывается верным.
Таким образом, для каждого домена, который мы хотим найти, у нас будет целый список потенциальных whois серверов с большей или меньшей вероятностью работоспособности. Например, для russia.edu.ru у нас будет:
Такая схема позволяет отфильтровать все несуществующие whois серверы и в то же время не дает надолго заблокировать серверы, которые по тем или иным причинам стали временно недоступны.
Стоит отметить, что когда мы в следующий раз будем искать домен в зоне edu.ru, то активными будут считаться сразу два whois сервера:
Мой модуль ищет ссылки достаточно агрессивно, принимая за whois сервер любую строку, которая выглядит как хостнейм и содержит слово «whois» (как мы уже выяснили, «лишние» whois серверы — не проблема). Если же мы нашли ссылку в формате «whois server: », то название сервера уже не обязательно должно содержать слово «whois» (на практике, это может быть даже не хостнейм, а просто IP адрес). Все найденные whois серверы по умолчанию считается активными.
Правда здесь есть один подводный камень. Результат может содержать название собственного whois сервера, и если так вышло, что мы обратились к нему по какому-то алиасу, оно будет выглядеть как ссылка на другой whois сервер. Например:
Здесь упоминается whois.jprs.jp, алиасом которого, на самом деле, и является whois.jp. То есть если мы теперь пошлем запрос на whois.jprs.jp, то получим такой же самый результат. Кроме этого, некоторые whois серверы могут работать как прокси и возвращать результаты с какого-то другого whois сервера — естественно, упомянув его имя в результате.
Иными словами, нам нужно каким-то образом выявлять подобные ситуации: во-первых, чтобы не выдавать пользователю два одинаковых результата, а во-вторых, чтобы не тратить время на ненужные запросы.
На первый взгляд, решение элементарное: нужно просто сравнить два результата, и если они одинаковые, второй откинуть (запомнив, что переход между этими двумя whois серверами в дальнейшем делать не нужно). Однако не все так просто. Часто результат содержит точное время, когда был сделан запрос — соответственно, два запроса, сделанные подряд, будут отличаться значением времени. Если первый whois сервер работает как прокси, то он, как правило, будет содержать еще какой-то дополнительный текст. И самое интересное: некоторые whois серверы умудряются от запроса к запросу выдавать данные в разном порядке! То есть результат запросов абсолютно одинаковый, но несколько строк поменяны местами.
Поэтому перед сравнением я заменяю все последовательности цифр на «X», удаляю все пустые строки и строки, которые начинаются с «#» или «%» (комментарии), и, на всякий случай, заменяю множественные пробелы на один и делаю «trim» всем строкам. После этого я сравниваю два множества строк (используя тип set в Python), и если второе является подмножеством первого, значит это дубликат.
С IDN доменами (типа «правительство.рф»), к счастью, никаких проблем нет. Переводим «правительство.рф» в «xn--80aealotwbjpid2k.xn--p1ai» и ищем на whois.iana.org домен верхнего уровня «xn--p1ai»:
Как определить правильный whois сервер для IP адреса?
С IP адресами ситуация несколько другая. Есть пять основных региональных whois серверов:
Если спросить у какого-нибудь регионального сервера про IP адрес, за который он не отвечает, то с определенной вероятностью он сможет указать на нужный сервер, однако далеко не всегда. Поэтому я по очереди опрашиваю все пять региональных whois серверов, а также whois.iana.org, пока кто-то из них не вернет результат или не укажет на нужный whois сервер.
Первый запрос я всегда посылаю на ARIN, так как он отвечает за наибольшее число IP адресов (да и пользователей нашего продукта чаще всего будут интересовать именно IP адреса из Северной Америки). Кроме того, для остальных IP адресов ARIN почти всегда может указать на нужный региональный whois сервер. В большинстве случаев IANA также может указать на правильный сервер, однако в таком случае пришлось бы каждый раз делать минимум по два запроса.
Стоит отметить, что AfriNIC — относительно новый whois сервер. До этого все африканские IP адреса были распределены между ARIN, RIPE и APNIC. Поэтому другие региональные whois серверы часто думают, что эти IP адреса до сих пор им делегированы. Например:
ARIN также скажет, что за 213.154.64.0 отвечает RIPE. Если же обратиться к RIPE, то он ответит, что за диапазон 213.154.64.0 — 213.154.95.255 уже отвечает AfriNIC.
Также стоит помнить про две вещи. whois.lacnic.net работает как прокси, и если про какой-то IP адрес информации не имеет, то отправляет запрос на остальные четыре сервера и, в конечном итоге, возвращает нужный результат. Может показаться, что в таком случае все запросы нужно просто посылать на LACNIC. На самом деле, делать это абсолютно не стоит: два из пяти региональных whois серверов (RIPE и AfriNIC) достаточно агрессивно банят IP адреса пользователей, которые посылают слишком много запросов. Не уверен на счет точных цифр, но 10000 запросов в сутки, думаю, будет достаточно, чтобы оказаться заблокированным AfriNIC. Когда LACNIC посылает запросы на другие региональные серверы, он, естественно, указывает IP пользователя, от имени которого делается запрос. Иными словами, если даже какой-то IP адрес не принадлежит AfriNIC, есть большая вероятность, что LACNIC отправит запрос и на него, тем самым, увеличив счетчик. Поэтому на LACNIC я отправляю запросы в последнюю очередь.
Ссылки на другие whois серверы ищутся так же само, как и для доменов. Правда есть несколько нюансов. ARIN всегда показывает ссылки на дополнительные whois серверы в виде «ReferralServer: ». Если же он за IP адрес не отвечает, но знает, на каком из региональных серверов его нужно искать, то указывать полное название whois сервера он, скорее всего, не будет, а просто ограничится аббревиатурой типа LACNIC или RIPE.
Как правильно отправить запрос?
Итак, с горем пополам, мы наконец-то нашли нужный whois сервер. Как теперь отправить на него запрос?
В подавляющем большинстве случаев нужно просто открыть соединение на порт 43, отправить строку вида » \r\n» и прочитать данные, которые вернет сервер. Однако, как всегда, есть исключения (тут без хардкода, к сожалению, уже не обойтись).
Не смотря на то, что RFC 3912 явно предписывает посылать «\r\n», есть как минимум один whois сервер, который требует «\n» и с «\r\n» работать отказывается! Это whois сервер Мальты whois.nic.org.mt.
Кроме того, следующие whois серверы требуют особый синтаксис:
К whois.arin.org можно посылать запросы и в обычном виде » \r\n», но тогда есть риск получить вместо полного результата вот это:
С whois.nic.name ситуация вообще интересная. Например:
Информации не так уж и много (хотя и лучше, чем ничего). Однако обратите внимание на строку:
Можно отправить такой запрос:
Самого whois сервера регистратора он не показал, но показал адрес сайта:
Как мы уже знаем, в большинстве случаев whois сервер находится где-то неподалеку. Пробуем:
Это, конечно, работает не для всех доменов в зоне «name», но для многих.
Также рекомендую почитать про дополнительный синтаксис региональных whois серверов (детально описан на их сайтах). Я его у себя в модуле не использую, но кому-то может пригодиться. Например, параметр «-B» позволяет whois.ripe.net выводить поля «notify», «changed» и «e-mail», которые по умолчанию не показываются:
В этом примере я использую telnet, так как через Unix-овый whois или другую утилиту передать специальные параметры не удается.
Еще один нюанс связан со считыванием результатов с whois сервера. Первоначально у меня был приблизительно такой код:
Иными словами, читаем данные, пока они есть. Если происходит ошибка, возвращаем пустой результат.
Оказалось, что это работает не всегда (хотя и, наверно, в 99% случаев). Есть whois серверы, которые после отправки данных закрывают соединение таким образом, что на клиенте всегда происходит ошибка (хотя все данные перед этим были успешно прочитаны).
Поэтому код был изменен на:
Наконец, оказалось, что кроме протокола whois, существует еще один, который называется rwhois. О нем речь пойдет ниже.
Referral Whois
Что такое rwhois («Referral Whois») можно прочитать здесь: http://en.wikipedia.org/wiki/Whois#Referral_Whois. В нескольких словах, это протокол, который должен исправить все недостатки стандартного whois и, в конце концов, полностью его заменить. По умолчанию протокол использует порт 4321. Не смотря на то, что rwhois был разработан еще в 1994-м году, широкого распространения он до сих пор так и не получил.
Впервые ссылки на rwhois серверы я увидел в результатах, которые мне возвращал ARIN (хотя подавляющее большинство ссылок по-прежнему вели на обыкновенные whois серверы). Обычно, уже само их название содержало слово «rwhois». Кроме того, в большинстве случаев ARIN явно указывал, какой протокол надо использовать: «whois://» или «rwhois://». Первый же rwhois сервер, к которому я попробовал отправить запрос, показал, что простым » \r\n» тут не обойтись. Пришлось открывать спецификацию.
Referral Whois описан в RFC 2167 (http://tools.ietf.org/html/rfc2167). Это огромный нечитаемый документ на 170КБ. Проглядев его по диагонали, я сразу же вспомнил слова Joel-а Spolsky: «если кто-то дал вам спецификацию для какой-то новой технологии, и вы не можете ее понять, сильно не расстраивайтесь. Никто другой ее тоже не поймет, поэтому это вряд ли имеет значение».
Каких-либо вменяемых примеров в документе не содержалось, Google мне также ничем не смог помочь. Поэтому, повозившись с telnet-ом и окончательно зайдя в тупик, я решил, что это не тот случай, когда нужно изобретать велосипед. На http://projects.arin.net/rwhois/ лежал написанный на C клиент с вполне подходящей GPL v2 лицензией. Свыше 100КБ кода и поддержка rwhois версий 1.0 и 1.5 — самому такое не написать. С теми rwhois серверами, с которыми я зашел в тупик, он блестяще справился. Упомянутый выше jwhois также имел встроенную поддержку rwhois, но вряд ли она была настолько же совершенной (по крайней мене, поддержки разных версий сервера там не было).
В общем, если мой модуль находил rwhois сервер, то просто вызывал через subpocess сторонний rwhois клиент, который брал на себя всю коммуникацию с сервером и возвращал готовый результат.
Радость длилась недолго: оказалось, что с большинством реальных rwhois серверов клиент не работает. Никаких видимых причин для этого не было, однако клиент упрямо возвращал «error querying rwhois server». Google, естественно, ничем помочь не смог. Самое обидное, что jwhois с этими серверами прекрасно справлялся.
Провозившись довольно долго, я, наконец, обнаружил удивительную вещь: все эти «rwhois» серверы на самом деле работают по протоколу обычного whois! Иными словами, мой навороченный клиент соединяется с сервером и думает «интересно, он работает как rwhois версии 1.0 или rwhois версии 1.5?» А сервер на самом деле ничего кроме тупого » \r\n» не понимает! Такой наглости клиент, естественно, не ожидает и выдает ошибку.
Подозреваю, что все эти серверы банально «не осилили» правильно реализовать rwhois протокол и, в конце концов, вернулись к обычному whois, при этом продолжая формально идентифицировать себя как rwhois сервер. Так что Joel Spolsky был абсолютно прав.
На самом деле, кое-что от rwhois у этих серверов все-таки осталось: строго структурированный формат возвращаемых данных. Все разбито на секции, никаких лишних пробелов, имя/значение разделены двоеточием. Rwhois клиент потом трансформировал это в красивую таблицу с табуляцией. Реализовать то же самое в моем модуле заняло всего несколько строк кода.
Теперь, если rwhois клиент для какого-то rwhois сервера выдает ошибку, модуль пробует повторно обратиться к нему как к обычному whois серверу. Если это ему удается, сервер навсегда заносится в список обычных whois серверов.
Как обработать полученный результат?
Самое сложное — это отличить валидный результат от сообщения об ошибке. Задача абсолютно нетривиальная: формат сообщения об ошибке для конкретного whois сервера может быть каким угодно. Алгоритм был придуман и усовершенствован экспериментальным путем. У меня уже был достаточно большой набор валидных результатов от различных whois серверов, получить сообщения об ошибке также не составило труда: достаточно было отправить к каждому известному серверу запрос на несуществующий или некорректный домен или IP адрес (это легко автоматизировалось).
В конце концов, я пришел к следующему:
Если результат получен для IP адреса с одного из пяти региональных whois серверов, то нижеследующие строки точно свидетельствует об ошибке:
Если ARIN вернул нам несколько результатов (например, для 8.8.8.8), то нужно выбрать из них нужный:
Разбиваем результат по #end и #start и выбираем ту часть, которая соответствует наименьшему диапазону (в нашем случае 8.8.8.0 — 8.8.8.255).
Ну и несколько последних штрихов:
1. Удаляем из результата все строки, которые содержат наш собственный IP адрес (многие whois серверы включают его в результат).
2. Удаляем все HTML тэги (некоторые whois серверы любят вставлять их, где не надо).
3. Исправляем кодировку для японских и корейских whois серверов:
Вот как бы и все. Если вы прочитали всю статью, следующий раздел можете смело пропускать.
Короткие итоги
Работа whois протокола описана в RFC 3912 (http://tools.ietf.org/html/rfc3912), содержащем минимум информации и оставляющем whois серверам широкое поле для «самодеятельности». Фактически, все сводится к следующему: открыть TCP соединение на порт 43 к нужному whois серверу, послать запрос в определенном формате, закончить его «\r\n» и получить результат также в определенном формате. Конкретные детали каждый whois сервер определяет по собственному усмотрению. Также не всегда очевидно, откуда взять нужный whois сервер для конкретного домена или IP адреса.
Для получения whois информации существует стандартная Unix-овая утилита «whois», однако она использует очень простой и достаточно устаревший алгоритм, который во многих ситуациях не работает. Среди альтернатив можно выделить jwhois и Ruby Whois — обе программы используют принцип хардкода, работая на основе километровых конфигурационных файлов, которые содержат все известные whois серверы и описание особенностей работы с каждым из них. Такой подход также не всегда работает, кроме того, требует постоянного обновления конфигурации (стоит отметить, что конфигурация jwhois не обновлялась с 2011-го года).
Как показала практика, вполне реально написать свою собственную whois библиотеку, которая будет иметь минимум хардкода, но при этом сможет эффективно определять нужные whois серверы и коммуницировать с ними.
В целом, работа с whois сводится к решению трех принципиальных задач:
Результат, полученный от первого whois сервера, может содержать ссылку на другой whois сервер с дополнительной информацией. Чаще всего, она будет выглядеть как «whois server: », однако в отдельных случаях может выглядеть и по-другому. Здесь нужно не забывать о том, что многие whois серверы бывают доступны под несколькими алиасами, и найденное название может быть не дополнительным whois сервером, а просто другим алиасом первого сервера (на практике, whois серверы часто включают в результат свое название).
С IP адресами ситуация другая. Есть пять основных региональных whois серверов:
Стоит помнить, что whois.ripe.net и whois.afrinic.net могут легко забанить IP адрес, с которого приходит слишком много запросов. Кроме того, whois.lacnic.net работает как прокси и, в случае необходимости, отправляет запросы на все остальные региональные whois серверы (естественно, увеличивая «счетчики» на whois.ripe.net и whois.afrinic.net).
В подавляющем большинстве случаев правильный запрос к whois серверу должен выглядеть как » \r\n», однако некоторые whois серверы требуют другой формат запроса (детали смотреть в разделе «Как правильно отправить запрос?«).
Некоторые whois серверы работают по альтернативному протоколу, который называется rwhois («Referral Whois») и использует порт 4321 (смотреть http://en.wikipedia.org/wiki/Whois#Referral_Whois и http://tools.ietf.org/html/rfc2167). Его реализация достаточно сложна, поэтому для работы с rwhois серверами рекомендуется использовать уже имеющиеся решения (например, http://projects.arin.net/rwhois/). При этом стоит помнить, что многие серверы, которые идентифицируют себя как rwhois, на самом деле работают по протоколу обычного whois! Упомянутый выше rwhois клиент этого не подозревает и выдает ошибку.
Когда результат с whois сервера наконец-то получен, встает задача отличить валидный результат от сообщения об ошибке. На практике сделать это достаточно непросто, так как у разных whois серверов сообщение об ошибке может выглядеть как угодно. Алгоритм, который используется в моем модуле, детально описан в разделе «Как обработать полученный результат?«.
Нужно помнить, что многие whois серверы включают в результат IP адрес, с которого был сделан запрос. Также некоторые whois серверы используют в своих результатах HTML тэги. Большинство whois серверов возвращают результат в кодировке utf8, однако японские и корейские whois серверы используют iso-2022-jp и euc-kr соответственно.