Скрипт whois не получает некоторые домены
Я пытаюсь получить данные whois с помощью этой функции:
function getDomain()
$domain = 'stackru.com';
$whois = '';
$connection = @fsockopen('whois.internic.net', 43);
if ($connection) {
@fputs($connection, $domain ."\r\n");
while (!feof($connection)) {
$whois .= @fgets($connection, 128);
}
}
fclose($connection);
return $whois;
}
Он отлично работает для некоторых доменов, но когда я пытаюсь "apple.com","cnn.com" или "google.com", получаю это:
APPLE.COM.ZON.COM
APPLE.COM.WWW.ZON.COM
APPLE.COM.WWW.BEYONDWHOIS.COM
APPLE.COM.WAS.PWNED.BY.M1CROSOFT.COM
APPLE.COM.MORE.INFO.AT.WWW.BEYONDWHOIS.COM
APPLE.COM.IS.OWN3D.BY.NAKEDJER.COM
APPLE.COM.IS.0WN3D.BY.GULLI.COM
APPLE.COM.DENIS.DA.DOIDE.DA.PIEM.UNIX-BG.COM
APPLE.COM.BEYONDWHOIS.COM
APPLE.COM.AT.WWW.BEYONDWHOIS.COM
APPLE.COM
2 ответа
Ваш скрипт только запросы
whois.internic.net
помните, что есть несколько провайдеров доменов / IP по всему миру.
Полноценные инструменты, такие как те, которые предоставляются в большинстве дистрибутивов Linux, знают, что нужно попробовать несколько разных серверов, а затем проверить данные со всех из них, чтобы определить, какой сервер является официальным.
По памяти я считаю, что есть 5 всемирных авторитетных зон, внутренняя у вас уже есть плюс:
whois.afrinic.net
whois.lacnic.net
whois.arin.net
whois.apnic.net
У Ripe (центральный реестр, который мы используем здесь, в Европе) также есть, но это не так, как вы ожидаете, "whois.ripe.net", и у меня нет времени на его поиск прямо сейчас.
Теперь, помимо того, что я сказал выше, вы можете рассмотреть следующее. Большинство органов управления Whois ограничат (или даже заблокируют) ваш трафик, если сочтут, что вы делаете слишком много запросов в течение 24 часов, вместо этого вы можете захотеть войти на ftp-сайт любого из вышеперечисленных провайдеров и загрузить различные биты. базы данных, а затем написать (или найти) свой собственный скрипт для их обработки.
В настоящее время я делаю это с одним из моих собственных серверов, который подключается с помощью следующего сценария оболочки (один раз каждые 24 часа):
#!/bin/bash
rm -f delegated-afrinic-latest
rm -f delegated-lacnic-latest
rm -f delegated-arin-latest
rm -f delegated-apnic-latest
rm -f delegated-ripencc-latest
rm -f ripe.db.inetnum
rm -f apnic.db.inetnum
rm -f ripe.db.inetnum.gz
rm -f apnic.db.inetnum.gz
wget ftp://ftp.afrinic.net/pub/stats/afrinic/delegated-afrinic-latest
wget ftp://ftp.lacnic.net/pub/stats/lacnic/delegated-lacnic-latest
wget ftp://ftp.arin.net/pub/stats/arin/delegated-arin-latest
wget ftp://ftp.apnic.net/pub/stats/apnic/delegated-apnic-latest
wget ftp://ftp.ripe.net/ripe/stats/delegated-ripencc-latest
wget ftp://ftp.ripe.net/ripe/dbase/split/ripe.db.inetnum.gz
ftp -n -v ftp.apnic.net <<END
user anonymous anonymous@anonymous.org
binary
passive
get /apnic/whois-data/APNIC/split/apnic.db.inetnum.gz apnic.db.inetnum.gz
bye
END
gunzip ripe.db.inetnum
gunzip apnic.db.inetnum
Затем у меня есть пользовательская написанная программа, которая разбирает файлы на пользовательскую структуру базы данных, с которой мои серверы затем выполняют свои запросы.
Поскольку все серверы зеркально отражают данные друг друга, вы сможете получить полный набор данных с одного сервера, но если нет, то изменение сценария оболочки для загрузки данных с других серверов не займет много времени. они тоже отвечают "ftp.????" и имеют одинаковую универсальную структуру папок.
Однако я не могу помочь вам с синтаксическим анализатором, так как он содержит собственный код, но формат файла (особенно если вы получаете разделенные файлы) идентичен тому, что вы видите в типичном выводе whois, поэтому с ним очень легко работать.
Загружая и обрабатывая свои собственные данные, вы обойдете все ограничения, налагаемые провайдерами, и в результате вы, скорее всего, будете быстрее запрашивать собственное хранилище данных, чем каждый раз запускать запросы с вашего сервера на серверы запросов. кто-то вводит IP-адрес.
ОБНОВИТЬ
Whois-серверов гораздо больше, чем просто тех, которые я перечислил здесь, однако, вместо того, чтобы перечислять их все на этой странице, эта ссылка:
https://jfreewhois.googlecode.com/git/JFreeWhois/src/uk/org/freedonia/jfreewhois/etc/serverlist.xml
приведет вас к XML-файлу, который является частью проекта по коду Google, возвращенный XML-файл даст вам довольно большой список всех доступных серверов whois, а также список TLD, которые каждый из них обслуживает, что позволяет адаптировать ваш скрипт для связи с правильным сервером в зависимости от введенного адреса.
Префикс ваших запросов с = знак, как =example.com а не просто доменное имя и вы не увидите дополнительных результатов.
Длинная причина в том, что по умолчанию сервер whois выполняет поиск по префиксу и возвращает все объекты, хранящиеся в реестре, чье имя начинается с имени, которое вы задаете в запросе. И, как бы мало это ни было известно, серверы имен являются объектами, хранящимися в реестрах, и давно считалось забавным регистрировать бесполезные серверы имен, просто чтобы "разыграть" невинных зрителей, выполняющих запросы и возвращающих результаты как ваши, которые могли бы быть интерпретированы некоторыми людьми. не зная деталей как: "О, боже, XXXX взломан, посмотри на результаты...", так как ты можешь добавить любое слово в качестве метки (между двумя точками), если закончил.COM/.NET доменное имя у вас есть. Конечно, это не имеет ничего общего с атакой.
Используя префикс с равной строкой, вы устанавливаете точное совпадение вместо префиксного совпадения. Обратите внимание, что пурист может добавить, что даже в этом случае вы можете увидеть две записи назад, поскольку вы можете зарегистрировать сервер имен, имя которого является именем доменного имени (что является более запутанным, чем полезным, но это возможно, и это происходит).
Кстати, для доменных имен.COM вы должны использовать соответствующий сервер Whois реестра, который является whois.verisign-grs.com, То же самое для других TLD. Имейте в виду, что в зависимости от того, что вы ищете, вам может понадобиться 2 запроса whois на домен, так как.COM/.NET (в настоящее время) все еще тонкий реестр. См. Мой ответ на https://unix.stackexchange.com/a/407030/211833 для получения дополнительной информации по этому вопросу.