DNS 동작 원리와 Linux 실전 장애 분석

admin · 2026-10-12 · 조회 4

DNS 동작 원리와 Linux 실전 장애 분석

서버를 운영하다 보면 다음과 같은 장애가 발생한다.

IP 주소로는 접속되는데 도메인으로는 접속되지 않는다.
특정 서버에서만 DNS 조회가 실패한다.
DNS 조회 결과가 서버마다 다르다.
DNS 레코드를 변경했는데 이전 IP 주소가 계속 조회된다.
웹 서비스가 간헐적으로 접속되지 않는다.
DNS 조회가 오래 걸리거나 타임아웃이 발생한다.
UDP 53번 포트는 통신되는데 DNS 조회가 실패한다.

이러한 문제는 단순히 DNS 서버가 실행 중인지 확인하는 것만으로 해결되지 않는다.

DNS 요청이 어느 서버로 전달되는지, 어떤 레코드를 조회하는지, 캐시가 어떻게 동작하는지, 그리고 실제 패킷이 정상적으로 왕복하는지를 확인해야 한다.

이번 편에서는 다음 순서로 학습한다.

DNS란 무엇인가?
        ↓
도메인 이름과 IP 주소
        ↓
DNS 조회 과정
        ↓
재귀 질의와 반복 질의
        ↓
DNS 레코드와 TTL
        ↓
Linux DNS 설정
        ↓
dig와 nslookup
        ↓
tcpdump 패킷 분석
        ↓
실제 DNS 장애 분석

1. DNS란 무엇인가?

DNS는 Domain Name System의 약자다.

사람이 기억하기 쉬운 도메인 이름을 IP 주소 등의 정보로 변환하거나 조회할 수 있도록 해주는 분산형 이름 시스템이다.

예를 들어 사용자가 웹 브라우저에서 다음 주소를 입력한다고 가정하자.

www.example.com

컴퓨터는 실제 네트워크 통신을 위해 목적지 IP 주소를 알아야 한다.

DNS 조회를 통해 다음과 같은 결과를 얻을 수 있다.

www.example.com
        |
        | DNS Query
        v
DNS Server
        |
        | DNS Response
        v
93.184.216.34

위 IP 주소는 구조를 설명하기 위한 예시다. 실제 조회 결과는 도메인과 DNS 설정에 따라 달라진다.

DNS는 단순히 웹사이트 주소를 IP로 바꾸는 기능만 제공하지 않는다.

메일 서버 위치, 별칭, IPv6 주소, 서비스 정보 등 다양한 정보를 관리한다.

대표적인 DNS 레코드는 다음과 같다.

레코드역할A도메인 이름에 대한 IPv4 주소AAAA도메인 이름에 대한 IPv6 주소CNAME다른 도메인 이름을 가리키는 별칭MX메일 서버 정보NS해당 DNS 영역을 담당하는 네임서버PTRIP 주소에 대한 역방향 조회 정보TXT도메인과 관련된 텍스트 정보SOADNS 영역의 관리 정보

시스템 엔지니어는 이 레코드들이 어떤 상황에서 사용되는지 이해해야 한다.

2. DNS는 왜 필요한가?

DNS가 없다면 사용자는 서버에 접속할 때마다 IP 주소를 직접 입력해야 한다.

예를 들어 다음과 같은 구조다.

https://192.168.10.100

하지만 서버의 IP 주소가 변경되면 모든 사용자가 새로운 주소를 알아야 한다.

반면 DNS를 사용하면 다음과 같이 접근할 수 있다.

https://app.example.com

서버의 IP 주소가 변경되더라도 DNS 레코드를 변경하면 동일한 도메인 이름을 유지할 수 있다.

물론 DNS 캐시와 TTL 때문에 변경 사항이 모든 곳에 즉시 반영되는 것은 아니다.

DNS를 사용하는 핵심적인 이유는 다음과 같다.

사람이 기억하기 쉬운 이름 사용
서비스 주소 변경 관리
서비스와 서버의 논리적 분리
메일 서버 위치 관리
여러 IP 주소를 이용한 서비스 구성
내부 및 외부 이름 해석 관리

특히 기업 환경에서는 내부 DNS와 외부 DNS를 구분해서 운영하기도 한다.

예를 들어 내부에서는 다음 주소를 사용할 수 있다.

db01.internal.example.com
192.168.10.20

외부에서는 내부 데이터베이스 주소를 공개하지 않고 웹 서비스 주소만 제공할 수 있다.

3. DNS 조회는 어떻게 진행되는가?

DNS 조회 과정은 단순히 클라이언트가 DNS 서버에 질문하고 응답을 받는 것으로 끝나지 않을 수 있다.

