DNS problems to RoadRunner - tcp vs udp

Mailman List Mirror (Read Only)
1

Date: Fri, 13 Jun 2008 14:14:55 -0400
From: Jon Kibler <Jon.Kibler@aset.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Mark Price wrote:
<SNIP>
>>From what I have read, public DNS servers should support both UDP and
> TCP queries. TCP queries are often used when a UDP query fails, or if
> the answer is over a certain length.
>

UDP is used for queries.

Sometimes.

TCP is used for zone transfers.

Yes.

If my server responded to TCP queries from anyone other than a secondary
server, I would be VERY concerned.

If it does not, you should be very concerned. The RFCs (several, but
I'll point first to good old 1122) allow either TCP or UDP to be used
for any operation that will fit in a 512 byte transfer. (EDNS0 allows
larger UDP.)

TCP is to be used any time a truncated bit is set in a replay. If you
ever send a large reply that won't fit in 512 bytes, the request will
be repeated using a TCP connection. If you ignore these, your DNS is
broken. It is even allowed under the spec to start out with TCP, as AXFR
queries typically do.

Yes, I realize that this is fairly common and it does not break much,
but, should DNSSEC catch on, you might just find the breakage a bit
worse than it is today and there is no reason to have even the slight
breakage that is there now.

2

Kevin Oberman wrote:

If it does not, you should be very concerned. The RFCs (several, but
I'll point first to good old 1122) allow either TCP or UDP to be used
for any operation that will fit in a 512 byte transfer. (EDNS0 allows
larger UDP.)

TCP is to be used any time a truncated bit is set in a replay. If you
ever send a large reply that won't fit in 512 bytes, the request will
be repeated using a TCP connection. If you ignore these, your DNS is
broken. It is even allowed under the spec to start out with TCP, as AXFR
queries typically do.

Yes, I realize that this is fairly common and it does not break much,
but, should DNSSEC catch on, you might just find the breakage a bit
worse than it is today and there is no reason to have even the slight
breakage that is there now.

Okay, I stand corrected. I was approaching this from a security
perspective only, and apparently based on incorrect information.

But this leaves me with a couple of questions:

Various hardening documents for Cisco routers specify the best practices
are to only allow 53/tcp connections to/from secondary name servers.
Plus, from all I can tell, Cisco's 'ip inspect dns' CBAC appears to only
handle UDP data connections and anything TCP would be denied. From what
you are saying, the hardening recommendations are wrong and that CBAC
may break some DNS responses. Is this correct?

Also, other than "That's what the RFCs call for," why use TCP for data
exchange instead of larger UDP packets?

Jon Kibler
- --
Jon R. Kibler
Chief Technical Officer
Advanced Systems Engineering Technology, Inc.
Charleston, SC USA
o: 843-849-8214
c: 843-224-2494
s: 843-564-4224

My PGP Fingerprint is:
BAA2 1F2C 5543 5D25 4636 A392 515C 5045 CF39 4253

3

First: if you don't allow TCP queries, then you're going to break lots
of recent applications for DNS.

Second: unless your server and resolver support EDNS0, there is no way
to increase the size of a UDP response, and even then, it's not large
enough for many applications (ENUM, TXT, APL, etc.).

TCP response to queries has been specified since RFC1035. The maximum
message size is limited to 65535 bytes (due to the 16bit message size
field before the header).

RE the Cisco questions: this would not be the first time Cisco lagged in
supporting enhanced services on the network.

4

Jon Kibler wrote:

Various hardening documents for Cisco routers specify the best practices
are to only allow 53/tcp connections to/from secondary name servers.
Plus, from all I can tell, Cisco's 'ip inspect dns' CBAC appears to only
handle UDP data connections and anything TCP would be denied. From what
you are saying, the hardening recommendations are wrong and that CBAC
may break some DNS responses. Is this correct?

A number of Cisco default from years gone by would break DSN, today, in it's current form. Such as how PIXs and ASAs with fixup/DPI would block udp/53 packets larger than 512 bytes, not permitting EDNS packets through.

5

Justin Shore wrote:

Jon Kibler wrote:

Various hardening documents for Cisco routers specify the best practices
are to only allow 53/tcp connections to/from secondary name servers.
Plus, from all I can tell, Cisco's 'ip inspect dns' CBAC appears to only
handle UDP data connections and anything TCP would be denied. From what
you are saying, the hardening recommendations are wrong and that CBAC
may break some DNS responses. Is this correct?

A number of Cisco default from years gone by would break DSN, today, in it's current form. Such as how PIXs and ASAs with fixup/DPI would block udp/53 packets larger than 512 bytes, not permitting EDNS packets through.

Thunderbird apparently thought that I was ready to send my message before I did. I was going to add some ASA config as an example.

policy-map type inspect dns migrated_dns_map_1
  parameters
   message-length maximum 2048

I don't have an IOS CBAC example but there's surely something similar.

Justin

6

Jon Kibler <Jon.Kibler@aset.com> writes:

Okay, I stand corrected. I was approaching this from a security
perspective only, and apparently based on incorrect information.

It always puzzles me when people say things like that - it's as if
they've lost sight of the *whole point* of security being to protect
services, data, etc. and ensure that they continue uninterrupted and
uncorrupted. If one is approaching problems "from a security
perspective only" with no concern to breaking services... wouldn't
the even more secure solution involve just reaching for the power
switch?

But this leaves me with a couple of questions:

Various hardening documents for Cisco routers specify the best practices
are to only allow 53/tcp connections to/from secondary name servers.
Plus, from all I can tell, Cisco's 'ip inspect dns' CBAC appears to only
handle UDP data connections and anything TCP would be denied. From what
you are saying, the hardening recommendations are wrong and that CBAC
may break some DNS responses. Is this correct?

I bet if you look in these same hardening documents you'll find
suggestions for static bogon filters (which become stale over time),
filtering all ICMP (breaks PMTUD) and all sorts of other jack moves.

Also, other than "That's what the RFCs call for," why use TCP for data
exchange instead of larger UDP packets?

Well, the inheritance is from the "default IP maximum datagram size"
of 576 bytes, RFC879, which a host must observe absent specific
knowledge that the far end can do better. In the vast majority of
cases (assuming your resolver and cacheing nameserver won't puke) I
suspect there would be no problem sending a somewhat-bigger-than-this-size
DNS reply... right up till you go over 1500 bytes for your datagram,
at which point you're back to square one. With cryptologically signed
replies containing a lot of AAAA records and other data, bigger than
1500 bytes is certainly not outside the realm of possibility. Trying
to fragment and reassemble DNS queries is a step away from goodness.
With TCP, you have a virtual stream service rather than a datagram
service, and in exchange for the overhead of setting up and tearing
down the connection, one gets the ability to do transactions that are
much larger.

                                        ---Rob

7

Jon Kibler writes:

Also, other than "That's what the RFCs call for," why use TCP for
data exchange instead of larger UDP packets?

TCP is more robust for large (>Path MTU) data transfers, and less
prone to spoofing.

A few months ago I sent a message to SwiNOG (like NANOG only less
North American and more Swiss) about this topic, trying to explain
some of the tradeoffs:

http://www.mail-archive.com/swinog@lists.swinog.ch/msg02612.html

Mostly I think that people "approaching this from a security
perspective only" often forget that by fencing in the(ir idea of the)
current status quo, they often prevent beneficial evolution of
protocols as well, contributing to the Internet's "ossification".

8

Mostly I think that people "approaching this from a security
perspective only" often forget that by fencing in the(ir idea of the)
current status quo, they often prevent beneficial evolution of
protocols as well, contributing to the Internet's "ossification".

folk do not always get the implications of the internet being a
'disruptive technology,' and that this is a good thing which needs to be
preserved and even enhanced. they use skype and want to block ports.

it's rampant. the old siliness of blocking tcp/53 is just one of the
corner cases that keeps popping up publicly. try using this year's crop
of innovative apps from behind some corporate firewall. packet/port
xenophobia overrides the users' desire to be productive every time. it
departments are paid to minimize cost and risk, not maximize workers'
productivity.

randy