사내 DNS 서버 로그를 한 달 살펴봤더니 장애가 먼저 보였다

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

인터넷은 정상인데 그룹웨어만 늦게 열리고, 파일 서버는 IP 주소로 접속하면 되는데 이름으로는 연결되지 않는 순간이 있나요? 이런 간헐적 장애는 서버 성능이나 회선 품질보다 사내 DNS 서버의 응답 지연, 잘못된 레코드, 비정상적인 재시도에서 시작되는 경우가 적지 않습니다. 문제는 DNS가 완전히 멈추기 전까지는 대부분의 직원이 그 존재조차 의식하지 않는다는 점입니다.

한 달 동안 DNS 로그를 모아 시간대별 요청량과 실패 유형을 살펴보면 단순 장애 기록 이상의 정보가 보입니다. 퇴사자 PC가 계속 예전 서버를 찾는 현상, 폐기한 프린터 주소를 반복 조회하는 프로그램, 외부 DNS로 빠져나가는 단말처럼 평소에는 숨어 있던 운영 문제가 드러납니다. 아래 내용은 복잡한 보안 장비를 새로 도입하기 전에 적용할 수 있는 DNS 운영 꿀팁과 생활형 점검 방법을 중심으로 구성했습니다.

DNS 로그를 모으자 평소 안 보이던 낭비가 드러났습니다

요청 건수보다 실패 패턴을 먼저 봅니다

DNS 모니터링을 시작하면 흔히 초당 질의 수부터 확인하지만, 중소 규모 사내 네트워크에서는 전체 건수보다 NXDOMAIN, SERVFAIL, timeout의 반복 주기가 더 유용합니다. NXDOMAIN은 요청한 이름이 존재하지 않는다는 뜻이고, SERVFAIL은 DNS 서버가 정상적인 답을 완성하지 못했다는 신호입니다. 한두 번 발생하는 것은 자연스럽지만 같은 단말이 5초나 30초 간격으로 동일한 이름을 계속 조회한다면 프로그램 설정이나 오래된 스크립트를 의심해야 합니다.

숨은 팁은 실패 건수를 단순 합계로 보지 않고 요청 단말·조회 이름·시간대 세 축으로 나누는 것입니다. 예를 들어 오전 9시에 실패가 몰리면 로그인 스크립트나 자동 실행 프로그램을, 밤마다 반복되면 백업 작업이나 예약된 배치 프로그램을 살펴볼 수 있습니다. 서버가 어떤 역할을 하는지 기본 개념이 필요하다면 지식백과의 서버 설명을 함께 참고하면 DNS와 업무 서버의 관계를 이해하기 쉽습니다.

• NXDOMAIN 상위 이름: 오타가 난 주소, 철거한 장비 이름, 종료된 내부 도메인을 찾는 데 유용합니다. 상위 20개만 추려도 정리할 설정이 빠르게 보입니다.
• SERVFAIL 발생 시각: 상위 DNS 전달자 문제인지, 내부 DNS 존 오류인지 구분할 단서입니다. 같은 시각의 방화벽 로그와 함께 보면 정확도가 높아집니다.
• 응답 시간 백분위: 평균값만 보면 일부 사용자의 긴 대기 시간이 감춰집니다. 중앙값과 95백분위 값을 함께 기록하는 편이 좋습니다.
• 반복 조회 간격: 일정한 간격은 사람이 아니라 프로그램이 만든 요청일 가능성이 큽니다. 해당 단말의 예약 작업과 에이전트 설정을 확인합니다.
• 질의 유형: A 레코드뿐 아니라 AAAA, PTR, SRV 조회를 나눠 보면 IPv6 설정 오류나 도메인 가입 장비의 위치 검색 문제도 발견할 수 있습니다.

로그를 오래 보관하지 않아도 기준선은 만들 수 있습니다

모든 DNS 원문 로그를 무기한 쌓으면 저장 공간과 개인정보 관리 부담이 커집니다. 실무에서는 원문을 짧게 보관하고 일별 집계 데이터를 더 오래 남기는 방식이 효율적입니다. 첫 주에는 정상 상태의 기준선을 만들고, 둘째 주부터 전주 같은 요일과 비교하면 월요일 로그인 폭증이나 금요일 백업 작업 같은 반복 패턴을 쉽게 구분할 수 있습니다.

운영 팁: 장애가 없는 날의 수치를 먼저 저장해야 이상을 판단할 수 있습니다. ‘느리다’는 표현 대신 정상일 때 20ms, 이상일 때 300ms처럼 비교 가능한 기준을 남겨 보세요.

설정을 조금 바꿨더니 문의 전화가 줄었습니다

TTL은 무조건 짧게 잡는 값이 아닙니다