재귀 DNS 서버에 캐시가 없다면 여러 DNS 서버를 순서대로 조회해야 할 수 있기 때문이다.

일반적인 조회 과정을 살펴보자.

사용자가 다음 도메인을 조회한다고 가정한다.

www.example.com

전체 구조는 다음과 같다.

Client
   |
   | 1. DNS Query
   v
Recursive DNS Resolver
   |
   | 2. Root DNS Server 조회
   v
Root DNS Server
   |
   | 3. .com TLD DNS Server 정보
   v
Recursive DNS Resolver
   |
   | 4. .com TLD DNS Server 조회
   v
TLD DNS Server
   |
   | 5. example.com 권한 DNS 서버 정보
   v
Recursive DNS Resolver
   |
   | 6. 권한 DNS 서버 조회
   v
Authoritative DNS Server
   |
   | 7. A 또는 AAAA 레코드 응답
   v
Recursive DNS Resolver
   |
   | 8. 최종 응답
   v
Client

여기서 중요한 점은 모든 DNS 조회가 매번 Root DNS 서버부터 시작하는 것은 아니라는 것이다.

재귀 DNS 서버에 유효한 캐시가 있다면 캐시된 응답을 바로 반환할 수 있다.

또한 클라이언트의 로컬 캐시, 운영체제의 이름 해석 설정, 브라우저 캐시 등에 따라 실제 조회 경로가 달라질 수 있다.

4. DNS Root, TLD, Authoritative Server

DNS 계층 구조를 이해하려면 세 가지 서버를 구분해야 한다.

4-1. Root DNS Server

Root DNS 서버는 DNS 계층 구조의 최상위에 위치한다.

Root DNS 서버가 모든 도메인의 IP 주소를 직접 관리하는 것은 아니다.

대신 조회하려는 최상위 도메인을 담당하는 DNS 서버 정보를 제공한다.

예를 들어:

www.example.com

을 조회할 때 Root DNS 서버는 .com을 담당하는 TLD 네임서버 정보를 안내할 수 있다.

4-2. TLD DNS Server

TLD는 Top-Level Domain의 약자다.

대표적인 예시는 다음과 같다.

.com
.net
.org
.kr
.jp

TLD DNS 서버는 해당 최상위 도메인 아래에서 어떤 권한 DNS 서버가 특정 도메인 영역을 담당하는지 알려준다.

예를 들어 example.com의 권한 DNS 서버 정보를 제공할 수 있다.

4-3. Authoritative DNS Server

Authoritative DNS Server는 자신이 담당하는 DNS 영역에 대해 권한 있는 응답을 제공하는 서버다.

예를 들어 다음 도메인의 DNS 영역을 관리한다고 가정하자.

example.com

해당 영역에 다음 레코드가 등록되어 있을 수 있다.

www.example.com  A  192.168.10.100

실제 레코드는 DNS 운영자가 설정한 값에 따라 달라진다.

4-4. 전체 구조

                    Root DNS
                       |
                       v
                   .com TLD
                       |
                       v
              example.com DNS
                       |
                       v
                www.example.com
                       |
                       v
                 IP Address

시스템 엔지니어가 DNS 장애를 분석할 때는 다음을 구분해야 한다.

재귀 DNS 서버에 문제가 있는가?
권한 DNS 서버에 문제가 있는가?
도메인 위임 설정에 문제가 있는가?
조회 결과가 캐시에 남아 있는가?

이 구분이 중요한 이유는 DNS 조회가 실패한다고 해서 반드시 애플리케이션 서버의 문제인 것은 아니기 때문이다.

5. Recursive Query와 Iterative Query

DNS 질의에는 재귀 질의와 반복 질의라는 개념이 있다.

두 개념을 구분하면 DNS 서버 사이에서 어떤 일이 일어나는지 이해하기 쉬워진다.

5-1. Recursive Query

재귀 질의는 요청한 서버가 최종 답변을 찾아 반환하도록 요구하는 방식이다.

예를 들어 클라이언트가 재귀 DNS 서버에 다음을 요청한다.

www.example.com의 IP 주소를 알려줘.

재귀 DNS 서버는 캐시에 답이 없다면 필요한 DNS 서버들을 조회하고 결과를 클라이언트에 반환할 수 있다.

Client
   |
   | www.example.com 조회
   v
Recursive Resolver
   |
   | 필요한 DNS 서버 조회
   v
Authoritative Server
   |
   | 최종 레코드
   v
Recursive Resolver
   |
   | 최종 응답
   v
Client

5-2. Iterative Query

반복 질의에서는 DNS 서버가 최종 답변 대신 다음 단계에 조회할 서버 정보를 반환할 수 있다.

