Same reason as DoH (DNS Queries over HTTP), but with better:

1. performance: since the TCP+TLS handshake is only performed once and the connection is kept open forever

2. privacy: the resolver doesn't get the requesting party's IP address

> privacy: the resolver doesn't get the requesting party's IP address

How does that work? Is it somewhat like Tor?

The resolver is a client of an XMPP server and might be on the same server or even a different server the requesting party is on.

[Requesting Party]<--->[XMPP server]<--->[XMPP Server]<--->[Resolver]

    [Requesting Party]<--->[XMPP server1]<--->[XMPP Server2]<--->[Resolver] 

But do I need to trust XMPP server 1 and 2?

And will XMPP server 2 have my IP address?

> But do I need to trust XMPP server 1 and 2?

You trust whatever server you query. That might be server one, or it might be server one and server two. It's a federated network, so you make requests through your own server.

> And will XMPP server 2 have my IP address?

No. It's a federated network, like email, so it just gets your XMPP address (historically referred to as a "Jabber ID" or "JID").

XMPP is not e2ee, the second server gets your JID (but not your IP, supposing your client doesn't leak it): you need to trust the servers (1, 2 and the resolver).

Also; you don't get virtual circuits, but the performance should be superior. Tor only supports A, AAAA and PTR; DoX supports every record type.

You can connect to XMPP servers over tor, even host them on .onion addresses.

Also, XMPP has e2e extensions, at least one of which supports encrypting/verifying arbitrary XML[1], so if the resolver supported it, you could only trust the resolver. (also don't forget about DNSSEC which can be used to verify DNS responses too)

[1]: https://xmpp.org/extensions/xep-0373.html

Agreed, the best case is when you have e2ee (which unfortunately is not in core) and DNSSEC.

I must admit to being biased against using DNSSEC alone because a malicious XMPP server can still inspect and/or modify queries and responses. By self-hosting you mitigate, but without e2ee the server is still trusted (in the threat-model).

There's an awful lot of "why not?" here. Remember, this is an Experimental XEP. The XMPP Council saw no reason to actively block it, but that doesn't mean we're all mad keen that everyone should rush out and do it.

There was an intense debate on whether it ought to be published as Standards Track or Humorous...

There are, however, already multiple independent implementations:

https://github.com/wiktor-k/prosody-dox

https://github.com/moparisthebest/jDnsProxy

>There was an intense debate on whether it ought to be published as Standards Track or Humorous...

It's just as humorous as DoT or DoH.

I'm sure there are valid reasons, but I also think there's a law that no matter how comprehensive your application protocol, it will eventually get turned into a transport for a higher-level (sometimes shoddier) application protocol.