난 변하지 않았어아무것serverfault.com의 DNS 항목과 관련, 하지만 오늘 일부 사용자가 다음과 같이 보고했습니다.serverfault.com DNS가 이를 해결하지 못합니다..
나는그냥 쿼리그리고 저는 이것을 확인할 수 있습니다. 제가 식별할 수 있는 특별한 이유 없이 소수의 국가에서 serverfault.com dns가 해결되지 않는 것 같습니다. (또한 다음을 통해 확인되었습니다.내 DNS는 무엇입니까이는 비슷한 방식으로 전 세계적으로 핑을 수행하므로 두 가지 소스에서 문제로 확인되었습니다.)
serverfault.com의 DNS를 건드리지 않은 경우 왜 이런 일이 발생합니까?
우리 등록 기관은 (개그) GoDaddy이고 저는 대부분 문제 없이 기본 DNS 설정을 사용합니다. 내가 뭔가 잘못하고 있는 걸까요? DNS의 신들이 나를 버렸나요?
이 문제를 해결하기 위해 제가 할 수 있는 일이 있나요? DNS를 따라잡거나 DNS가 전 세계적으로 올바르게 전파되도록 강제할 수 있는 방법이 있습니까?
업데이트: 월요일 오전 3시 30분(PST) 현재 모든 것이 올바른 것으로 보입니다. JustPing 보고서 사이트는 모든 위치에서 접속할 수 있습니다. 많은 유익한 답변 감사드립니다. 많이 배웠고 다음번에 이런 일이 생기면 참고하도록 하겠습니다..
답변1
이것은 직접적인 DNS 문제가 아니라 인터넷의 일부 부분과 serverfault.com의 DNS 서버 간의 네트워크 라우팅 문제입니다. 네임서버에 연결할 수 없으므로 도메인 확인이 중지됩니다.
내가 알 수 있는 한 라우팅 문제는 IP 주소가 있는 (Global Crossing?) 라우터에 있습니다 204.245.39.50.
처럼표시됨~에 의해@반지름, ns52로의 패킷(에서 사용됨)stackoverflow.com) 여기에서 208.109.115.121여기까지의 전달이 올바르게 작동합니다. 그러나 ns22로의 패킷은 대신 208.109.115.201.
이 두 주소는 모두 동일 /24하고 해당 BGP 공지도 /24이 주소 에 대한 것입니다.일어나지 말아야 할 일.
GoDaddy에 도달하기 위해 Global Crossing 대신 MFN Above.net을 사용하는 내 네트워크를 통해 추적 경로를 수행했으며 수준 아래에는 라우팅 속임수의 흔적이 없습니다. /24두 이름 서버 모두 여기에서 동일한 추적 경로를 갖습니다.
내가 이런 것을 본 유일한 시간은 깨졌어시스코 익스프레스 포워딩(CEF). 이는 패킷 라우팅을 가속화하는 데 사용되는 하드웨어 수준 캐시입니다. 불행하게도 때때로 실제 라우팅 테이블과 동기화되지 않고 잘못된 인터페이스를 통해 패킷을 전달하려고 시도합니다. CEF 항목은 /32기본 라우팅 테이블 항목이 /24. 이러한 종류의 문제를 찾는 것은 까다롭지만 일단 확인되면 일반적으로 쉽게 해결할 수 있습니다.
GC에 이메일을 보내고 대화를 시도했지만 고객이 아닌 사람을 위한 티켓을 생성하지 않습니다. 혹시 여러분 중에~이다GC 고객이시라면 이 사실을 신고해 주십시오...
10:38 UTC 업데이트 Jeff가 지적했듯이 이제 문제는 해결되었습니다. 위에서 언급한 두 서버에 대한 추적 경로는 이제 208.109.115.121다음 홉을 통해 이동합니다.
답변2
serverfault.com에 대한 DNS 서버 [ns21.domaincontrol.com, ns22.domaincontrol.com. ]에 연결할 수 없습니다. 지난 20시간 동안 적어도 스웨덴의 주요 isps 몇 마리로부터 [텔리아,텔레2,브레드밴드2].
동시에 stackoverflow.com 및 superuser.com [ ns51.domaincontrol.com, ns52.domaincontrol.com ]의 '이웃' DNS 서버에 연결할 수 있습니다.
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/레코드 유형 사용: ANY
- 제공된 이름 서버가 ping에 응답하는지 확인하십시오. [이름 서버는 잘 작동하고 여전히 icmp를 차단할 수 있기 때문에 그리 과학적이지는 않지만, 이 경우에는 telia를 통해 다른 서버에 icmp가 허용되는 것 같습니다]거울.
편집하다: 작업장에서 경로 추적
폴란드
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 설정이 매우 열악하여 다음과 같은 중요한 사이트에는 충분하지 않습니다.
- 네임서버가 2개뿐이다
- 같은 바구니에 있는 모든 계란(둘 다 같은 AS에 있음)
우리는 방금 결과를 보았습니다. 라우팅 결함(인터넷에서 매우 흔한 일)은 일부 사용자(국가가 아닌 운영자에 따라 다름)에서 serverfault.com을 사라지게 만드는 데 충분합니다.
다른 AS에 있는 네임서버를 더 추가하는 것이 좋습니다. 이를 통해 실패 복원력이 가능해집니다. 민간 회사에 임대하거나 serverfault 사용자에게 보조 DNS 호스팅을 제공하도록 요청할 수 있습니다(사용자가 1000명 이상의 담당자를 보유한 경우에만 가능함 :-)
답변4
실패한 위치에서 자세한 해결 추적을 확인하는 것이 편리할 것입니다. 해결 경로의 어떤 계층에서 실패하는지 확인하세요. 나는 당신이 사용하고 있는 서비스에 대해 잘 모르지만 아마도 어딘가에 있는 옵션일 것입니다.
실패하면 루트 또는 TLD의 실패가 더 많은 도메인에 영향을 미치기 때문에 문제가 트리의 "하위"에 있을 가능성이 높습니다(원하는 바입니다). 복원력을 높이려면 domaincontrol의 네트워크에 문제가 있는 경우 두 번째 DNS 서비스에 위임하여 더 나은 해결 중복성을 보장할 수 있습니다.