이 윈도우 명령어들을 배우고 나서야 DNS 문제에 대해 추측하는 것을 마침내 멈췄다

오랫동안, DNS 문제는 사이트가 로드되지 않거나 내 휴대폰에서는 로드되지만 PC에서는 로드되지 않는 것을 의미했고, 나는 인터넷을 고치기 위해 수많은 Windows 명령어를 하나씩 실행하곤 했습니다. 나는 또한 라우터를 재시작하거나, 다른 DNS 서버로 바꾸거나, Windows를 재부팅하고 바라곤 했습니다. 가끔 그 중 하나가 효과가 있었지만, 어떤 것이 왜 효과가 있었는지 말할 수 없었습니다. 왜냐하면 나는 실제로 문제를 살펴본 적이 없었기 때문입니다.

그러나 DNS 문제를 처리하는 더 나은 방법은 DNS가 무엇을 하고 있는지 보여주는 몇 가지 Windows 명령어를 배우는 것입니다. 캐시가 오래되었는지, DNS 서버에 접근할 수 없는지, 아니면 경로 자체가 끊겼는지를 추측하는 대신, 실제로 내부에서 무슨 일이 일어나고 있는지 확인할 수 있습니다.

ipconfig /displaydns

Windows가 현재 기억하고 있는 모든 주소를 보여줍니다

인터넷이 끊겼을 때 내가 처음 실행하는 명령은 ipconfig /displaydns입니다. 윈도우는 최근에 조회한 사이트 이름과 해당 사이트가 해석된 IP 주소를 포함한 로컬 DNS 캐시를 유지합니다. 이는 사이트를 열 때마다 PC가 동일한 질문을 DNS 서버에 묻지 않도록 합니다. 문제는 캐시된 답변이 오래될 수 있다는 점인데, 오래된 답변은 특정 사이트가 당신의 컴퓨터에서만 로드되지 않고 다른 곳에서는 정상적으로 로드되는 가장 흔한 이유 중 하나입니다.

ipconfig /displaydns를 Windows 터미널이나 명령 프롬프트에서 실행하면 해당 캐시의 모든 레코드를 출력합니다. 각 항목은 레코드 이름, 레코드 유형, 레코드가 만료될 때까지 남은 시간을 나타내는 TTL(Time To Live) 값, 그리고 Windows가 기록한 실제 IP 주소를 보여줍니다. 마지막 부분이 제가 관심 있는 내용입니다. 사이트가 제대로 작동하지 않을 경우, 제 PC가 실제로 통신해야 한다고 생각하는 주소를 정확히 확인할 수 있습니다.

여기서 추측은 멈춥니다. 캐시된 IP가 잘못된 것처럼 보이면, 다른 것을 건드리기 전에 캐시에 문제가 있다는 것을 알 수 있습니다. PowerShell은 Get-DnsClientCache cmdlet을 통해 이 과정을 더 발전시켜, 이름이나 레코드 유형별로 캐시를 필터링할 수 있게 합니다.

nslookup

DNS 서버에 직접 요청하므로 어떤 것이 해결되는지 추측하지 않아도 됩니다

ipconfig /displaydns는 내 PC가 이미 알고 있는 것을 알려줍니다. nslookup은 지금 실제로 맞는 것이 무엇인지 알려줍니다. 이것은 DNS 서버에 직접 쿼리하고 호스트 이름에 연결된 IP 주소를 반환하는 명령줄 도구로, 내가 새로 받은 답변을 캐시에 있는 오래된 답변과 비교할 수 있게 합니다.

DNS가 문제라는 가장 명확한 신호는 사이트가 로드되지 않지만, 직접 IP 주소로 핑을 보내면 정상적으로 작동할 때입니다. 이런 분리는 연결은 정상적이지만, 이름을 주소로 변환하는 과정에 문제가 있다는 것을 의미합니다. nslookup example.com을 실행하면 이를 확인할 수 있습니다. 명령어가 IP 주소를 반환하면 DNS가 제 역할을 하고 있는 것입니다. '존재하지 않는 도메인'을 반환하거나 단순히 시간 초과가 발생하면, 조회 자체가 제대로 작동하지 않는 것입니다.

출력에는 어떤 DNS 서버가 응답했는지도 표시됩니다. 일반적인 결과는 "비권한(non-authoritative)"으로 표시되며, 이는 답변이 도메인의 공식 기록이 아닌 서버의 캐시에서 온 것임을 의미하며, 이는 예상되는 일입니다. 더 깊이 알아볼 수도 있습니다. -type=mx를 추가하면 메일 기록을 가져올 수 있어 이메일이 문제일 때 유용하며, -type=ns는 도메인의 이름 서버를 나열합니다. 일상적인 문제 해결에서는 일반적인 nslookup만으로도 해결책이 레졸버 문제인지 여부를 확인하기에 충분합니다.

트레이스루트

연결이 정확히 어디에서 끊기는지 보여줍니다

nslookup이 호스트명이 IP로 해결되는 것을 확인하면, 다음 질문은 실제로 패킷이 그 IP에 도달할 수 있는지입니다. 그것이 tracert의 역할입니다. tracert는 DNS 조회 자체를 추적하지 않고, 데이터가 해결된 주소로 가는 경로를 표시하며 그 경로가 어디에서 느려지거나 멈추는지를 보여줍니다.

