据我的理解，LetsEncrypt DNSvalidation通过设置静态TXTlogging到DNS（基本上只是一个随机数），然后由LetsEncrypt服务器进行检查。
当我第一次听到这个消息的时候，我非常兴奋，并期待更复杂的东西：一个公钥存储在我的域的DNS中。 然后，为了validation，我创build了一个签名的消息，并且LetsEncrypt服务器检查签名是否有效。 由于我拥有DNS和私钥中的公钥，这就build立了我控制域的certificate。
发现这种方式不起作用有点令人失望：它需要人工交互，甚至需要更新一个新的TXTlogging。
是否有一个技术原因，没有使用签名方法？ 如果不是，那么LetsEncrypt没有实现它的原因是什么？
我相信你的想法并不是真的发生。 让我们来encryption，遵循IETF ACME工作组的ACME协议草案的当前版本。 在该草案中， 第8.5节要求使用随机string（在提问中提供）和账户密钥作为创buildTXTlogging值的第一步。
客户通过从挑战中提供的“标记”值和客户的账户密钥构build密钥授权来回应这个挑战。 客户端然后计算密钥授权的SHA-256摘要[FIPS180-4] 。
拥有帐户密钥和控制DNS应该足以certificate对域的控制权，以及与请求证书的帐户的连接。 与帐户关联的公钥不在DNS中公开，由LE保存，而私钥应安全地保存在服务器本身上，就像任何其他私钥一样。
那么，你最后的问题是不是有一个技术原因，就是没有使用签名方法？ 如果不是，那么LetsEncrypt没有实现它的原因是什么？ 似乎已经错过了这一点。 签名被使用。