예를 들어 Root DNS 서버가 다음과 같이 안내한다고 가정하자.

.com을 담당하는 DNS 서버에 문의하세요.

그다음 TLD 서버가 다음과 같이 안내할 수 있다.

example.com의 권한 DNS 서버에 문의하세요.

재귀 DNS 서버는 이 안내를 따라 다음 서버를 조회한다.

Root
  |
  | .com DNS 정보
  v
TLD
  |
  | example.com DNS 정보
  v
Authoritative DNS
  |
  | 최종 레코드
  v
Resolver

실제 DNS 서버는 설정과 질의 유형에 따라 다르게 동작할 수 있다.

일반적으로 클라이언트는 재귀 DNS 서버에 재귀 질의를 요청하고, 재귀 DNS 서버는 Root·TLD·권한 DNS 서버를 반복적으로 조회할 수 있다.

6. DNS Cache와 TTL

DNS에서 매우 중요한 개념이 Cache와 TTL이다.

DNS 조회 결과를 매번 처음부터 찾으면 네트워크 트래픽과 응답 시간이 증가할 수 있다.

이를 줄이기 위해 DNS 응답을 일정 시간 캐시에 저장한다.

6-1. TTL이란?

TTL은 Time To Live의 약자다.

DNS 레코드의 TTL은 해당 레코드를 캐시에 저장해 둘 수 있는 시간을 나타낸다.

예를 들어 다음과 같은 DNS 응답을 받았다고 하자.

www.example.com.  300  IN  A  192.168.10.100

여기서:

은 TTL 300초를 의미한다.

즉, 캐시를 사용하는 DNS 서버는 해당 응답을 일반적으로 최대 300초 동안 유효한 정보로 사용할 수 있다.

TTL이 만료되면 캐시 서버는 필요에 따라 다시 조회한다.

단, TTL은 모든 클라이언트가 정확히 같은 시점에 새 레코드를 조회하게 만든다는 의미는 아니다. 클라이언트와 DNS 서버마다 캐시 상태가 다를 수 있다.

6-2. DNS 레코드를 변경했는데 이전 IP가 나오는 이유

다음과 같은 상황을 가정하자.

변경 전:

www.example.com
192.168.10.100

변경 후:

www.example.com
192.168.10.200

권한 DNS 서버의 레코드는 변경되었지만, 재귀 DNS 서버에 이전 결과가 캐시되어 있을 수 있다.

Client
   |
   v
Recursive DNS Cache
   |
   | 이전 캐시 결과
   v
192.168.10.100

따라서 권한 DNS 서버에서 레코드를 변경했다고 해서 모든 사용자가 즉시 새 IP를 조회하는 것은 아니다.

DNS 변경 작업 전 TTL을 낮춰 두는 방법이 사용되기도 하지만, 기존 캐시가 이미 저장한 TTL은 변경 즉시 소급해서 낮아지지 않는다.

6-3. TTL 확인하기

다음 명령어를 실행한다.

dig www.example.com

응답의 ANSWER SECTION을 확인한다.

;; ANSWER SECTION:
www.example.com.  300  IN  A  192.168.10.100

이 결과에서 TTL을 확인할 수 있다.

캐시가 유지되는 동안 TTL은 감소할 수 있다.

7. DNS 레코드 종류 자세히 알아보기

실제 서버 운영에서 자주 사용하는 DNS 레코드를 살펴보자.

7-1. A 레코드

도메인 이름에 대한 IPv4 주소를 지정한다.

app.example.com.  IN  A  192.168.10.100

조회:

dig A app.example.com

7-2. AAAA 레코드

도메인 이름에 대한 IPv6 주소를 지정한다.

app.example.com.  IN  AAAA  2001:db8::100

조회:

dig AAAA app.example.com

2001:db8::/32는 문서 예제용 IPv6 주소 범위다.

A 레코드가 정상이어도 AAAA 레코드나 IPv6 경로에 문제가 있으면 일부 환경에서 접속 지연이나 실패가 발생할 수 있다.

7-3. CNAME 레코드

CNAME은 다른 도메인 이름을 가리키는 별칭이다.

예:

www.example.com.  IN  CNAME  example.com.

조회:

dig CNAME www.example.com

CNAME은 일반적으로 다른 레코드를 가리키며, CNAME 자체가 IP 주소를 저장하는 것은 아니다.

CNAME을 설정할 때는 같은 이름에 다른 일반 레코드를 함께 설정하는 것이 제한될 수 있으므로 DNS 제공자의 규칙을 확인해야 한다.

7-4. MX 레코드

메일을 받을 서버를 지정한다.

example.com.  IN  MX  10 mail.example.com.

