DNS не может распространяться по всему миру
Я не изменил ничего, касающегося записи DNS для faultserver.ru, но некоторые пользователи сегодня сообщали, что DNS faultserver.ru не удается разрешить их.
Я выполнил запрос Justping, и я могу что-то вроде подтвердить это - faultserver.ru dns, кажется, не удается разрешить в нескольких странах, без какой-либо конкретной причины, которую я могу различить. (также подтверждено через " Что такое мой DNS", который аналогичным образом выполняет пинг по всему миру, поэтому это подтверждается как проблема двумя разными источниками.)
Почему это произошло бы, если бы я не коснулся DNS для faultserver.ru?
наш регистратор - (gag) GoDaddy, и я использую настройки DNS по умолчанию по большей части без происшествий. Я делаю что-то неправильно? Боги DNS оставили меня?
Что я могу сделать, чтобы это исправить? Есть ли способ обмануть DNS или заставить DNS правильно распространяться по всему миру?
Обновление: по состоянию на понедельник в 3:30 по тихоокеанскому времени все выглядит правильно. Сайт отчетов JustPing доступен из любого места. Спасибо за много очень информативных ответов, я многому научился и буду ссылаться на этот вопрос в следующий раз, когда это произойдет..
7 ответов
Это не проблема DNS, это проблема сетевой маршрутизации между некоторыми частями Интернета и DNS-серверами для faultserver.ru. Поскольку сервер имен недоступен, домен перестает разрешаться.
Насколько я могу судить, проблема с маршрутизацией на маршрутизаторе (Global Crossing?) С IP-адресом 204.245.39.50,
Как показывает radius, пакеты к ns52 (как используется http://stackoverflow.com/) проходят отсюда к 208.109.115.121 и оттуда работают правильно. Однако пакеты к ns22 идут вместо 208.109.115.201,
Поскольку эти два адреса находятся в одном и том же /24 и соответствующее объявление BGP также для /24 этого не должно случиться.
Я сделал трассировки через мою сеть, которая в конечном итоге использует MFN Above.net вместо Global Crossing, чтобы добраться до GoDaddy, и нет никаких признаков хитрости маршрутизации ниже /24 уровень - оба сервера имен имеют идентичные трассировки отсюда.
Единственный раз, когда я видел что-то подобное, это было сломано Cisco Express Forwarding (CEF). Это кэш аппаратного уровня, используемый для ускорения маршрутизации пакетов. К сожалению, иногда он не синхронизируется с реальной таблицей маршрутизации и пытается пересылать пакеты через неправильный интерфейс. Записи CEF могут идти до /32 уровень, даже если основная запись таблицы маршрутизации предназначена для /24, Найти такие проблемы сложно, но, как только они обнаружены, их обычно легко исправить.
Я отправил письмо по электронной почте для GC, а также попытался поговорить с ними, но они не создадут билет для не-клиентов. Если кто-либо из вас является клиентом GC, попробуйте сообщить об этом...
ОБНОВЛЕНИЕ в 10:38 UTC Как заметил Джефф, проблема теперь прояснилась. Трассировки на оба упомянутых выше сервера теперь проходят через 208.109.115.121 следующий прыжок.
Ваши DNS-серверы для faultserver.ru [ ns21.domaincontrol.com, ns22.domaincontrol.com. ] недоступны за последние ~20 часов, по крайней мере, от пары главных испов в Швеции [ telia, tele2, http://bredband2.com/ ].
в то же время доступны "соседние" DNS-серверы для stackoverflow.com и superuser.com [ns51.domaincontrol.com, ns52.domaincontrol.com].
Пример трассировки до ns52.domaincontrol.com:
1. xxxxxxxxxxx
2. 83.233.28.193
3. 83.233.79.81
4. 213.200.72.5
5. 64.208.110.129
6. 204.245.39.50
7. 208.109.115.121
8. 208.109.115.162
9. 208.109.113.62
10. 208.109.255.26
и ns21.domaincontrol.com
1. xxxxxxxxxxxx
2. 83.233.28.193
3. 83.233.79.81
4. 213.200.72.5
5. 64.208.110.129
6. 204.245.39.50
7. 208.109.115.201
8. ???
может быть, испорчена фильтрация / кто-то вызвал нежелательную защиту ddos и занес в черный список некоторые части интернета. вероятно, вам следует обратиться к поставщику услуг DNS - иди папа.
Вы можете проверить, если проблема [частично] решена с помощью:
- проверка того, что Godaddy отреагировал и изменил серверы имен - например, ищите faultserver.ru на http://www.squish.net/dnscheck/ используя тип отчета: ЛЮБОЙ
- проверьте, отвечают ли предоставленные серверы имен на ping [не очень научно, так как серверы имен могут работать нормально и по-прежнему блокировать icmp, но в этом случае кажется, что icmp разрешен для других серверов] из telia через зеркало.
редактировать: трассировки с рабочих мест
Польша
1. xxxxxxxxxxxxxxx
2. 153.19.40.254
3. ???
4. 153.19.254.236
5. 212.191.224.205
6. 213.248.83.129
7. 80.91.254.171
8. 80.91.249.105
80.91.251.230
80.91.254.93
80.91.251.52
9. 213.248.89.182
10. 204.245.39.50
11. 208.109.115.121
12. 208.109.115.162
13. 208.109.113.62
14. 208.109.255.26
Германия
1. xxxxxxxxxxxx
2. 89.149.218.181
3. 89.149.218.2
4. 134.222.105.249
5. 134.222.231.205
6. 134.222.227.146
7. 80.81.194.26
8. 64.125.24.6
9. 64.125.31.249
10. 64.125.27.165
11. 64.125.26.178
12. 64.125.26.242
13. 209.249.175.170
14. 208.109.113.58
15. 208.109.255.26
редактировать: теперь все работает нормально.
Мои предложения: как объяснил Alnitak, проблема не в DNS, а в маршрутизации (вероятно, BGP). То, что в настройке DNS ничего не изменилось, это нормально, так как проблема не в DNS.
На faultserver.ru сегодня очень плохая настройка DNS, которой явно недостаточно для такого важного сайта, как этот:
- только два сервера имен
- все яйца в одной корзине (оба в одной AS)
Мы только что увидели результат: сбой маршрутизации (что довольно распространено в Интернете) достаточен для того, чтобы faultserver.ru исчезал для некоторых пользователей (в зависимости от их операторов, а не от их стран).
Я предлагаю добавить больше серверов имен, расположенных в других AS. Это позволило бы отказоустойчивость. Вы можете либо сдать их в аренду частным компаниям, либо попросить пользователей serverfault предложить вторичный DNS-хостинг (может быть, только если у пользователя> 1000 представителей:-)
Я подтверждаю, что NS21.DOMAINCONTROL.COM и NS22.DOMAINCONTROL.COM также не доступны для ISP Free.fr во Франции.
Как и pQd traceroute, мои также заканчиваются после 208.109.115.201 для ns21 и ns22.
traceroute to NS22.DOMAINCONTROL.COM (208.109.255.11), 64 hops max, 40 byte packets
1 x.x.x.x (x.x.x.x) 2.526 ms 0.799 ms 0.798 ms
2 78.224.126.254 (78.224.126.254) 6.313 ms 6.063 ms 6.589 ms
3 213.228.5.254 (213.228.5.254) 6.099 ms 6.776 ms *
4 212.27.50.170 (212.27.50.170) 6.943 ms 6.866 ms 6.842 ms
5 212.27.50.190 (212.27.50.190) 8.308 ms 6.641 ms 6.866 ms
6 212.27.38.226 (212.27.38.226) 68.660 ms 185.527 ms 14.123 ms
7 204.245.39.50 (204.245.39.50) 48.544 ms 19.391 ms 19.753 ms
8 208.109.115.201 (208.109.115.201) 19.315 ms 19.668 ms 34.110 ms
9 * * *
10 * * *
11 * * *
12 * * *
Но ns52.domaincontrol.com (208.109.255.26) работает и находится в той же подсети, что и ns22.domaincontrol.com (208.109.255.11)
traceroute to ns52.domaincontrol.com (208.109.255.26), 64 hops max, 40 byte packets
1 x.x.x.x (x.x.x.x) 1.229 ms 0.816 ms 0.808 ms
2 78.224.126.254 (78.224.126.254) 12.127 ms 5.623 ms 6.068 ms
3 * * *
4 212.27.50.170 (212.27.50.170) 13.824 ms 6.683 ms 6.828 ms
5 212.27.50.190 (212.27.50.190) 6.962 ms * 7.085 ms
6 212.27.38.226 (212.27.38.226) 35.379 ms 7.105 ms 7.830 ms
7 204.245.39.50 (204.245.39.50) 19.896 ms 19.426 ms 19.355 ms
8 208.109.115.121 (208.109.115.121) 37.931 ms 19.665 ms 19.814 ms
9 208.109.115.162 (208.109.115.162) 19.663 ms 19.395 ms 29.670 ms
10 208.109.113.62 (208.109.113.62) 19.398 ms 19.220 ms 19.158 ms
11 * * *
12 * * *
13 * * *
Как видите, на этот раз после 204.245.39.50 мы идем к 208.109.115.121 вместо 208.109.115.201. И у pQd та же трассировка. С рабочего места я не пересек этот роутер 204.245.39.50 (Global Crossing).
Помогло бы больше трассировки с рабочего и нерабочего места, но весьма вероятно, что у Global Crossing есть фиктивные записи маршрутизации для 208.109.255.11/32 и 216.69.185.11/32 как 208.109.255.10, 208.109.255.12, 216.69.185.10, 216.69.185.12 работают хорошо.
Трудно понять, почему у него есть фиктивная запись о маршрутизации. Вероятно, 208.109.115.201 (Go Daddy) рекламирует нерабочий маршрут для 208.109.255.11/32 и 216.69.185.11/32.
РЕДАКТИРОВАТЬ: Вы можете telnet route-server.eu.gblx.net подключиться к серверу маршрута Global Crossing и выполнить трассировку изнутри сети Global Crossing
РЕДАКТИРОВАТЬ: Кажется, что та же проблема уже произошла с другими NS несколько дней назад, см.: http://www.newtondynamics.com/forum/viewtopic.php?f=9&t=5277&start=0
Что было бы удобно, так это увидеть детальную трассировку разрешения из тех мест, где происходит сбой... посмотреть, на каком уровне пути разрешения происходит сбой. Я не знаком с услугой, которую вы используете, но, возможно, это вариант где-то.
В противном случае, наиболее вероятно, что проблемы "снизу" в дереве, поскольку сбои в корне или TLD повлияют на большее количество доменов (можно надеяться). Для повышения устойчивости вы можете делегировать вторую службу DNS, чтобы обеспечить лучшую избыточность в разрешении, если есть проблемы с сетью (ами) domaincontrol.
Я удивлен, что у вас нет собственного DNS. Преимущество такого подхода заключается в том, что DNS доступен, как и (надеюсь) ваш сайт.
По крайней мере, от UPC, я получаю эту реакцию, когда пытаюсь получить вашу запись A с вашего авторизованного сервера (ns21.domaincontrol.com).
; <<>> DiG 9.5.1-P2 <<>> @ns21.domaincontrol.com faultserver.ru
; (1 server found)
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 38663
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;faultserver.ru. IN A
;; Query time: 23 msec
;; SERVER: 216.69.185.11#53(216.69.185.11)
;; WHEN: Sun Jul 19 12:09:40 2009
;; MSG SIZE rcvd: 33
Когда я пытаюсь сделать то же самое с компьютера в другой сети (OVH), я получаю ответ
; <<>> DiG 9.4.2-P2 <<>> @216.69.185.11 faultserver.ru
; (1 server found)
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 33998
;; flags: qr aa; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 0
;; QUESTION SECTION:
;faultserver.ru. IN A
;; ANSWER SECTION:
faultserver.ru. 3600 IN A 69.59.196.212
;; AUTHORITY SECTION:
faultserver.ru. 3600 IN NS ns21.domaincontrol.com.
faultserver.ru. 3600 IN NS ns22.domaincontrol.com.
;; Query time: 83 msec
;; SERVER: 216.69.185.11#53(216.69.185.11)
;; WHEN: Sun Jul 19 12:11:05 2009
;; MSG SIZE rcvd: 101
Я получаю аналогичное поведение для пары других доменов, поэтому я предполагаю, что UPC (по крайней мере) молча перенаправляет DNS-запросы на их собственный кэширующий сервер имен и подделывает ответы. Если ваш DNS ненадлежащим образом вел себя неправильно, это могло бы объяснить это, поскольку серверы имен UPC могут кэшировать ответ NXDOMAIN.