EDNS0 Packet blocked

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Announcements

EDNS0 Packet blocked

L2 Linker

Hi,

We have internal DNS’s that send query EDNS packets and
those packets apparently are blocked by our Firewall (PA-3050 IOS Version
5.0.2)

I didn’t find any doc or discussion here about this issue

Could someone help me to allow those packets pass through
our FW. (increase the DNS packet size as described for example below for a
juniper FW)

Thanks a lot

Summary:

This article provides information how to allow the EDNS
queries pass through the SRX firewall, with DNS ALG enabled.

Problem
or Goal:

    • The basic DNS protocol is
           not sufficient to support some required features. Moreover, DNS messages
           carried by UDP were restricted to 512 bytes; not considering the Internet
           Protocol (IP) and Transport Layer headers.

      • EDNS (Extension mechanisms
             for DNS) is a specification for expanding the size of several parameters
             of the Domain Name System (DNS) protocol, which had prior size
             restrictions.

        • In practice, difficulties
               can arise when using EDNS to traverse firewalls, as certain firewalls
               assume a maximum DNS message length of 512 bytes and block longer DNS
               packets.

          • EDNS (as per RFC 2671)
                 queries are dropped by the SRX firewall, with DNS ALG enabled.

Cause:

Solution:

To allow EDNS queries to pass through the SRX firewall, with DNS ALG
enabled, run the following command from the configuration mode:

user# set security alg dns
maximum-message-length 8192

Note: The above setting is valid only from 10.1 or later, to
10.2. From 10.2 onwards, the limitation of 512 bytes will be removed; so the
above command will no longer be required from 10.2 or later.


2 REPLIES 2

L5 Sessionator

Hello BSadozai


Today, we do not support the EDNS RFC 2671. Usually, if DNS servers enabled with EDNS tries to talk to a non-EDNS server, the non-EDNS servers will simply ignore the OPT request and will not negotiate a larger packet size.

However, I do see a feature request (FR) submitted to our development team to potentially add it to our upcoming releases. You can also request your account's SE to vote for it.

FR ID : 2315

Hope that information helps!

Thanks and regards,

Kunal Adak

To summarize my findings regarding EDNS:

If you are using BIND then add one of these values to your BIND config:

max-udp-size 1460;

edns-udp-size 1460;

or

max-udp-size 1280;

edns-udp-size 1280;

whatever floats your boat.

According to http://www.cisco.com/en/US/docs/security/asa/asa83/asdm63/configuration_guide/ddns.html one could say that:

- Old standard: max 512 bytes for UDP (DNS).

- New standard: max 4096 bytes for UDP (DNS).

- Microsoft standard: max 1280 bytes for UDP (DNS).

where 1280 seems to be connected to that 1280 is the smallest allowed MTU for IPv6 networks.

References:

http://tools.ietf.org/html/draft-andrews-dnsext-udp-fragmentation-01

"

If the IPv6 stack does not support IPV6_USE_MIN_MTU, then steps

should be taken to prevent PMTUD occuring.  These include, but are

not limited to, setting the MTU of the interface the packets are

being sent over to the minimum IPv6 MTU (1280 bytes), or restricing

DNS/UDP packets to no more than 1280 bytes including IPv6 headers.

"

http://www.ietf.org/rfc/rfc2671.txt

"

4.5.1.

Note that a 512-octet UDP payload requires a 576-octet IP

reassembly buffer.  Choosing 1280 on an Ethernet connected

requestor would be reasonable.  The consequence of choosing too

large a value may be an ICMP message from an intermediate

gateway, or even a silent drop of the response message.

"

http://tools.ietf.org/html/draft-ietf-dnsind-udp-size-02

"

1280 bytes of DNS data is chosen as the new default to provide a

generous allowance for IP headers and still be within the highly

prevalent approximately Ethernet size or larger MTU and buffering

generally available today.

An IPv6 server should enable fragmentation on UDP replies.  While

fragmentation will not be frequent if the above guidelines are

followed, it may occur on occasion. In principle, IPv6 headers and

options could be huge, resulting in a very large UDP packet even

though the DNS payload is limited, but this should not occur in

practice.

"

Way to test if you are affected of any EDNS bugs in your infrastructure:

>dig +short rs.dns-oarc.net txt

and then check the logs of your firewalls etc.

  • 6145 Views
  • 2 replies
  • 0 Likes
Like what you see?

Show your appreciation!

Click Like if a post is helpful to you or if you just want to show your support.

Click Accept as Solution to acknowledge that the answer to your question has been provided.

The button appears next to the replies on topics you’ve started. The member who gave the solution and all future visitors to this topic will appreciate it!

These simple actions take just seconds of your time, but go a long way in showing appreciation for community members and the LIVEcommunity as a whole!

The LIVEcommunity thanks you for your participation!