DNS 레코드의 TTL을 짧게 설정하면 서버 주소를 바꿀 때 빠르게 반영된다는 장점이 있습니다. 하지만 모든 내부 레코드를 지나치게 짧게 두면 단말과 DNS 서버가 같은 정보를 계속 확인하므로 요청량이 늘고, DNS 서버가 잠깐 흔들릴 때 업무 영향도 커질 수 있습니다. 주소 변경이 거의 없는 프린터, 인증 서버, 관리 장비와 자주 전환되는 서비스 레코드에 같은 TTL을 적용하지 않는 것이 핵심입니다.

실무에서 유용했던 방법은 변경 예정이 있는 레코드만 사전에 TTL을 낮추는 것입니다. 평소에는 안정적인 캐시 시간을 유지하다가 서버 이전 하루 전이나 서비스 전환 계획에 맞춰 TTL을 단계적으로 낮춥니다. 전환이 끝난 뒤에는 새 주소가 충분히 전파됐는지 확인하고 원래 값으로 복원합니다. 이때 변경 전 값과 복원 시점을 작업 기록에 남기지 않으면 짧아진 TTL이 몇 달 동안 방치될 수 있으니 주의해야 합니다.

1. 변경 대상만 고릅니다. 전체 존의 TTL을 일괄 수정하지 말고 실제 IP가 바뀌는 A·CNAME 레코드를 특정합니다.
2. 기존 TTL보다 일찍 준비합니다. 기존 값이 24시간이라면 전환 직전에 낮춰도 이전 캐시가 남을 수 있으므로 최소 기존 TTL만큼 여유를 둡니다.
3. 서로 다른 위치에서 확인합니다. 서버실, 일반 사무실 VLAN, 원격접속 구간에서 각각 새 주소가 조회되는지 검사합니다.
4. 롤백 레코드를 준비합니다. 장애가 생겼을 때 되돌릴 IP와 적용 명령, 담당자를 작업 문서에 함께 기록합니다.
5. 전환 후 TTL을 복원합니다. 낮은 값이 계속 유지되면 불필요한 조회가 늘어나므로 완료 조건에 복원 작업을 포함합니다.

보조 DNS보다 먼저 클라이언트 배치를 확인합니다

DNS 서버를 두 대 구축해도 클라이언트가 두 주소를 제대로 전달받지 못하면 이중화 효과가 없습니다. 특히 고정 IP를 쓰는 복합기, 출입통제 장비, 오래된 NAS에는 첫 번째 DNS만 입력돼 있는 경우가 많습니다. DHCP를 쓰는 PC는 옵션이 갱신되지만 수동 설정 장비는 그대로 남기 때문에, 서버 이중화 작업과 단말 DNS 설정 조사를 한 묶음으로 진행해야 합니다.

또 하나 잘 알려지지 않은 함정은 보조 DNS 칸에 공용 DNS를 넣는 방식입니다. 내부 업무 주소는 외부 DNS가 알 수 없으므로 단말이 공용 DNS를 선택하는 순간 그룹웨어나 파일 서버 이름 조회가 실패할 수 있습니다. 내부 단말에는 내부 DNS만 배포하고, 외부 도메인 조회는 내부 DNS가 승인된 포워더로 전달하도록 설계하는 편이 일관적입니다. 네트워크 서비스가 조직 전체 시스템과 연결되는 관점은 범정부 IT 서비스 시스템 관련 설명에서도 확장해 살펴볼 수 있습니다.

• DHCP 옵션 확인: 기본 VLAN뿐 아니라 무선, 전화기, 게스트망의 DNS 배포 주소를 각각 확인합니다.
• 고정 IP 장비 조사: 프린터 웹 화면이나 장비 관리대장에서 DNS 주소를 별도 항목으로 수집합니다.
• 보조 서버 실제 시험: 주 DNS 서비스를 잠시 차단한 시험 구간에서 이름 조회와 업무 로그인이 유지되는지 검증합니다.
• 포워더 순서 확인: 응답이 불안정한 외부 DNS가 첫 순서에 있으면 내부 사용자는 간헐적인 지연을 경험할 수 있습니다.
• 역방향 조회 구성: PTR 레코드를 관리하면 IP만 남은 보안 로그에서 장비 이름을 찾는 시간이 줄어듭니다.

현장 팁: DNS 이중화는 서버 두 대가 켜져 있다는 뜻이 아니라, 단말이 어느 한쪽의 장애에도 같은 내부 이름을 정상적으로 해석하는 상태를 뜻합니다.

회의실 PC 한 대의 반복 조회를 따라가니 원인이 잡혔습니다

월요일 아침의 8초 지연은 서버 성능 문제가 아니었습니다

직원 70명 규모의 한 사무실에서는 월요일 오전마다 전자결재 첫 화면이 6~8초 늦게 열렸습니다. CPU와 메모리 사용률은 낮았고 네트워크 손실도 보이지 않아 애플리케이션 서버 증설이 검토되고 있었습니다. 그러나 DNS 로그를 한 달 모아 보니 오전 8시 50분부터 특정 회의실 PC 한 대가 존재하지 않는 old-auth라는 내부 이름을 초당 여러 번 조회하고 있었습니다. 실패 응답 자체는 짧았지만 보안 에이전트가 즉시 재시도하면서 DNS 요청 대기열을 밀어내고 있었습니다.

