> What I've never understood is how this doesn't ultimately just shift the security risk to my DNS registrar. > Instead of social-engineering the CA to give me

> What I've never understood is how this doesn't ultimately just shift the security risk to my DNS registrar. > Instead of social-engineering the CA to give me a cert, I have to social-engineer the registrar to store a TXT record. I don't see why one should be significantly harder than the other. Rogue registrars aren't necessary: one can simply attack the registrar or interfere with the DNS traffic. These attacks have already been seen in the wild and are continuing today: check out info on DNSpionage (https://blog.talosintelligence.com/2019/04/dnspionage-brings-out-karkoff.html https://blog.talosintelligence.com/2019/04/dnspionage-brings...) and Sea Turtle (https://blog.talosintelligence.com/2019/04/seaturtle.html https://blog.talosintelligence.com/2019/04/seaturtle.html) attacks. Meanwhile, Let's Encrypt has been making some interesting changes. For instance, they just introduced multi-perspective challenges (https://letsencrypt.org/2020/02/19/multi-perspective-validation.html https://letsencrypt.org/2020/02/19/multi-perspective-validat...) in which they submit multiple challenges to the user from different network paths. Attackers hijacking network paths to interfere with challenges must then intercept all possible paths to a client, which is much harder. That said, I'm not a fan of devolving our certificate validation to DNS--it's like building a castle on Jello. It wasn't designed to be a security-first protocol, and it's definitely showing its age.