여기서 숫자 10은 우선순위 값이다. 일반적으로 값이 낮을수록 우선순위가 높다.

조회:

dig MX example.com

7-5. NS 레코드

DNS 영역을 담당하는 네임서버를 지정한다.

dig NS example.com

도메인 위임이나 권한 DNS 서버 설정을 점검할 때 중요하다.

7-6. PTR 레코드

PTR은 IP 주소를 기반으로 이름을 조회할 때 사용한다.

이를 역방향 DNS 조회라고 한다.

dig -x 192.168.10.100

역방향 DNS는 정방향 DNS와 별도의 영역에서 관리될 수 있다. 따라서 A 레코드가 정상이라고 해서 PTR도 반드시 정상인 것은 아니다.

8. DNS는 UDP 53번만 사용하는가?

DNS는 일반적으로 UDP 53번 포트를 사용하지만 TCP 53번도 사용한다.

이 부분은 실무에서 자주 혼동한다.

구분주요 용도UDP 53일반적인 DNS 질의에 널리 사용TCP 53큰 응답, 잘린 응답 후 재시도, 영역 전송 등

DNS가 항상 UDP만 사용하는 것은 아니다.

8-1. UDP DNS 조회

일반적인 DNS 질의는 UDP를 통해 전송될 수 있다.

Client
192.168.10.50:53000
       |
       | UDP/53
       v
DNS Server
192.168.10.53:53

UDP는 TCP처럼 연결 설정을 위한 3-Way Handshake가 필요하지 않다.

따라서 DNS 조회에서는 UDP 요청과 응답이 정상적으로 왕복하는지 확인하는 것이 중요하다.

8-2. TCP DNS 조회

DNS 응답이 UDP로 전달하기에 크거나 DNS 메시지에 TC(Truncated) 표시가 설정되는 경우, 클라이언트는 TCP로 재시도할 수 있다.

또한 DNS 영역 전송(AXFR/IXFR)은 TCP를 사용한다.

TCP 53번이 방화벽에서 차단되어 있다면 일부 DNS 조회 또는 영역 전송이 실패할 수 있다.

따라서 DNS 서버의 방화벽을 구성할 때는 UDP 53번만 허용하면 모든 DNS 작업이 정상적으로 수행된다고 가정해서는 안 된다.

9. Linux에서 DNS 설정 확인하기

DNS 장애를 분석할 때는 먼저 서버가 어떤 DNS 서버를 사용하고 있는지 확인한다.

9-1. /etc/resolv.conf 확인

cat /etc/resolv.conf

예:

nameserver 192.168.10.53
nameserver 192.168.10.54
search internal.example.com

각 항목의 의미는 다음과 같다.

설정의미nameserverDNS 질의를 보낼 DNS 서버search검색 도메인 설정

단, 최신 Linux에서는 /etc/resolv.conf가 NetworkManager나 systemd-resolved 등에 의해 관리될 수 있다.

따라서 파일을 직접 수정하기 전에 현재 시스템의 DNS 관리 방식을 확인해야 한다.

9-2. DNS 서버 설정 확인

NetworkManager를 사용하는 Rocky Linux 계열에서는 다음 명령어를 사용할 수 있다.

nmcli device show

특정 인터페이스만 확인하려면:

nmcli device show ens160

출력에서 다음 항목을 찾는다.

IP4.DNS[1]
IP4.DNS[2]
IP4.DOMAIN[1]

실제 설정은 인터페이스와 NetworkManager 프로파일에 따라 달라질 수 있다.

9-3. systemd-resolved 사용 여부 확인

resolvectl status

이 명령어는 systemd-resolved를 사용하는 환경에서 DNS 설정을 확인하는 데 유용하다.

명령어가 없거나 서비스가 사용되지 않는 환경에서는 다른 방식으로 DNS 설정을 확인해야 한다.

10. nslookup과 dig 사용법

DNS를 분석할 때 자주 사용하는 도구가 nslookup과 dig다.

두 도구 모두 DNS 질의를 수행할 수 있지만, dig는 상세한 응답과 질의 정보를 확인하기에 특히 유용하다.

10-1. nslookup

nslookup www.example.com

특정 DNS 서버를 지정할 수도 있다.

nslookup www.example.com 192.168.10.53

이를 통해 기본 DNS 서버의 결과와 특정 DNS 서버의 결과를 비교할 수 있다.

10-2. dig 기본 조회

dig www.example.com

주요 응답 영역은 다음과 같다.

QUESTION SECTION
ANSWER SECTION
AUTHORITY SECTION
ADDITIONAL SECTION

각 영역은 다음과 같은 정보를 담을 수 있다.

