70. DNS 레코드와 질의 유형

📚 네트워크 · 패킷 분석 › 02. 포트 · 프로토콜 분석 — 70편
이전 글: 69. IMAP · 다음 글: 71. DHCP 위장·고갈 공격의 원리와 탐지
참고(01. TCP/IP 구조 이해): 47. DNS 이름 해석 흐름 — 도메인이 IP가 되기까지 — 재귀·반복 질의와 캐시 흐름은 이 글에서 다룸

1. 왜 알아야 하는가

거의 모든 통신은 DNS 질의로 시작합니다. 앞 글에서 본 것처럼 HTTPS 내용은 암호화되어 있어도, DNS 질의 로그는 "어떤 단말이 어떤 도메인을 찾았는가" 를 알려주는 중요한 단서입니다.

그런데 DNS 로그에는 도메인 이름만 있는 것이 아닙니다.

• 질의 유형(레코드 타입): A를 찾았는가, TXT를 찾았는가, PTR을 찾았는가
• 응답 코드: 이름이 있었는가(NOERROR), 없었는가(NXDOMAIN), 서버가 실패했는가(SERVFAIL)
• 응답 값과 TTL: 어떤 IP로 해석되었고 얼마나 캐시되는가

이 값들의 정상 범위를 알아야 다음 글에서 다룰 DNS 터널링·DGA 같은 악용을 구분할 수 있습니다. 이름 해석의 전체 흐름(재귀·반복 질의, 캐시)은 14. DNS 이름 해석 흐름에서 다뤘으므로 여기서는 레코드와 응답의 의미에 집중합니다.

---

2. 핵심 개념

그림 1. 레코드 유형별로 이름이 가리키는 대상이 다릅니다

2-1. 주요 레코드 타입

타입	의미	예	관제 포인트
A	도메인 → IPv4	www.example.com → 203.0.113.10	가장 흔한 질의
AAAA	도메인 → IPv6	→ 2001:db8::10	IPv6 관제 누락 주의 (13. IPv6 기초)
CNAME	별칭 → 정식 이름	www → web.cdn.example.net	CDN·클라우드 연결 추적
MX	메일 수신 서버	10 mail.example.com	메일 서버가 아닌 단말의 MX 질의는 드묾
NS	도메인의 권한 네임서버	ns1.example.com	도메인 관리 주체 확인
SOA	영역(zone) 관리 정보	주 네임서버, 일련번호, 갱신 주기	영역 설정 확인
PTR	IP → 도메인 (역방향)	10.113.0.203.in-addr.arpa → www.example.com	서버·로그 시스템이 자동으로 많이 질의
TXT	임의 텍스트	SPF, 도메인 소유 확인 값	긴 데이터를 담을 수 있어 악용 통로가 되기도 함
SRV	서비스 위치(호스트·포트)	_ldap._tcp.example.com	Active Directory 환경에서 흔함
CAA	인증서 발급 허용 CA	0 issue "ca.example"	인증서 오발급 방지 설정
HTTPS / SVCB	서비스 접속 정보(프로토콜, ECH 설정 등)		최신 브라우저가 A/AAAA와 함께 질의

2-2. 응답 코드(RCODE)

RCODE	의미	일반적 원인
NOERROR	정상 처리	이름이 존재 (답이 0개인 NOERROR도 있음: 이름은 있으나 해당 타입 레코드가 없음)
NXDOMAIN	이름이 존재하지 않음	오타, 삭제된 도메인, 무작위로 생성된 도메인
SERVFAIL	서버가 답을 만들지 못함	권한 서버 장애, DNSSEC 검증 실패
REFUSED	정책상 거부	허용되지 않은 클라이언트의 재귀 질의, 존 전송 거부

2-3. DNS 메시지에서 관제가 보는 값

값	의미	관제 포인트
질의 이름(QNAME)	찾는 도메인	길이·문자 구성·상위 도메인
질의 타입(QTYPE)	찾는 레코드 종류	타입별 비율
RCODE	결과	NXDOMAIN 비율
응답 레코드와 TTL	해석 결과·캐시 시간	매우 짧은 TTL + 자주 바뀌는 IP
플래그(QR·AA·RD·RA 등)	질의/응답, 권한 응답 여부, 재귀 요청·가능	필드 해석은 03. Wireshark 패킷 분석 시리즈에서 다룸

