目的是省个服务器，
背景是，app 主要功能不依赖服务器，服务器只提供极少配置信息以及一个附属功能，使用时连不上就放弃，
后来发现效果不好，懒得维护相关抗投诉服务器功能就直接把服务器域名解析到 127.0.0.1 了，可是发现就这居然还偶尔出现尝试连接服务器浪费了几秒的情况，
排查发现是网络呆理软件异常，对 app 来说服务器连接上了等待响应，实际上只是卡住了，
于是我就提前加个判断，域名提前解析一下，指向本地就直接关闭相关服务，

然后突然觉得，既然都提前 dns 解析了，不如干脆做个 txt 记录的解析，内容放个 json 之类的直接把配置信息自带了，要开关什么直接改 txt 记录就好，0 成本，也能避免服务器停止维护时连几个简单配置都获取不到，

想知道有没人这么做过的，不是在必须 txt 记录的情况使用 txt 记录，而是为了降低成本强行使用的 txt，
想知道有没什么坑，能想到的就只有解析记录更改不会实时生效，这点我这可以接收，

也有可能 很久 甚至 几年不生效

精辟

dns 可以伪造

应该没啥问题，至于生效问题，可以把 ttl 弄到 60 秒

这个不至于吧，感觉上，十分钟到半小时就能生效了吧，一直不刷新缓存那这 dns 服务器也该废了吧，

还有一种运营商 叫长城宽带

详细说说？用户主动破解自己骗自己情况我这边不需要在意，而且 http 甚至 https 都防不住这些，
其他应该没有什么安全性的问题吧，正经 dns 服务器拿到的记录应该都是真实的，

有所耳闻，但没用过，我正经备案的域名，他应该不会随便把我的解析污染了吧，

以太坊 bootstrap node 就是这么做的，可以参考一下

涨知识了，看起来是去中心化节点使用 dns txt 记录分发着什么，
在项目 ethereum/go-ethereum 找到了 txt 记录相关操作的代码，
有先例就好，

看起来没什么问题，很机智

有条件的话可以先做实验
把 TXT 记录和服务器请求数据做对比
看实际用户的更新延迟情况如何
问题不大再正式使用

https://betterprogramming.pub/apparently-you-can-use-route53-as-a-blazingly-fast-database-dd416b56b005

问题不大 https://docs.ipfs.io/concepts/dnslink/#resolve-dnslink-name

如果不想用服务器，还是搞个函数计算，或者把 txt 放在对象存储里好一些。

txt 记录一条最大 255 字符 你可以 base64 然后多条记录
但是太多记录的话 等下解析不出来哦

这个思路 666 呀

函数计算之类的有考虑过，但是国内貌似没啥免费的吧，原本我是想挂在 github pages 或者 cloudflare 上的，但是连接太慢，我这个可以接受失败，但不能接受太慢，

嗯，255 是个瓶颈，虽然可以多条但也影响效率，
不过对我还好，只是存几个 key value，够用，

ESET 就是这么干的
https://img.maocdn.cn/img/2021/05/13/Snipaste_2021-05-13_20-01-32.png
https://img.maocdn.cn/img/2021/05/13/Snipaste_2021-05-13_20-01-09.png

如果你只是找个位置放一个非关键的配置信息，用 github 等代码托管平台就可以了。
你要知道在国外有人拿推特当 C&C 服务器用的。

应该没问题

曾经有人拿博客类平台做配置源。

各级 DNS 缓存无法控制, DNS 服务器为了压榨性能故意不遵守协议里的 TTL 长期缓存下去你拿它真没什么办法. 这种 TTL hack 只能用于不太重要的功能. 重要的功能比如版本升级判定, 搞个很小的 json 放 cdn 会更好.

挺多这么干的，怕楼上说的解析问题就 HTTPDNS 或者 DNS over HTTPS

最好的配置源是 Github ！
可以顺便推荐一下我用这种方式做的 app 吗？
大佬可以 iPhone 下载试一试：NFC Master
向大佬们学习！

另：iCloud 也推荐用作配置源！

利用过 txt 记录传文件，不过是很小的二进制

可以考虑直接上 github，配合 jsdliver 读取仓库下的配置文件 @ latest

几年前用过 TXT 记录对比是否需要更新
29313(当前版本号).build.app.com TXT 29400
如上方法使用，一个版本号只用一次，基本上不遇到缓存问题，但是有时会丢解析导致无法获取更新

永恒之蓝的开关不就是个域名吗～

这是病毒木马常用的通信手段，容易被误伤

可以，直接调用 http DNS 解析即可。

配置这样管理起来不 ge 的慌吗……——……

255 长度限制，可以来个链表～

最新版本信息可以用 txt 来做，简单而且符合版本更新逻辑

github gist 好像也还合适？

数据量不大的话可以考虑用 CNAME 甚至 A 记录实现。

有比较成功的案例：forwardemail
https://forwardemail.net/en/faq#table-dns-management-by-registrar

我就是这么做的，我是使用域名的 txt 记录做 license 授权，为了随时都可以取消授权。

挂 pages 或者 github 仓库是一个很正确的方案。DNS 记录的话，这个思路确实很巧妙，但是很难控制其实效性和准确性，不建议用。pages 速度慢的话，可以用微林的 vxserver 来替代，直接把 github 仓库作为 http 服务发布。

即使你把 ttl 设置成 1，你也防不住 dns 递归服务器缓存，dnspod 啥的 都不是标准实现。缓存时间是他们自己控制的，不走 ttl