웹사이트가 느리다고 모두 DNS 문제는 아닙니다. 같은 도메인을 같은 조건에서 반복 질의하고, 기본 DNS와 다른 DNS의 응답을 비교하면 이름 조회 구간에 문제가 있는지 좁힐 수 있습니다. 먼저 설정을 바꾸지 않는 조회부터 시작하세요.
아래 명령은 BIND의 dig가 설치된 Linux·macOS·WSL 환경을 가정합니다. 사내 전용 도메인은 공용 DNS로 보내지 말고 담당자가 지정한 DNS만 사용합니다. 예제 도메인 example.com은 점검 대상 공개 도메인으로 바꿀 수 있습니다.
이 글에서 바로 찾기 5개 항목
1. Query time이 실제로 출력되게 조회합니다
dig example.com A +noall +answer +stats +comments +time=2 +tries=1+noall +answer만 사용하면 응답 레코드만 보이고 통계가 빠집니다. 응답 시간을 보려면 +stats, 응답 상태를 함께 보려면 +comments를 명시하세요. 옵션 의미는 ISC BIND dig 문서에서 확인할 수 있습니다.
해석용 출력 예시이며 실측값이 아닙니다.
status: NOERROR
example.com. 300 IN A 192.0.2.10
;; Query time: 24 msecNOERROR는 DNS 응답 상태이지 웹사이트 정상 동작의 보증이 아닙니다. 예시 IP는 문서 설명용 주소입니다. Query time은 해당 질의의 시간이며 브라우저 전체 로딩 시간과 다릅니다. 값 하나만 보고 느리다고 판정하지 말고 첫 질의와 반복 질의를 구분합니다.
2. dig의 기본 DNS와 다른 재귀 DNS를 비교합니다
@서버주소를 생략한 BIND dig는 /etc/resolv.conf의 서버를 참고합니다. 브라우저나 운영체제의 모든 이름 해석 경로를 그대로 시험하는 것은 아니므로, 출력의 SERVER 항목도 함께 확인하세요.
dig example.com A +noall +answer +stats +comments +time=2 +tries=1
dig @1.1.1.1 example.com A +noall +answer +stats +comments +time=2 +tries=1
dig @8.8.8.8 example.com A +noall +answer +stats +comments +time=2 +tries=1위 명령은 컴퓨터의 DNS 설정을 변경하지 않습니다. 기본 서버와 명시한 공용 서버의 응답을 비교하는 조회입니다. 외부 DNS 접속이 차단된 회사망에서는 타임아웃이 날 수 있으므로 보안 설정을 해제하지 마세요.
| 관찰한 차이 | 다음 확인 |
|---|---|
| 기본 DNS만 반복해서 느림 | 해당 DNS까지의 네트워크 경로와 DNS 서버의 처리·포워딩 상태를 확인합니다. |
| 모든 DNS가 느림 | 클라이언트 네트워크와 공통 경로, 대상 도메인 권한 서버를 나눠 점검합니다. |
| 첫 질의만 느림 | 캐시 유무와 TTL을 확인합니다. 모든 응답이 항상 캐시된다고 가정하지 않습니다. |
| dig는 빠르고 브라우저만 느림 | 브라우저 보안 DNS, 프록시, 연결·TLS·서버 응답 구간을 따로 확인합니다. |
다운로드도 느리거나 방마다 차이가 크다면 DNS보다 유선·무선 속도를 나눠 확인하는 와이파이 진단부터 진행하는 편이 맞습니다.
3. 권한 DNS와 재귀 DNS를 혼동하지 않습니다
dig example.com NS +short
dig +trace example.com A첫 명령으로 권한 NS 이름을 확인할 수 있습니다. 다음 예제의 ns1.example.net은 실제로 조회된 권한 서버 이름으로 바꾸세요.
dig @ns1.example.net example.com SOA +norecurse +stats +comments +time=2 +tries=1+trace는 로컬 dig가 위임 경로를 따라 질의하는 방식입니다. 평소 사용하는 재귀 DNS의 내부 경로를 그대로 재현하는 것은 아닙니다. 방화벽 정책으로 직접 질의가 막힌 환경에서는 trace 실패만으로 권한 서버 장애라고 결론 내리지 않습니다.
4. 느린 응답과 주소를 받지 못한 응답을 구분합니다
Query time이 짧아도 원하는 주소를 얻지 못할 수 있습니다. 응답 시간부터 비교하기 전에 status, 요청한 레코드 종류, ANSWER와 AUTHORITY 영역을 함께 읽으세요.
- NXDOMAIN: 조회한 이름이 없다는 응답입니다. CNAME이 있으면 별칭이 가리키는 최종 이름의 문제일 수도 있습니다. 먼저 도메인 철자와 CNAME 연결을 확인합니다.
- NOERROR인데 요청한 A·AAAA가 없음: 이름은 있지만 그 종류의 데이터가 없는 NODATA일 수 있습니다. NODATA는 별도의
status값이 아닙니다. ANSWER가 비었다는 사실만으로 단정하지 말고, AUTHORITY의 SOA와 NS를 확인해 위임 응답과 구분합니다. - SERVFAIL: DNS 서버가 질의를 처리하지 못했습니다. 이 코드 하나만으로 도메인 삭제나 특정 장애 원인을 확정하지 않습니다.
- REFUSED: 서버 정책에 따라 질의가 거부됐습니다. 해당 서버가 내 질의를 허용하는지 확인하고 보안 정책을 임의로 해제하지 않습니다.
- 타임아웃: 제한 시간 안에 응답을 받지 못한 상황입니다. NXDOMAIN 같은 DNS 응답 코드가 아니므로 서버 주소·접속 경로·허용 정책을 따로 확인합니다.
응답 코드의 정의는 RFC 1035의 메시지 헤더 규격, NODATA와 위임 응답의 구분은 RFC 2308의 No Data 설명을 참고하세요.
주소가 없다는 응답이면 AUTHORITY도 표시합니다
dig example.com A +noall +comments +answer +authority +stats +time=2 +tries=1
dig example.com AAAA +noall +comments +answer +authority +stats +time=2 +tries=1+authority를 넣어 SOA 등 권한 정보를 숨기지 않는 명령입니다. A는 IPv4 주소, AAAA는 IPv6 주소를 조회합니다. 실제 응답은 대상 도메인의 설정에 따라 달라지며, 위 도메인이 특정 오류를 반환한다고 가정한 예제가 아닙니다.
캐시 시간은 MINIMUM 값 하나로 정하지 않습니다
RFC 2308에서 권한 서버의 부정 응답에 사용하는 SOA TTL은 SOA 자체의 TTL과 SOA MINIMUM 중 작은 값으로 정합니다. 재귀 DNS가 돌려주는 캐시 응답에서는 남은 TTL이 줄어들 수 있습니다. 부정 응답의 SOA와 TTL 규칙을 함께 확인하세요.
따라서 일반 A 레코드의 TTL만 낮추거나 SOA 설정을 바꿨다고 이미 저장된 부정 캐시가 즉시 지워지는 것은 아닙니다. 같은 이름과 레코드 종류로 권한 서버의 응답과 사용하는 재귀 DNS의 응답을 비교하고, 남은 TTL을 기록하세요. 캐시 삭제가 필요하면 해당 DNS 제품의 공식 절차와 운영 권한을 먼저 확인합니다.
5. 설정 변경 전후에는 같은 조건으로 재측정합니다
- 시간, 네트워크, 질의한 서버, 응답 상태, Query time을 기록합니다.
- 한 조건씩 바꿉니다. DNS·공유기·VPN을 동시에 바꾸면 원인을 알기 어렵습니다.
- 첫 응답과 반복 응답을 구분하고 단 한 번의 빠른 결과로 종료하지 않습니다.
- 회사망에서는 내부 도메인 해석과 VPN 접속도 정상인지 확인합니다.
앱 장애와 연결해 조사한다면 요청 ID와 시각으로 로그를 좁히는 방법을 함께 사용하세요. DNS가 실제 병목인지 확인한 뒤에야 캐시 정책·서버·네트워크 설정 중 무엇을 바꿀지 판단할 수 있습니다.