EDNS(0) – Extension Mechanisms for DNS

I’m reading, working and studying about EDNS(0) because a customer wants something similar to a parental control service that restricts access to particular domains from particular devices, as a result, we need a device-specific identifier. We need a precise client identity information for this requirement. There will be lots of laptops on the Internet and it’s unlikely that we can configure a VPN tunnel for each laptop. Therefore, DNS servers and DNS requests will go through Internet. I’m thinking whether EDNS(0) fits this requirement.

The DNS protocol send messages by UDP and it was restricted to 512 bytes but, in 1999, there was a proposal to extend DNS to allow for new flags and response codes, and to provide support for longer responses. This extension mechanism is EDNS and it has increased the functionalities of the protocol. EDNS adds information to DNS messages in the form of pseudo-Resource Records (“pseudo-RR”). For instance, the OPT pseudo-record provides space for up to 16 flags. One of them is the DNSSEC flag but there are also flags for Client Subnet (ECS) and Device ID.

Review of OPT Option Codes

Firstly, I’ve been reading about DNSSEC which is a security extension to DNS for cryptographic authentication and data integrity, but not confidentiality, which means, all DNSSEC responses are authenticated but not encrypted. Therefore, it was designed to protect applications from using forged or manipulated DNS data, such as that created by DNS cache poisoning. This security extension doesn’t fit the requirement I’m looking for because there is no way to identify the user device.

DNSSEC - Authenticity of DNS records

Another extension I’ve been reading is Client Subnet (ECS). I was already reading about it two years ago when F5 BIG-IP DNS included this feature in v14.0. The BIG-IP places the client IP address into the EDNS0 field to determine the topology proximity of the client. This feature improves too much the use of DNS-based load balancing to select a service address near the client when the client computer is not necessarily near the recursive resolver. However, the ECS feature is not enough either to identify users’ computers.

With EDNS0 Client Subnet Support

Finally, I think I’ve found how to identify the user computer. There is already a DNS EDNS option to carry a client-specific identifier in DNS queries, but it’s still a draft. However, dnsmasq uses EDNS option code 65073 from the “Reserved for Local/Experimental Use” range to pass the client’s MAC address, or the Cisco Umbrella implementation which encodes the client’s MAC address with the option code 26946 from the “Unassigned” range. I can use F5 BIG-IP to authenticate users’ computers as DoH proxy farm and forward the DNS requests with the client identification in the EDNS field to the internal DNS server for analysis, filtering, cache control and recurses the request. What do you think?

Building a private DoH infrastructure

To sum up, EDNS has improved a lot the DNS protocol and it’s really useful for client identification, DNS-based load balancing and DNS Security.

Regards my friends! Have you ever configured EDNS?