---

3. 동작 원리

CNAME이 섞인 일반적인 질의 결과는 다음처럼 여러 레코드가 연결된 사슬로 돌아옵니다.

[클라이언트] "www.example.com 의 A 레코드는?"  (QTYPE=A)
      ↓ 내부 DNS(리졸버, 192.168.10.1)
      ↓ 캐시 없음 → 권한 서버에 질의 (net-14 참고)
[응답]
  www.example.com.      300  IN CNAME  web.cdn.example.net.
  web.cdn.example.net.   60  IN A      203.0.113.10
      ↓
[클라이언트] 최종 IP 203.0.113.10 으로 TCP 연결
      ↓
[관제 관점] DNS 로그: 질의 이름 www.example.com / 응답 IP 203.0.113.10
            방화벽 로그: 목적지 203.0.113.10 만 남음
            → 두 로그를 IP·시간으로 연결해야 "어느 도메인 접속"인지 알 수 있음

역방향(PTR) 질의는 IP를 뒤집어 in-addr.arpa 아래 이름으로 묻습니다. 203.0.113.10의 PTR 질의 이름은 10.113.0.203.in-addr.arpa입니다. PTR 값은 IP 소유자가 설정하는 것이므로 정방향(A) 레코드와 일치한다는 보장이 없습니다.

---

4. 실제 명령어 / 실습

실습 환경: 본인 소유 Linux VM (Rocky Linux 또는 Ubuntu). 인터페이스 이름은 ens33을 예시로 사용합니다.

도구 설치:

# Rocky Linux
sudo dnf install -y bind-utils tcpdump
# Ubuntu
sudo apt install -y dnsutils tcpdump

4-1. VM이 사용하는 DNS 서버 확인

배포판	확인 방법	비고
Rocky Linux	cat /etc/resolv.conf, nmcli -g IP4.DNS device show ens33	NetworkManager가 resolv.conf 관리
Ubuntu	resolvectl status	resolv.conf에는 로컬 스텁 127.0.0.53이 보임

4-2. 레코드 타입별 질의

dig example.com A +noall +answer
dig example.com AAAA +noall +answer
dig www.example.com +noall +answer     # CNAME 사슬이 있으면 함께 표시
dig example.com MX +short
dig example.com NS +short
dig example.com TXT +short
dig example.com SOA +short
dig -x 1.1.1.1 +short                  # 역방향(PTR) 질의

4-3. 응답 코드 확인

dig example.com | grep status
dig no-such-name.example.com | grep status     # 존재하지 않는 이름 → NXDOMAIN

📷 [실습 화면 삽입] 타입별 dig 결과와 NOERROR / NXDOMAIN 상태가 보이는 화면

4-4. 네트워크에서 질의 타입과 응답 확인

# 터미널 1
sudo tcpdump -ni ens33 -l 'port 53'
# 터미널 2
dig example.com MX
dig no-such-name.example.com

---

5. 결과 확인

형식 예시(값은 환경마다 다름):

$ dig example.com | grep status
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 41234

$ dig no-such-name.example.com | grep status
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 5120

$ dig www.example.com +noall +answer
www.example.com.      300  IN  CNAME  web.cdn.example.net.
web.cdn.example.net.   60  IN  A      203.0.113.10

# tcpdump
IP 192.168.10.20.53211 > 192.168.10.1.53: 4412+ MX? example.com. (29)
IP 192.168.10.1.53 > 192.168.10.20.53211: 4412 1/0/1 MX mail.example.com. 10 (60)
IP 192.168.10.20.40920 > 192.168.10.1.53: 9981+ A? no-such-name.example.com. (42)
IP 192.168.10.1.53 > 192.168.10.20.40920: 9981 NXDomain 0/1/1 (103)

tcpdump 표기	의미
MX?, A?	질의 타입
+	재귀 요청(RD) 플래그가 설정된 질의
1/0/1	응답·권한·추가 섹션의 레코드 수
NXDomain	응답 코드 NXDOMAIN

