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
-------------------------------------------------------------------------------
