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

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

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

• Почему это произошло бы, если бы я не коснулся DNS для serverfault.com?

• наш регистратор - (gag) GoDaddy, и я использую настройки DNS по умолчанию по большей части без происшествий. Я делаю что-то неправильно? Боги DNS оставили меня?

• Что я могу сделать, чтобы это исправить? Есть ли способ обмануть DNS или заставить DNS правильно распространяться по всему миру?

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

Это не проблема DNS, это проблема сетевой маршрутизации между некоторыми частями Интернета и DNS-серверами для serverfault.com. Поскольку сервер имен недоступен, домен перестает разрешаться.

Насколько я могу судить, проблема с маршрутизацией на маршрутизаторе (Global Crossing?) С IP-адресом 204.245.39.50.

Как показано на @radius , пакетов ns52 (как используется 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, а также попытался поговорить с ними, но они не будут создавать билеты для не клиентов. Если какой - либо из вас есть клиент ГК, пожалуйста , попробуйте и сообщить об этом ...

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

ваши DNS-серверы для serverfault.com [ns21.domaincontrol.com, ns22.domaincontrol.com. ] недоступны за последний ~ 20h, по крайней мере , из пары основного МНПА в швеции [ Телий , Теле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 - иди папа.

Вы можете проверить, если проблема [частично] решена с помощью:

1. проверка того, что Godaddy отреагировал и изменил серверы имен - например, ищите serverfault.com на http://www.squish.net/dnscheck/, используя тип отчета: ЛЮБОЙ
2. проверьте, отвечают ли предоставленные серверы имен на 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.

На 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 та же трассировка. С рабочего места я не пересек этот роутер 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 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.