DNS-TLS Proxy Server

AstLinux now supports the getdns/stubby package, a local DNS Privacy stub resolver using DNS-over-TLS. Getdns/Stubby encrypts local DNS queries forwarded to upstream recursive DNS-TLS servers.

The stubby 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.

Info → DNS and Privacy talk by Sara Dickinson, Sinodun - YouTube

Note: AstLinux 1.3.3 or later is required

DNS-TLS Proxy Configuration

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

The “DNSSEC Validation” selection defines the stubby dnssec_return_status configuration. By default, any DNSSEC validation is expected to be performed by the upstream recursive server. Offloading the DNSSEC validation upstream via a secure channel is the fastest method.

DNS-TLS DNSSEC Configuration

If you want to enable the stubby dnssec_return_status configuration, select the “perform local validation” option. In this case the local DNS-TLS proxy will perform DNSSEC validation. Local validation forces additional DNS lookups and slightly slows the overall response time. Perform local validation when the upstream recursive server does not perform DNSSEC validation or you don't trust it's validation.

The “Query Server(s)” selection defines the stubby round_robin_upstreams configuration. By default, only the first upstream recursive server entry is used to handle all DNS queries. If that server becomes unavailable then the next server in the list will be used to handle all DNS queries.

Tip → The default “one until unavailable, then next” generally yields the best performance.

DNS-TLS Query Configuration

If you want to enable the stubby round_robin_upstreams configuration, select the “across all available server(s)” option. In this case all DNS queries will be sequentially distributed across all the upstream recursive server entries.

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.

DNS-TLS Proxy server list

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

If your external connection supports native IPv6, you may want to add the Quad9 IPv6 server.

2620:fe::fe~dns.quad9.net
9.9.9.9~dns.quad9.net
149.112.112.112~dns.quad9.net

If you prefer Cloudflare, the IPv4 DNS-TLS “anycast” servers are:

1.1.1.1~cloudflare-dns.com
1.0.0.1~cloudflare-dns.com

or, Cloudflare IPv6 DNS-TLS “anycast” servers:

2606:4700:4700::1111~cloudflare-dns.com
2606:4700:4700::1001~cloudflare-dns.com

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

Display DNS-TLS Status

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.

Restricting DNS

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.

Possible Startup Issues

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 “us.pool.ntp.org”, 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 “*.pool.ntp.org” domain names with the Quad9 server “9.9.9.9”, we can add the following line into the /mnt/kd/dnsmasq.static file:

server=/pool.ntp.org/9.9.9.9

Note → Do not add this line unless required.