DNS가 전세계로 전파되지 않음

나는 변경하지 않은 것도 serverfault.com에 대한 DNS 항목과 관련이 있지만, 일부 사용자는 오늘보고 된 serverfault.com의 DNS 그들을 위해 해결하기 위해 실패 .

나는 정당한 쿼리를 실행했으며 이것을 확인할 수 있습니다 .serverfault.com dns는 소수의 국가에서 식별 할 수없는 특별한 이유없이 해결되지 않는 것으로 보입니다. (또한 비슷한 방식으로 일부 핑을 수행하는 What 's My DNS 를 통해 확인 되었으므로 두 가지 다른 소스에서 문제로 확인되었습니다.)

• serverfault.com의 DNS를 건드리지 않으면 왜 이런 일이 발생합니까?

• 등록 기관은 (개그) GoDaddy이며, 대부분의 경우 기본 DNS 설정을 사고없이 사용합니다. 내가 뭔가 잘못하고 있습니까? DNS의 신들이 저를 버리셨습니까?

• 이 문제를 해결하기 위해 내가 할 수있는 일이 있습니까? DNS를 거위로 옮기거나 DNS가 전 세계적으로 올바르게 전파되도록 할 수 있습니까?

업데이트 : 월요일 오전 3시 30 분 (PST 기준), 모든 것이 올바르게 보입니다. JustPing 보고서 사이트는 모든 위치에서 액세스 할 수 있습니다. 매우 유익한 많은 답변에 감사드립니다. 나는 많은 것을 배웠으며 다음에 일어날 때이 Q를 참조 할 것입니다.

이는 직접 DNS 문제가 아니라 인터넷의 일부와 serverfault.com의 DNS 서버 간의 네트워크 라우팅 문제입니다. 네임 서버에 도달 할 수 없기 때문에 도메인 분석이 중지됩니다.

내가 알 수있는 한 라우팅 문제는 IP 주소가있는 (Global Crossing?) 라우터에 있습니다 204.245.39.50.

같이 도시 하여 @radius (의해 사용되는 ns52에 패킷 stackoverflow.com ) 여기에서 패스 208.109.115.121올바르게가 직장에서. 그러나 ns22로가는 패킷은 대신으로 이동합니다 208.109.115.201.

이 두 주소는 모두 동일 /24하며 해당 BGP 공지도 마찬가지이기 때문에 이런 일/24 이 발생하지 않아야합니다 .

GoDaddy에 연결하기 위해 궁극적으로 Global Crossing 대신 MFN Above.net을 사용하는 네트워크를 통해 traceroutes를 수행했으며 /24레벨 아래에 라우팅 트릭의 흔적이 없습니다. 두 네임 서버는 여기에서 동일한 traceroutes를 갖습니다.

이와 같은 것을 본 유일한 시간은 CEF ( Cisco Express Forwarding) 가 깨졌습니다 . 패킷 라우팅을 가속화하는 데 사용되는 하드웨어 수준 캐시입니다. 불행히도 때때로 실제 라우팅 테이블과 동기화되지 않고 잘못된 인터페이스를 통해 패킷을 전달하려고 시도합니다. /32기본 라우팅 테이블 항목이에 대한 경우에도 CEF 항목이 레벨 로 내려갈 수 있습니다 /24. 이런 종류의 문제를 찾는 것은 까다 롭지 만 일단 확인되면 일반적으로 쉽게 해결할 수 있습니다.

나는 GC에게 이메일을 보냈고 그들과 대화를 시도했지만 비 고객을위한 티켓을 만들지는 않을 것이다. 당신의 어떤 경우 입니다 GC의 고객 시도하고이를보고하십시오 ...

10:38 UTC에 업데이트 Jeff가 언급 한 것처럼 문제가 해결되었습니다. 위에서 언급 한 두 서버에 대한 추적 경로는 이제 208.109.115.121다음 홉을 통과합니다 .

serverfault.com 용 DNS 서버 [ns21.domaincontrol.com, ns22.domaincontrol.com. ]에 연결할 수 없습니다. 스웨덴에서 적어도 몇 주 동안 주요 섬에서 온 ~ 20 시간 동안 [ telia , tele2 , bredband2 ].

동시에 stackoverflow.com 및 superuser.com에 대한 '이웃'DNS 서버 [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가 이름 서버를 반응 및 변경했는지 확인-예 : recort 유형을 사용하여 http://www.squish.net/dnscheck/ 에서 lookup serverfault.com : ANY
2. 제공된 네임 서버가 핑에 응답하는지 확인하십시오. [네임 서버는 잘 작동하고 여전히 ICMP를 차단할 수 있기 때문에 매우 과학적이지는 않지만이 경우 ic 리아가 유리 를 통해 다른 서버에 ICMP가 허용되는 것 같습니다] .

편집 : 작업장에서 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       

편집 : 모두 실제로 작동합니다.

내 제안 : 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와 마찬가지로 광산은 ns21과 ns22 모두 208.109.115.201 이후에 종료됩니다.

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.201 대신 208.109.115.121로 이동합니다. 그리고 pQd는 동일한 추적 경로를 갖습니다. 직장에서 나는이 204.245.39.50 라우터 (글로벌 크로싱)를 건너지 않았습니다.

작업장과 비 작업장에서 더 많은 추적 경로가 도움이 될 수 있지만 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 서비스에 위임 할 수 있습니다.

자신의 DNS를 호스팅하지 않은 것에 대해 놀랐습니다. 그렇게하는 것의 장점은 DNS에 접근 할 수 있으면 사이트도 (가능하면)하는 것입니다.

적어도 UPC에서는 권위있는 서버 (ns21.domaincontrol.com)에서 A 레코드를 가져 오려고 할 때이 반응을 얻습니다.

; <<>> 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 응답을 캐싱 할 수 있으므로이를 설명 할 수 있습니다.