What is DNS Server Pinning?
Who needs yet another description of how to use DNS with best practices at a network level? Say no more, we’re adding to the dictionary, albeit not nearly as proliferously as Mr. William Shakespeare. Imagine if he was alive today in the world of cyber! We would have serious coinage (pun intended)!
DNS Server Pinning is our attempt to convey the concept of mandating a specific DNS server for all clients on a given network, regardless of their static or cached setting. It applies specifically to layer 3 networks and is only practical for legacy, unencrypted DNS services running on port 53 on a layer 3 gateway.
Why even pin DNS server settings?
In general, it is to apply a specific protective DNS server policy without having to change an endpoints’ configuration. However, consider these additional benefits:
- Any malicious use of a malware-distributing DNS server is hijacked but without the endpoint having any indication of the re-direction
- Legacy equipment statically assigned to some internet DNS server such as 4.2.2.1 is still functional, but now answered by policy
- Systems Administrators have an easy way to spot which endpoints need to be updated via traffic logs
Problematic Cases
Sometimes this approach causes the endpoint’s DNS to fail entirely. Here are three specific cases:
- Endpoint is using an alternate DNS Server on the same network subnet as itself, in which case, there’s no network-level enforcement at layer 3; say if a device at 10.1.1.10/24 is using 10.1.1.11 for DNS, which is in the same subnet
- Endpoint is using static DNS which requires encryption (DNScrypt, DoT, DoH) and has no fallback
- Active Directory DNS Servers to AD DNS Server updates (DC to DC port 53 cannot be intercepted)
How to apply DNS Server Pinning
All of these requirements must be met for a seamless deployment:
- Consider adjustments for endpoints or scenarios that fall into Problematic Cases above
- On pfSense, add a
127.0.0.2/8
alias and configureunbound
to keep running on127.0.0.1
only - Enable DNS server to listen on the dedicated 127/8 interface
- Add a NAT rule that matches any internal traffic destined to the public internet on port 53 for either TCP or UDP, NATted to 127/8 IP
- the rules should look like this on AsusWRT (these rules are inserted by the adam:ONE installation script provided in the adamnet.io/asus instructions):
admin@RT-AC86U-C240:/tmp/home/root# iptables -t nat -L -n -v | grep 53 1913 129K DNAT udp -- * * 0.0.0.0/0 !192.168.50.1 udp dpt:53 to:192.168.50.1:53 335 15080 DNAT tcp -- * * 0.0.0.0/0 !192.168.50.1 tcp dpt:53 to:192.168.50.1:53
- the rules should look like this on pfSense if you follow adamnet.io/pfsense:
[24.11-RELEASE][admin@home.pfsense.arpa]/root: pfctl -sn | grep domain rdr on ix1 inet proto tcp from any to ! (self) port = domain -> 127.0.0.2 rdr on ix1 inet proto udp from any to ! (self) port = domain -> 127.0.0.2
- the rules should look like this on VyOS (instructions at adamnet.io/vyos):
admin@vyos:~$ show nat destination rules Rule Source Destination Proto In-Int Translation ------ ------------- ------------- ------- --------------- --------------- 530 10.53.10.0/24 0.0.0.0/0 IP @I_adamone-ints 10.53.10.1 sport any dport 53 port 53
- the rules should look like this on AsusWRT (these rules are inserted by the adam:ONE installation script provided in the adamnet.io/asus instructions):
- Repeat above for IPv6, if applicable
MDM-delivered DNS Encryption
This article wouldn’t be complete without the mention of the most secure approach, which is available to supervised endpoints. Android and iOS can both receive a pinned DNS server assignment via Mobile Device Management (MDM) platforms. Incidentally, this is also how Microsoft ZTDNS will work - an MDM-delivered protective DoH resolver.
RFC9642 - Discovery of Designated Resolvers
adam:ONE supports this latest standard for endpoints requesting a service binding record for _dns.resolver.arpa
. More details on encrypted DNS here.
Additional notes
The above approach on legacy clear-text DNS is the ADAMnetworks default treatment for smaller networks served with pfSense, while it is not the default on the VyOS platform. VyOS typically serves larger, more complex networks and as such, the network design architect will need to decide the relevancy of this application per network.