EDNS0 – DNS Extensions #

History #

There are a growing number of issues that we have seen relating to this quite old however only recently used extension to DNS called EDNS0.

The extension was originally outlined in RFC2671 which was published in 1999.

The idea behind these extensions was that the DNS packet itself had a hard limit to its size when originally implemented and nowadays with more and more being done via DNS we had exhausted this hard limit.

One solution would have been to simply extend the size of the DNS packet however this would have caused issues with backwards compatibility with older devices and could have caused more issues than it solved.

With the advent of technologies such as DNSSEC the use of EDNS0 has come more apparent and this is the reason for seeing more and more issues arise over time.

How it works #

Most of the time EDNS0 is not needed and hosts can carry on sending queries as they always have.

If the host believes that the query may be larger than a standard DNS packet it adds an option to the original query to state that the client supports the EDNS0 extension. Within this option it states the maximum size of response that is accepted (up to 4096 bytes) and other details such as version but these are out of the scope to this document.

When the resolver such as Googles public DNS servers or any public cache server receives one of these EDNS0 enabled queries it then knows that the response that it sends back to the client can be sent in a large packet (again, up to 4096 bytes depending on the field in the query).

Issues it causes #

When DNS packets pass through firewalls such as the Cisco ASA they are usually inspected to ensure that they are not malformed or are other packets disguised as DNS packets.

Most of the time an inspect map is used against the DNS packets to set the maximum size to that of the original DNS specification (512-bytes).

When one of the large EDNS0 packets returns from the resolver and it is larger than this 512-byte limit the packet is dropped and a syslog entry triggered:

%ASA-4-410001: Dropped UDP DNS reply from outside:199.7.83.42/53 to inside:1.1.1.1/54266; packet length 1502 bytes exceeds configured limit of 512 bytes

The client does not receive this packet and due to it being UDP and not TCP (connectionless protocol) it just sends the query again and again which in turn means that the client cannot resolve that address and connectivity is broken.

Tests to see if this is happening #

If on a UNIX/Linux/Mac system you can check if the issue affects you using a command such as below:

dig +dnssec +norec +vc +notcp any . @199.7.83.42

If you are on a Windows system you can do a similar check by doing the following:

nslookup -type=TXT rs.dns-oarc.net. 4.2.2.6

If the above return results then EDNS0 resolution is not an issue for you.

Fixes #

There are a couple of fixes that can be used to get around this issue.

One option, which was used prior to ASA version 8.2(2) was to raise the limit of the DNS message size limit, this works however it may also allow malformed / non-DNS packets to make it through. This solution can be implemented by using something similar to the below:

policy-map type inspect dns preset_dns_map
 parameters
  message-length maximum 4096

The other solution and the one recommended is to use the below command that was added in ASA version 8.2(2):

policy-map type inspect dns preset_dns_map
 parameters
  message-length maximum client auto
  message-length maximum 512

When using this second solution the message-length maximum client auto command allows the ASA to inspect the DNS packet to see if the query contains the EDNS0 extension and if so raises the limit to that of the size field in the EDNS0 option. At the same time the message-length maximum 512 command ensures that legacy DNS queries do not go over the 512-byte limit.