DNS has traditionally faced a “last mile” security problem: communication between a DNS client and its local DNS server is almost always unencrypted and therefore susceptible to spoofing, interception, etc. Two proposed mechanisms to address that problem, DNS over TLS (“DOT”) and DNS over HTTPS (“DOH”), can both be used to bypass an organization’s existing DNS infrastructure. However, from a security point of view, this is not the best solution. In this blog I explain how DOT and DOH work and I make recommendations for dealing with DNS client security problems.
What is DOT and DOH?
DNSSEC, a DNS security extension, usually ignores DNS clients when adding authentication and data integrity checks to DNS. The local DNS server performs DNSSEC verification and verifies the authenticity and integrity of the data, but then passes the result to the DNS client in a way that is vulnerable to spoofing. The IETF’s DPRIVE (DNS PRIVate Exchange) Working Group has developed two solutions to this “last mile” problem of DNS: DNS over TLS, also known as “DoT”, as defined in RFC 7858, and DNS over HTTPS, known as “DoH”. ”, enshrined in RFC 8484.
Both DoT and DoH have important functions: The communication between the DNS client and the DNS server is encrypted with DoT and DoH, ensuring data confidentiality and integrity. DNS clients can authenticate to the DNS server using the protocol as desired.
DoT uses a unique TCP port: 853. DoH, on the other hand, uses TCP port 443, which is also used for other HTTPS traffic. This makes it very difficult to separate DoH from other HTTPS traffic.
We generally recommend that customers block direct DNS traffic between any internal IP addresses and the Internet. This prevents certain types of malware, such as DNSChanger, from doing its job, and forces internal hosts to use an IT-managed DNS infrastructure. That internal DNS infrastructure may, for example, enforce a name resolution policy that uses security mechanisms such as Response Policy Zones (RPZs). Unfortunately, DoH makes it very difficult to prevent internal hosts from querying DNS servers on the Internet. (DoT is easier to block because it uses a unique known port.)
In addition, some applications that support DoH intentionally ignore the local DNS client configuration. For example, Mozilla’s Firefox browser provides experimental support for DoH in some versions. When enabled, Firefox ignores all local DNS configuration and sends DNS queries directly to Cloudflare over HTTPS. In doing so, it bypasses all local security mechanisms such as RPZs. In addition, DNS resolution of users becomes invisible to the internal IT organization. This makes it much more complicated to diagnose DNS problems, because now one application on the device (Firefox, in this case) uses different DNS servers than other applications.
The DOH developers had good objectives: their goal was to make web browsing secure in parts of the Internet where eavesdropping on DNS traffic and manipulating DNS responses is unfortunately common. But for use on corporate networks, this is not the most suitable method.
Implementation Recommendations for DOT and DOH
Companies would do well to block direct DNS traffic between internal IP addresses and DNS servers on the Internet, including DoT, DoH and Cloudflare. This should force users to use their organization’s internal DNS infrastructure, allowing internal IT to enforce DNS resolution policies and resolve potential issues.
It’s easy to block standard DNS and DoT traffic between internal IP addresses. Firewall rules like this should suffice:
# Allow queries to the Internet from authorized internal DNS servers
Allow TCP/UDP in/outAuthorized Internal DNS Server 1> port 53. Feather
# Reject queries to the Internet from other internal IP addresses
Deny tcp/udp in/out of all IP addresses on port 53
Refuse tcp/udp in/out to all IP addresses on port 853
DoH is more difficult to block, as a firewall cannot distinguish it from HTTPS, but the following firewall rules should work:
# Block DoH on Cloudflare
Deny tcp/udp in/out on port 443 in 220.127.116.11
Deny tcp/udp in/out 18.104.22.168 on port 443
Denied TCP/UDP in/out on port 443 2606:4700:4700::1111
Deny tcp/udp in/out on port 443 at 2606:4700:4700::1001
# DoH block Google Public DNS
port 443. but deny tcp/udp in/out until 22.214.171.124
Deny tcp/udp in/out on port 443 in 126.96.36.199
tcp/udp in/out on port 443 denied until 2001:4860:4860::8888
tcp/udp in/out on port 443 denied 2001:4860:4860::8844
The DNS “last mile” issue should be resolved. This is why the Infoblox Internet Systems Consortium is working closely with our partner to add DOT support to the next version of Bind and then to Infoblox NIOS.
This is an attachment submitted by Cricket Liu, Chief DNS Architect of Infoblox. Through this link you will get more information about the prospects of the company.
Alcohol maven. Incurable pop culture specialist. Communicator. Gamer. Certified explorer.