Я не изменилсячто-либосвязанные с записью DNS для serverfault.com, но некоторые пользователи сегодня сообщили, чтоDNS-сервер serverfault.com не может разрешить их.
Я побежалзапрос justpingи я могу это подтвердить — DNS-сервер serverfault.com, похоже, не может быть разрешен в нескольких странах, по какой-то конкретной причине, которую я не могу определить. (также подтверждено черезКакой у меня DNS?(который отправляет некоторые мировые пинги аналогичным образом, поэтому наличие этой проблемы подтверждено двумя разными источниками.)
Почему это происходит, если я не трогал DNS для serverfault.com?
Наш регистратор (кляп) GoDaddy, и я использую настройки DNS по умолчанию в большинстве случаев без инцидентов. Я что-то делаю не так? Боги DNS оставили меня?
Можно ли что-то сделать, чтобы это исправить? Есть ли способ подстегнуть DNS или заставить DNS распространяться правильно по всему миру?
Обновление: по состоянию на понедельник в 3:30 утра по тихоокеанскому времени все выглядит правильно.. JustPing сообщает, что сайт доступен из всех мест. Спасибо за множество очень информативных ответов, я многому научился и обращусь к этому вопросу в следующий раз, когда это произойдет..
решение1
Это не проблема DNS напрямую, это проблема сетевой маршрутизации между некоторыми частями интернета и DNS-серверами для serverfault.com. Поскольку серверы имен недоступны, домен перестает разрешаться.
Насколько я могу судить, проблема с маршрутизацией возникла на маршрутизаторе (Global Crossing?) с IP-адресом 204.245.39.50.
Какпоказанок@радиус, пакеты на ns52 (используетсяstackoverflow.com) проходят отсюда 208.109.115.121и оттуда работают правильно. Однако пакеты в ns22 идут вместо этого в 208.109.115.201.
Поскольку эти два адреса находятся в одном и том же месте /24, а соответствующее объявление BGP также предназначено для /24этогоэтого не должно было случиться.
Я выполнил трассировку маршрутов через свою сеть, которая в конечном итоге использует MFN Above.net вместо Global Crossing для доступа к GoDaddy, и не обнаружил никаких признаков каких-либо мошеннических действий с маршрутизацией ниже /24уровня — оба сервера имен имеют идентичные трассировки маршрутов отсюда.
Единственный раз, когда я видел что-то подобное, оно было сломано.Cisco Express Переадресация(CEF). Это кэш аппаратного уровня, используемый для ускорения маршрутизации пакетов. К сожалению, иногда он рассинхронизируется с реальной таблицей маршрутизации и пытается пересылать пакеты через неправильный интерфейс. Записи CEF могут перейти на уровень, /32даже если базовая запись таблицы маршрутизации относится к /24. Сложно найти такие проблемы, но после их обнаружения их обычно легко исправить.
Я написал письмо GC и также пытался поговорить с ними, но они не создают тикет для не клиентов. Если кто-то из васявляютсяклиент GC, пожалуйста, попробуйте сообщить об этом...
ОБНОВЛЕНИЕ в 10:38 UTC Как заметил Джефф, проблема теперь устранена. Трассировки к обоим серверам, упомянутым выше, теперь проходят через 208.109.115.121следующий хоп.
решение2
Ваши DNS-серверы для serverfault.com [ns21.domaincontrol.com, ns22.domaincontrol.com.] недоступны. в течение последних ~20 часов, по крайней мере, от нескольких основных интернет-провайдеров в Швеции [телия,теле2,bredband2].
в то же время «соседние» 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 - Go Daddy.
Вы можете проверить, решена ли проблема [частично] следующим образом:
- проверка того, отреагировал ли godaddy и изменил ли серверы имен - например, поиск serverfault.com по адресу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
редактировать: теперь действительно все работает отлично.
решение3
Мои предложения: как объяснил Alnitak, проблема не в DNS, а в маршрутизации (вероятно, BGP). Тот факт, что ничего не было изменено в настройках DNS, является нормальным, поскольку проблема была не в DNS.
На сегодняшний день у serverfault.com очень плохая настройка DNS, явно недостаточная для такого важного сайта, как этот:
- только два сервера имен
- все яйца в одной корзине (оба находятся в одной и той же АС)
Мы только что увидели результат: сбой маршрутизации (довольно распространенное явление в Интернете) может привести к исчезновению serverfault.com у некоторых пользователей (в зависимости от их операторов, а не от страны).
Предлагаю добавить больше серверов имен, расположенных в других AS. Это позволит обеспечить отказоустойчивость. Вы можете либо сдать их в аренду частным компаниям, либо попросить пользователей serverfault предложить вторичный хостинг DNS (возможно, только если у пользователя > 1000 репутаций :-)
решение4
Было бы удобно увидеть подробную трассировку разрешения из мест, где произошел сбой... посмотреть, на каком слое пути разрешения произошел сбой. Я не знаком с сервисом, который вы используете, но, возможно, где-то это вариант.
Если это не удастся, то, скорее всего, проблемы находятся "ниже" в дереве, поскольку сбои в корне или TLD повлияют на большее количество доменов (можно надеяться). Чтобы повысить устойчивость, вы можете делегировать полномочия второй службе DNS, чтобы обеспечить лучшую избыточность в разрешении, если возникнут проблемы с сетью(ями) domaincontrol.