Cloudflare has a nice page for various fun ways to query DNS (via Twitter, Google Sheets, email, etc.): https://developers.cloudflare.com/1.1.1.1/fun-stuff/

It seems DoX would fit in there perfectly!

I wonder how one would go about contacting someone at cloudflare responsible for that... :)

I'd draw your attention to:

* the name of the protocol: DoX

* the name of the request: IQ-get

* lastly, the current date

edit: OK, this might not be a joke after all, but it sure has a few hints in there.

DoX is DNS-over-XMPP

DoH is DNS-over-HTTP

DoT is DNS-over-TLS

Yah, naming a DNS protocol DOX and then releasing it on the worst day of the year on the internet might not have been a great idea… I suppose we should have seen this coming :)

date of the XEP is 2019-03-29, so no april fools day XEP.

> * the name of the request: IQ-get

IQ is the usual abbreviation for info/query elements in XMPP ...

>* lastly, the current date

Have you read it completely?

>Version 0.0.1 (2019-03-11)

hmm... interesting, but why?

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.

[deleted]

This is a real protocol. It just got published yesterday and made its way onto HN today.

Purely curious, what advantages does this give you in a corporate sort of scenario where your login is probably authing against Active Directory? Does this protocol offer any leverage for developers in a multi-forest setup via API to programmatically choose domain controllers?