- Access exclusive content
- Connect with peers
- Share your expertise
- Find support resources
11-22-2013 07:13 AM
Has anyone implemented EDNS on their network? How does the firewall treat it? Is it just as DNS? Does it block it because the packets are too big?
Does anyone know if there is a plan to make it its own discreet application?
Thanks for the info...
Ben
11-22-2013 07:27 AM
Hello bgranholm,
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
11-22-2013 07:27 AM
Hello bgranholm,
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
11-22-2013 07:39 AM
So how does the Firewall classify this traffic now? unknown-udp or unknown-tcp?
11-22-2013 07:47 AM
Hello bgranholm,
The DNS decoder does not enforce a length check for EDNS, and so the traffic should still be identified as DNS.
Thanks and regards,
Kunal Adak
12-01-2013 10:37 AM
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.
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!