DNS UDP 패킷은 Header, Question, Answer를 순서대로 읽는다
단순 A 레코드 질의도 바이트 흐름은 정해져 있습니다. 클라이언트는 헤더와 질문을 만들고, 응답에서는 같은 ID인지 확인한 뒤 Answer의 A 레코드 RDATA 4바이트를 IPv4 주소로 해석합니다.
12 byte
Header
ID요청과 응답을 매칭
Flags표준 질의, 재귀 요청, 응답 코드
CountsQuestion/Answer 개수
query
Question
QNAMEexample.com을 라벨 길이와 문자열로 인코딩
QTYPEA = IPv4 주소 요청
QCLASSIN = Internet class
response
Answer
NAME압축 포인터일 수 있어 offset 계산 필요
TTL캐시 가능 시간
RDATAA 레코드는 4바이트 IPv4
01
헤더 작성
Transaction ID와 플래그, 질문 개수 1을 네트워크 바이트 순서로 넣습니다.
02
질문 인코딩
도메인을 라벨 길이 + 문자열 조각으로 바꾸고 Type A, Class IN을 붙입니다.
03
UDP 전송
완성된 바이트열을 8.8.8.8:53 같은 resolver로 보냅니다.
04
응답 판독
Question을 건너뛰고 Answer에서 Type A, Class IN, RDLENGTH 4를 확인합니다.
필드
의미
파서 확인
Transaction ID
요청과 응답을 맞추는 번호
보낸 ID와 응답 ID가 같은지 확인
Flags / RCODE
재귀, 응답 여부, 오류 상태
응답 코드가 오류인지 확인
QNAME / NAME
도메인 이름과 압축 포인터
라벨 종료 바이트와 포인터를 정확히 건너뜀
TYPE / CLASS / LEN
레코드 종류와 데이터 길이
A, IN, 길이 4인 응답만 IPv4로 해석
UDP 한계
응답 없음은 유실일 수 있다
클라이언트가 timeout과 재시도를 직접 둬야 합니다.
TCP 전환
응답이 잘리면 TCP DNS로 다시 묻는다
큰 응답이나 truncation 상황에서는 TCP 재시도가 필요합니다.
QUIC 연결
신뢰성이 필요하면 위 계층이 맡는다
QUIC처럼 UDP 위에서 순서, 재전송, 암호화를 설계할 수 있습니다.