在常规认知中，DNS TXT 记录主要用于存储域名验证或反垃圾邮件策略等文本信息，其 “255 字节限制” 的说法广为流传。然而，这一认知存在根本性误区。本文将揭示如何利用 DNS 协议，特别是通过 TCP 传输机制，实现高达 64KB 的数据负载，从而直接在 TXT 记录中传输完整的图像文件。这不仅是一个技术奇技，更是一套可落地的工程实践，其核心在于理解并配置正确的协议参数，同时明确其安全边界。
技术原理的核心在于破除两个迷思。首先，TXT 记录本身并无 255 字节的硬性上限。根据 RFC 1035 第 3.3.14 节，一个 TXT 记录由多个 “字符 - 字符串”（character-string）组成，每个字符串的长度由一个字节标识，因此单个字符串确实被限制在 0-255 字节内。但关键在于，一个 TXT 记录可以包含多个这样的字符串，它们在传输时会被拼接成一个连续的数据块。真正的限制来自于 DNS 消息本身的大小，而非 TXT 记录的内部结构。其次，UDP 并非 DNS 的唯一传输层。当响应数据超过 UDP 的默认 512 字节（或 EDNS0 扩展后的 4096 字节）时，符合标准的 DNS 服务器和客户端会自动回退到 TCP 连接。而 TCP 承载的 DNS 消息，其长度由消息开头的两个字节（16 位无符号整数）标识，理论上限为 65,535 字节。这意味着，只要服务端能生成并返回一个超过 UDP 阈值的 TXT 记录，客户端在收到截断（TC）标志后，便会通过 TCP 重新发起查询，从而获取完整的图像数据。
在工程实现层面，David Leadbeater 的实践提供了一个清晰的蓝图。其服务端是一个用 Go 语言编写的自定义 DNS 服务器，核心逻辑是监听对特定域名（如*.log.battery.st）的 TXT 查询，并根据子域名（如cat或dog）返回对应图像文件的二进制内容。为最大化数据效率，他选择直接传输原始二进制数据，而非 Base64 编码，从而避免了约 33% 的体积膨胀。在客户端，他巧妙地利用了 Google Public DNS 的 JSON API。由于浏览器无法直接发起原生 DNS 查询，通过向https://dns.google/resolve发送 HTTPS 请求，可以间接获取 TXT 记录内容。前端 JavaScript 代码负责解析 JSON 响应，将其中被转义的字符串（如\123）还原为原始字节，并最终构建为Blob对象，从而在页面上渲染出图像。对于非浏览器环境，如使用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 即可完成整个过程。若本地递归 DNS 不支持大响应，可显式指定@dns.google或@9.9.9.9等支持该特性的公共解析器。
然而，这项技术的双刃剑属性不容忽视。从安全角度看，它提供了一种新颖的隐蔽通信渠道。攻击者长期以来利用 DNS 隧道（如 MITRE ATT&CK T1071.004）进行数据渗出，但传统方法通常受限于小数据包，效率低下。通过 TCP 传输大负载，攻击者可以直接将恶意载荷（如完整的可执行文件或图像形式的 C2 指令）封装在 TXT 记录中，直接送达浏览器环境。更关键的是，由于 Google Public DNS 等服务拥有包含其 IP 地址（如 8.8.8.8）的 SSL 证书，浏览器可以直接向这些 IP 发起 HTTPS 请求，完全绕过基于域名的 DNS 过滤策略。这使得在严格网络环境中，用户或恶意软件仍能建立对外通信。随着 Let's Encrypt 等机构开始颁发 IP 地址证书，此类攻击面将进一步扩大。作为防御方，必须意识到传统的 DNS 日志分析可能无法捕获此类大体积、高频率的 TXT 查询，需要部署专门的 DNS 流量深度包检测（DPI）系统，监控异常的 TCP DNS 连接和超大 TXT 响应。
为了确保该技术在合法场景下的稳定运行，以下是一份关键参数与操作清单：
- 服务端配置：确保 DNS 服务器支持 TCP 连接，并能处理超过 4096 字节的响应。在 Go 或其他语言实现中，需正确设置响应消息的 TC 标志（当通过 UDP 发送时）和消息长度字段（当通过 TCP 发送时）。
- TTL 设置：为避免污染递归 DNS 缓存并消耗其资源，务必设置极低的 TTL 值（如 10 秒），正如原作者所做。高 TTL 可能导致无用数据在全网缓存中长期驻留。
- 客户端容错：在前端代码或脚本中，必须包含对本地 DNS 解析器不支持大响应的降级处理逻辑，例如自动切换到
dns.google等已知支持的公共解析器。 - 数据格式：优先选择传输原始二进制数据，而非文本编码（如 Base64），以最大化有效载荷。同时，确保服务端和客户端对数据的转义与解码规则保持一致。
- 监控指标：运维人员应监控 DNS 服务器的 TCP 连接数、平均响应大小和特定 TXT 查询域名的 QPS。异常飙升的指标是潜在滥用或故障的早期信号。
总而言之，利用 DNS 传输图像并非天方夜谭，而是建立在对协议细节深刻理解之上的工程实践。它既展示了网络协议的灵活性与强大，也暴露了现有安全体系的盲区。无论是将其用于创新的网络应用，还是作为安全防御的研究对象，掌握其核心参数与边界条件，都是成功的关键所在。