Haru Utils

NAME RESOLUTION

DNS 조회가 실패하거나 느릴 때

현재 DNS 서버, 로컬 resolver, 지정 서버 조회를 비교해 이름 해석 문제를 좁힙니다.
DNS 실패Temporary failure in name resolutionresolvectldigSERVFAIL
환경systemd-resolved 또는 BIND 도구 사용 환경
분류네트워크
검토일2026-08-27
진행5단계 · 조회 우선

SAFE OPERATING BOUNDARY

중단·복구 기준부터 확인하세요

STOP CONDITIONS

여기서는 멈추세요

  • 명령 출력의 서버·서비스·경로가 예상 대상과 다르면 변경 단계로 넘어가지 않습니다.
  • 현재 접속 세션, 백업 또는 콘솔 복구 경로를 확보하지 못했다면 상태 변경 명령을 실행하지 않습니다.
ROLLBACK

복구 기준

변경 전 설정과 출력값을 기록하고, 예상과 다른 결과가 나오면 추가 변경을 멈춘 뒤 승인된 운영 복구 절차로 되돌립니다.

ESCALATION PACK

담당자에게 전달할 자료

  • 장애 발생 시각·정상화 시각과 원문 오류 메시지
  • 민감정보를 제거한 조회 명령 출력과 변경 전후 차이
  • 조치 후 동일 조건으로 수행한 재검증 결과
공식 문서와 읽기 전용 진단 명령을 우선 검토했습니다. 실제 서버에서는 설치된 버전의 --help와 man을 함께 확인하세요.

BEFORE YOU START

이런 증상에서 시작합니다

  • 이름으로만 접속 실패
  • SERVFAIL
  • 조회 지연
  • 간헐적 API 실패

CHECK THE BRANCH

놓치기 쉬운 원인 분기

01

사내 도메인만 실패

인터페이스별 DNS 서버와 route-only domain이 적용되는 split DNS 환경인지 resolvectl status에서 확인합니다.

02

/etc/resolv.conf가 예상과 다른 경우

systemd-resolved 사용 환경에서는 심볼릭 링크 대상과 per-link 구성이 실제 조회 경로를 결정할 수 있습니다.

03

UDP만 실패하거나 응답이 큰 경우

dig 기본 조회와 +tcp 결과를 비교하고 방화벽이 UDP와 TCP 53을 다르게 처리하는지 확인합니다.

FOLLOW THE FLOW

순서대로 확인하기

1
조회시스템을 변경하지 않는 확인 단계

현재 resolver 구성 확인

인터페이스별 DNS 서버와 검색 도메인을 확인합니다.

resolver 전체 상태
resolvectl status
resolv.conf 연결
ls -l /etc/resolv.conf
결과 읽기

예상하지 않은 DNS 서버나 끊어진 심볼릭 링크가 있는지 봅니다.

다음 판단

현재 설정을 기록한 뒤 조회를 비교합니다.

2
조회시스템을 변경하지 않는 확인 단계

로컬 resolver로 조회

실제 애플리케이션과 가까운 경로로 먼저 시험합니다.

systemd-resolved 조회
resolvectl query example.com
기본 dig 조회
dig example.com
결과 읽기

응답 코드, SERVER, Query time을 기록합니다.

다음 판단

NXDOMAIN과 timeout, SERVFAIL을 구분합니다.

3
조회시스템을 변경하지 않는 확인 단계

지정 DNS 서버와 비교

외부 DNS 사용이 정책상 허용된 환경에서만 비교합니다.

Cloudflare DNS 비교
dig @1.1.1.1 example.com
TCP 조회 비교
dig +tcp example.com
결과 읽기

지정 서버만 성공하면 로컬 resolver 또는 사내 DNS 경로 문제일 수 있습니다.

다음 판단

방화벽의 UDP/TCP 53 허용 여부도 확인합니다.

4
조회시스템을 변경하지 않는 확인 단계

resolver 로그 확인

현재 부팅의 systemd-resolved 오류를 확인합니다.

resolved 상태
systemctl status systemd-resolved --no-pager -l
최근 로그
journalctl -u systemd-resolved -b -n 100 --no-pager
결과 읽기

업스트림 timeout과 설정 반영 실패를 구분합니다.

다음 판단

설정 파일을 바꾸기 전에 원인을 기록합니다.

5
변경데이터·서비스 상태가 달라질 수 있는 단계

캐시 정리 후 재검증

캐시 삭제는 일시적으로 조회량을 늘릴 수 있습니다.

변경 단계입니다. 실행 전 대상 이름과 경로, 서비스 중단 영향, 복구 방법을 다시 확인하세요.
로컬 DNS 캐시 비우기
sudo resolvectl flush-caches
재조회
resolvectl query example.com && dig example.com
결과 읽기

동일 도메인을 여러 번 조회해 응답과 지연이 안정적인지 봅니다.

다음 판단

재발하면 DNS 서버·네트워크 담당자에게 비교 결과를 전달합니다.

PRIMARY REFERENCES

공식 문서

배포판과 버전에 따라 옵션·로그 위치가 다를 수 있습니다. 실행 전 서버의 --help와 로컬 매뉴얼을 함께 확인하세요.

도구 빠른 검색

최근 사용한 도구를 다시 열거나, 이름과 기능으로 검색하세요.

검색어와 도구의 입력·결과는 저장하지 않습니다.

↑↓ 이동 · Enter 열기 · Esc 닫기