TXT 레코드 255자 초과: 올바른 분할

문제

긴 TXT 값 — 대부분 2048비트 DKIM 키, 가끔 비대해진 SPF나 도메인 인증 레코드 — 을 붙여 넣었는데 뭔가 잘못됩니다. DNS 제공업체가 “string too long”으로 거부하거나, 레코드는 저장되는데 그걸 쓰는 쪽(DKIM 서명, 도메인 인증)이 그래도 실패합니다.

증상

• DNS 패널이 “character string too long” 또는 “255자 초과” 오류를 냅니다.
• 레코드는 저장됐지만 dig TXT에 값이 여러 따옴표 문자열로 쪼개져 나오고, 이게 맞는지 확신이 안 섭니다.
• 레코드가 분명히 있는데도 DKIM 검증이 body hash did not verify나 key not found로 실패합니다.
• DKIM 키를 1024비트에서 2048비트로 교체한 직후 시작됐습니다.

255 제한의 실체

거의 모두가 여기서 걸리니 정확히 짚겠습니다. RFC 1035 §3.3.14는 TXT 레코드의 RDATA를 “하나 이상의 <character-string>”이라고 정의합니다. <character-string>은 1바이트 길이 값 + 그만큼의 데이터인데, 1바이트는 최대 255까지입니다. 따라서 개별 문자열은 255바이트를 넘을 수 없습니다. 이게 진짜 규칙입니다.

오해는 이걸 “TXT 레코드는 255자를 넘을 수 없다”로 읽는 데서 옵니다. 넘을 수 있습니다. TXT 레코드는 문자열을 줄줄이 이어 담을 수 있고, RDATA 총합 65,535바이트까지 허용됩니다(실제로는 DNS 메시지 크기 제한에 훨씬 먼저 부딪힙니다). 리졸버는 레코드를 돌려줄 때 문자열들을 구분자 없이 이어 붙입니다 — 바이트 단위로 그냥 붙죠. 그래서 "abc" "def"는 애플리케이션에 abcdef로 전달됩니다.

2048비트 DKIM 키는 base64 기준 390자가 넘습니다. 255바이트 문자열 하나에 물리적으로 들어갈 수 없습니다. 해법은 키를 줄이는 게 아니라, 원본과 정확히 같게 이어 붙는 두 개 이상의 문자열로 게시하는 것입니다.

주요 원인 3가지

1. 2048비트 DKIM 키를 한 문자열로 붙여넣음 — 가장 흔한 경우입니다. 키가 255바이트보다 길어서, 엄격한 제공업체는 거부하고 허술한 곳은 망가뜨립니다. 존 파일이나 패널에서의 올바른 형식: "v=DKIM1; k=rsa; p=MIIBIjANBg...앞부분" "...뒷부분...AQAB". base64는 어디서 끊어도 되지만 — 문자를 더하면 안 됩니다.
2. 분할 지점에 공백·줄바꿈이 끼어듦 — 제대로 잘랐는데 텍스트 편집기가 줄을 접었거나 붙여넣기에 공백이 딸려와, 조각 ‘안에’ 공백이 생깁니다. 이어 붙이면 그 한 바이트 때문에 base64가 깨지고, 공개키가 파싱되지 않으며, DKIM이 조용히 실패합니다. 레코드는 완성돼 보이지만 데이터는 아닙니다.
3. 예상 못 한 제공업체 자동 분할 — Route 53, Google Cloud DNS, Cloudflare, PowerDNS는 긴 값을 알아서 분할합니다. 보통 괜찮지만 — 여기에 수동 분할까지 겹치면 이중 따옴표나 잘못된 조각화가 생길 수 있습니다. 손으로 자르기 전에 내 제공업체가 자동 분할하는지부터 확인하세요.

DechoNet으로 진단

• DNS 진단은 리졸버가 실제로 보는 그대로 TXT 레코드를 가져와 문자열 조각을 보여줍니다. 머릿속에서 (구분자 없이) 이어 붙여, 결과가 정확히 내 키와 같은지 — 군더더기 공백 없이, 끝이 잘리지 않았는지 — 확인하세요.
• 이메일 진단은 DKIM·SPF·DMARC 레코드를 끝까지 읽습니다. 분할된 DKIM 키가 깨졌다면, 모호한 DNS 오류가 아니라 ‘유효하지 않은 키’로 여기서 드러납니다.

해결 체크리스트

• 문자열당 문제인지 확인: 값의 길이를 세세요. 255바이트 미만이면 길이 문제가 아닙니다. 초과면 반드시 분할해야 합니다.
• 각 255바이트 이하 조각으로 나누고, 각 조각을 자체 따옴표로 감싸고, 정확히 공백 하나로 구분: "조각1" "조각2".
• 조각 안에 아무것도 새지 않았는지 확인 — base64 안에 공백이나 줄바꿈 금지. 자르는 위치는 자유, 끼어든 문자는 치명적입니다.
• dig +short TXT selector._domainkey.example.com으로 실제 레코드를 다시 읽고 따옴표 문자열을 머릿속으로 이어 붙이세요. 합친 결과가 원본 키와 바이트 단위로 같아야 합니다.
• 제공업체가 자동 분할한다면 값을 한 줄로 붙여넣고 알아서 쪼개게 두세요 — 미리 자르면 따옴표가 깨질 수 있습니다.
• DKIM은 테스트 메일을 보내 수신 측 Authentication-Results의 dkim=pass를 확인하세요. 레코드 존재만으로는 부족합니다.

에스컬레이션 시점

• DNS 패널이 다중 문자열 TXT 값을 일절 거부하고 따옴표 조각을 입력할 방법도 없다면, 제공업체 인터페이스가 병목입니다 — 티켓을 열거나 긴 TXT를 다루는 제공업체로 존을 옮기세요.
• 레코드는 완벽히 이어 붙는데 DKIM이 여전히 실패한다면, 문제는 DNS를 벗어난 것입니다: 게시된 공개키가 메일 서버의 개인키와 안 맞는, 키쌍 불일치이지 255바이트 분할 문제가 아닙니다.