2026 기업 DNS 장애 원인 찾고 해결하는 법 단계별 가이드

• 목록
• 답변
• 글쓰기
• 옵션
  • 수정
  • 삭제

인터넷 연결 표시는 정상인데 업무 사이트만 열리지 않거나, 사내 시스템 접속이 유난히 늦고, 같은 주소가 직원마다 다르게 연결되나요? 이런 현상은 회선이나 방화벽보다 DNS 장애에서 시작되는 경우가 많습니다. DNS는 사람이 입력한 도메인을 서버의 IP 주소로 연결하는 핵심 네트워크 서비스이므로, 작은 설정 오류도 회사 전체의 업무 중단으로 이어질 수 있습니다.

특히 2026년 기업 IT 환경은 클라우드 업무 도구, SaaS, 원격근무, 하이브리드 인프라가 함께 사용됩니다. 따라서 DNS 문제를 단순히 ‘인터넷이 느리다’고 판단해 공유기부터 재부팅하면 원인을 놓치기 쉽습니다. 아래 순서대로 증상을 분리하면 담당자가 아니어도 장애 범위를 빠르게 좁힐 수 있습니다.

DNS 장애인지 먼저 구분하는 10분 진단법

IP 접속과 도메인 접속을 비교합니다

DNS 장애의 대표적인 특징은 IP 통신은 되지만 도메인 이름으로 접속할 수 없다는 것입니다. 먼저 다른 웹사이트도 열리지 않는지 확인하고, 사내 메신저나 이미 연결된 원격 세션은 유지되는지 살펴보세요. 모든 통신이 끊겼다면 DNS보다 회선, 스위치, 게이트웨이 또는 방화벽 장애를 먼저 의심해야 합니다.

Windows에서는 명령 프롬프트를 열어 ipconfig /all로 현재 DNS 서버 주소를 확인한 뒤, nslookup 회사도메인을 실행합니다. macOS나 Linux에서는 dig 회사도메인 또는 nslookup을 활용할 수 있습니다. 응답 시간이 지나치게 길거나 ‘server failed’, ‘timed out’, ‘NXDOMAIN’이 표시된다면 결과별로 원인을 나눠야 합니다. 네트워크의 기본 개념이 낯설다면 네트워크 용어 정의를 함께 참고하면 장비와 서비스의 관계를 이해하기 쉽습니다.

한 명의 문제인지 전사 장애인지 확인합니다

문제가 발생한 PC 한 대만 검사하면 잘못된 결론을 내릴 수 있습니다. 같은 부서의 유선 PC, 무선 노트북, 업무용 스마트폰에서 동일한 도메인을 각각 조회해 보세요. 특정 PC만 실패하면 로컬 캐시나 고정 DNS 설정이 원인일 가능성이 높고, 특정 층이나 VLAN만 실패하면 DHCP 옵션과 네트워크 구간을 점검해야 합니다.

• 한 대만 실패: 로컬 DNS 캐시, VPN 클라이언트, 보안 프로그램, hosts 파일을 확인합니다.
• 특정 부서만 실패: 해당 VLAN의 DHCP 옵션 006과 접근제어 정책을 확인합니다.
• 전 직원이 실패: 사내 DNS 서버, 포워더, 방화벽의 UDP·TCP 53번 정책을 점검합니다.
• 외부 도메인만 실패: 상위 DNS 포워더나 인터넷 회선 경로를 확인합니다.

장애 발생 시각, 실패한 도메인, 사용한 DNS 서버, 오류 메시지를 먼저 기록하세요. 재부팅으로 증상이 사라져도 이 네 가지가 있어야 재발 원인을 추적할 수 있습니다.

가장 흔한 DNS 고장 원인과 오류 메시지 해석

타임아웃과 SERVFAIL은 의미가 다릅니다

DNS 타임아웃은 클라이언트가 서버의 응답을 받지 못했다는 뜻입니다. DNS 서버가 중단됐거나 네트워크 경로가 끊겼을 수 있고, 방화벽이 53번 포트를 차단했을 수도 있습니다. UDP 질의는 통과하지만 큰 응답이나 영역 전송에 필요한 TCP 53번이 막혀 일부 도메인만 실패하는 사례도 있으므로 두 프로토콜을 함께 확인해야 합니다.

SERVFAIL은 서버에 도달했지만 정상적인 답을 만들지 못했다는 의미입니다. 상위 DNS 연결 실패, DNSSEC 검증 오류, 잘못된 위임, 서버 자원 부족 등이 대표 원인입니다. 반면 NXDOMAIN은 해당 이름이 존재하지 않는다는 응답입니다. 철자 오류뿐 아니라 아직 전파되지 않은 레코드, 잘못된 검색 접미사, 음수 캐시 때문에 정상 도메인도 일시적으로 존재하지 않는 것처럼 보일 수 있습니다.

사내·외부 응답이 다르면 Split DNS를 봅니다

