Page MenuHomeVyOS Platform

Encrypted DNS
Open, WishlistPublicFEATURE REQUEST


Encrypted DNS makes user tracking more difficult for service providers.

Different approaches exist

  • DNS over TLS
  • DNS over HTTPS

It would be nice to set this up in VyOS and let clients use VyOS as their DNS forwarder (announce automatically via DHCP) instead of manually configuring every client manually.

Cloudflare has a free implementation if you need some servers to test.

Most tutorials I found use "unbound" as DNS cache/forwarder.


Difficulty level
Unknown (require assessment)
Why the issue appeared?
Will be filled on close

Event Timeline

syncer triaged this task as Wishlist priority.Oct 19 2018, 5:54 PM

There is no way to signal DOH (DNS over HTTP/S) via dhcp.
DOH and DOT is supported in latest dnsdist packages see and

It should also be a good idea to include dnsdist into vyos for dns cacheing and loadbalancing.

pdns recursor is used for forwarder and we not going to include an additional layer

pdns recursor is from the same people who writes dnsdist.
There are three products wirh diffrent scopes:

pdns-server = Authoritive DNS Server
pdns-recursor = Recursive DNS Server
dnsdist = Loadbalancer, Filter, Cache

The normal setup would be

INTERNET/USER --> DNSDIST (anycast) -- > some pdns-recursor|pdns-server

This is why they implement things like DOH and DOT at first in dnsdist and later on to the other products.

Most ISP's use anycast DNS systems this means you have only one or two IPv4/IPv6 addresses for their users. Cause most resolver libs are not good in handling multiple servers
and errors on one of them. Also you don't want have more pdns-recursors as needed cause you only get good dns performance with massive cacheing. See:

There is no mechanism to distribute caches between recursor instances. So don't create to many recursor instances better a few big and distribute dnsdist in front of them as anycast.
So from my point of view it would be for many setups helpfull to have dnsdist and recursor in vyos so that the user can choose what he need.

@rherold my point bit different
we will take care about DNS little bit later

Just adding a suggestion since cloudflared (argo tunnel) is open source :

Cloudflared can be setup to create a local resolver that forwards upstream DNS queries over https via a yaml configuration

proxy-dns: true
proxy-dns-port: 53

then current dns forwarding can be set to use it

set service dns forwarding listen-address
set service dns forwarding name-server

cloudflared would have to be packaged and a module written to pass arguments like:

set service dns-encryption upstream

I've used the following script to get the argo tunnel running and encrypting dns, i then use as the system nameserver and as the dns forwarder's only upstream nameserver. Works well so far but the integration is lacking with the vyos config

#run as root
curl -OJ
dpkg -i ./cloudflared-stable-linux-amd64.deb
mkdir /etc/cloudflared
echo "proxy-dns: true
proxy-dns-port: 53
 -" | > /etc/cloudflared/config.yml
cloudflared service install
systemctl enable cloudflared
systemctl start cloudflared

Wait, Argo tunnel uses Cloudflare's WARP VPN system, which under the hood is basically wireguard...

There are two possible places where encrypted DNS support might be desired in a standard setup where VyOS is hosting a local resolver/recursor:

  1. On the connection between the local resolver (VyOS) and an upstream DNS resolver — benefit to users is queries to an upstream resolver are prevented from inspection or manipulation by the ISP.
  2. On the connection between client devices and the local resolver (VyOS) — benefit is if end-devices are configured to use the resolver (generally a manual process unless a customer has some sort of MDM solution in place), some operating systems will view that resolver as more trustworthy and preferred over other over-the-top defaults (such as DNS tunneling over iCloud Private Relay for iOS/macOS, or maybe some browser defaults).

I'm not quite clear which of the two this ticket is referring to, best bet would be to consolidate this and other related tickets into two separate asks framed around each of these two usecases.