영역의미QUESTION조회한 이름과 레코드 종류ANSWER질의에 대한 답변AUTHORITY권한 있는 서버 관련 정보ADDITIONAL추가로 제공되는 관련 정보

10-3. A 레코드만 조회

dig A www.example.com

10-4. AAAA 레코드 조회

dig AAAA www.example.com

10-5. MX 레코드 조회

dig MX example.com

10-6. 특정 DNS 서버에 직접 질의

dig @192.168.10.53 www.example.com

이 명령어는 지정한 DNS 서버에 질의한다.

운영체제의 기본 DNS 서버 설정을 통하지 않고 특정 DNS 서버의 응답을 비교할 때 유용하다.

10-7. TCP로 DNS 질의

dig +tcp @192.168.10.53 www.example.com

UDP 질의와 TCP 질의의 결과를 비교하면 TCP 53번 통신 문제를 확인하는 데 도움이 된다.

10-8. DNS 조회 시간 확인

dig www.example.com

출력 마지막 부분에서 다음 항목을 확인할 수 있다.

;; Query time: 12 msec

조회 시간이 평소보다 크게 증가했다면 DNS 서버 응답 지연, 네트워크 지연, 재시도 등의 가능성을 확인해야 한다.

단, 한 번의 측정만으로 원인을 확정하지 말고 여러 차례 결과를 비교하는 것이 좋다.

11. tcpdump로 DNS 패킷 분석하기

dig는 DNS 조회 결과를 보여준다.

반면 tcpdump는 실제 네트워크 인터페이스에서 관찰되는 DNS 패킷을 보여준다.

DNS 조회가 실패할 때 요청이 전송되는지, 응답이 돌아오는지 확인하는 데 유용하다.

11-1. UDP 53번 패킷 확인

tcpdump -nn -i ens160 udp port 53

예를 들어 다음과 같은 패킷을 관찰할 수 있다.

192.168.10.50.53000 > 192.168.10.53.53: UDP
192.168.10.53.53 > 192.168.10.50.53000: UDP

첫 번째는 클라이언트에서 DNS 서버로 가는 요청이고, 두 번째는 DNS 서버에서 클라이언트로 돌아오는 응답일 수 있다.

단, UDP 패킷이 보인다는 사실만으로 DNS 응답 내용이 올바르다고 판단할 수는 없다.

11-2. TCP 53번 패킷 확인

tcpdump -nn -i ens160 tcp port 53

DNS TCP 연결의 SYN, SYN-ACK, ACK와 DNS 데이터 흐름을 확인할 수 있다.

11-3. UDP와 TCP DNS를 동시에 확인

tcpdump -nn -i ens160 'port 53'

11-4. 특정 DNS 서버와 통신 확인

tcpdump -nn -i ens160 host 192.168.10.53 and port 53

11-5. 패킷을 파일로 저장

tcpdump -nn -i ens160 -s 0 -w /tmp/dns-capture.pcap 'port 53'

저장한 파일을 다시 확인한다.

tcpdump -nn -r /tmp/dns-capture.pcap

패킷 분석 도구가 있다면 PCAP 파일을 Wireshark로 열어 DNS Transaction ID, Query Name, Query Type, Response Code 등을 확인할 수 있다.

운영 환경에서는 필요한 시간과 범위만 캡처하고, 패킷 파일에 민감한 정보가 포함될 수 있음을 고려해야 한다.

12. 실제 장애 사례 1 — IP 접속은 되지만 도메인 접속이 안 된다

상황:

IP 접속
정상

도메인 접속
실패

예를 들어 다음 접속은 정상이다.

curl -v --connect-timeout 5 http://192.168.10.100/

하지만 다음 접속은 실패한다.

curl -v --connect-timeout 5 http://app.internal.example.com/

이 경우 먼저 DNS 조회를 확인한다.

dig app.internal.example.com

그리고 기본 DNS 서버가 아닌 특정 DNS 서버에도 질의한다.

dig @192.168.10.53 app.internal.example.com

가능한 원인은 다음과 같다.

A 레코드가 없음
잘못된 IP 주소가 등록됨
잘못된 DNS 서버를 사용함
내부 DNS 영역이 설정되지 않음
DNS 질의가 방화벽에서 차단됨
캐시에 이전 레코드가 남아 있음

다음과 같이 분석 범위를 나눈다.

IP 접속 성공
     |
     v
네트워크 경로는 일단 동작
     |
     v
DNS 조회 결과 확인
     |
     +-- 올바른 IP가 반환됨
     |       |
     |       v
     |   HTTP/TLS/가상 호스트 등 점검
     |
     +-- 조회 실패 또는 잘못된 IP
             |
             v
         DNS 설정 및 레코드 점검