기업에서는 같은 도메인에 대해 사내에서는 내부 IP를, 외부에서는 공인 IP를 반환하는 Split DNS 구성을 자주 사용합니다. 내부 영역에 신규 레코드를 추가하지 않았거나 VPN 사용자가 외부 DNS를 참조하면 사무실과 재택 환경의 결과가 달라집니다. 이때 공용 DNS로 무조건 변경하면 내부 ERP나 파일 서버를 찾지 못하는 부작용이 생길 수 있습니다.

1. 요청 서버 확인: nslookup 또는 dig 결과에서 실제 응답한 DNS 서버 주소를 봅니다.
2. 응답 코드 확인: timeout, SERVFAIL, NXDOMAIN을 구분해 기록합니다.
3. 반환 IP 비교: 사내망, 모바일망, VPN 환경에서 얻은 IP가 설계와 일치하는지 비교합니다.
4. 권한 서버 확인: 외부 도메인이라면 등록기관의 NS 위임과 권한 DNS 상태를 확인합니다.
5. 변경 이력 확인: 장애 직전 레코드, 방화벽, DHCP, VPN 정책 변경이 있었는지 찾습니다.

DNS는 전체 네트워크 구조 안에서 동작하므로 서버 설정만 보지 말고 클라이언트부터 권한 DNS까지 질의 경로 전체를 살펴야 합니다.

사용자 PC에서 안전하게 복구하는 단계

캐시 초기화 전에 현재 값을 남깁니다

브라우저를 닫고 곧바로 PC를 재부팅하기보다 현재 설정과 조회 결과를 먼저 캡처하세요. 이후 Windows에서는 ipconfig /flushdns로 DNS 캐시를 비우고, DHCP를 사용하는 PC라면 ipconfig /release와 ipconfig /renew를 순서대로 실행할 수 있습니다. 다만 원격으로 연결된 PC에서 IP 갱신을 수행하면 관리 세션이 끊길 수 있으므로 현장 사용자와 협의해야 합니다.

브라우저도 자체 DNS 캐시나 보안 DNS 기능을 사용할 수 있습니다. 운영체제의 nslookup은 정상인데 특정 브라우저만 실패한다면 브라우저 재시작, 프록시 설정, 보안 DNS 정책을 확인하세요. 회사가 지정한 DNS를 우회하도록 개인용 DoH가 활성화되면 내부 도메인이 조회되지 않거나 보안 로그가 누락될 수 있습니다.

공용 DNS 변경은 임시 진단으로 제한합니다

인터넷에 소개된 해결법을 따라 PC의 DNS 주소를 공용 서비스로 바꾸면 외부 사이트가 즉시 열릴 수 있습니다. 그러나 이것은 사내 DNS 장애를 우회했음을 보여주는 진단 결과일 뿐, 기업 환경의 근본 해결책은 아닙니다. 내부 서버 이름, 접근통제, 유해 사이트 차단, 감사 로그와 연동된 환경이라면 임의 변경이 보안 정책을 깨뜨릴 수 있습니다.

1. 현재 IP, 게이트웨이, DNS 서버 주소와 오류 화면을 저장합니다.
2. 다른 PC에서 같은 도메인을 조회해 영향 범위를 비교합니다.
3. 로컬 캐시를 초기화한 뒤 동일 명령으로 다시 조회합니다.
4. VPN과 프록시를 승인된 절차에 따라 각각 분리 시험합니다.
5. 해결되지 않으면 기록한 시각과 결과를 네트워크 담당자에게 전달합니다.

주의: hosts 파일에 IP와 도메인을 직접 추가하는 방식은 긴급 우회에만 사용해야 합니다. 서버 IP가 바뀌어도 자동 갱신되지 않아 더 큰 장애를 만들 수 있습니다.

한두 명의 PC에서만 반복된다면 DHCP가 배포한 주소와 수동 입력값이 섞였는지도 살펴보세요. 퇴사한 관리자가 남긴 고정 DNS, 오래된 VPN 어댑터의 우선순위, 가상화 프로그램이 만든 네트워크 어댑터가 예상치 못한 조회 경로를 만들기도 합니다.

서버와 네트워크 장비에서 해결하는 순서

서비스 상태보다 질의 경로를 끝까지 확인합니다

DNS 서비스가 ‘실행 중’이라고 표시돼도 정상 응답을 보장하지는 않습니다. 서버의 CPU, 메모리, 디스크 여유 공간, 소켓 수, 질의 지연시간과 오류 로그를 함께 확인하세요. 캐시 DNS가 외부 질의를 전달하는 포워더에 도달하는지, 권한 DNS의 영역 파일이 정상 로드됐는지도 실제 질의로 검증해야 합니다.

이중화된 DNS 서버를 운영한다면 두 서버에 각각 직접 질의해 결과를 비교합니다. 한쪽 서버에만 최신 레코드가 없으면 클라이언트마다 성공과 실패가 번갈아 나타나 문제를 재현하기 어렵습니다. Active Directory 연동 환경에서는 영역 복제 상태와 도메인 컨트롤러의 시간 동기화도 확인해야 합니다.

