RE: DNS ACL ?

From: Dario Ciccarone (dciccaro) (dciccaro@cisco.com)
Date: Wed Nov 23 2005 - 15:59:44 EST


> >RFC-2671 ('Extension Mechanisms for DNS (EDNS0)') updates
> RFC-2671 and
> >allows 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
-------------------------------------------------------------------------------



This archive was generated by hypermail 2.1.7 : Sat Apr 12 2008 - 10:55:11 EDT