주의할 점은 IP 접속 성공만으로 DNS 외의 모든 네트워크 문제가 없다고 단정할 수는 없다는 것이다. 도메인 접속 시에는 다른 IP가 반환되거나 IPv6 경로가 선택될 수도 있다.

13. 실제 장애 사례 2 — DNS 조회가 타임아웃된다

상황:

dig www.example.com

을 실행했는데 응답이 오지 않는다.

먼저 기본 DNS 서버를 확인한다.

cat /etc/resolv.conf

예:

nameserver 192.168.10.53

이어서 해당 DNS 서버에 직접 질의한다.

dig @192.168.10.53 www.example.com

그다음 패킷을 캡처한다.

tcpdump -nn -i ens160 'host 192.168.10.53 and port 53'

패킷 분석

상황 A: 요청 자체가 보이지 않는다

Client
  |
  | DNS Query가 캡처되지 않음
  v
DNS Server

이 경우 명령어 실행 여부, 실제 DNS 질의 경로, 인터페이스 선택, 로컬 Resolver 구성 등을 확인한다.

캡처한 인터페이스가 실제 송신 인터페이스인지도 확인해야 한다.

상황 B: 요청은 보이지만 응답이 없다

Client → DNS Server
DNS Query

DNS Response 없음

다음 항목을 확인한다.

DNS 서버가 실행 중인가?
DNS 서버가 해당 질의를 처리할 수 있는가?
서버 방화벽이 요청을 차단하는가?
네트워크 ACL이 요청이나 응답을 차단하는가?
응답 패킷이 다른 경로로 나가는가?

상황 C: 응답이 보이지만 클라이언트에서 타임아웃된다

이 경우 다음을 확인한다.

응답 패킷이 클라이언트까지 실제로 도착하는가?
클라이언트 방화벽이 응답을 차단하는가?
DNS Transaction ID와 질의 정보가 일치하는가?
응답이 요청한 DNS 질의에 대한 것인가?

가능하다면 클라이언트와 DNS 서버 양쪽에서 동시에 캡처하면 분석 범위를 줄일 수 있다.

14. 실제 장애 사례 3 — DNS 레코드를 변경했는데 이전 IP가 나온다

상황:

기존 레코드:

app.example.com → 192.168.10.100

변경한 레코드:

app.example.com → 192.168.10.200

그런데 서버에서 계속 이전 IP가 나온다.

먼저 현재 설정된 DNS 서버를 확인한다.

cat /etc/resolv.conf

다음으로 해당 DNS 서버에 직접 질의한다.

dig @192.168.10.53 app.example.com

권한 DNS 서버를 확인하려면 다음 명령어를 사용할 수 있다.

dig NS example.com

도메인의 DNS 계층을 따라가며 조회하려면 다음을 사용한다.

dig +trace app.example.com

dig +trace는 Root부터 권한 DNS 서버까지의 위임 과정을 직접 따라가며 확인하는 데 유용하다. 다만 실행 환경에서 외부 DNS 서버로 직접 질의할 수 있어야 하며, 내부 전용 도메인이나 제한된 네트워크에서는 정상적으로 동작하지 않을 수 있다.

분석 결과는 다음처럼 나눌 수 있다.

권한 DNS 서버
192.168.10.200 반환

재귀 DNS 서버
192.168.10.100 반환

이 경우 재귀 DNS 서버의 캐시를 확인해야 한다.

반대로 권한 DNS 서버에서도 이전 IP를 반환한다면 레코드 변경이 올바르게 적용되었는지, 다른 DNS 영역을 수정한 것은 아닌지, 위임이 올바른지 확인해야 한다.

15. 실제 장애 사례 4 — 특정 서버에서만 DNS가 실패한다

상황:

Server A
DNS 조회 성공

Server B
DNS 조회 실패

두 서버에서 다음 명령어를 실행한다.

cat /etc/resolv.conf
nmcli device show
dig app.internal.example.com

DNS 서버 설정이 다르다면 서로 다른 DNS 서버에 질의하고 있을 수 있다.

예를 들어:

Server A
nameserver 192.168.10.53

Server B
nameserver 8.8.8.8

내부 전용 도메인은 사내 DNS 서버에서만 관리할 수 있다.

이 경우 외부 DNS 서버에서는 해당 도메인을 찾지 못할 수 있다.

다음처럼 비교한다.

dig @192.168.10.53 app.internal.example.com
dig @8.8.8.8 app.internal.example.com

단, 내부 도메인 이름이나 내부 DNS 응답을 외부 DNS 서버에 질의하면 정보가 외부로 전달될 수 있다. 실제 운영 환경에서는 승인된 DNS 서버를 사용하고 내부 도메인 정보 노출에 주의해야 한다.

