DNS isn't a central authority. Everyone selects their own DNS server. It can say whatever it wants.

This is a rare case where it's centralized in practice and yet the option to do your own thing hasn't been removed from the relevant software.

If you can agree with your communication target on a common DNS server under your or their control that doesn’t respect authoritative DNS servers, and both of you can securely connect to said server, then you already have a continued, trusted communication mechanism that you may as well use for your communication. You’re just arguing a pretty pointless technicality.

> If you can agree with your communication target on a common DNS server under your or their control that doesn’t respect authoritative DNS servers, and both of you can securely connect to said server, then you already have a continued, trusted communication mechanism that you may as well use for your communication.

Why? It can easily be the case that that traffic is observable by outside parties. You'd still need to encrypt your communication.

Connecting to the DNS server "securely" doesn't really get you anything except some DOS resistance.

DNS already supports encryption on the protocol level. And even if you can’t use DOH/DOT, you can use PGP or age or whatever in your clear text too.

  $ dig +short @<trusted_server> TXT <encrypted_content>.
  <encrypted_content_back>

In practice yes, but it's good to know the smtp rfc does support domain literals, ie user@IP.