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

사용법

1. 전체 TXT 값 붙여넣기(DKIM 공개 키·긴 SPF·긴 DMARC). 샘플 버튼은 현실적 예시 채움.
2. 발행할 DNS UI 선택. 출력이 그 공급자 인용으로 조정.
3. 값 필드에 복붙. 리졸버가 클라이언트용으로 청크 투명하게 재조립.

자주 묻는 질문

왜 255바이트?

DNS character-string은 단일 바이트 길이 프리픽스. 그 바이트가 단일 문자열을 255로 캡. TXT 레코드는 리졸버가 연결하는 여러 문자열 포함 가능 — `"abc" "def"`는 `abcdef`로 읽힘. 프로토콜은 결합을 애플리케이션에 맡김.

Cloudflare 정말 자동 분할?

응. 600바이트 문자열 Cloudflare에 붙여넣으면 내부에서 조용히 3개 character-string으로 분할. Cloudflare용 출력은 결합된 값 — 그거 붙여넣기, 인용 필요 없음.

특정 위치에서 잘라야 하나?

아니다. 리졸버는 문자열들을 사이에 아무것도 넣지 않고 이어 붙이므로, 각 조각이 255바이트를 넘지 않고 순서만 맞으면 어디서 자르든 상관없다. 중요한 것은 경계에서 무언가가 더해지지 않는 것이다. 이음매에 들어간 공백 하나, 또는 컨트롤 패널이 각 조각을 따로 따옴표로 묶으면서 공백을 붙이는 경우, 수신 측이 재구성하는 값이 달라진다.

긴 키는 쪼개는 게 맞나, 더 나은 방법이 있나?

DKIM이라면 키가 꼭 그렇게 길어야 하는지부터 생각해보라. 1024비트 키는 쪼개지 않아도 들어가지만 2048비트는 그렇지 않아서, 많은 제공자가 긴 키를 쪼개서 공개한다. 그건 괜찮다. 괜찮지 않은 것은 하나의 레코드를 같은 이름의 여러 TXT 레코드로 나누는 것이다. 그건 더 긴 값이 아니라 다른 구조이고, 검증이 실패한다.

관련 도구