• VM이 사용하는 DNS 서버를 배포판에 맞게 확인했다
• A·AAAA·CNAME·MX·NS·TXT·PTR 질의 결과를 확인했다
• NOERROR와 NXDOMAIN을 구분했다
• tcpdump에서 질의 타입과 응답 코드를 읽었다

📷 [실습 화면 삽입] tcpdump에 MX? 질의와 NXDomain 응답이 보이는 화면

---

6. 패킷 / 로그 분석

DNS 서버의 질의 로그는 기본으로 꺼져 있는 경우가 많습니다. BIND는 rndc querylog on으로 켤 수 있고, 네트워크 센서(Zeek의 dns.log 등)는 질의·타입·응답 코드·응답 값을 함께 기록합니다. BIND 질의 로그 형식 예시(버전에 따라 다름):

client @0x7f... 192.168.10.30#53422 (www.example.com): query: www.example.com IN A +E(0)K (192.168.10.1)

관찰	정상일 수 있는 경우	의심해야 하는 경우
NXDOMAIN 비율 증가	오타, 삭제된 도메인, 잘못된 설정의 프로그램	한 단말에서 무작위 형태 도메인의 NXDOMAIN 다수 (08편 DGA)
TXT 질의	메일 서버의 SPF 확인, 도메인 인증	일반 PC가 한 도메인의 서로 다른 하위 이름으로 TXT 반복 질의
PTR 질의 다수	로그 서버·메일 서버의 역방향 조회	일반 단말이 내부 IP 대역 전체를 순서대로 역조회 (내부 정보 수집)
AXFR(존 전송) 요청	주 서버 ↔ 보조 서버 간 동기화	허가되지 않은 IP의 존 전송 요청 (REFUSED 로그 확인)
매우 짧은 TTL + 응답 IP가 자주 바뀜	CDN·로드밸런싱	평판이 낮은 도메인에서 같은 패턴 (08편 Fast Flux)
외부 DNS로 직접 질의	정책상 허용된 경우	내부 리졸버를 거치지 않는 53번 직접 통신 (08편)

---

7. 보안관제 관점

위치	남는 정보	한계
내부 DNS 서버 질의 로그	단말 IP, 질의 이름·타입	기본 비활성인 경우 많음, 로그량 큼
네트워크 센서 (Zeek, Suricata)	질의·응답·RCODE·TTL	센서가 보는 구간만
방화벽	53번 통신 5-tuple	질의 이름 없음
단말 (EDR, Windows DNS Client 이벤트 등)	어떤 프로세스가 질의했는지	수집 설정 필요

한계와 오탐 주의

• 단말이 캐시를 쓰면 같은 도메인을 다시 질의하지 않으므로, DNS 로그에 없는 접속도 있습니다.
• 내부 DNS 서버 로그에서는 출발지가 단말이지만, 외부 구간에서는 리졸버 IP로만 보입니다. 어느 위치의 로그인지 먼저 확인합니다.
• DoH(DNS over HTTPS)·DoT(DNS over TLS)를 쓰는 단말은 기존 53번 DNS 로그에 남지 않습니다(08. DNS 악용 유형에서 다룸).
• NXDOMAIN은 설정 오류로도 대량 발생합니다. 도메인 형태와 단말 범위를 함께 봅니다.

---

8. 핵심 정리

• DNS 로그의 핵심 값은 질의 이름·질의 타입·응답 코드·응답 값·TTL입니다.
• A·AAAA·CNAME은 접속 대상, MX·NS·SOA는 도메인 구조, PTR은 역방향 조회, TXT는 임의 데이터를 담습니다.
• NOERROR·NXDOMAIN·SERVFAIL·REFUSED의 비율 변화가 이상 탐지의 기준이 됩니다.
• 방화벽 로그에는 IP만 남으므로, DNS 로그와 시간·IP로 연결해야 "어느 도메인 접속"인지 알 수 있습니다.
• 질의 로그는 기본으로 꺼져 있는 경우가 많고, DoH·캐시로 누락될 수 있다는 한계를 전제로 분석합니다.

다음 글: 08. DNS 악용 유형 — 터널링·DGA·비정상 질의 탐지