16. DNS 응답 코드 이해하기

DNS 조회 결과가 반환되더라도 반드시 정상적인 답변이라는 뜻은 아니다.

DNS 응답 코드인 RCODE를 확인해야 한다.

대표적인 응답 코드는 다음과 같다.

응답 코드의미일반적인 점검 방향NOERRORDNS 질의 처리 성공ANSWER에 원하는 레코드가 있는지 확인NXDOMAIN해당 이름이 존재하지 않음도메인 이름과 DNS 영역 확인SERVFAIL서버가 질의를 처리하지 못함권한 서버, DNSSEC, 위임, Resolver 로그 확인REFUSED질의가 거부됨ACL 및 DNS 서버 정책 확인응답 없음패킷 손실이나 서버 무응답 가능Routing, 방화벽, 서버 상태 확인

특히 NOERROR는 질의 처리에 문제가 없다는 뜻이지만, 원하는 A 레코드가 반드시 존재한다는 의미는 아니다.

예를 들어 해당 이름은 존재하지만 요청한 레코드 종류가 없을 수 있다.

이러한 상황은 NODATA라고 부르며, 실제 응답에서는 NOERROR와 빈 ANSWER SECTION으로 나타날 수 있다.

16-1. NXDOMAIN 확인

dig nonexistent.example.com

응답의 status 부분을 확인한다.

예:

;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN

16-2. DNS 서버의 상세 정보 확인

dig +comments +stats www.example.com

응답 코드, 플래그, 질의 시간 등을 확인할 수 있다.

17. DNSSEC와 SERVFAIL

DNSSEC는 DNS 응답의 진위와 무결성을 검증할 수 있도록 하는 확장 기술이다.

DNSSEC가 적용된 영역에서는 서명 및 검증 정보가 올바르게 구성되어야 한다.

서명 만료, 잘못된 DS 레코드, 위임 설정 문제 등으로 DNSSEC 검증이 실패하면 검증을 수행하는 Resolver가 SERVFAIL을 반환할 수 있다.

이 경우 단순히 A 레코드만 확인해서는 원인을 찾기 어렵다.

다음과 같이 확인할 수 있다.

dig www.example.com

DNSSEC 검증을 수행하지 않는 조회와 비교할 때는 다음 명령어를 사용할 수 있다.

dig +cd www.example.com

+cd는 Checking Disabled 비트를 설정해 Resolver의 DNSSEC 검증 동작을 비교하는 데 사용된다.

단, 이 결과만으로 DNSSEC가 장애 원인이라고 확정해서는 안 된다. 실제 DNSSEC 설정과 검증 경로를 추가로 확인해야 한다.

운영 환경에서 DNSSEC 검증을 무조건 비활성화하는 것은 해결책이 아니다.

18. DNS 장애 분석 전체 흐름

실제 운영에서는 다음 순서로 접근하면 효율적이다.

1. 도메인 이름 확인
        |
        v
2. 현재 DNS 서버 확인
   cat /etc/resolv.conf
        |
        v
3. 기본 DNS 조회
   dig app.example.com
        |
        v
4. 특정 DNS 서버 직접 조회
   dig @DNS_IP app.example.com
        |
        v
5. 응답 코드 및 레코드 확인
   NOERROR / NXDOMAIN / SERVFAIL
        |
        v
6. DNS 패킷 확인
   tcpdump -nn -i ens160 port 53
        |
        v
7. 권한 DNS 서버와 위임 확인
   dig NS example.com
   dig +trace app.example.com
        |
        v
8. TTL과 캐시 확인
        |
        v
9. 애플리케이션 연결 확인
   curl / nc / ss

이 순서로 분석하면 DNS 문제와 애플리케이션 연결 문제를 구분하기 쉬워진다.

19. 시스템 엔지니어를 위한 실습

실제 Linux 서버에서 다음 실습을 수행해 보자.

실습 1. DNS 서버 설정 확인

cat /etc/resolv.conf

사용 중인 DNS 서버를 기록한다.

실습 2. A 레코드 조회

dig A example.com

응답 IP 주소와 TTL을 확인한다.

실습 3. AAAA 레코드 조회

dig AAAA example.com

IPv6 레코드가 존재하는지 확인한다.

실습 4. 특정 DNS 서버에 질의

dig @1.1.1.1 example.com

이 명령어는 Cloudflare의 공개 DNS Resolver를 대상으로 하는 예시다. 운영 환경이나 폐쇄망에서는 외부 DNS 통신이 차단될 수 있으므로 접근 가능한 DNS 서버로 변경한다.

실습 5. DNS 패킷 확인

