DNS-TLS Proxy Server

AstLinux supports the unbound package, functioning as a local DNS proxy forwarder using DNS-over-TLS.

The unbound local service functions as a DNS forwarder, used in conjunction with dnsmasq, encrypting and authenticating requests using the DNS-TLS protocol and passing them to an upstream DNS-TLS server.

Note: AstLinux 1.3.3 through 1.4.0 supported DNS-TLS but used stubby

Note: AstLinux 1.4.1 or later uses unbound

Configuring DNS-TLS is as simple as it gets.

Select the Network Tab in the web interface.
Network Tab

Network Services:
DNS-TLS Network Tab

By default DNS-TLS is disabled, to enable, select “enabled” from the menu and click Save Settings and then Restart DNS-TLS.

DNS-TLS Default Configuration

DNS-TLS Default Configuration

The default configuration is to use Quad9 as the DNS-TLS provider, which is a good choice for most users.

Note -> The tilde (~) separated IPv4/IPv6 and Auth_Name must both be defined. The Optional_Port defaults to 853.

The default Quad9 DNS-TLS provider is an “anycast” server, so it should provide reasonable performance throughout the world.

Below is a list of IPv4-only and IPv4/IPv6 entries for various public “anycast” DNS-TLS servers.

Quad9 DNSSEC (block threats/malware)



Quad9 (no filtering, no upstream DNSSEC)



Cloudflare DNSSEC (no filtering)



Cloudflare DNSSEC (block malware)



Cloudflare DNSSEC (block malware/adult)



Google DNSSEC (no filtering)



NextDNS DNSSEC (block threats/malware/trackers/ads) NextDNS Setup
(Replace the xxxxxx with your unique Endpoint ID)



Additional DNS-TLS public servers can be found here: DNS Privacy Public Resolvers

A quick glance of the Status tab's DNS entry will show if DNS-TLS is enabled.

Select the Status Tab in the web interface.
Status Tab

DNS-TLS Proxy Status

The DNS entry “DNS-TLS Proxy Server Enabled” indicates the status. If not, the standard upstream nameserver's will be shown, indicating DNS-TLS is disabled.

By default, no changes to the Firewall settings are necessary for DNS-TLS to function.

Optionally, if AstLinux is acting as the router for your network, you may want to require all LAN devices get their DNS from the internal LAN interface(s) of AstLinux. This may be desired regardless if DNS-TLS is enabled or not. For example, custom web content filtering may be applied by using features of your DNS provider, to be effective you want to route all DNS via a specific server and block any other DNS requests.

Possibly even more important, malware has been known to change a local PC's DNS entries to point to a poisoned DNS server. One more reason to restrict DNS access to only trusted providers.

Therefore, if AstLinux is acting as the router for your network, the following firewall rule will prevent LAN devices from directly using public DNS servers:

Network tab → Firewall Configuration:

Click on Firewall Configuration

The above rule blocks forwarded DNS packets from the LAN to the External interface. The local LAN interface(s) will still be reachable for DNS lookups. Also note this rule does not effect Local→EXT DNS packets.

Note -> If you are using the DMZ interface, you may want to also add a Deny DMZ→EXT rule.

To determine if the above rule is blocking packets, look at your syslog for lines containing:

AIF:Host LAN->INET denied: ... SRC=x.x.x.x DST=y.y.y.y PROTO=UDP DPT=53

The SRC= entry will identify which LAN device is misconfigured.

In order to validate the DNS-TLS provider's certificate, the DNS-TLS client's system must have it's clock set to a reasonable time. Fortunately most AstLinux boards have a real time clock with battery backup so this is not a common problem, but if your board's CMOS battery is dead or such, and the system time is not reasonable at startup, this can be a problem when enabling DNS-TLS. Regardless, one of the first things AstLinux does at startup is to accurately set the system clock using the NTP protocol. If the specified NTP server is a numeric IP address or a locally resolved DNS name (via local /etc/hosts), no problem. But, if the specified NTP server was, say “”, we have the classic chicken-egg problem.

The solution is to configure dnsmasq to resolve a specific domain name with a specific server, where DNS-TLS is not used. For example to resolve all “*” domain names with the Quad9 server “”, we can add the following line into the /mnt/kd/dnsmasq.static file:


Note -> Do not add this line unless required.

  • userdoc/tt_dns_tls_proxy.txt
  • Last modified: 2023/02/17 19:38
  • by abelbeck