[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.
-Doug
More information about the dns-operations
mailing list