Revision 1.


Currently Toxcore supports ToxDNS. This is a service that sits on top of the historically insecure DNS system. With the idea in mind that Toxcore should be a ‘security first’ project; using DNS as a back-end/platform/service, is problematic. That said, while it’s true that knowing, using, and understanding the intent behind a ToxID will make your use of Tox more secure, the primary connection to a friend being a ToxID is a non-starter for most users. An easy and human-readable name-to-ToxID resolution system/service is clearly required from the Tox Messenger. The primary goal of Tox Quick Name Lookup is replace ToxDNS with a more secure, and simpler to maintain/implement system. Secondly, we aim to provide an API that allows clients to quickly, simply, and securely (without the need to create or manage the security themselves) interface with servers of their choosing, without the need to use a 3rd party system/API.


  1. The system must be able to resolve any byte-string to a ToxID.
  2. It must be able to connect to, and resolve any ‘name’ without leaking information (who’s the real info requester, the name of the ToxID searched, or the real ToxID itself).
  3. Under expected/default configuration it must not expose the long term public key of the user requesting information.


The scope of this document is only to cover the replacement for ToxDNS. Many other users/developers/supporters have a wish list for what TQNL could become. But the majority is out of the scope of this revision.

In scope

  1. Create and expose an API that clients can use with Toxcore to make and respond to string-to-ToxID queries.

Not in scope

  1. Distributed name resolution
  2. Signed name resolution
  3. Verified name resolution
  4. Relayed name resolution
  5. Name Server Lookup (method to find an unknown/new name-server)

Technical Design

The nonce exists to identify which packet the server is responding to, as well as prohibit replays, or pre-generation.

Future Plans

This specification is tentative, and intended to provide the lowest level of support. Ideally we’ll be able to enhance TQNL with additional feature sets improving usability, and security.