Назад | Перейти на главную страницу

Некоторые DNS-серверы в мире дают неправильный IP-адрес для нашего домена?

Наш домен, grahamhancock.com, ошибочно разрешается несколькими людьми по всему миру, но для большинства людей он разрешается правильно.

Когда я просматриваю список бесплатных открытых DNS-провайдеров, около 90% разрешаются правильно и предоставляют информацию, соответствующую нашему файлу зоны. 10%, однако, этого не делают и утверждают, что IP-адрес связан с некоторыми Amazon EC2 экземпляр, которым мы никогда раньше не владели и не использовали. Вот несколько примеров DNS-серверов, дающих неверную информацию:

dig www.grahamhancock.com @173.84.127.88
dig www.grahamhancock.com @209.222.18.222

Как эти серверы могли иметь неверную информацию и как мы можем вернуть контроль над ситуацией?

Может быть, это что-то злонамеренное или неправильная конфигурация? Наш сайт посещается 1 миллион раз в месяц и имеет хорошие результаты поиска, поэтому мы, вероятно, являемся целью чего-то вредоносного. Неправильный IP-адрес, который ошибочный сервер возвращает некоторым людям, указывает на какой-то сайт быстрого обогащения на экземпляре AWS EC2.

Что нам делать?

Скиталец прав, у вас проблема с настройкой сервера имен. Вот конец вывода из dig +trace +additional www.grahamhancock.com:

grahamhancock.com.      172800  IN      NS      ns1.grahamhancock.com.
grahamhancock.com.      172800  IN      NS      ns2.grahamhancock.com.
grahamhancock.com.      172800  IN      NS      server.grahamhancock.com.
ns1.grahamhancock.com.  172800  IN      A       199.168.117.67
ns2.grahamhancock.com.  172800  IN      A       199.168.117.67
server.grahamhancock.com. 172800 IN     A       199.168.117.67
;; Received 144 bytes from 192.35.51.30#53(f.gtld-servers.net) in 92 ms

www.grahamhancock.com.  14400   IN      CNAME   grahamhancock.com.
grahamhancock.com.      14400   IN      A       199.168.117.67
grahamhancock.com.      86400   IN      NS      ns2.grahamhancock.com.com.
grahamhancock.com.      86400   IN      NS      ns1.grahamhancock.com.com.
;; Received 123 bytes from 199.168.117.67#53(ns2.grahamhancock.com) in 17 ms

Ваши клейкие записи указывают на IP-адрес 199.168.117.67, который возвращает правильный ответ. Однако ваша зона определяет записи сервера имен, заканчивающиеся на com.com. Если мы +trace вместо этого один из тех серверов имен ...

com.com.                172800  IN      NS      ns-180.awsdns-22.com.
com.com.                172800  IN      NS      ns-895.awsdns-47.net.
com.com.                172800  IN      NS      ns-1084.awsdns-07.org.
com.com.                172800  IN      NS      ns-2015.awsdns-59.co.uk.
;; Received 212 bytes from 192.26.92.30#53(c.gtld-servers.net) in 22 ms

ns1.grahamhancock.com.com. 30   IN      A       54.201.82.69
com.com.                172800  IN      NS      ns-1084.awsdns-07.org.
com.com.                172800  IN      NS      ns-180.awsdns-22.com.
com.com.                172800  IN      NS      ns-2015.awsdns-59.co.uk.
com.com.                172800  IN      NS      ns-895.awsdns-47.net.
;; Received 196 bytes from 205.251.195.127#53(ns-895.awsdns-47.net) in 16 ms

... мы оказываемся на чьих-то серверах имен, размещенных на AWS.

Ваша проблема известна как несоответствие записи клея. Первоначально удаленные серверы имен узнают о вашем домене через связующие записи, но как только эти удаленные серверы выполнят обновление в конечном итоге они запрашивают фиктивные серверы имен, которые вы определили с дополнительным .com в конце.

Это не единственная твоя проблема. Вы трижды указываете один и тот же IP-адрес в своих клеевых записях, что крайне нестабильно. У вас всегда должно быть несколько серверов имен, они никогда не должны совместно использовать подсеть или одноранговый узел вышестоящей сети, и они никогда не должны находиться в одном и том же физическом месте. В настоящее время любая краткая проблема маршрутизации между DNS-серверами и вашим единственным сервером приведет к тому, что ваш домен станет временно недоступным.

Обновить:

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

Деталь, которую, кажется, упускают из виду большинство людей, - это комментарий, который я цитирую здесь:

  • [...] георезервированные DNS-серверы предотвращают сценарии, в которых кратковременное прерывание маршрутизации приводит к временному отрицательному кэшированию серверов имен. Каким бы коротким ни был период отрицательного кэширования, он почти наверняка превысит время, в течение которого было прерывание соединения. [...] количество сценариев, в которых отсутствие геоизбыточности DNS не приведет к возникновению спорадических и трудных для устранения проблем доступности, равно нулю.

Если вы считаете, что мое понимание негативного кэширования серверов имен неверно, это открытая игра для обсуждения, но помимо этого вам нужно внести что-то в таблицу, кроме «это небольшой сайт, и кого волнует, если и веб-сайт, и DNS-сервер не работают. в то же время". Если вы говорите это, вы не понимаете тему почти так хорошо, как думаете.

Второе обновление:

Я пошел дальше и написал канонические вопросы и ответы на которую мы можем ссылаться всякий раз, когда в будущем возникнет тема единого DNS-сервера. Надеюсь, это решит проблему.

Использование следующих инструментов дает несколько подсказок

https://www.whatsmydns.net/#NS/grahamhancock.com сообщает, что записи NS в домене указывают на ns1.grahamhancock.com.com обратите внимание на дополнительный .com

http://mxtoolbox.com/SuperTool.aspx?action=dns%3agrahamhancock.com&run=toolpage также сообщает, что тот же сервер имен является авторитетным.

Если вы посмотрите сюда http://www.dnsstuff.com/tools#dnsReport|type=domain&&value=grahamhancock.com он также сообщает, что ваши серверы имен открыты.

Таким образом, может показаться, что где-то в строке серверы имен установлены неправильно. Если они отображаются правильно через панель управления и т. Д., Вам нужно будет поговорить с провайдером, чтобы они могли проверить их на реальных серверах.

По этим ссылкам также есть полный отчет о передовых методах работы и способах их устранения.