source: https://www.afnic.fr/en/resources/blog/yeti-dns-over-tls-public-resolver.html

There is a new DNS-over-TLS public DNS resolver, and it uses the Yeti root. You want explanations? You’re right.

First, about DNS-over-TLS. The DNS (Domain Name System) protocol is a critical part of the Internet infrastructure. It is used for almost every transaction on the Internet. By default, it does not provide any privacy (see RFC 7626 for a complete discussion of DNS privacy considerations). Among its weaknesses is the fact that, today, DNS requests and responses are sent in the clear so any sniffer can learn that you are interested in www.aa.org or jane-smith-server.accounting.company.example. To address this specific problem, a standard for encryption of DNS requests and responses, using the well-known protocol TLS (Transport Layer Security), has been developed. The standard is in RFC 7858.

As of today, there are very few DNS resolvers that accept DNS-over-TLS. The typical ISP resolver, or the big public resolvers, don’t use it. Sadly, this is also the case of resolvers pretending to provide a service for people who do not trust the other resolvers. (See an up-to-date list of existing public resolvers.)

And Yeti, what is it? It is an alternative DNS root which focus, not on creating “dummy” TLDs and selling them, but on technical experimentations about the DNS root service, experimentation which cannot be done on the “real” root, which is way too sensitive. Note there was no public Yeti resolver. To use the Yeti root, the only way was to configure your resolver to forward to the Yeti root.

But, first, a warning: Yeti is a technical experimentation, not a political one. Be aware that DNS queries to the Yeti root name servers are stored, and studied by researchers. (This is the same with the “real” root, by the way, not to mention the unofficial uses such as MoreCowBell.)

Since there are few DNS-over-TLS resolvers, and in order to gather more information from experience, we have set up a public DNS-over-TLS resolver using the Yeti root. It answers on the standard DNS-over-TLS port, 853, at dns-resolver.yeti.eu.org. It is IPv6-only, which makes sense for Yeti, whose name servers use only IPv6.

Two warnings: it is an experimental service, managed only on a “best effort” basis, and since it sends requests to the Yeti root, the user’s data is captured and analyzed. So, it is to test technically privacy-enhancing techniques, not to provide actual privacy. (We would be glad to see a real privacy-enabled public DNS resolver, with DNS-over-TLS and other features.)

Usage

Today, most DNS clients cannot speak DNS-over-TLS. If you want to use it and don’t know DNS-over-TLS clients, you can find some listed at the DNS privacy portal.

A way to use this service as a forwarder for a local resolver. The Unbound server can do that with a setup like:

server:
  ...
  auto-trust-anchor-file: "autokey/yeti-key.key"
  ssl-upstream: yes

forward-zone:
  name: "."
  #forward-host: "dns-resolver.yeti.eu.org" # Or the IP address:
  forward-addr: 2001:4b98:dc2:43:216:3eff:fea9:41a@853
  forward-first: no

If you have the getdns utilities installed (for instance via the Debian package getdns-utils), you can test the resolver with the command getdns_query:

% getdns_query  @2001:4b98:dc2:43:216:3eff:fea9:41a -s -l L www.eff.org AAAA
...
  "just_address_answers":
  [
    {
      "address_data": <bindata for 2a04:4e42:1b::201>,
      "address_type": <bindata of "IPv6">
    }
  ],
...

If you use the proxy Stubby, you can run it with:

% stubby  @2001:4b98:dc2:43:216:3eff:fea9:41a -L

(Or similar arguments from Stubby configuration file.)

Good luck with this service and, if there is a problem, do not hesitate to ask details and/or help on the Yeti mailing lists.

Implementation

The public resolver itself is implemented with Unbound. Here is its configuration:

server:
  use-syslog: yes
  root-hints: "yeti-hints"
  auto-trust-anchor-file: autokey/yeti-key.key
  interface: 2001:4b98:dc2:43:216:3eff:fea9:41a@853go
  qname-minimisation: yes
  harden-below-nxdomain: yes
  harden-referral-path: yes
  harden-glue: yes
  ssl-service-key: "/etc/unbound/tls-server.key"
  ssl-service-pem: "/etc/unbound/tls-server.pem"
  ssl-port: 853
  access-control: ::0/0 allow
  log-queries: yes

As you see, the requests (query name and source IP address) are logged locally (see above the warning about privacy) but not transmitted. The query name is sent to the Yeti coordinators.

(You can also see that, today, QNAME minimisation (RFC 7816 is activated on this resolver, thus limiting the amount of data sent to the Yeti root name servers.)