담당자는 먼저 해당 PC를 네트워크에서 분리한 뒤 같은 시간대의 응답 지연을 비교했습니다. 95백분위 응답 시간이 수백 밀리초에서 수십 밀리초 수준으로 내려가자 문제 범위를 단말로 좁혔습니다. 프로그램 목록만 봐서는 원인이 나오지 않았지만 시작 프로그램과 예약 작업을 확인하니 예전에 사용하던 인증 서버를 찾는 구형 회의 솔루션 모듈이 남아 있었습니다. 단순히 DNS에 임시 레코드를 만들어 오류를 숨기지 않고, 해당 모듈의 설정 파일과 배포 정책을 찾아 현재 인증 주소로 수정했습니다.

1. 08:50 요청 급증 확인: DNS 로그를 요청 IP별로 묶어 회의실 PC가 전체 실패 질의의 대부분을 만든다는 사실을 확인했습니다.
2. 09:05 영향 분리: PC의 유선 연결을 끊고 업무 시스템 응답 시간을 다시 측정해 상관관계를 확보했습니다.
3. 09:20 프로세스 추적: 요청 주기와 실행 중인 서비스의 재시도 간격을 대조해 오래된 회의 솔루션 모듈을 후보로 정했습니다.
4. 10:10 설정 교체: 존재하지 않는 서버 이름을 새 주소로 단순 치환하기 전에 해당 모듈이 계속 필요한지 부서 담당자와 확인했습니다.
5. 다음 날 재검증: 같은 시간에 질의 수, NXDOMAIN 비율, 전자결재 첫 화면 시간을 다시 측정했습니다.

한 대를 고친 뒤 같은 흔적을 전사에서 찾았습니다

회의실 PC만 수정하고 끝냈다면 비슷한 문제가 다른 장소에서 다시 나타났을 것입니다. 담당자는 발견한 실패 도메인을 기준으로 한 달치 로그를 재검색했고, 교육장 노트북 세 대와 창고 단말 한 대에서도 동일한 조회가 발생한다는 사실을 찾았습니다. 네 장비 모두 같은 시기에 설치된 이미지로 운영되고 있었습니다. 이를 계기로 OS 이미지에서 구형 모듈을 제거하고 신규 PC 배포 절차에 설치 후 DNS 실패 조회 검사를 추가했습니다.

비용 측면에서도 차이가 컸습니다. 처음 검토한 서버 증설은 장비 구매뿐 아니라 라이선스, 랙 공간, 전력, 백업 범위 확대까지 이어질 수 있었지만 실제 조치는 설정 수정과 배포 이미지 정비였습니다. 서버라는 장비의 다양한 역할은 서버 관련 지식백과 자료에서 확인할 수 있지만, 장비를 늘리기 전에는 서버가 받는 요청이 정상적인지부터 살펴야 합니다. 용량을 추가해 비정상 트래픽을 견디게 만드는 것과 원인을 제거하는 것은 전혀 다른 대응입니다.

• 재발 방지 규칙: 동일한 NXDOMAIN이 한 단말에서 10분 이상 반복되면 운영 담당자에게 알림이 가도록 설정했습니다.
• 배포 전 시험: 새 PC 이미지를 격리 VLAN에서 30분간 실행하고 실패 도메인 목록을 확인하게 했습니다.
• 예외 처리: 오프라인 환경에서 정상적으로 발생하는 탐색 요청은 승인 목록에 넣되 사유와 만료일을 기록했습니다.
• 변경 증거: 수정 전후의 질의 건수와 95백분위 응답 시간을 같은 그래프로 남겨 효과를 수치로 확인했습니다.
• 업무 체감 확인: 기술 지표만 보지 않고 실제 사용자가 전자결재, 파일 공유, 프린터 검색을 다시 수행하게 했습니다.

일주일 뒤 월요일 오전에도 전자결재 첫 화면은 평소 속도로 열렸고, DNS 실패 질의는 기준선 아래로 유지됐습니다. 교육장 노트북을 켠 날에도 과거처럼 요청이 폭증하지 않았습니다. 담당자는 매주 월요일 9시에 자동으로 생성되는 보고서에 ‘실패 도메인 상위 20개’와 ‘신규 요청 단말’을 추가했고, 다음 달에는 폐기한 NAS를 찾는 스캔 프로그램까지 같은 방식으로 발견했습니다. 한 대의 회의실 PC에서 시작한 추적은 서버 구매 없이 체감 장애를 없애고, 사내 IT 시스템에 남은 오래된 설정을 지속적으로 찾아내는 운영 습관으로 자리 잡았습니다.