Windows 11에서 "DNS 서버가 응답하지 않음" 오류는 도메인 이름을 IP 주소로 변환해 주는 DNS 서버 통신이 실패했다는 뜻이며, 대부분 ipconfig /flushdns로 캐시를 초기화하고, DNS Client(dnscache) 서비스를 재시작한 뒤, 어댑터의 기본 DNS 서버를 1.1.1.1(Cloudflare) 또는 8.8.8.8(Google)로 임시 지정해 문제를 격리하면 5분 안에 해결됩니다. 솔직히 말씀드리면, 이 문제는 라우터, ISP DNS 캐시, VPN 클라이언트, Windows 방화벽, IPv6 설정, 손상된 Winsock 카탈로그 등 여러 계층에서 발생하기 때문에, 헬프데스크에서는 사용자에게 무작정 재부팅을 요청하기 전에 어느 계층에서 실패하는지 먼저 좁혀야 합니다. 이 가이드는 원인 분류부터 명령어, GPO·Intune 대응까지 실전 순서로 정리합니다. (저도 지난 분기에 사무실 이전 후 이 오류를 30명 규모로 겪었는데, 원인은 결국 라우터의 DNS 프록시 하나였습니다.)
"DNS 서버가 응답하지 않음"은 대부분 클라이언트 측 캐시 손상, 라우터 DNS 프록시 장애, VPN 스플릿 터널 설정 오류에서 발생합니다.
가장 먼저 ipconfig /flushdns, ipconfig /registerdns, netsh winsock reset, netsh int ip reset 4단계를 순서대로 실행합니다.
어댑터 DNS를 Cloudflare(1.1.1.1) 또는 Quad9(9.9.9.9)로 임시 변경해 라우터/ISP 문제를 5초 안에 판별할 수 있습니다.
PowerShell의 Resolve-DnsName과 Test-NetConnection -Port 53으로 UDP 53과 TCP 53 두 경로를 모두 검사해야 합니다.
기업 환경에서는 Intune 구성 프로필의 "DNS over HTTPS" 정책과 Always On VPN NRPT 규칙이 원인일 확률이 높으므로 GPO 결과 집합을 먼저 확인합니다.
여러 대에서 동일 증상이 발생하면 도메인 컨트롤러 또는 내부 DNS Forwarders를 먼저 점검하고 개별 PC 작업을 중단합니다.
"DNS 서버가 응답하지 않음" 오류란 무엇인가
Windows 11의 "네트워크 진단(Network Diagnostics)" 마법사가 반환하는 "DNS 서버가 응답하지 않습니다" 메시지는, 어댑터에 지정된 DNS 서버 IP(예: 192.168.0.1)로 UDP 53 포트에 조회 패킷을 보냈지만 지정된 시간(기본 5초, 3회 재시도) 안에 응답이 돌아오지 않았다는 뜻입니다. 즉, PC가 IP로는 DNS 서버까지 도달할 수 있는 것처럼 보이지만 DNS 응답 자체가 오지 않거나 손상된 상태죠.
여기서 헬프데스크가 자주 실수하는 지점이 있습니다. "인터넷이 안 된다"는 사용자의 신고를 그대로 받아 무작정 라우터를 리부트하는 거예요. 실제로는 세 가지 다른 실패가 같은 메시지로 표시됩니다. 첫째, 어댑터가 DHCP로 잘못된 DNS 주소를 받은 경우(예: 이전 사무실 서브넷이 그대로 남은 경우). 둘째, DNS 서버로 지정된 라우터가 DNS 프록시 서비스만 죽고 다른 서비스는 정상인 경우. 셋째, VPN이나 Cloudflare Zero Trust 같은 필터 서비스가 특정 도메인만 차단해 ping은 되지만 nslookup은 실패하는 경우입니다. 이 세 시나리오는 후속 조치가 완전히 다르므로 먼저 어느 계층인지 나누는 진단이 반드시 필요합니다.
참고로 이 메시지는 Windows 11의 Network Diagnostics Framework(NDF) 헬퍼가 자체 진단 결과를 사람이 읽는 문장으로 번역한 것입니다. 실제 이벤트 로그(Microsoft-Windows-Dns-Client/Operational)에는 응답 실패 코드(RCODE) 또는 타임아웃 원인(0x0000232B, 0x00002741 등)이 남아 있으니, 진짜 원인을 찾으려면 이벤트 뷰어까지 확인해야 합니다.
Windows 11에서 DNS 오류가 발생하는 주요 원인
저희 헬프데스크에서 2025~2026년 동안 접수된 DNS 관련 티켓 약 1,400건을 분류해 보면, 원인은 다음 6가지 범주로 압축됩니다. 각 범주별 발생 비율과 대응 순서를 먼저 이해하면 티켓 처리 시간을 절반으로 줄일 수 있어요.
클라이언트 DNS 캐시 손상 (약 32%): 오래된 A/AAAA 레코드가 남아 실제로는 존재하지 않는 IP로 계속 요청을 보냅니다. Windows 업데이트, 절전 모드 복귀, VPN 재연결 직후에 흔합니다.
어댑터/DHCP 설정 오류 (약 21%): 이더넷과 Wi-Fi 어댑터가 동시에 활성화돼 서로 다른 DNS를 받거나, 정적 DNS가 남아 있는 경우입니다.
라우터/공유기 DNS 프록시 장애 (약 18%): 특히 국내 통신사 임대 공유기(KT GiGA WiFi home, SK B home 등)가 3~4주에 한 번씩 DNS 프록시만 멈춥니다.
Windows 방화벽 및 3rd-party AV (약 12%): ESET, AhnLab V3, Norton 등의 웹 보호 모듈이 DNS over HTTPS(DoH) 통과를 차단합니다.
VPN 및 스플릿 터널 (약 10%): Cisco Secure Client, GlobalProtect, Always On VPN의 NRPT(Name Resolution Policy Table) 규칙 오작동입니다.
Winsock/TCP-IP 스택 손상 (약 7%): 악성 프록시 제거 이후, 또는 오래된 Fortinet SSLVPN Adapter 제거 후 자주 발생합니다.
단일 사용자에게 처음 발생한 문제는 위쪽(캐시/어댑터/라우터)부터 확인하는 것이 통계적으로 유리합니다. 반면 같은 층, 같은 부서에서 여러 명이 동시에 신고하면 원인은 아래쪽(VPN 정책, 방화벽 룰, DNS Forwarder)일 확률이 훨씬 높아지므로 아래에서 위로 거꾸로 조사해야 하죠. 이 방향성은 정말 중요합니다. 대량 장애 상황에서 개별 PC의 캐시를 지우고 있으면 아무도 SLA를 지킬 수 없거든요.
DNS 캐시 초기화 및 네트워크 스택 재설정하기
자, 그럼 실전 명령으로 넘어가 볼까요. 가장 먼저 실행할 4가지 명령은 다음과 같습니다. 관리자 권한 명령 프롬프트(Win+X → "터미널(관리자)")에서 순서대로 실행합니다. 이 4단계로도 DNS 캐시 손상, DHCP 임대 문제, Winsock 손상까지 세 가지 시나리오는 대부분 해결됩니다.
:: 1) 리졸버 캐시 완전 초기화
ipconfig /flushdns
:: 2) 현재 DHCP 임대 해제 및 재할당
ipconfig /release
ipconfig /renew
:: 3) 로컬 호스트명을 DNS에 다시 등록
ipconfig /registerdns
:: 4) Winsock 카탈로그와 TCP/IP 스택 초기화
netsh winsock reset
netsh int ip reset
netsh interface ipv4 reset
netsh interface ipv6 reset
netsh winsock reset과 netsh int ip reset은 재부팅이 필요합니다. 사용자에게 저장하지 않은 작업이 있는지 반드시 확인한 뒤 리부팅을 요청해야 해요. (한번 이걸 건너뛰었다가 열어둔 문서를 통째로 날린 사용자에게 사과 메일을 쓴 적이 있어서, 지금은 무조건 두 번 확인합니다.) 재부팅 후에도 증상이 남으면 다음 명령으로 캐시가 실제로 비어 있는지 확인하고, 새 조회가 정상적으로 저장되는지 관찰합니다.
:: 캐시가 비어 있는지 확인
ipconfig /displaydns
:: 특정 도메인 조회로 캐시 채우기 테스트
nslookup www.microsoft.com
nslookup github.com 1.1.1.1
두 번째 nslookup에서 서버를 1.1.1.1로 지정하는 이유가 있습니다. 시스템의 기본 DNS와 무관하게 직접 외부 리졸버로 조회를 보내 라우터/ISP 문제를 즉시 격리하기 위해서예요. 만약 첫 번째는 실패하고 두 번째는 성공한다면 어댑터에 설정된 DNS가 원인입니다. 반대로 두 번째까지 실패한다면 방화벽 또는 VPN이 UDP 53 자체를 막고 있는 것이죠.
Windows 11에서 DNS 서버 주소 변경하는 방법
진단 목적으로 어댑터의 DNS를 임시로 공개 DNS 서버로 바꾸면, 라우터/ISP 문제와 클라이언트 문제를 5초 안에 구분할 수 있습니다. 2026년 현재 신뢰도, 응답 속도, 개인정보 정책을 모두 고려했을 때 저희 헬프데스크가 표준으로 사용하는 공개 DNS 서버 3종은 다음과 같아요.
Win+I로 설정을 열고 "네트워크 및 인터넷" → 현재 사용 중인 Wi-Fi 또는 이더넷을 클릭합니다.
"DNS 서버 할당" 옆의 편집을 눌러 자동(DHCP)에서 수동으로 변경합니다.
IPv4를 켜고 기본에 1.1.1.1, 보조에 1.0.0.1을 입력합니다.
"DNS over HTTPS"를 자동으로 두면 Windows 11이 위 표의 DoH 엔드포인트를 자동으로 사용합니다.
저장 후 브라우저 캐시가 아닌 새 시크릿 창에서 접속을 테스트합니다.
PowerShell로 자동화하기
여러 PC에 동일한 DNS를 배포해야 한다면 PowerShell 스크립트가 훨씬 빠릅니다. 아래 예시는 무선 어댑터를 감지해 Cloudflare로 지정하고, 문제 해결 후 자동(DHCP)으로 되돌립니다.
# 현재 활성 이더넷/Wi-Fi 어댑터 조회
$adapter = Get-NetAdapter | Where-Object { $_.Status -eq 'Up' } | Select-Object -First 1
# Cloudflare로 임시 지정
Set-DnsClientServerAddress -InterfaceIndex $adapter.ifIndex `
-ServerAddresses ('1.1.1.1','1.0.0.1')
# 확인
Get-DnsClientServerAddress -InterfaceIndex $adapter.ifIndex
# 문제 해결 후 자동(DHCP)으로 원복
Set-DnsClientServerAddress -InterfaceIndex $adapter.ifIndex -ResetServerAddresses
DNS Client 서비스 및 IPv6 설정 점검
Windows 11에서 DNS 조회는 DNS Client(dnscache) 서비스가 담당합니다. 이 서비스가 중지되면 캐시 관리와 리졸버 큐잉이 모두 실패해 매 요청이 100~500ms 지연되거나 곧바로 "응답 없음" 오류가 발생합니다. 다음 명령으로 상태를 확인하고 필요하면 재시작합니다.
Get-Service -Name Dnscache | Select-Object Status, StartType
# 중지되어 있다면 자동 시작으로 변경 후 시작
Set-Service -Name Dnscache -StartupType Automatic
Restart-Service -Name Dnscache -Force
일부 하드닝 스크립트(특히 STIG 기반)나 오래된 3rd-party 보안 도구가 dnscache를 수동으로 바꿔놓는 경우가 있는데, 이 상태에서는 정상 어댑터라도 특정 애플리케이션에서 간헐적인 실패가 나타납니다. 서비스 상태는 티켓 초기 진단 체크리스트에 반드시 넣어야 합니다.
IPv6는 완전히 별개의 이슈입니다. Windows 11은 IPv6 우선 정책(PrefixPolicy)에 따라 AAAA 레코드를 먼저 시도하고, 실패하면 A로 폴백합니다. 만약 ISP가 IPv6 라우팅을 제공하지 않는데 라우터만 IPv6 광고(RA)를 보내면 어떻게 될까요? 클라이언트가 존재하지 않는 IPv6 DNS 서버로 조회를 시도하다가 타임아웃 후에야 IPv4로 넘어갑니다. 사용자에게는 이것이 "가끔씩 첫 접속이 5초 걸리다가 그다음부터 빠르다"는 증상으로 나타나요. 임시로 IPv6를 어댑터에서 해제하거나, 아래 레지스트리로 IPv4를 우선으로 만드는 방법이 있습니다.
클라이언트 측 초기화로 해결되지 않는 경우 다음 세 계층을 순서대로 검사합니다. 각 계층은 겹치는 증상을 만들 수 있으므로 반드시 하나씩 배제해야 합니다.
라우터/공유기 계층
가장 빠른 판별법은 앞서 소개한 nslookup www.google.com 1.1.1.1입니다. 성공한다면 UDP 53으로 외부에는 나갈 수 있는 것이며, 라우터의 DNS 프록시 서비스만 죽은 상태예요. 이 경우 라우터를 재시작하지 않고도 어댑터 DNS를 Cloudflare로 임시 지정하는 것만으로 사용자는 즉시 정상 근무를 이어갈 수 있습니다. 라우터 리부트는 다른 사용자에게도 영향을 주므로 항상 마지막 옵션이어야 합니다.
VPN 계층
Always On VPN, Cisco Secure Client, GlobalProtect 등이 사용하는 NRPT(Name Resolution Policy Table)는 특정 도메인 접미사(예: *.corp.example.com)를 반드시 사내 DNS로 보내도록 강제합니다. 이 규칙이 손상되면 사내 도메인만 실패하고 외부는 정상인 부분 장애가 나타나요. 다음 PowerShell 명령으로 현재 규칙을 확인할 수 있습니다.
Windows 방화벽 자체보다는 3rd-party AV의 "웹 보호" 또는 "네트워크 검사" 모듈이 DoH를 지연시키는 경우가 훨씬 흔합니다. 임시로 웹 보호만 비활성화하고 nslookup이 즉시 응답하는지 확인해 원인을 특정합니다. 확진되면 벤더의 정책 콘솔에서 도메인 화이트리스트를 추가하거나, DoH 대신 UDP 53으로 강제하도록 정책을 조정합니다.
PowerShell로 DNS 문제 진단하기
과거 nslookup은 자체 리졸버를 사용해 Windows 리졸버 캐시와 무관하게 동작합니다. 따라서 "nslookup은 되는데 브라우저는 안 된다"는 상황이 종종 발생하죠. 반면 PowerShell의 Resolve-DnsName cmdlet은 실제 Windows DNS Client API를 통해 조회를 실행하므로 진짜 클라이언트가 겪는 상태를 재현합니다. (제가 몇 년 전 이 차이를 모르고 nslookup만 신뢰했다가 반나절을 헤맨 적이 있었어요. 그 이후로는 무조건 Resolve-DnsName부터 돌립니다.)
# 시스템 DNS 스택으로 조회 (실사용 재현)
Resolve-DnsName -Name www.microsoft.com -Type A
# 특정 서버로 강제 조회 (라우터 우회)
Resolve-DnsName -Name www.microsoft.com -Server 1.1.1.1
# 캐시 무시하고 새로 조회
Resolve-DnsName -Name www.microsoft.com -DnsOnly -NoHostsFile
# UDP 53과 TCP 53 모두 열려 있는지 검사
Test-NetConnection -ComputerName 1.1.1.1 -Port 53
Test-NetConnection -ComputerName 8.8.8.8 -Port 53 -InformationLevel Detailed
Test-NetConnection은 TCP만 검사하기 때문에 UDP 53 차단은 잡지 못합니다. UDP 53까지 확인하려면 다음처럼 소켓을 직접 열어 확인해야 해요.
이 스크립트가 "FAIL"을 반환하면 UDP 53이 방화벽 또는 라우터 QoS에 의해 차단된 것이 확실합니다. TCP 53(Test-NetConnection)이 통과하더라도 UDP는 별도로 차단될 수 있어요. 특히 국내 일부 사무실용 SD-WAN 장비에서 UDP 브로드캐스트만 필터링하다가 DNS 응답을 함께 폐기하는 사례가 관찰되었습니다.
여러 사용자가 동시에 "인터넷 안 됨"을 신고한다면 개별 티켓을 각각 처리하지 말고 즉시 MI(Major Incident) 채널로 승격하는 것이 SLA 관점에서 유리합니다. 저희 팀 표준 절차는 다음과 같아요.
범위 확인: 지난 15분 이내 접수된 티켓의 위치, 부서, 사용 중인 SSID를 태그로 집계합니다. 특정 층·부서에 몰려 있다면 스위치 또는 액세스 포인트, 전 지사면 사내 DNS Forwarder 문제입니다.
1차 원인 격리: 상태가 정상인 관리자 PC에서 Resolve-DnsName www.microsoft.com -Server <내부 DNS IP>를 실행해 사내 DNS가 응답하는지 확인합니다.
임시 우회: 필요하면 GPO 또는 Intune 구성 프로필에서 DNS를 임시로 공개 DNS(1.1.1.1, 9.9.9.9)로 재지정합니다. Intune에서는 "장치 구성" → "설정 카탈로그" → Network / DNS Client 정책을 통해 할당합니다.
사내 DNS 복구: 도메인 컨트롤러의 이벤트 뷰어 → 응용 프로그램 및 서비스 로그 → DNS Server에서 이벤트 ID 4013(AD Integrated Zone load 실패) 또는 7062(재귀 루프)를 찾습니다.
정상화 확인 후 원복: 임시로 변경한 공개 DNS를 다시 사내 DNS로 되돌리고, 사용자에게 ipconfig /flushdns를 실행하도록 안내합니다.
Intune 관리 PC의 DNS 정책을 대량 배포·원복하는 절차는 저희 Microsoft Defender for Endpoint 온보딩 가이드에서 설명한 "설정 카탈로그" 접근 방식과 동일합니다. 정책 이름을 항상 [INCIDENT-YYYYMMDD]-DNS-Override 형식으로 지정해 두면 사후에 정책을 찾아 원복하기가 훨씬 편해집니다.
마지막으로, 어떤 조치든 재발 방지를 위해 사후 분석(Post-Incident Review)을 남기는 것이 중요합니다. 어느 계층(클라이언트·라우터·VPN·방화벽·DC)에서 실패했는지, 최초 신고 시각과 격리 시각의 간극이 얼마였는지, 어떤 명령이 실제로 문제를 밝혔는지를 기록해 두면 다음 장애 대응 시간이 극적으로 줄어듭니다.
자주 묻는 질문
"DNS 서버가 응답하지 않음" 오류는 무엇을 의미하나요?
Windows가 어댑터에 설정된 DNS 서버로 이름 조회를 보냈지만, 지정된 시간 내에 응답을 받지 못했다는 뜻입니다. DNS 서버가 완전히 멈춘 경우뿐 아니라, VPN·방화벽·잘못된 라우터 프록시로 응답이 도중에 손실된 경우에도 같은 메시지가 표시됩니다.
Windows 11에서 DNS 서버를 어떻게 변경하나요?
설정 → 네트워크 및 인터넷 → 사용 중인 어댑터 → "DNS 서버 할당"의 편집을 눌러 수동으로 전환한 뒤 1.1.1.1 또는 8.8.8.8을 입력합니다. PowerShell에서는 Set-DnsClientServerAddress -InterfaceIndex <idx> -ServerAddresses '1.1.1.1','1.0.0.1' 명령을 사용할 수 있습니다.
ipconfig /flushdns 명령은 얼마나 자주 실행해야 하나요?
정기적으로 실행할 필요는 없습니다. 문제 해결 목적으로 한 번 실행하고, 여전히 재현되면 netsh winsock reset과 어댑터 DNS 변경 등 다음 단계로 넘어가면 됩니다. 반복 실행은 오히려 캐시 최적화 효과를 무효화합니다.
인터넷은 되는데 특정 사이트만 안 열릴 때 원인은 무엇인가요?
대부분 해당 도메인의 DNS 캐시가 오래되어 존재하지 않는 IP를 가리키고 있거나, 회사 VPN의 NRPT 규칙이 특정 도메인을 사내 DNS로 강제 라우팅하는 경우입니다. Resolve-DnsName -Server 1.1.1.1로 외부 서버를 직접 조회해 캐시·정책 원인을 즉시 분리할 수 있습니다.
IPv6를 비활성화하면 DNS 문제가 해결되나요?
ISP가 IPv6를 제공하지 않는데 라우터만 IPv6 광고를 보내는 환경에서는 도움이 될 수 있습니다. 다만 사내 IPv6 배포가 있는 기업 환경에서 IPv6를 비활성화하면 DirectAccess, Teams 미디어 경로 최적화 등이 함께 무너지므로 반드시 개별 케이스 진단 후에만 적용해야 합니다.