방화벽·DHCP·레코드를 차례로 검사합니다

방화벽에서는 클라이언트 구간에서 내부 DNS로 향하는 UDP와 TCP 53번, 내부 DNS에서 포워더로 향하는 정책을 구분해 확인합니다. 단순 허용 여부뿐 아니라 세션 제한, IPS 오탐, NAT 적용, 비대칭 경로도 살펴보세요. 최근 정책 변경 직후 장애가 시작됐다면 무작정 전체 정책을 되돌리기보다 변경 항목과 로그를 대조하는 편이 안전합니다.

• DHCP: 기본 DNS와 보조 DNS 주소가 실제 운영 서버인지 확인합니다.
• A·AAAA 레코드: IPv4와 IPv6 응답이 현재 서버 주소와 일치하는지 검사합니다.
• CNAME: 별칭이 삭제되었거나 순환 참조를 만들지 않았는지 봅니다.
• MX·TXT: 메일 라우팅과 SPF·DKIM·DMARC 관련 값의 오탈자를 확인합니다.
• TTL: 변경 전 충분히 낮췄는지, 변경 후 다시 운영 기준으로 복원했는지 점검합니다.
• 시간 동기화: DNSSEC와 인증 연동에 영향을 줄 정도의 시각 오차가 없는지 확인합니다.

레코드 변경 비용 자체는 크지 않지만 장애 비용은 사용자 수와 중단 시간에 비례해 증가합니다. 내부 담당자의 긴급 대응만으로 끝낼지, 월 단위 모니터링과 이중화 운영을 포함한 관리 서비스를 이용할지는 중요도에 따라 판단하세요. 여러 지점이나 24시간 운영 사업장은 장애 후 호출 방식보다 상시 감시와 자동 알림 체계가 유리합니다.

재발을 막는 운영 체크리스트와 자주 묻는 질문

TTL과 이중화를 변경 전에 설계합니다

DNS 변경 당일에 TTL을 낮추면 기존 캐시에 남은 값은 즉시 사라지지 않습니다. 중요한 서비스 이전은 기존 TTL만큼 여유를 두고 값을 낮춘 뒤 변경해야 합니다. 예를 들어 기존 TTL이 24시간이라면 최소 하루 전에 낮추고, 전환이 안정화된 후 트래픽 특성에 맞는 값으로 복원하는 방식이 안전합니다.

기본 DNS와 보조 DNS를 설정했다고 해서 이중화가 끝나는 것도 아닙니다. 두 서버가 같은 전원, 같은 스위치, 같은 회선에 연결돼 있으면 단일 장애 지점이 그대로 남습니다. 가능하면 장애 도메인을 분리하고, 설정 복제와 정기 복구 시험까지 운영 절차에 포함하세요. IT 인프라의 범위를 이해하려면 IT 개념 자료도 참고할 수 있습니다.

현장에서 자주 묻는 질문

Q. DNS 서버를 두 개 입력하면 첫 번째가 느릴 때 항상 두 번째로 넘어가나요?
운영체제와 애플리케이션의 선택 방식에 따라 다르며, 단순한 순차 대기만을 보장하지 않습니다. 따라서 두 서버 모두 동일한 레코드와 성능을 유지해야 합니다.

Q. 웹사이트는 열리는데 이메일만 실패할 수도 있나요?
가능합니다. 웹 접속에 쓰는 A·AAAA 레코드가 정상이어도 MX 레코드, 메일 서버 이름, SPF·DKIM 관련 TXT 레코드에 문제가 있으면 송수신이나 인증만 실패할 수 있습니다.

• DNS 서버 가용성과 응답시간을 1분 단위로 감시합니다.
• SERVFAIL, NXDOMAIN 급증과 외부 포워더 실패율에 경보를 설정합니다.
• 모든 레코드 변경에 요청자, 작업자, 이전 값, 새 값, 복구 방법을 기록합니다.
• 분기마다 보조 DNS 직접 질의와 장애 전환 훈련을 시행합니다.
• 퇴사자 계정과 불필요한 관리자 권한을 정기적으로 정리합니다.
• 외부 도메인의 만료일, 네임서버 위임, DNSSEC 상태를 함께 점검합니다.

마지막으로 사용자가 ‘사이트가 안 열린다’고 신고할 때는 위치, 연결 방식, 실패 주소, 발생 시각, 오류 문구를 받는 표준 양식을 마련하세요. 이 다섯 가지 정보만 일관되게 수집해도 DNS, 회선, 무선, 방화벽, 서버 장애를 구분하는 시간이 크게 줄어듭니다. 빠른 복구보다 더 중요한 것은 같은 장애를 다시 겪지 않도록 기록과 감시 체계를 남기는 것입니다.