概要

• TXTレコードの 実際のサイズ制限 と誤解についての解説
• UDPとTCP による制限の違い
• バイナリデータ の取り扱いと課題
• Google Public DNSなどを利用した 大容量TXTレコード の実演
• セキュリティやキャッシュ に関する考察

TXTレコードのサイズ制限と実際

• TXTレコード は、RFC 1035 section 3.3.14に準拠し、 複数のcharacter-string を持つことが可能
• 1つのcharacter-stringは 最大255バイト まで、複数連結することでレコード全体のサイズが拡張可能
• UDPの場合、DNSペイロードは現在 約1232バイト が上限
• TCP利用時 は、DNSプロトコルの仕様上 最大64KB まで送信可能
• 実際には、 TXTレコードに画像データ など大容量データを格納し、TCP経由で配信する実験も可能

バイナリデータの扱いとJSON APIの課題

• Google Public DNSの JSON API を利用し、 大きなTXTレスポンス をTCP経由で配信可能

• バイナリデータ をTXTレコードに格納することで、 Base64等のエンコードによるオーバーヘッド削減

• JSONはバイナリデータ処理に最適化されていないため、 独自のJSONパース処理 が必要

• 実際のデータ取得には、 digコマンドとPerlワンライナー を組み合わせてバイナリ復元が可能

  • 例:

    $ dig +short dog.log.battery.st TXT | perl -pe'chomp; s/" "//g; s/^"//; s/"$//; s/\\(\d{3})/chr $1/eg; s/\\([\\"])/$1/g' > dog.avif
    $ sha256sum dog.avif
    

DNSサーバ・キャッシュ・セキュリティの考察

• Google Public DNS や @dns.google 等のオープンリカーサーを使うことで大容量TXTレコードの取得が容易
• TTLを10秒 など短く設定し、不要なキャッシュを防止
• TTLを長く設定すれば、 分散CDN的な利用 も理論上可能（ただしTTL制御が入る可能性あり）
• DNSトンネリング によるデータ伝送は既知だが、 大容量データをブラウザへ直接送信 は新しいアプローチ
• Let's Encryptの IPアドレス証明書 普及により、 HTTPS通信の直接化 やDNSフィルタ回避の懸念

サーバ構成とAI活用

• サーバ側は Go製のカスタムDNSサーバ を使用
• サーバ実装は ChatGPT を利用しつつ、 細部は手動修正
• サーバコードは全て 公開、クライアントHTMLやブログ記事は 自作

まとめ

• TXTレコードの真の上限 はUDP/TCPによるDNSペイロードサイズ依存
• バイナリデータの直接格納 により、効率的な大容量データ転送が可能
• セキュリティやキャッシュ の観点からも、今後の活用や規制に注目