DNS не вдалося поширити по всьому світу

Я нічого не змінив, пов’язаний із записом DNS для serverfault.com , але деякі користувачі сьогодні повідомляли, що DNS serverfault.com не вдається вирішити їх .

Я запустив запит щойно, і я можу начебто це підтвердити - сервер default.com dns, здається, не вдається вирішити в кількох країнах, без будь-якої конкретної причини, яку я не можу розрізнити. (також підтверджено в службі What My DNS, яка робить деякі пінг-файли у всьому світі аналогічним чином, тому це підтверджено двома різними джерелами.)

• Чому це станеться, якщо я не торкнувся DNS для serverfault.com?

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

• Чи можу я щось зробити, щоб виправити це? Будь-який спосіб гусати DNS або змусити DNS правильно поширюватися по всьому світу?

Оновлення: станом на понеділок о 3:30 ранку PST, все виглядає правильно. Сайт 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цього, цього не повинно відбуватися .

Я робив traceroutes через свою мережу, яка в кінцевому підсумку використовує MFN Above.net замість Global Crossing, щоб дістатися до GoDaddy, і немає жодних ознак хитрощів маршрутизації нижче /24рівня - обидва сервери імен мають однакові маршрути звідси.

Єдиний раз, коли я бачив щось подібне, це було зламане переадресація Cisco Express (CEF). Це кеш апаратного рівня, який використовується для прискорення маршрутизації пакетів. На жаль, іноді він виходить із синхронізації з реальною таблицею маршрутизації та намагається переслати пакети через неправильний інтерфейс. Записи CEF можуть знизитися до /32рівня, навіть якщо базовий запис таблиці таблиць маршрутизації призначений для a /24. Складно знайти подібні проблеми, але після їх виявлення їх легко легко усунути.

Я надіслав електронною поштою GC, а також намагався поговорити з ними, але вони не створили квиток для не клієнтів. Якщо хтось із вас є клієнтом GC, спробуйте повідомити про це ...

ОНОВЛЕННЯ о 10:38 UTC Як зауважив Джефф, проблема тепер усунулася. Сліди до обох вищезгаданих серверів проходять через 208.109.115.121наступний скачок.

ваші dns-сервери для serverfault.com [ns21.domaincontrol.com, ns22.domaincontrol.com. ] недосяжні. протягом останнього ~ 20 год. , щонайменше, від пари основних острів у Швеції [ telia , 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 - ідіть тато.

ви можете перевірити, чи проблема [частково] вирішена за допомогою:

1. перевірка того, чи реагував godaddy та змінив сервери імен - наприклад, lookup serverfault.com за адресою http://www.squish.net/dnscheck/, використовуючи тип recort: БУДЬ-ЯК
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)

Ми щойно побачили результат: глюк маршрутизації (те, що є досить поширеним в Інтернеті) достатньо для того, щоб сервер defaultfault зникав для деяких користувачів (залежно від операторів, а не від їх країн).

Я пропоную додати більше серверів імен, розташованих в інших AS. Це дозволило б витримати стійкість. Ви можете взяти їх в оренду приватним компаніям або попросити користувачів сервера за замовчуванням запропонувати вторинний 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

EDIT: Схоже, що однакова проблема вже виникала з іншими НС кілька днів тому, див: 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.