DNS 메시지 디코더

둘 다 맞고, 바로 그 점이 핵심입니다. rcode는 원래 헤더 안의 4비트였는데 EDNS0가 OPT 레코드의 TTL 필드에 상위 8비트를 넣어 12비트로 넓혔습니다. 헤더의 4비트만 읽는 디코더는 16의 하위 4비트, 즉 0을 보고 NOERROR라고 말합니다. 그래서 리졸버가 EDNS 버전을 거부하고 있는 상황이 아무 문제 없는 빈 응답처럼 보입니다. OPT 레코드가 있는 메시지는 반드시 두 조각을 합쳐야 하며 이 도구는 그렇게 계산합니다. 확장 rcode 자체도 EDNS0 패널에 따로 표시해서 추가 비트가 어디서 왔는지 볼 수 있게 했습니다.

UDP 패킷에 담겼을 바로 그 와이어 포맷 메시지 전체를 base64url로 인코딩하고, RFC 8484에 따라 패딩을 없앤 것입니다. URL 질의 문자열에서 살아남아야 하므로 + 와 / 대신 - 와 _ 를 씁니다. 두 가지가 자주 혼동을 부릅니다. GET 요청에서는 같은 질의가 같은 URL이 되어 HTTP 캐시에 올라갈 수 있도록 메시지 id를 0으로 두는 것이 관례이고, 응답은 JSON이 아니라 application/dns-message 원본 바이트로 돌아옵니다. 그래서 네트워크 패널에서 복사한 것은 16진수로 바꿔야 읽을 수 있습니다. 여기서는 두 형태 모두 붙여넣을 수 있습니다.

포인터는 이름의 나머지를 찾을 수 있는 메시지 내 오프셋을 가리키며, RFC 1035는 반드시 앞서 나온 위치를 가리키라고 규정합니다. 뒤쪽만 가리키게 한 것은 취향의 문제가 아니라 포인터 추적이 반드시 끝나도록 보장하는 장치입니다. 자기 자신이나 더 뒤의 오프셋을 가리키면 단 두 바이트로 순진한 디코더를 영원히 돌게 만들 수 있고, 실제로 그런 모양의 패킷이 서비스 거부 시험용으로 돌아다닙니다. 그래서 앞쪽이나 자기 자신을 가리키는 포인터는 따라가지 않고 결함으로 보고하며, 뒤쪽 연쇄에도 점프 횟수 상한을 둡니다.

전부입니다. 사이에 아무것도 넣지 않고 이어 붙인 것이 값입니다. TXT의 rdata는 1바이트 길이가 앞에 붙는 문자열들의 나열이라 문자열 하나가 255바이트를 넘을 수 없습니다. DKIM 공개키나 긴 SPF 정책처럼 그보다 긴 값은 반드시 쪼개야 하고 받는 쪽이 이어 붙입니다. DKIM 레코드가 base64 중간에서 끊긴 두 조각처럼 보이는 이유입니다. 이 도구가 조각을 따로 보여 주는 것은 그 분할이 실제로 패킷에 존재하기 때문이고, 작성자가 별개의 값으로 의도한 실수는 이어 붙이지 않아야만 눈에 띄기 때문입니다.

HTTPS나 SVCB 레코드는 우선순위와 대상 이름, 그리고 키/값 SvcParams의 목록입니다. 서버가 말하는 프로토콜을 담은 alpn, port, A와 AAAA 조회를 기다리는 동안 먼저 시도할 주소인 ipv4hint와 ipv6hint, 암호화된 클라이언트 헬로 설정인 ech 등이 있습니다. 와이어 포맷은 파라미터가 키 번호의 오름차순이고 중복이 없어야 한다고 요구합니다. 덕분에 파싱이 값싸지지만, 손으로 만든 레코드가 가장 자주 어기는 규칙이기도 합니다. 키 순서가 어긋난 레코드는 잘못된 레코드이므로, 그럴듯해 보이도록 몰래 재정렬하지 않고 원본 16진수로 보여 줍니다.

되지 않고, 패킷 하나만 읽는 도구라면 무엇도 할 수 없습니다. RRSIG는 해당 존의 DNSKEY로 검증해야 하는데 그 키를 따로 가져와 DS 레코드를 타고 신뢰 기준점까지 연결해야 하고, TSIG는 정의상 메시지에 실리지 않는 공유 비밀로 검증합니다. 대신 바이트 자체가 말해 주는 것은 모두 얻을 수 있습니다. 어떤 RRSIG가 어떤 타입을 덮는지, 시작과 만료 시각은 언제인지, DNSKEY 집합과 대조할 키 태그와 서명자 이름은 무엇인지, 그리고 AD 비트가 켜져 있는지입니다. AD 비트는 상위의 어떤 리졸버가 검증했다고 주장한다는 사실만 기록할 뿐 검증이 실제로 이루어졌음을 뜻하지는 않습니다.