today keys : dns, question,answer, authority, additional, resource record, ttl, referral, glube, nxdomain, section
1. 한눈에 보기 — dig 결과 하나로 보는 네 섹션
DNS 메시지는 헤더 뒤에 네 섹션이 이어집니다. Question은 고유한 형식을 쓰고, 나머지 Answer·Authority·Additional은 모두 같은 리소스 레코드(RR) 형식을 씁니다. 세 섹션의 차이는 형식이 아니라 담는 레코드의 역할입니다.
아래는 BIND 개발사인 ISC의 권한 서버 ns1.isc.org에 isc.org의 A 레코드를 비재귀(+norec)로 물은 결과입니다. 여기서는 출력의 어느 부분이 어떤 섹션인지만 먼저 확인합니다.
$ dig @ns1.isc.org isc.org A +norec
; <<>> DiG 9.18.39-0ubuntu0.24.04.5-Ubuntu <<>> @ns1.isc.org isc.org A +norec
; (2 servers found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 58496 ← [헤더]
;; flags: qr aa; QUERY: 1, ANSWER: 4, AUTHORITY: 5, ADDITIONAL: 7 ← [헤더] COUNT 4개
;; OPT PSEUDOSECTION: ← [Additional] OPT
; EDNS: version: 0, flags:; udp: 1232
; COOKIE: 30c394c65b8941dc010000006abae8fb5df2fc4b4d317390 (good)
;; QUESTION SECTION: ← [Question]
;isc.org. IN A
;; ANSWER SECTION: ← [Answer]
isc.org. 300 IN A 151.101.195.42
isc.org. 300 IN A 151.101.67.42
isc.org. 300 IN A 151.101.3.42
isc.org. 300 IN A 151.101.131.42
;; AUTHORITY SECTION: ← [Authority]
isc.org. 7200 IN NS ns1.isc.org.
isc.org. 7200 IN NS ns3.isc.org.
isc.org. 7200 IN NS nsp.dnsnode.net.
isc.org. 7200 IN NS ns.isc.afilias-nst.info.
isc.org. 7200 IN NS ns2.isc.org.
;; ADDITIONAL SECTION: ← [Additional]
ns1.isc.org. 7200 IN A 149.20.2.26
ns2.isc.org. 7200 IN A 199.6.1.52
ns3.isc.org. 7200 IN A 51.75.79.143
ns1.isc.org. 7200 IN AAAA 2001:500:6b:2::26
ns2.isc.org. 7200 IN AAAA 2001:500:60:d::52
ns3.isc.org. 7200 IN AAAA 2001:41d0:701:1100::2c92
;; Query time: 148 msec
;; SERVER: 149.20.2.26#53(ns1.isc.org) (UDP)
;; WHEN: Tue Sep 29 07:23:56 KST 2026
;; MSG SIZE rcvd: 380| 섹션 | dig 출력 위치 | 내용 |
| Question | QUESTION SECTION |
무엇을 물었는가 |
| Answer | ANSWER SECTION |
질문에 대한 답 |
| Authority | AUTHORITY SECTION |
이 이름에 대한 권한 정보 |
| Additional | ADDITIONAL SECTION, OPT PSEUDOSECTION |
앞 섹션에 나온 이름의 주소, 확장 정보(OPT) |
4개의 섹션을 하나씩 살펴봅니다.
2. Question 섹션
1장의 예시에서 QUESTION SECTION 아래의 한 줄이 Question 섹션입니다. 패킷 안에서는 다음 세 필드로 구성됩니다.
| 필드 | 크기 | 내용 |
| QNAME | 가변 | 질의 이름 |
| QTYPE | 16비트 | 요청하는 레코드 타입 (A, AAAA, NS 등) |
| QCLASS | 16비트 | 거의 항상 1 (IN, Internet) |
dig로 보는 Question 섹션
;; QUESTION SECTION:
;isc.org. IN A- 줄 맨 앞의
;는 dig가 "이 줄은 레코드가 아니다"라는 뜻으로 붙인 주석 표시입니다. Question에는 TTL도 RDATA도 없기 때문입니다. - 이름 끝의
.이 라벨 형식의 마지막 0, 즉 루트입니다. IN이 QCLASS,A가 QTYPE입니다.- 응답 메시지는 이 Question을 그대로 복사해서 돌려줍니다. 그래서 응답만 캡처해도 무엇을 물었는지 알 수 있습니다.
3. Answer 섹션
Answer 섹션은 질문에 대한 답 레코드를 담습니다. Answer·Authority·Additional은 모두 같은 리소스 레코드(RR) 형식을 쓰므로, 이 장에서 RR 형식을 먼저 정리하고 Answer를 읽는 법을 봅니다. 여기서 익힌 형식은 4장과 5장에서도 그대로 쓰입니다.
3.1 리소스 레코드(RR) 형식
1장 예시의 ANSWER, AUTHORITY, ADDITIONAL 섹션에 있는 각 줄이 리소스 레코드입니다. 패킷 안에서는 모두 아래 형식입니다.
| 필드 | 크기 | 내용 |
| NAME | 가변 | 레코드 이름 |
| TYPE | 16비트 | 레코드 타입 |
| CLASS | 16비트 | 1 (IN) |
| TTL | 32비트 | 캐시 가능 시간(초) |
| RDLENGTH | 16비트 | RDATA 길이 |
| RDATA | 가변 | 실제 값 (IP 주소, NS 이름, SOA 필드 등) |
dig 출력 한 줄과 RR 필드의 대응
isc.org. 300 IN A 151.101.195.42
└ NAME ┘ └TTL┘ └CLASS┘ └TYPE┘ └─── RDATA ───┘dig는 NAME, TTL, CLASS, TYPE, RDATA 순서로 출력합니다. 실제 패킷 안의 순서(NAME, TYPE, CLASS, TTL, RDLENGTH, RDATA)와는 다르다는 점만 기억해 두면 됩니다. RDLENGTH는 dig 출력에 나타나지 않습니다.
같은 형식에 RDATA만 달라집니다. 1장 예시에서 Answer의 A 레코드는 RDATA가 IP 주소이고, Authority의 NS 레코드는 RDATA가 네임서버 이름입니다. RDATA에 무엇이 들어가는지는 TYPE이 정합니다.
자주 보는 타입 코드
| Type | 값 | 용도 | Type | 값 | 용도 |
| A | 1 | IPv4 주소 | SRV | 33 | 서비스 위치 |
| NS | 2 | 네임서버 | OPT | 41 | EDNS 가상 레코드 |
| CNAME | 5 | 별칭 | DS | 43 | DNSSEC 위임 서명자 |
| SOA | 6 | 존 권한 정보 | RRSIG | 46 | DNSSEC 서명 |
| PTR | 12 | 역방향 | DNSKEY | 48 | DNSSEC 공개키 |
| MX | 15 | 메일 서버 | NSEC3 | 50 | DNSSEC 부재 증명 |
| TXT | 16 | 텍스트 | HTTPS | 65 | HTTPS 서비스 바인딩 |
| AAAA | 28 | IPv6 주소 | AXFR | 252 | 존 전송 (QTYPE 전용) |
3.2 Answer 섹션 읽기
Answer에 요청한 레코드가 들어 있고, 권한 서버가 aa로 답했다면 정상 답입니다. 1장의 결과가 바로 이 경우입니다.
$ dig @ns1.isc.org isc.org A +norec
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 58496
;; flags: qr aa; QUERY: 1, ANSWER: 4, AUTHORITY: 5, ADDITIONAL: 7
;; ANSWER SECTION:
isc.org. 300 IN A 151.101.195.42
isc.org. 300 IN A 151.101.67.42
isc.org. 300 IN A 151.101.3.42
isc.org. 300 IN A 151.101.131.42- Answer의 레코드 이름은 질문한 이름과 같습니다. 물은 이름(isc.org)에 대한 답이기 때문입니다. 질문한 이름이 별칭(CNAME)이라면 Answer에 CNAME과 그 대상의 레코드가 함께 옵니다.
- A 레코드 4개는 하나의 묶음입니다. 이름·타입·클래스가 같은 레코드 묶음을 RRset이라고 하며, 답은 항상 RRset 단위로 옵니다. 서버가 순서를 돌려 가며 주는 경우가 많아서 RRset 안의 순서에는 의미를 두지 않습니다.
- flags의 aa와 status NOERROR가 권한 서버의 정상 답임을 보여 줍니다. 같은 질의를 리졸버에 하면 flags가 qr rd ra로 바뀌고 aa가 사라집니다. 답은 같지만 리졸버는 권한 서버가 아니기 때문입니다.
4. Authority 섹션
Authority 섹션은 이 이름에 대한 권한 정보를 담습니다. 들어가는 레코드는 크게 두 종류입니다.
NS는 "이 존의 권한자가 누구인가"를, SOA는 "이 존에는 그런 데이터가 없다"는 근거를 알려 줍니다.
| 응답 | Authority 내용 | 본 포스팅 관련 위치 |
| 정상 답 | 존의 NS (생략될 수 있음) | 4.1 |
| Referral | 하위 존의 NS | 4.2 |
| NXDOMAIN | SOA | 4.3 |
| NODATA | SOA | 4.4 |
네 경우 모두 isc.org 질의로 확인합니다. 모두 +norec(RD=0)로 직접 질의한 결과입니다.
| 본 포스팅 관련 위치 | 누구에게 | 무엇을 |
| 4.1 | isc.org의 권한 서버 (ns1.isc.org) | isc.org A |
| 4.2 | 상위 존 .org의 서버 | isc.org A |
| 4.3 | isc.org의 권한 서버 | 없는 이름 (zigi.isc.org) A |
| 4.4 | isc.org의 권한 서버 | 있는 이름, 없는 타입 (isc.org PTR) |
4.1 정상 답의 Authority — 존의 NS
1장 결과의 Authority 섹션입니다.
;; AUTHORITY SECTION:
isc.org. 7200 IN NS ns1.isc.org.
isc.org. 7200 IN NS ns3.isc.org.
isc.org. 7200 IN NS nsp.dnsnode.net.
isc.org. 7200 IN NS ns.isc.afilias-nst.info.
isc.org. 7200 IN NS ns2.isc.org.- 답(Answer)과 함께 "이 존의 권한 서버는 이 다섯 대"라는 정보를 준 것입니다.
aa응답에 담긴 NS이므로 isc.org 존이 직접 선언한 원본입니다. - 레코드 이름은 존 이름(
isc.org.)입니다. 여기서는 질문한 이름이 존의 꼭대기(apex)라서 Answer와 이름이 같지만,www.isc.org를 물었다면 Answer는www.isc.org., Authority는 여전히isc.org.가 됩니다. - 정상 답에서 Authority는 없어도 되는 부가 정보입니다. 서버 설정(minimal responses)에 따라 비어 있을 수 있고, 그래도 정상 답인 것은 같습니다.
4.2 Referral — 하위 존의 NS
같은 질문을 isc.org의 권한 서버가 아니라 상위 존 .org의 서버에 합니다.
$ dig org NS +short
d0.org.afilias-nst.org.
b0.org.afilias-nst.org.
...
$ dig @d0.org.afilias-nst.org isc.org A +norec
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 58155
;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 5, ADDITIONAL: 7
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;isc.org. IN A
;; AUTHORITY SECTION:
isc.org. 3600 IN NS nsp.dnsnode.net.
isc.org. 3600 IN NS ns1.isc.org.
isc.org. 3600 IN NS ns2.isc.org.
isc.org. 3600 IN NS ns3.isc.org.
isc.org. 3600 IN NS ns.isc.afilias-nst.info.
;; ADDITIONAL SECTION:
ns1.isc.org. 3600 IN A 149.20.2.26
ns2.isc.org. 3600 IN A 199.6.1.52
ns3.isc.org. 3600 IN A 51.75.79.143
ns1.isc.org. 3600 IN AAAA 2001:500:6b:2::26
ns2.isc.org. 3600 IN AAAA 2001:500:60:d::52
ns3.isc.org. 3600 IN AAAA 2001:41d0:701:1100::2c92
;; SERVER: 199.19.57.1#53(d0.org.afilias-nst.org) (UDP)
;; MSG SIZE rcvd: 288- flags에
aa가 없고, status는 NOERROR인데 ANSWER가 0개입니다. .org 서버는 isc.org의 A 레코드를 모르므로 "isc.org는 이 서버들에게 물어보라"고 안내한 것입니다. 이것이 referral입니다. - Authority의 NS 5개가 안내의 핵심입니다. 레코드 이름이 질문한 이름을 담당하는 하위 존(isc.org)이고, 값이 그 존의 네임서버입니다.
- 4.1과 목록은 같지만 의미가 다릅니다. 4.1의 NS는 isc.org 권한 서버가 직접 준 원본이고, 여기의 NS는 .org가 위임을 위해 보관하는 사본입니다.
- Additional에 함께 온 NS의 주소(glue)는 5.1에서 다룹니다.
4.3 NXDOMAIN — 이름이 없다는 근거, SOA
isc.org의 권한 서버에 존재하지 않는 이름을 물어봅니다.
$ dig @ns1.isc.org zigi.isc.org A +norec
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 35515
;; flags: qr aa; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1
;; QUESTION SECTION:
;zigi.isc.org. IN A
;; AUTHORITY SECTION:
isc.org. 3600 IN SOA ns-int.isc.org. hostmaster.isc.org. 2026092802 7200 3600 24796800 3600
;; MSG SIZE rcvd: 123- status가 NXDOMAIN이고 flags에
aa가 있습니다. isc.org 존의 권한 서버가 "그런 이름은 없다"고 확정한 답입니다. - AUTHORITY의 SOA는 "없다"는 답의 근거이자, 리졸버가 이 부정 응답을 얼마나 캐시할지의 기준입니다. 캐시 시간은 SOA 레코드의 TTL과 SOA의 마지막 필드(MINIMUM) 중 작은 값입니다(RFC 2308). 여기서는 둘 다 3600이므로 1시간입니다.
4.4 NODATA — 타입이 없다는 근거, SOA
이번에는 존재하는 이름(isc.org)에 없는 타입(PTR)을 물어봅니다.
$ dig @ns1.isc.org isc.org PTR +norec
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 46409
;; flags: qr aa; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1
;; QUESTION SECTION:
;isc.org. IN PTR
;; AUTHORITY SECTION:
isc.org. 3600 IN SOA ns-int.isc.org. hostmaster.isc.org. 2026092802 7200 3600 24796800 3600
;; MSG SIZE rcvd: 118- status가 NOERROR이고 ANSWER가 0개입니다. 여기까지는 referral과 같습니다.
- 차이는 두 가지입니다. flags에 aa가 있고, AUTHORITY에 NS가 아니라 SOA가 있습니다. "이름은 있지만 그 타입의 레코드가 없다"는 뜻입니다.
- 4.3의 NXDOMAIN과 비교하면 status 값만 다르고 섹션 구성은 같습니다.
5. Additional 섹션
Additional 섹션은 받는 쪽이 다음 단계에서 필요로 할 부가 정보를 담습니다. 들어가는 것은 크게 두 가지입니다. 하나는 앞 섹션에 나온 이름의 주소이고, 다른 하나는 레코드가 아닌 확장 정보인 OPT입니다.
5.1 앞 섹션에 나온 이름의 주소 — 부가 주소와 glue
1장(정상 답)과 4.2(referral)의 Additional을 나란히 보면 같은 모양입니다.
# 1장 : isc.org 권한 서버의 정상 답
;; ADDITIONAL SECTION:
ns1.isc.org. 7200 IN A 149.20.2.26
ns2.isc.org. 7200 IN A 199.6.1.52
ns3.isc.org. 7200 IN A 51.75.79.143
ns1.isc.org. 7200 IN AAAA 2001:500:6b:2::26
ns2.isc.org. 7200 IN AAAA 2001:500:60:d::52
ns3.isc.org. 7200 IN AAAA 2001:41d0:701:1100::2c92
# 4.2 : .org 서버의 referral
;; ADDITIONAL SECTION:
ns1.isc.org. 3600 IN A 149.20.2.26
... (같은 6개)- 두 응답 모두 Authority에 나온 NS의 주소를 Additional에 실었습니다. 받는 쪽이 NS 이름만 받고 주소를 다시 조회하지 않아도 되게 하려는 것입니다.
- referral에서 이 주소를 특별히 glue라고 부릅니다. 상위 존이 하위 존의 NS 주소를 대신 보관해 두었다가 위임 안내에 붙여 주는 것입니다. 리졸버는 glue 덕분에 곧바로 다음 서버에 질의할 수 있습니다.
- 두 응답 모두 NS 5개 중 3개의 주소만 있습니다. 서버는 자기 관할(bailiwick) 안에 있는 이름의 주소만 실을 수 있기 때문입니다. ns1~ns3.isc.org는 isc.org 안(따라서 .org 안)의 이름이지만,
nsp.dnsnode.net(.net)과ns.isc.afilias-nst.info(.info)는 다른 도메인이라 주소를 줄 권한이 없습니다. - 주소가 오지 않은 NS에 물으려면 리졸버가 그 주소부터 따로 조회해야 합니다. NS가 모두 이런 경우라면 조회 단계가 크게 늘어납니다. 이 영향은 lame delegation 글에서 실측으로 다룹니다.
- 헤더의 ADDITIONAL 개수에는 이 주소들 외에 OPT 레코드 하나가 더 포함됩니다. 두 응답 모두 주소 6개 + OPT 1개 = 7입니다.
5.2 OPT — EDNS 확장 정보
요즘 DNS 덤프를 보면 질의 패킷인데도 Additional이 1개로 찍혀 있고, Wireshark Info 열 끝에는 OPT가 붙어 있습니다. 이것은 실제 레코드가 아니라 EDNS(0)의 OPT 가상 레코드입니다.
왜 필요한가
원래 DNS 헤더는 12바이트 고정이라 새 기능을 넣을 자리가 없습니다. RCODE는 4비트뿐이고, UDP 응답은 512바이트로 제한되어 있었습니다. 헤더를 늘리면 기존 구현과 호환이 깨지므로, Additional 섹션에 특수한 레코드를 하나 얹어 확장 정보를 나르는 방식을 택했습니다. 이해하지 못하는 구현은 무시하면 되므로 호환성이 유지됩니다.
OPT 레코드의 필드 재해석
OPT는 RR 형식을 빌려 쓰되, 각 필드를 다른 의미로 씁니다.
| RR 필드 | OPT에서의 의미 |
| NAME | 항상 루트 (Wireshark에서 <Root>) |
| TYPE | 41 (OPT) |
| CLASS | UDP 수신 가능 크기 |
| TTL 상위 8비트 | 확장 RCODE (헤더의 4비트와 합쳐 12비트) |
| TTL 다음 8비트 | EDNS 버전 (현재 0) |
| TTL 나머지 16비트 | 플래그. 최상위 비트가 DO |
| RDATA | 옵션 목록 (코드, 길이, 값) |
주요 역할
- UDP 크기 협상: 보낸 쪽이 받을 수 있는 UDP 크기를 알립니다. 이 값 덕분에 512바이트가 넘는 응답도 TCP 재질의 없이 받을 수 있습니다. 구현마다 기본값이 다릅니다. dig와 최근 BIND는 1232(2020년 DNS Flag Day 권고값, IP 단편화 회피 목적), Windows DNS는 4000입니다.
- DO 비트 (DNSSEC OK): "DNSSEC 레코드(RRSIG, NSEC/NSEC3 등)도 함께 보내 달라"는 요청입니다. 같은 질의라도 DO 값에 따라 응답 크기가 크게 달라집니다.
- 확장 RCODE: 16 이상의 응답 코드를 표현합니다.
자주 보는 EDNS 옵션
| 옵션 | 코드 | 용도 |
| NSID | 3 | 응답한 서버의 식별자 (애니캐스트 서버 구분) |
| ECS (Client Subnet) | 8 | 클라이언트 서브넷 정보 전달 (CDN 최적화) |
| COOKIE | 10 | 출발지 위조 방지용 토큰 (dig 기본 사용) |
| Padding | 12 | 암호화 전송 시 길이 은닉 |
| EDE (Extended DNS Error) | 15 | SERVFAIL 등의 상세 원인 전달 |
dig로 보는 OPT
dig는 OPT 레코드를 일반 섹션이 아니라 OPT PSEUDOSECTION으로 따로 보여 줍니다.
1장과 같은 질의에 +dnssec을 붙여 DO=1로 물어보면 응답이 이렇게 달라집니다.
$ dig @ns1.isc.org isc.org A +norec +dnssec
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 13449
;; flags: qr aa; QUERY: 1, ANSWER: 5, AUTHORITY: 6, ADDITIONAL: 13
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 1232
; COOKIE: 68f2a8baff294fc4010000006abaf1e51bb3c40582781744 (good)
;; ANSWER SECTION:
isc.org. 300 IN A 151.101.131.42
... (A 레코드 4개)
isc.org. 300 IN RRSIG A 13 2 300 20261007083945 20260923082238 27566 isc.org. OXvaMtH9...
;; AUTHORITY SECTION:
isc.org. 7200 IN NS ns2.isc.org.
... (NS 5개)
isc.org. 7200 IN RRSIG NS 13 2 7200 20261008165013 20260924163245 27566 isc.org. kROmm8Uc...
;; ADDITIONAL SECTION:
ns1.isc.org. 7200 IN A 149.20.2.26
... (A·AAAA 6개)
ns1.isc.org. 7200 IN RRSIG A 13 3 7200 20261009020228 20260925012508 27566 isc.org. Dy6gNRf2...
... (RRSIG 6개)
;; MSG SIZE rcvd: 1204| 항목 | DO=0 | DO=1 (+dnssec) |
| OPT flags | 없음 | do |
| ANSWER | 4 (A) | 5 (A 4 + RRSIG 1) |
| AUTHORITY | 5 (NS) | 6 (NS 5 + RRSIG 1) |
| ADDITIONAL | 7 (주소 6 + OPT) | 13 (주소 6 + RRSIG 6 + OPT) |
| 응답 크기 | 380바이트 | 1204바이트 |
flags: do: DO 비트가 켜져 있으므로 서버가 RRSIG(서명)를 함께 보냈습니다. RRSIG는 레코드마다가 아니라 RRset마다 하나입니다. 그래서 A 레코드 4개에 서명 1개, NS 5개에 서명 1개가 붙었습니다. Additional은 ns1~ns3의 A와 AAAA가 각각 별도의 RRset이라 서명이 6개입니다.- 응답 크기가 380에서 1204바이트로 약 3배가 되었습니다. 권장 UDP 크기 1232바이트에 거의 닿은 크기입니다. NS가 더 많거나 서명이 더 긴 알고리즘이었다면 한도를 넘어 TC=1이 되고 TCP로 다시 물어야 했을 것입니다. 같은 질의의 응답 크기가 다르다면 DO 비트부터 확인해야 하는 이유입니다.
udp: 1232: 서버가 알린 UDP 수신 크기입니다.
6. 정리 — 네 섹션으로 응답 유형 구분하기
지금까지 본 네 가지 응답을 섹션 구성으로 모으면 다음과 같습니다.
| 응답 유형 | AA | RCODE | Answer | Authority | Additional |
| 정상 답 (권한 서버) | 1 | NOERROR | 요청한 레코드 | 존의 NS (생략 가능) | NS의 주소 (생략 가능) |
| Referral (위임 안내) | 0 | NOERROR | 없음 | 하위 존의 NS | glue (NS 주소) |
| NXDOMAIN (이름 없음) | 1 | NXDOMAIN | 없음 | SOA | - |
| NODATA (이름은 있으나 타입 없음) | 1 | NOERROR | 없음 | SOA | - |
- NOERROR인데 Answer가 0개라면 referral이거나 NODATA입니다.
Authority에 NS가 있으면 referral, SOA가 있으면 NODATA입니다. - 위 표는 권한 서버에 직접 물었을 때 기준입니다. 리졸버가 같은 결과를 전달할 때는 AA=0, RA=1이 됩니다.
- Additional에는 이 표의 내용과 별개로 EDNS를 쓰면 OPT 레코드가 하나 더 붙습니다.
네 가지 유형을 한 번에 구분하는 법
flags에 aa가 있는가?
├─ 없음 → ANSWER 0 + AUTHORITY에 NS → Referral
│ (리졸버의 응답이라면 rd ra가 있고, 결과 유형은 status와 섹션으로 판단)
└─ 있음 → status와 섹션 확인
├─ NOERROR + ANSWER 있음 → 정상 답
├─ NOERROR + ANSWER 0 + SOA → NODATA
└─ NXDOMAIN + ANSWER 0 + SOA → NXDOMAIN
참고 자료
- RFC 1035 — Domain Names: Implementation and Specification : https://datatracker.ietf.org/doc/html/rfc1035
- RFC 2308 — Negative Caching of DNS Queries (DNS NCACHE) : https://datatracker.ietf.org/doc/html/rfc2308
- RFC 4034 — Resource Records for the DNS Security Extensions (RRSIG 형식) : https://datatracker.ietf.org/doc/html/rfc4034
- RFC 6891 — Extension Mechanisms for DNS (EDNS(0)) : https://datatracker.ietf.org/doc/html/rfc6891
- RFC 7873 — Domain Name System (DNS) Cookies : https://datatracker.ietf.org/doc/html/rfc7873
- RFC 8914 — Extended DNS Errors : https://datatracker.ietf.org/doc/html/rfc8914
- RFC 9499 — DNS Terminology (referral, glue, bailiwick 정의) : https://datatracker.ietf.org/doc/html/rfc9499
- IANA — DNS Parameters (타입 코드, EDNS 옵션 레지스트리) : https://www.iana.org/assignments/dns-parameters/dns-parameters.xhtml