Having a list of public resolvers to be used with dnscrypt clients is critical.
However, the good old CSV file had quite a few drawbacks.
First, it was centralized. One file, available at a unique URL hardcoded in clients and scripts, maintained by one person. It’s fragile and not sustainable.
In order to address this, dnscrypt-proxy v2 works differently. Users subscribe to one or more “sources”.
A source is a URL returning a list of resolvers, and a public key.
Data from these sources are automatically downloaded, verified, and regularly updated.
So, the OpenNIC organization can autonomously maintain a list of their available resolvers, signed with their own key.
If you run your own private servers, you can list them in a private URL. If you use Kubernetes to spawn the server instances, the source data can be built automatically.
If someone wants to publish a list of resolvers that works well for a given country, or a list of resolvers that block ads, or a list of resolvers responding to non-standard ports, or whatever, they can.
Users just subscribe to the sources they are interested in. Then, they can let the software automatically pick the fastest server in all of the available ones, or explicitly choose a subset of servers from these sources to use.
This doesn’t prevent having some reference page (maybe the dnscrypt-proxy wiki) that lists some of the available/recommended sources.
Which brings us to the second point: what kind of data do these sources return?
The CSV format is a bit unusual for software configuration. But it made sense. After all, the list of resolvers and their properties could be nicely presented as a table.
However:
- CSV is not so easy to edit. Everybody doesn’t use a spreadsheet, and long lines don’t play well with text editors. And CSV is not really normalized (separators and quotes…)
- CSV is not extensible. Columns could be added or removed, if we assume that the first line contains property names, and that software associate individual cells to properties. In practice, doing so is lousy, so most scripts and applications just expect a property to be at a specific column. Adding/removing properties effectively is impossible.
- The CSV file was not great for computers to parse reliably. It was also not great for humans to read, as it contained too much useless information (public keys, IP addresses, protocol version, DNSSEC record), unused information (GPS coordinates), and not enough information (just a couple characters to describe what the server is).
So, I’m looking for suggestions to replace it. Or rather, to add to it, since the legacy CSV format will remain supported as well.
dnscrypt-proxy 2 introduces something called “stamps” (for the lack of a better word). A stamp is a base64 string that contains a protocol identifier (regular non-encrypted DNS, DNSCrypt, DNS-over-HTTP2, …) as well as all the parameters required to connect to a server: IP address, port, public keys, etc.
So, if you want people to use your server, you can just give them a single string to copy&paste.
Back to “what could we replace the CSV file with?”.
I’m looking for suggestions on a better way to publish lists of servers. The new format has to:
- Be easy to parse by scripts
- Be human readable
- Allow freeform text.
It could just be something like:
# example-server-1
This is a DNS server provided by https://example.com, located in India.
It filters out ads and trackers. It doesn’t log anything. It supports DNSSEC, and https://example.com also has cool privacy-oriented free software you should check out.
sdns://unoiwueovqunoeiuqwoienuvioquweo
# example-server-2
Another server in India, but that one doesn’t filter anything. Blablabla.
sdns://weonqviuwenqioevunqwioeuvqwoeqw
We still need some structure to have it parsable (here: the name after the #
and the sdns://
stamps on their own line), but everything else can be freeform.
Note that stamps also include information about DNSSEC support and log/nolog, so GUIs, scripts and applications can still apply filters based on that. In fact, stamps include a 64 bit bitfield, so we have 62 bits left to store other properties.
I need your input. You are running servers, using the software, writing software, maintaining websites, your input on this is really badly needed.
What do you think about the general idea? What should we replace CSV files with? I’d be then glad to implement whatever makes everybody happy.