DNS 문제 해결을 위해 Tracert가 제공하는 가장 유용한 기능은 DNS가 원인인지 아닌지를 판별하는 것입니다. tracert example.com을 실행하고 즉시 "대상 시스템 이름을 확인할 수 없습니다"라는 메시지가 나타나면, Windows가 해당 호스트 이름에 대한 IP를 전혀 얻지 못한 것입니다. 문제는 분명히 DNS 또는 hosts 파일에 있으며 라우팅 문제가 아닙니다. 그러나 추적이 첫 번째 홉을 넘어선다면, 호스트 이름이 이미 성공적으로 확인된 것이므로 DNS가 작동했음을 의미하며, 문제는 경로의 그 이후에 존재합니다.

여기에는 깔끔한 방법이 있습니다. 호스트 이름에 대해 tracert를 실행한 다음, nslookup이 제공한 실제 IP에 대해 다시 실행해 보세요. IP 버전이 완료되고 호스트 이름 버전이 시작조차 되지 않으면, 일반 연결이 정상임을 확인하면서 문제를 DNS 해상도로 국한시킨 것입니다. 또한 tracert를 직접 공용 리졸버, 예를 들어 tracert 8.8.8.8에 지정할 수도 있습니다. DNS 서버에 도달하는 것이 느리거나 타임아웃이 많으면, 나머지 연결이 아무리 정상적이어도 조회 속도가 느리게 느껴질 수 있으며, 이는 때때로 라우터 설정이 조용히 속도에 영향을 주고 있는 신호일 수 있습니다.

ipconfig /flushdns

아무 곳도 보내지 않는 오래된 캐시를 삭제합니다

이 시점에서 나는 보통 무엇이 잘못되었는지 알고 있으며, 대부분의 경우 내 PC를 오래된 주소로 가리키는 오래된 캐시 항목입니다. 해결 방법은 ipconfig /flushdns입니다. 이 명령은 전체 로컬 DNS 캐시를 지워서 다음에 사이트를 방문할 때 Windows가 새 레코드를 가져오도록 강제합니다.

이것은 웹사이트가 새로운 서버로 이전한 후에 가장 중요합니다. 사이트는 이제 새로운 IP에 있지만, 사용자의 PC는 여전히 이전 IP를 기억하고 있어 더 이상 응답하지 않는 주소로 사용자를 안내합니다. 캐시를 비우면 그 오래된 항목이 삭제됩니다. 동일한 원리는 DNS 서버를 변경한 후나, 악성코드가 조회를 리디렉션하여 캐시가 손상되었다고 의심될 때도 적용됩니다. 이 명령은 안전하며, 일상적인 네트워크 유지 관리와 비교할 수 있고, 성능이나 설정에 해를 끼치지 않습니다.

알아두면 좋은 한 가지는 플러시(flushing)만으로 캐시를 항상 완전히 비울 수 있는 것은 아니라는 점입니다. 로컬 호스트 파일에 있는 항목은 지워지지 않으며, 백그라운드 앱이 즉시 새로운 조회를 트리거하여 몇 초 안에 다시 캐시를 채울 수 있습니다. 따라서 플러시 직후에 ipconfig /displaydns를 실행했는데도 항목이 보인다면 이것은 정상입니다. 플러시로 문제가 해결되면 문제는 오래된 레코드였던 것입니다. 그렇지 않다면 캐시 문제를 배제한 것이므로 다음 단계를 진행할 수 있습니다. 이후 더 신뢰할 수 있는 리졸버로 전환하는 것도 고려할 가치가 있으며, DNS를 변경하는 것은 단순히 PC를 위한 것이 아닙니다.

netsh winsock 초기화

다른 방법이 통하지 않을 때 시도할 수 있는 해결책

캐시가 깨끗하고, 호스트명이 해결되며, 경로도 정상인데 네트워킹이 여전히 작동하지 않는다면 문제는 DNS보다 더 깊을 수 있습니다. 이럴 때 제가 사용하는 방법은 netsh winsock reset입니다.

Winsock은 브라우저와 같은 애플리케이션과 네트워크 자체 사이에 위치한 윈도우 네트워킹 구성 요소입니다. 그 구성은 Winsock 카탈로그라고 불리는 곳에 저장되며, 그 카탈로그는 악성 소프트웨어, 잘못 설치된 네트워크 소프트웨어, 또는 제거한 장치의 남은 항목으로 인해 손상될 수 있습니다. 그렇게 되면 이상한 오류가 발생합니다: 올바른 설정에도 불구하고 DNS 조회가 실패하거나, 브라우저가 명확한 이유 없이 제한된 연결 상태를 보고하는 경우 등이 있습니다.

관리자 권한 명령 프롬프트에서 netsh winsock reset를 실행하면 해당 카탈로그가 기본 상태로 재설정되고, 작업을 마치려면 재부팅하면 됩니다. 실행하기 전에 netsh winsock show catalog > winsock-before.txt로 스냅샷을 저장하여 변경된 내용을 기록해둡니다. 문제가 Winsock보다는 IP 구성과 관련이 있다면, 관련된 netsh int ip reset 명령이 TCP/IP 설정을 같은 방식으로 재구성합니다. 어느 것도 보장된 해결책은 아니지만, 지원을 요청하기 전에 마지막 수단으로 재설정을 하면 캐시를 아무리 지워도 해결되지 않는 손상된 데이터를 정리할 수 있습니다.

DNS 문제를 어디서 찾아야 하는지 알면 해결하는 것은 쉽다

나는 여전히 DNS 문제를 겪고 있다. 왜냐하면 누구나 겪기 때문이다. 하지만 내 연결에 모든 기술을 다 쏟아붓는 대신, 나는 두세 개의 명령어를 실행하고, 그들이 말하는 것을 읽고, 올바른 해결책을 적용한다. 원인을 알게 되면, 해결책은 쉬운 부분이다.