터미널 1:

tcpdump -nn -i ens160 'port 53'

터미널 2:

dig @192.168.10.53 example.com

터미널 1에서 DNS Query와 Response가 관찰되는지 확인한다.

주의할 점은 로컬 캐시나 Resolver 구성에 따라 실제 패킷이 예상한 인터페이스에서 보이지 않을 수 있다는 것이다. 또한 dig @DNS_IP는 지정한 DNS 서버에 직접 질의하므로 기본 Resolver를 통한 조회와는 경로가 다를 수 있다.

실습 6. TCP DNS 조회

dig +tcp @192.168.10.53 example.com

UDP 질의와 TCP 질의가 모두 가능한지 비교한다.

실습 7. 조회 경로 확인

dig +trace example.com

DNS 계층 구조와 위임 정보를 확인한다.

외부 DNS 서버에 직접 접근할 수 없는 환경에서는 이 실습이 실패할 수 있다.

20. DNS 장애 분석 시 반드시 기억할 점

DNS 장애를 분석할 때는 다음 항목을 구분해야 한다.

첫째, DNS 서버에 도달할 수 없는 문제와 DNS 응답 내용이 잘못된 문제는 다르다.

요청이 전송되지 않는지, 요청은 도착하지만 응답이 없는지, 응답은 있지만 NXDOMAIN이나 SERVFAIL이 반환되는지 구분해야 한다.

둘째, 권한 DNS 서버의 레코드와 재귀 DNS 서버의 캐시 결과는 다를 수 있다.

레코드를 변경한 후 이전 IP가 계속 나온다면 권한 DNS 서버와 재귀 DNS 서버를 각각 확인한다.

셋째, DNS 조회가 성공해도 서비스 접속까지 성공한다는 보장은 없다.

DNS 조회 결과가 올바른 IP를 반환하더라도 TCP Port, 방화벽, TLS 인증서, 웹 서버 설정 등의 문제로 접속이 실패할 수 있다.

넷째, UDP 53번뿐 아니라 TCP 53번도 고려해야 한다.

일반적인 DNS 조회는 UDP를 사용하는 경우가 많지만, 일부 상황에서는 TCP가 필요하다.

다섯째, 내부 DNS와 외부 DNS의 차이를 이해해야 한다.

기업 환경에서는 내부 전용 도메인과 외부 공개 도메인을 분리해서 운영할 수 있다. 서버마다 다른 DNS 서버를 사용하면 같은 도메인의 조회 결과가 다를 수 있다.

마무리

DNS는 단순히 도메인을 IP 주소로 바꾸는 기능이 아니다.

Root DNS, TLD DNS, Authoritative DNS, Recursive Resolver, Cache, TTL이 서로 연결되어 동작하는 분산 시스템이다.

시스템 엔지니어는 DNS 장애가 발생했을 때 다음 질문에 답할 수 있어야 한다.

어떤 DNS 서버에 질의하고 있는가?

DNS 요청 패킷이 실제로 전송되는가?

DNS 서버가 응답하고 있는가?

응답 코드는 NOERROR인가, NXDOMAIN인가, SERVFAIL인가?

응답한 IP 주소가 올바른가?

권한 DNS 서버와 재귀 DNS 서버의 결과가 다른가?

DNS 조회는 성공했는데 TCP 연결이 실패하는가?

이 질문들을 차례대로 확인하면 DNS 문제와 네트워크 문제, 애플리케이션 문제를 분리할 수 있다.

특히 다음 명령어는 반드시 익혀 두자.

# DNS 서버 설정
cat /etc/resolv.conf

# 기본 DNS 조회
dig example.com

# 특정 DNS 서버 조회
dig @192.168.10.53 example.com

# DNS 계층 구조 확인
dig +trace example.com

# TCP 기반 DNS 조회
dig +tcp @192.168.10.53 example.com

# DNS 패킷 확인
tcpdump -nn -i ens160 'port 53'

다음 편에서는 DNS와 함께 네트워크 자동 설정의 핵심인 DHCP 동작 원리와 IP 주소 할당 과정을 살펴본다.

DHCP Discover, Offer, Request, ACK의 DORA 과정부터 DHCP 서버와 클라이언트의 역할, IP 주소 임대(Lease), DHCP Relay, Linux에서의 장애 분석, tcpdump를 이용한 실제 DHCP 패킷 확인까지 학습한다.

다음 편인 **「시스템 엔지니어를 위한 네트워크 12편 — DHCP 동작 원리와 IP 주소 자동 할당, DORA 패킷 분석」**으로 이어가면 됩니다.

아직 댓글이 없습니다.

로그인 후 댓글을 남길 수 있습니다.