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

DNS не может распространяться по всему миру

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

Я запустил простой запрос и я могу как бы подтвердить это - serverfault.com dns, похоже, не удается разрешить в нескольких странах без какой-либо конкретной причины, которую я могу различить. (также подтверждено через Какой у меня DNS который делает некоторые пинги по всему миру аналогичным образом, поэтому это подтверждено как проблема двумя разными источниками.)

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

Обновление: по состоянию на понедельник в 3:30 утра по тихоокеанскому времени все выглядит правильно .. Сайт отчетов JustPing доступен из всех мест. Спасибо за множество очень информативных ответов, я многому научился и обращусь к этому вопросу, когда это произойдет в следующий раз ..

domain-name-system

Это не напрямую проблема 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 level - отсюда оба сервера имен имеют идентичные маршруты трассировки.

Единственный раз, когда я когда-либо видел что-то подобное, оно было сломано Cisco Express Forwarding (CEF). Это кэш аппаратного уровня, используемый для ускорения маршрутизации пакетов. К сожалению, время от времени он не синхронизируется с реальной таблицей маршрутизации и пытается пересылать пакеты через неправильный интерфейс. Записи CEF могут опуститься до /32 уровень, даже если базовая запись таблицы маршрутизации предназначена для /24. Найти такие проблемы сложно, но после выявления их обычно легко исправить.

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

ОБНОВЛЕНИЕ в 10:38 UTC Как отметил Джефф, проблема исчезла. Трассировки на оба упомянутых выше сервера теперь проходят через 208.109.115.121 следующий прыжок.

ваши DNS-серверы для serverfault.com [ns21.domaincontrol.com, ns22.domaincontrol.com. ] недоступны. за последние ~ 20 часов, по крайней мере, от пары крупных ИСП в Швеции [ телия, tele2, bredband2 ].

в то же время «соседние» DNS-серверы для stackoverflow.com и superuser.com [ns51.domaincontrol.com, ns52.domaincontrol.com] доступны.

образец traceroute на 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 и изменил ли серверы имен - например, поиск serverfault.com на http://www.squish.net/dnscheck/ используя тип записи: ЛЮБОЙ
проверьте, отвечают ли предоставленные серверы имен на ping [не очень научно, поскольку серверы имен могут работать нормально и по-прежнему блокировать icmp, но в этом случае кажется, что icmp разрешен для других серверов] от telia через зеркало.

редактировать: traceroutes с рабочих мест

Польша

 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

редактировать: теперь действительно все работает нормально.

Мои предложения: как объяснил Альнитак, проблема не в DNS, а в маршрутизации (вероятно, BGP). То, что ничего не было изменено в настройке DNS, является нормальным, поскольку проблема была не в DNS.

serverfault.com сегодня имеет очень плохую настройку DNS, явно недостаточную для такого важного сайта, как этот:

только два сервера имен
все яйца в одной корзине (оба находятся в одной AS)

Мы только что увидели результат: сбоя маршрутизации (что довольно часто встречается в Интернете) достаточно, чтобы сервер serverfault.com исчез для некоторых пользователей (в зависимости от их операторов, а не их стран).

Предлагаю добавить больше серверов имен, расположенных в другой 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 такой же traceroute. С рабочего места этот роутер 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 и выполнить traceroute из сети Global Crossing

РЕДАКТИРОВАТЬ: Кажется, что такая же проблема уже возникла с другими NS несколько дней назад, см.: http://www.newtondynamics.com/forum/viewtopic.php?f=9&t=5277&start=0

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

В противном случае наиболее вероятно, что проблемы находятся «ниже» в дереве, поскольку сбои в корне или TLD повлияют на большее количество доменов (можно надеяться). Чтобы повысить устойчивость, вы можете передать полномочия второй службе DNS, чтобы обеспечить лучшую избыточность при разрешении, если есть проблемы с сетями управления доменом.

Я удивлен, что у вас нет собственного DNS. Преимущество такого подхода в том, что DNS доступен, как и (надеюсь) ваш сайт.

По крайней мере, от UPC, я получаю такую реакцию при попытке получить вашу запись A с вашего авторитетного сервера (ns21.domaincontrol.com).

; <<>> DiG 9.5.1-P2 <<>> @ns21.domaincontrol.com serverfault.com
; (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:
;serverfault.com.       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 serverfault.com
; (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:
;serverfault.com.               IN      A

;; ANSWER SECTION:
serverfault.com.        3600    IN      A       69.59.196.212

;; AUTHORITY SECTION:
serverfault.com.        3600    IN      NS      ns21.domaincontrol.com.
serverfault.com.        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.