DNS 请求（例如 txt 记录）是否可以用于提供 .css 和 .js 文件？
Can DNS requests (such as txt records) be used to serve .css & .js files?
(这个问题很奇怪，我承认。它本质上是一个 "what if" 类的问题，不是我任何项目都需要的问题。如果你能指正我将不胜感激我在下面所做的任何假设都是不正确的——我肯定不是网络工程师！)
是否可以使用 DNS txt 记录（或新记录）来缓存整个 .css/.js 文件以用于网页浏览？
我怀疑最简单的方法（如果可能的话）是使用 browserify 和小型 DNS 客户端到 'dig' 一个定制的 node.js DNS 服务器，该服务器已经过训练以回复整个静态文件（.css、.js）。示例请求可能是：jquery.min.js.example.com，其中 txt 记录响应将是 jquery.min.js 的全部内容。它甚至可以是像 7fba88.js.example.com 这样的部分散列，因此可以验证结果文件来自 'unpoisoned' DNS 缓存，在浏览器的回复上运行 javascript 散列。
我怀疑 DNS 协议可能比 HTTP 协议更快（更少的开销，UPD 与 TCP）并且还可以提供更好的缓存形式。 DNS txt 请求（以 255 字节的块...）可能能够缓存在您的本地主机上，以用于您访问的任何网站——以及任何网络浏览器——并且通常也由您的 ISP 缓存。
HTTP 请求也有缓存，但没那么好。如果 .css 文件与已下载到浏览器的文件相同，浏览器仍需要连接到 HTTP d（或 CloudFlare.com 之类的 CDN）才能获得 304 响应。 （请忽略离线缓存清单。）此外，如果您在浏览器中打开一个新选项卡，该新选项卡将再次为同一站点请求这些静态文件。
我想很多 ISP 服务器管理员看到他们的 DNS 缓存被静态文件填满会非常恼火。我不知道在那种情况下他们会怎么做，也许他们会禁止对您的域进行缓存，这不太好。
有什么想法吗？
@Joe 的回答：在这个假设的场景中，DNS 客户端（可能是 browserify 和 this module or similar）将在 head-tag 中运行并在显示 body-tag 之前拉出其余的静态内容。它与 websocket 连接没有太大区别，因为它会在网页内运行。
这种方法的主要问题是浏览器无法发送 UDP 数据包。
如您所述，请参阅此处讨论 DNS TXT 记录潜在漏洞的文章：DNS TXT records represent vulnerability for caching DNS servers。如文章中所述，系统管理员和 public DNS 服务器管理员可能会完全禁用 TXT 记录的缓存，这将阻止将其用作有效的缓存机制。
native-dns does not make the browser send DNS requests itself. A HTTP request is sent by the browser to the Node.js DNS server module 这将在服务器上处理 DNS 请求并将回复发送到浏览器。所以你仍然需要 return 对浏览器的 HTTP 200 或 304 响应，而后者需要更多的工作，因为你必须实现自己的服务器端缓存机制来确定文件是否已更改。
(这个问题很奇怪，我承认。它本质上是一个 "what if" 类的问题，不是我任何项目都需要的问题。如果你能指正我将不胜感激我在下面所做的任何假设都是不正确的——我肯定不是网络工程师！)
是否可以使用 DNS txt 记录（或新记录）来缓存整个 .css/.js 文件以用于网页浏览？
我怀疑最简单的方法（如果可能的话）是使用 browserify 和小型 DNS 客户端到 'dig' 一个定制的 node.js DNS 服务器，该服务器已经过训练以回复整个静态文件（.css、.js）。示例请求可能是：jquery.min.js.example.com，其中 txt 记录响应将是 jquery.min.js 的全部内容。它甚至可以是像 7fba88.js.example.com 这样的部分散列，因此可以验证结果文件来自 'unpoisoned' DNS 缓存，在浏览器的回复上运行 javascript 散列。
我怀疑 DNS 协议可能比 HTTP 协议更快（更少的开销，UPD 与 TCP）并且还可以提供更好的缓存形式。 DNS txt 请求（以 255 字节的块...）可能能够缓存在您的本地主机上，以用于您访问的任何网站——以及任何网络浏览器——并且通常也由您的 ISP 缓存。
HTTP 请求也有缓存，但没那么好。如果 .css 文件与已下载到浏览器的文件相同，浏览器仍需要连接到 HTTP d（或 CloudFlare.com 之类的 CDN）才能获得 304 响应。 （请忽略离线缓存清单。）此外，如果您在浏览器中打开一个新选项卡，该新选项卡将再次为同一站点请求这些静态文件。
我想很多 ISP 服务器管理员看到他们的 DNS 缓存被静态文件填满会非常恼火。我不知道在那种情况下他们会怎么做，也许他们会禁止对您的域进行缓存，这不太好。
有什么想法吗？
@Joe 的回答：在这个假设的场景中，DNS 客户端（可能是 browserify 和 this module or similar）将在 head-tag 中运行并在显示 body-tag 之前拉出其余的静态内容。它与 websocket 连接没有太大区别，因为它会在网页内运行。
这种方法的主要问题是浏览器无法发送 UDP 数据包。
如您所述，请参阅此处讨论 DNS TXT 记录潜在漏洞的文章：DNS TXT records represent vulnerability for caching DNS servers。如文章中所述，系统管理员和 public DNS 服务器管理员可能会完全禁用 TXT 记录的缓存，这将阻止将其用作有效的缓存机制。
native-dns does not make the browser send DNS requests itself. A HTTP request is sent by the browser to the Node.js DNS server module 这将在服务器上处理 DNS 请求并将回复发送到浏览器。所以你仍然需要 return 对浏览器的 HTTP 200 或 304 响应，而后者需要更多的工作，因为你必须实现自己的服务器端缓存机制来确定文件是否已更改。