У меня есть два разных сервера FreeBSD (разные хостинговые компании), оба демонстрируют одно и то же поведение: они выбирают определенный IP-адрес (216.239.120.238) для каждого домена, который НЕ существует.
nslookup не работает как надо ....
$ nslookup thisdomainsurelydoesntexist.com
Server: xx.xx.229.3
Address: xx.xx.229.3#53
** server can't find thisdomainsurelydoesntexist.com: NXDOMAIN
копать дает мне:
$ dig thisdomainsurelydoesntexist.com
; <<>> DiG 9.6.-ESV-R5-P1 <<>> thisdomainsurelydoesntexist.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 51717
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0
;; QUESTION SECTION:
;thisdomainsurelydoesntexist.com. IN A
;; AUTHORITY SECTION:
com. 900 IN SOA a.gtld-servers.net. nstld.verisign-grs.com. 1370378827 1800 900 604800 86400
;; Query time: 23 msec
;; SERVER: xx.xx.229.3#53(xx.xx.229.3)
;; WHEN: Tue Jun 4 16:05:02 2013
;; MSG SIZE rcvd: 122
и пинг дает мне:
$ ping thisdomainsurelydoesntexist.com
PING phx2-ss-5-bug616849-lb.cnet.com (216.239.120.238): 56 data bytes
64 bytes from 216.239.120.238: icmp_seq=0 ttl=244 time=25.733 ms
64 bytes from 216.239.120.238: icmp_seq=1 ttl=244 time=20.460 ms
^C
--- phx2-ss-5-bug616849-lb.cnet.com ping statistics ---
2 packets transmitted, 2 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 20.460/23.096/25.733/2.637 ms
Обратите внимание, что последнее имя хоста dig, nstld.verisign-grs.com, преобразуется в этот IP-адрес.
Что исправить?
ОБНОВИТЬ: В /etc/resolv.conf есть две строки серверов имен, каждая с IP (v4), полученным от моего интернет-провайдера.
Но если я добавлю строку «search» в resolv.conf, поведение изменится: если «search mydomain.com» (т.е. мое настоящее доменное имя), все будет разрешено, и я получу свой собственный IP. Например, thisdomainsurelydoesntexist.com.mydomain.com. Не хорошо. Но если я установлю что-то другое, например «поиск myispdomain.com», тогда все будет работать: существующие домены разрешаются, а несуществующие - нет.
Но разве это не случайность?
Спасибо за предложения! Здесь host -a, а IP xx.xx.80.18 - это первый сервер имен в /etc/resolv.conf
$ host -a thisdomainsurelydoesntexist.com
Trying "thisdomainsurelydoesntexist.com"
Received 122 bytes from xx.xx.80.18#53 in 13 ms
Trying "thisdomainsurelydoesntexist.com"
Host thisdomainsurelydoesntexist.com not found: 3(NXDOMAIN)
Received 122 bytes from xx.xx.80.18#53 in 0 ms
Мой интернет-провайдер только что сказал мне, что это может быть из-за того, что мое имя хоста имеет форму «mydomain.com» вместо «myhost.mydomain.com» (что является их рекомендуемой практикой). Я видел, как это исправить. Это то, что нужно сделать? Никаких минусов?
Также, что очень важно, я должен упомянуть, что этот код Python работает так же, как и ping:
import _socket
_socket.getaddrinfo('thisdomainsurelydoesntexist.com', 80)
И многие другие модули python построены на этом ядре.
Система (особенно glibc, которая обрабатывает разрешение имен) ведет себя хаотично, когда имя хоста сервера является именем домена. На странице руководства для resolv.conf:
Список поиска обычно определяется по локальному доменному имени; по умолчанию он содержит только локальное доменное имя.
Простыми словами это означает, что когда поиск домена завершается неудачно (после того, как в / etc / hosts ничего не обнаруживается и распознаватель не может вернуть полезный результат), система приступит к беспечному удалению первой части имени хоста - например, ' abcxyz.com '- и добавьте остаток как суффикс поиска.
Поскольку '.com' - это суффикс поиска, полученный путем удаления 'abcxyz' из имени хоста, система добавляет '.com' в качестве суффикса поиска для неудачных поисков, что дает такие результаты, как:
foobar-abcxyz.cz -> foobar-abcxyz.cz.com -> www.czjewelry.com
foobar-abcxyz.com -> foobar-abcxyz.com.com -> www.cnet.com
Чтобы исправить это, вы, вероятно, захотите установить для имени хоста сервера такое имя хоста, как «hostname.abcxyz.com» вместо «abcxyz.com», что, в свою очередь, приведет к добавлению «abcxyz.com» как суффикс поиска по умолчанию.
В качестве временной меры вы можете создать случайную контрольную сумму MD5 и добавить ее в /etc/resolv.conf в качестве переопределения для суффикса поиска:
uuidgen | md5sum
e930f5f4ba6ba7868b0cc6718bcef568 -echo "поиск e930f5f4ba6ba7868b0cc6718bcef568" >> / etc / resolv.conf
Это приведет к добавлению «e930f5f4ba6ba7868b0cc6718bcef568» к неудачным поискам в DNS вместо «.com», что, в свою очередь, приведет к поведению по умолчанию при неудачных поисках несуществующих доменов. Если вы измените имя хоста на фактическое имя хоста, эту строку можно удалить.
Некоторые серверы имен намеренно возвращают IP-адреса несуществующих доменов. Интернет-провайдеры печально известны тем, что делают это - они могут фактически монетизировать рекламу, размещаемую на целевых страницах для несуществующих доменов.
Вы всегда можете изменить свой файл resolv.conf для использования общедоступных DNS-серверов, которые, как известно, не демонстрируют такого поведения. DNS Google (8.8.8.8 и 8.8.4.4) и DNS уровня 3 (с 4.2.2.1 по 4.2.2.6) обеспечивают общедоступный доступ к DNS и не перенаправляют неизвестные домены. (Источник: https://www.grc.com/dns/alternatives.htm)
Мне кажется, что вы используете сеть, в которой используется подстановочный DNS. Это означает, что он автоматически перенаправит вас на этот IP-адрес в случае сбоя адреса. Вы можете проверить это, выполнив поиск в своем веб-браузере. В случае сбоя он перенаправит вас на какую-то спонсируемую страницу поиска, которую обслуживает ваш интернет-провайдер.