Penetration Testing mailing list archives
RE: DNS ACL ?
From: "Dario Ciccarone (dciccaro)" <dciccaro () cisco com>
Date: Wed, 23 Nov 2005 15:59:44 -0500
RFC-2671 ('Extension Mechanisms for DNS (EDNS0)') updatesRFC-2671 andallows for packet sizes > 512 when using UDP as transport. A reference from MS: http://support.microsoft.com/kb/828263 Some queries that might exceed the 512-byte size are those like, for example, www.microsoft.com or www.yahoo.com, due to the number of A records returned. So, you will probably be OK with only allowing 53/udp to your DNS server.That's not always true. Yes, DNS extensions have a mechanism to increase the UDP message size. However, both sides (clients and servers) are involved in the process of negotiating those big messages. Not all DNS clients automatically try to negotiate bigger UDP messages. The same goes for DNS servers. And there's always security devices somewhere on the network that may not allow those extensions... either by stripping or disallowing the udp message size option or simply by ignoring (/not understanding) them. My recommendation is to not rely on any extended DNS functionality. Kyle
That's true - as an example, PIX firewalls pre 6.3(2) only allowed DNS UDP traffic <= 512. So, back to the start. RFC-1035 - section 4.2. Transport, subsection 4.2.1. UDP usage : "Messages sent using UDP user server port 53 (decimal). Messages carried by UDP are restricted to 512 bytes (not counting the IP or UDP headers). Longer messages are truncated and the TC bit is set in the header." So far, so good. Then RFC-2181 - "Clarifications to the DNS Specification", section "9. The TC (truncated) header bit": " 9. The TC (truncated) header bit The TC bit should be set in responses only when an RRSet is required as a part of the response, but could not be included in its entirety. The TC bit should not be set merely because some extra information could have been included, but there was insufficient room. This includes the results of additional section processing. In such cases the entire RRSet that will not fit in the response should be omitted, and the reply sent as is, with the TC bit clear. If the recipient of the reply needs the omitted data, it can construct a query for that data and send that separately. Where TC is set, the partial RRSet that would not completely fit may be left in the response. When a DNS client receives a reply with TC set, it should ignore that response, and query again, using a mechanism, such as a TCP connection, that will permit larger replies. " Key things to keep in mind here - RFC-2181 is a "Proposed Standard". Also, from RFC-2119, "Key words for use in RFCs to Indicate Requirement Levels": " 3. SHOULD This word, or the adjective "RECOMMENDED", mean that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course. " So, the whole 'query over TCP if TC set' is a 'should' - not a 'must'. Same goes for EDNS0. Many resolver implementations are probably doing it - while there could be others that don't, or devices that just plain not process TCP/53 as queries, but only as zone transfers. Leaving the whole RFC mumbo-jumbo aside, my point is simple: as with any other security setup, you shouldn't allow traffic into your network that isn't strictly required. So if the original poster does NOT need to allow 53/TCP to his/her DNS server, because he's absolutely, positively sure the replies are never going to be > 512 bytes . . . Why would he allow it then? Dario ------------------------------------------------------------------------------ Audit your website security with Acunetix Web Vulnerability Scanner: Hackers are concentrating their efforts on attacking applications on your website. Up to 75% of cyber attacks are launched on shopping carts, forms, login pages, dynamic content etc. Firewalls, SSL and locked-down servers are futile against web application hacking. Check your website for vulnerabilities to SQL injection, Cross site scripting and other web attacks before hackers do! Download Trial at: http://www.securityfocus.com/sponsor/pen-test_050831 -------------------------------------------------------------------------------
Current thread:
- Re: DNS ACL ?, (continued)
- Re: DNS ACL ? Thor (Hammer of God) (Nov 13)
- Re: DNS ACL ? Richard C Lewis (Nov 13)
- Re: DNS ACL ? Chris Brenton (Nov 13)
- Re: DNS ACL ? Lynx (Nov 13)
- Re: DNS ACL ? Justin Ferguson (Nov 14)
- Re: DNS ACL ? John Nemeth (Nov 13)
- RE: DNS ACL ? Maher Odeh (Nov 13)
- FW: DNS ACL ? Dario Ciccarone (dciccaro) (Nov 21)
- RE: DNS ACL ? Kyle Quest (Nov 22)
- RE: DNS ACL ? Dario Ciccarone (dciccaro) (Nov 24)
- RE: DNS ACL ? Dario Ciccarone (dciccaro) (Nov 24)
- RE: DNS ACL ? John Hally (Nov 26)