TXT 레코드 분할기 (255바이트 청크)

DNS TXT의 문자열 하나는 255바이트가 상한입니다. 길이가 문자열 맨 앞의 1바이트에 저장되기 때문입니다. 이것은 제공업체의 정책이 아니라 RFC 1035의 엄격한 제한이므로, 그보다 긴 것 — RSA DKIM 공개키, include가 많은 SPF 레코드 — 은 하나의 TXT 레코드 안에 여러 문자열로 나누어 게시해야 합니다. 이 도구는 바이트 경계에서 텍스트를 쪼개고, 쓰는 DNS 제공업체가 기대하는 형태로 출력합니다. BIND의 괄호 표기 ("part" "part"), 일반 존 파일용 공백으로 구분된 따옴표 문자열, Route 53이 받아들이는 형태, 그리고 알아서 쪼개 주는 제공업체에 대한 안내까지 포함합니다.

이어 붙일 때는 사이에 아무것도 들어가지 않습니다. 리졸버는 문자열들을 끝에서 끝으로 붙여 애플리케이션에 건네므로, 쪼개지는 지점은 base64 문자열 한가운데든 단어 중간이든 어디여도 됩니다. 떼어 낼 구분자도 없고, 조각 하나하나가 그 자체로 의미를 가져야 할 이유도 없습니다. 존 파일에서 더 깔끔해 보인다고 이음매에 공백이나 줄바꿈을 넣으면 값이 망가집니다. DKIM은 이 동작을 명시적으로 규정하고 있는데, DNS 관리 화면에서 "제대로 보이는" 키가 검증에 실패할 수 있는 이유가 이것입니다. 여분의 문자는 화면이 아니라 레코드 안에 들어 있습니다.

이 작업이 필요해지는 흔한 이유는 2048비트 RSA DKIM 키입니다. 그 공개키는 v=DKIM1; k=rsa; p= 접두어를 붙이기 전에 이미 base64로 약 392자이고, 레코드를 255바이트 너머 두 개의 문자열로 밀어 넣기에 충분합니다. 1024비트 키는 하나에 들어갑니다. 1024비트가 더 이상 좋은 선택이 아니게 된 뒤로도 그 길이에 머물러 있는 DKIM 레코드가 그토록 많은 이유 중 하나가 이것입니다.

실무적인 메모 둘. 문자가 아니라 바이트입니다. ASCII가 아닌 문자는 UTF-8에서 최대 4바이트를 차지하므로 255자 제한과 255바이트 제한은 같은 것이 아니고, 멀티바이트 시퀀스 중간에서 쪼개면 양쪽 다 유효하지 않은 반쪽이 됩니다. 그리고 응답 전체가 실제로 전달되어야 합니다. UDP 페이로드 한계를 넘어선 TXT 레코드는 잘린 응답과 TCP 재시도를 유발하는데, 제한이 심한 일부 네트워크는 이를 조용히 버립니다. 그래서 아주 큰 레코드는 어디서나 잘 되다가 사무실 한 곳에서만 안 될 수 있습니다.