SVCB / HTTPS 레코드 생성·해독기

SVCB(타입 64)와 웹 전용 쌍둥이인 HTTPS(타입 65)는 예전에 CNAME 하나에 문서 밖 지식을 더해야 했던 것을 한 레코드에 담습니다. 서비스가 말하는 ALPN 프로토콜, 포트, 주소 힌트, 그리고 ECH를 가능하게 하는 암호화된 client hello 설정입니다. 둘은 와이어 형식을 공유하며, 이 레코드에서 잘못되는 것은 거의 전부 다른 쪽이 파싱할 때까지는 멀쩡해 보이는 형식 세부 사항입니다. 이 페이지는 레코드를 정규화하고, 인코딩하고, 바이트를 분해하고, 위반한 조항을 해당 절과 함께 지적합니다.

첫째로 맞춰야 하는 것은 모드입니다. 우선순위 0은 AliasMode로, 대상이 별칭이며 SvcParam은 하나도 허용되지 않습니다. 1 이상은 ServiceMode이고, 숫자가 작은 쪽을 먼저 시도하며 같은 숫자끼리는 부하 분산될 수 있습니다. 우선순위가 0인데 alpn이 붙은 레코드는 필드가 하나 더 있는 레코드가 아니라 무효한 레코드이고, 이 페이지는 그것을 조용히 인코딩하지 않고 지적합니다.

둘째는 순서입니다. 와이어에서는 SvcParamKey가 번호 오름차순으로 나와야 하고 중복될 수 없지만, 표현 형식에서는 순서가 자유입니다. 그래서 1 . port=443 alpn="h2"와 1 . mandatory=port,alpn alpn="h2" port=443은 모두 키 0, 1, 3 순서의 바이트로 인코딩되고, 이 페이지가 출력하는 정규화 텍스트도 정렬된 상태로 돌아옵니다. 존 파일과 dig 응답의 순서가 다르다면 어느 쪽도 틀린 것이 아닙니다.

셋째는 이스케이프인데, 쉼표로 구분되는 값이 두 계층을 지나기 때문에 거의 모두가 여기서 걸립니다. 표현 값은 먼저 RFC 1035 문자열로 해제되어 역슬래시가 다음 문자를 이스케이프하고 세 자리 \DDD는 한 바이트가 됩니다. 그 결과를 쉼표로 나누는데, 이 계층에서는 역슬래시가 쉼표를 이스케이프합니다. 그래서 alpn="h2\,h3"는 프로토콜 두 개입니다. 첫 계층이 역슬래시를 먹어 버리고 둘째 계층은 평범한 구분자를 보기 때문입니다. 반면 alpn="h2\\,h3"는 h2,h3라는 이름의 프로토콜 하나입니다. \xNN 이스케이프도 없습니다. alpn="h2\x2ch3"는 h2x2ch3라는 프로토콜 하나입니다.

감추지 않고 처리하는 작은 경계들. SVCB rdata 안의 대상 이름은 DNS 압축을 쓰지 않으므로 항상 전체가 나옵니다. 알 수 없는 키는 값 없이 쓸 수도 있고 빈 값으로 쓸 수도 있으며, key65535와 key65535=""는 같은 4바이트입니다. mandatory는 자기 자신을 나열할 수 없고, 없는 키를 지목할 수 없으며, 정렬되어 돌아옵니다. alpn 없는 no-default-alpn은 무효입니다. 그리고 IPv6 힌트는 주소에 실제로 IPv4가 박혀 있을 때만 점 표기로 출력됩니다. 0 그룹이 정확히 여섯 개 연속이거나, 다섯 개 뒤에 ffff가 오는 경우입니다. 그래서 ::0.0.0.1은 ::1로 돌아오는데 ::192.0.2.1은 점을 유지합니다.

이 페이지가 알려 줄 수 없는 것은 그 레코드가 실제로 동작하는지입니다. 주소 힌트는 힌트입니다. RFC 9460은 A와 AAAA 레코드를 여전히 필요하게 두고, 리졸버는 힌트를 완전히 무시해도 됩니다. ech 값은 base64인지만 검사하며, 그 안의 키가 서버와 맞는지는 DNS가 아니라 TLS의 문제입니다. 그리고 문법적으로 완벽한 HTTPS 레코드라도 클라이언트가 조회하는 이름에 놓여 있지 않다면 아무 일도 하지 않습니다.