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