DNS Privacy Services

We operate DNS privacy services to help protect DNS traffic and to help diversify the DNS resolver landscape offering modern protocols.

If you would like to learn more about our privacy practices with regards to logging you might want to have a look at our privacy policy.

We do not provide DNS filter services, our resolvers provide the information they get from the authoritative DNS servers.

Choose a DNS server you trust, since it will handle (and see) all DNS queries you send it.

Our servers are located in Vienna, Austria. Everyone is free to use them but you might want to consider your location (distance/latency to us) before enabling them in your configuration.

DNS-over-HTTPS (DoH)

DoH is specified in RFC8484. A DoH client sends DNS queries over a HTTPS connection to the resolver to ensure confidentiality and integrity.

We operate the following DoH server for the general public:

  • https://doh.appliedprivacy.net/query

This is an experimental service which is operated on a best effort basis.

DoH Clients


Mozilla Firefox supports DoH, to make use of it, you have to specify which DoH server should be used.

Firefox: Edit -> Preferences -> Network Settings -> "Enable DNS over HTTPS" -> Custom



After enabling DoH you can check the TRR column in "about:networking#dns", a "true" in that column means the domain has been resolved using the configured DoH server.

Note: This enables Firefox's "TRR first" mode, which will cause cleartext queries via the native resolver in cases where the DoH server was not able to provide a useful answer (or you had a typo in the domain). This is to address the split-horizon issue. If you only access public domains (which the DoH server should be able to resolve) then you can avoid cleartext queries by using Firefox's "TRR only" mode (which requires you to also set 'network.trr.bootstrapAddress'). "TRR only" mode might cause issues should you ever be behind "captive portals" (i.e. in public WIFIs). Read more about Firefox DoH settings here.

DNS-over-TLS (DoT)

DoT (RFC7858) - like DoH - encrypts DNS traffic between the client and the resolver but does not make use of HTTPS. It encapsulates DNS traffic directly in TLS which means less metadata (better). Unfortunately main browser vendors choose to implement DoH only.

Modern Android versions support DoT.

We operate the following DoT servers:


  • IPv4 address:
  • IPv6 address: 2a00:63c1:a:229::3
  • TCP port: 443 or 853
  • Name for TLS verification: dot1.appliedprivacy.net
  • TLSA record: available
  • TCP Fast Open support: no

For redundancy reasons we recommend to use more than just our DoT server in your configuration.

DoT Clients

Android 9

Android 9 comes with a DoT client by default.

Stubby (Windows, macOS, Linux)

Stubby is a popular DoT client, which supports the strict profile (TLS connection is authenticated, no fallback) uses modern TLS ciphers and even includes features like padding and DNSSEC. Our DoT server is included in stubby's example config file.

DNS-over-Onion (TCP)

We also provide an onion endpoint for those that want to experiment with it.

This is a TCP (not DoT or DoH) endpoint. Transport level encryption is provided by the onion layer.

  • onion address: gdbr6pm66tzpavenstxove4ftwil52onqmhwioyb7dffojc6h56saoqd.onion
  • port: 53

This is an onion v3 service without server-side location anonymity to reduce the hop-count and latency.

Supported Standards

Our service supports a series of standards that aim to reduce the unnecessary exposure of DNS query data.

  • QNAME minimisation (RFC7816) is enabled to reduce query disclosure to 3rd parties

  • we run a copy of the root zone on loopback (RFC7706) to minimize the amount of queries we send to DNS root servers and to reduce latency

  • our resolvers perform DNSSEC-validation

  • Aggressive Use of DNSSEC-Validated Cache (RFC8198)

  • prefetching is enabled to reduce latency and make correlation of inbound and outbound connections harder.

  • TLS 1.2 and TLS 1.3 only

  • TLS session resumption

  • EDNS0 TCP keepalive Option (RFC7828)

  • we have TLSA records for our DNS endpoints (CA Constraint)

  • we do not set EDNS client subnet (RFC7871)

  • TCP Fast Open (RFC7413) is available on the DoH service

Our Wishlist

We hope to support the following in the future as they get implemented and enabled in the software and packages we use: