[dns-operations] DNS maximum packet size

Douglas Otis dotis at mail-abuse.org
Mon Sep 21 01:02:33 UTC 2009

On 9/18/09 10:50 AM, Patrick, Robert wrote:
> Are firewall vendors working to increase the default settings for DNS
> maximum packet size in order to better support EDNS and DNSSEC?

This expects UDP-DNS with frames exceeding IEEE maximum length will not 
become a popular means for reflected attack, even though this creates an 
attractive level of amplification off of robust servers.  Servers that 
can neither block nor be blocked without causing disruption. Deployment 
of BCP38 can be problematic, and is not widespread enough to afford 
reasonable levels of protection.

When the PMTU is restricted, TCP-DNS will likely become the option 
attempted.  However, TCP requires servers to retain unacknowledged data 
to support packet-loss recovery.  Without frame alignment, any change to 
a DNS message that is being retried could lead to message corruption. 
TCP only handles bytes, and not messages.

TCP must also avoid SYN Floods and half closed connections.  See RFC 
4987 describing non-standard mitigation strategies, such as SYN Cookies, 
and SYN Caches.

> Cisco firewalls have a default maximum packet size for DNS set to 512
> bytes, and I'm going to guess similar settings exist for other vendor
> firewalls.

This frame limitation remains common, and is likely to conserve limited 
resources by avoiding packet reassembly.  After all, packet 
fragmentation introduces several serious security concerns as well.

> A recent inquiry to increase the default setting for DNS maximum packet
> size enforcement on Cisco firewalls was answered with "the default
> configuration change is not on our firewall roadmap".
> Is anybody working to get the vendors to put this change into product
> roadmaps, especially as year-end approaches and the OMB deadline is
> reached?

Rather than promoting large UDP frames that lessen error detection rates 
and increase amplification risks, it would be better to ensure vendors 
properly implement SCTP handling.  Although SCTP over UDP is compatible 
with legacy equipment, SCTP over UDP should not be a goal.

SCTP avoids amplification risks by exchanging cookies.  SCTP offers 
message framing, allows unordered and unreliable delivery, enhances 
error detection suitable for jumbo frames, and detects bus bit errors 
that UDP or TCP may fail to detect 2% of these common events.  SCTP will 
greatly benefit the next generation of high speed Internet applications.

If DNS had initially used SCTP, spoofs issued over a 10Gb/s network to a 
static port would be limited to a success rate of once every 80 years 
without altering the current DNS message format.  The "send-it" and 
"forget-it" mode used by UDP-DNS to minimize server state can be 
replicated by SCTP's unreliable unordered delivery mode.  Even 
associations that are idle for some number of seconds can be auto closed 
by the transport.

> Example configuration change for Cisco ASA and FWSM shown below:
> --/--
> conf t
> policy-map type inspect dns preset_dns_map
>   parameters
>    message-length maximum 4096
> policy-map global_policy
>   class inspection_default
>    inspect dns preset_dns_map
> end

Promotion of large frame UDP-DNS is likely to become problematic. 
TCP-DNS will likely prove to be expensive and poorly supported by 
today's DNS server deployments. Introducing new non-standard versions of 
TCP are also likely to introduce unforeseen security issues.  SCTP 
represents safe approach for those seeking to improve DNS security.


More information about the dns-operations mailing list