DNS 확인 오류 디버깅


11

auth.otc.t-systems.comCloudflare 서버로 도메인의 DNS 확인 오류를 디버깅하고 있지만 멈추었습니다. 이상한 점은 쿼리를 실행하는 컴퓨터에 따라 조회가 성공 / 실패한다는 것이지만 구성이 다른 곳을 알 수는 없습니다.

실패는 항상 다음 메시지와 함께 발생합니다. server can't find auth.otc.t-systems.com: SERVFAIL

1.1.1.1 Cloudflare의 DNS입니다.

내가 지금까지 시도한 것 :

더 디버깅 할 수있는 힌트가 있습니까?


당신은 또한 함께 시도해 봤어 1.0.0.1또는 IPv6를이있는 경우 2606:4700:4700::11112606:4700:4700::1001, 그들도 모두 CloudFlare이다. 또한 blog.cloudflare.com/fixing-reachability-to-1-1-1-1- 글로벌 및 마지막 단락에서 문제를보고하는 방법을 제공합니다.
Patrick Mevzek

답변:


10

발굴을 사용해보십시오. 20 년 전에 그들은 nslookup을 더 이상 사용하지 않으려 고 노력했지만 근육 기억에 확고하게 뿌리 내리고 제거 할 수는 없었지만 발굴은 훨씬 우수합니다. 예를 들어.

dig +trace auth.otc.t-systems.com @1.1.1.1

당신을 위해 해상도를 완전히 추적하고 서로 다른 곳을 볼 수 있습니다.


고마워, 나는 nslookup에 대해 몰랐다. 이제 dig 명령을 시도했지만 이상하게도 내 컴퓨터에서 올바른 IP를 반환합니다. 내 컴퓨터와 로컬 컴퓨터 모두에서 명령의 출력을 여기에 게시했습니다 . gist.github.com/thomas88/600d367387505a13223a5270c89eedda . 발굴이 무엇이든간에 내 브라우저 (Mac의 Chrome)는 nslookup과 더 일치하는 것 같습니다. 주소를 확인할 수 없습니다.
Thomas Obermüller

2
사이의 서로 다른 결과를 기대 할 이유가 없다 dig그리고 nslookup이 쿼리는. 그러나 1.1.1.1애니 캐스트 주소 이므로 쿼리가 제공되는 서버에 따라 결과가 달라질 수 있습니다.
kasperd

Chrome, 웹 클라이언트가 리디렉션 될 수 있습니다. http 헤더가 curl -I <가려고하는 웹 페이지>에 전달에 관한 정보가 있습니까?
Sirch

+trace와 둘 다 사용하는 요점은 무엇입니까 @1.1.1.1? 이 옵션들이 어떻게 작동하는지 이해하고 있습니까?
Barmar

1
그렇습니다, 나는 이것이 어떻게 함께 작동하는지 이해합니다. @ <address>를 사용하는 요점은 클라이언트가 두 위치에서 사용중인 DNS 서버를 지정하는 것입니다. 주어진 예에서 클라우드 플레어는 있지만 다른 클라이언트가 다른 DNS 서버를 사용하는 경우 여기에 지정됩니다. 예를 들어, 내가있는 경우 resolv.conf의 서버 주소는 회사 주소이지만 여전히 1.1.1.1에서 해결할 수 있습니다.
Sirch

3

네트워크 사용자는 스위치 / 라우터 AP의 임의 인터페이스에서 다른 개인 주소를 대체하기 위해 1.1.1.1 이전 버전을 사용했습니다. (저는 수백 개의 무선 AP의 IP 주소가 공개되는 순간이 1.1.1.1 인 현재 위치에 있습니다.)

나는 당신이 Cloufare의 1.1.1.1과 대화 할 수없는 기계에 내 돈을 걸었습니다.이 인터페이스에 대한 (즉시) 경로가 있습니다.

예를 들어 필자의 경우 1.1.1.1에서 내 IP 주소를 알려줍니다.

$ sudo tcpdump -i any -n host 1.1.1.1 and port 67
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on any, link-type LINUX_SLL (Linux cooked), capture size 262144 bytes
13:11:51.037186 IP 1.1.1.1.67 > 10.x.x.x.68: BOOTP/DHCP, Reply, length 296
13:11:51.037250 IP 1.1.1.1.67 > 10.x.x.x.68: BOOTP/DHCP, Reply, length 296

4
RFC 3849 및 RFC 5737을 엄격하게 적용해야하는 이유입니다.
kasperd

1
"너무 낮음"은 무엇이든 결정하기에 까다로운 기초입니다. Cloudflare에는 많은 PoP가 있습니다. 64 bytes from 1.1.1.1: icmp_seq=1 ttl=58 time=1.30 ms실제 RTT입니다.
Håkan Lindqvist

@ HåkanLindqvist 귀하의 가치 외부 연결에 비해 너무 느리게 지연되는 것처럼 보이지만 신뢰할만한 지표는 아닙니다.
Rui F Ribeiro

@RuiFRibeiro Latency는 대기 시간이 긴 링크가 없어도 동일한 도시 연결에 적합합니다. (Traceroute는 ISP 내에서 4 개의 주소를, 도시의 인터넷 교환에서 Cloudflare 주소를 표시 한 다음 1.1.1.1을 표시합니다.)
Håkan Lindqvist

Cloudflare DNS에 도달 할 수있는 것 같습니다. 도메인에게는 실패합니다. auth.otc.t-systems.com및에 대해 nslookup을 실행했습니다 serverfault.com. 다음은 tcpdump의 결과입니다. gist.github.com/thomas88/03acc781f45c9427863b1876c75acb4d
Thomas Obermüller
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.