About noc_soc

Nowadays you have EDNS which will bypass the old "use TCP if response is larger than 512 bytes". This is handy when more and more DNS traffic uses DNSSEC which in many cases will result in a response which is larger than 512 bytes. Without EDNS the flow would be: * Send query * Get a nack in return (or whatever its called in DNS world) * Send syn * Get synack * Send ack * Send query again * Get response >512 bytes in return * Send finack * Get ack * Get finack * Send ack Compared to (with EDNS): * Send query (with EDNS where you inform that you accept UDP at 1280 bytes or smaller (or whatever size you accept)). * Get response >512 bytes in return The new "safe" sort of standard is 1280 bytes (which is also the lowest MTU a IPv6 link is forced to support). That is if you are using bind you can use something like this in your dns-servers: edns-udp-size 1280; max-udp-size 1280; But this will of course be a problem during DDoS specially when the udp can be easily spoofed (since no handshake takes place and there are too many ISPs out there who doesnt properly filter client connections regarding srcip's being used). The problem is that the attacker spoofs the srcip but now adds a EDNS header informing the dns-server which is being bounced at that the (faked) srcip accepts a 4096 bytes reply (or whatever). Since MTU is often 1500 bytes on the internet this UDP response will of course be over several packets but the point here is that some large query is being performed (for example containing DNSSEC information) which will incorrectly flood the victim (the faked srcip). Some sources: 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. " Also take a look at Cisco ASA 5500 Series Configuration Guide using ASDM, 6.3 - Configuring Dynamic DNS  [Cisco Adaptive Security Device Manager] - Cisco Systems which summarizes which dns-server supports which size by default. Regarding if the threat profiles in PA can look at packetsize aswell I have no clue (at least I failed to locate such in the manuals) - but if you for example choose 1280 bytes as max udp-size for incoming dns packets then make sure that your resolvers are setup according to above edns-udp-size and max-udp-size. ... View more

It's just what we need . Thanks for the reply ... View more