DNS 请求（例如 txt 记录）可以用于提供 .css 和 .js 文件吗？

Question

(我承认，这个问题很奇怪。它本质上是一种“假设”的问题，而不是任何项目都需要的问题。如果您能纠正我在下面所做的任何假设，我将不胜感激这不是真的——我肯定不是网络工程师！）

是否可以使用 DNS txt 记录（或新记录）来缓存整个 .css/.js 文件以用于网页浏览？

我怀疑最简单的方法（如果可能的话）是使用 browserify 和小型 DNS 客户端来“挖掘”一个定制的 node.js DNS 服务器，该服务器经过培训可以回复整个静态文件（.css , .js)。一个示例请求可能是：jquery.min.js.example.com，其中 txt 记录响应将是 jquery.min.js 的全部内容。它甚至可以是像 7fba88.js.example.com 这样的部分哈希，因此可以验证结果文件来自“未中毒”的 DNS 缓存，在浏览器的回复上运行 javascript 哈希。

我怀疑 DNS 协议可能比 HTTP 协议更快（开销更少，UPD 与 TCP 相比），也可能提供更好的缓存形式。 DNS txt 请求（以 255 字节的块...）可能能够缓存在您的本地主机上，以用于您访问的任何网站 - 以及任何 Web 浏览器 - 而且通常也被您的 ISP 缓存。

HTTP 请求也有缓存，但没有那么好。如果 .css 文件与已下载到浏览器的文件相同，则浏览器仍需要连接到 HTTP d（或 CloudFlare.com 等 CDN）才能获得 304 响应。 （请忽略离线缓存清单。）此外，如果您在浏览器中打开一个新选项卡，该新选项卡将再次为同一站点请求这些静态文件。

我想许多 ISP 服务器管理员看到他们的 DNS 缓存被静态文件填满会非常恼火。我不知道他们在这种情况下会做什么，也许他们会禁止对您的域进行缓存，这并不好。

有什么想法吗？

@Joe 的回答：在这个假设的场景中，一个 DNS 客户端，可能是 browserify 和 this module or similar，将在 head-tag 中运行，并在显示 body-tag 之前提取其余的静态内容。它与 websocket 连接没有太大区别，因为它会在网页中运行。

Answer 1

这种方法的主要问题是浏览器无法发送UDP数据包。

请参阅此处，了解您所描述的讨论 DNS TXT 记录潜在漏洞的文章：DNS TXT records represent vulnerability for caching DNS servers。如文章中所述，系统管理员和公共 DNS 服务器管理员可能会完全禁用 TXT 记录的缓存，这将阻止将其用作有效的缓存机制。

native-dns 不会让浏览器自己发送 DNS 请求。浏览器向Node.js DNS server module 发送HTTP 请求，Node.js DNS server module 将处理服务器上的DNS 请求并将回复发送给浏览器。因此，您仍然需要向浏览器返回 HTTP 200 或 304 响应，而后者需要更多的工作，因为您必须实现自己的服务器端缓存机制来确定文件是否已更改。