<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>On Jul 26, 2010, at 12:36 AM, Warren Kumari wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div><br>On Jul 26, 2010, at 12:34 AM, Kevin Oberman wrote:<br><br><blockquote type="cite"><blockquote type="cite">From: Warren Kumari <<a href="mailto:warren@kumari.net">warren@kumari.net</a>><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">Date: Sun, 25 Jul 2010 11:22:46 +0200<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">Sender: <a href="mailto:bind-users-bounces+oberman=es.net@lists.isc.org">bind-users-bounces+oberman=es.net@lists.isc.org</a><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">On Jul 25, 2010, at 4:33 AM, Danny Mayer wrote:<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">On 7/24/2010 5:10 AM, Warren Kumari wrote:<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">On Jul 23, 2010, at 2:37 PM, Danny Mayer wrote:<br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">On 7/22/2010 11:08 PM, Merton Campbell Crockett wrote:<br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">Thanks for the confirmation that the problem was related to DNSSEC.<br></blockquote></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">I didn't see your message until I got home from work; however, I did<br></blockquote></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">find the root of the problem late this afternoon. At each of our<br></blockquote></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">Internet egress and ingress points, we have Cisco ASA devices sitting in<br></blockquote></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">front of a pair of redundant firewalls. Each ASA is configured with the<br></blockquote></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">default DNS inspect policy that doesn't accept fragmented UDP packets.<br></blockquote></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">Why would any inspection policy not allow fragmented UDP packets?<br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">There's nothing wrong with that.<br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">Because it's "hard".... The issue is that then you need to buffer<br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">fragments until you get a full packet -- which leaves you open to<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">attacks that send a bunch of fragments but leave one of them out.<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">Vendors like to avoid reassembling fragments by default, because it<br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">makes their performance numbers better....<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">At the expense of correct behavior and loss of real performance.<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">Yes. <br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">Sorry, if I gave the impression that I was condoning this -- I'm not.<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">Vendors exist to sell boxen -- tuning for the test cases at the<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">expense of correctness often wins....<br></blockquote></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">And, as tests start to include DNSSEC (and EDNS0) tests, the vendors will<br></blockquote><blockquote type="cite">likely adjust defaults. Tests for DNSSEC are already appearing on<br></blockquote><blockquote type="cite">federal systems (not a trivial part of the business) and will likely<br></blockquote><blockquote type="cite">become general test in the procurement process in the next year. <br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">Of course, changing defaults will take longer to change.<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">Now to a more basic question...why the ^@#$ does everyone put STATEFUL<br></blockquote><blockquote type="cite">firewalls in front of servers.<br></blockquote><br>i suspect that this was intended as a rhetorical question / rant, but I'll ignore that and answer it anyway :-)<br><br>Folk seems to do this for 3 reasons:<br>1: They truly believe that a stateful firewall will protect their server, either from port 53 attacks, or attacks on other ports.<br>2: They went through some certification process that demands that all "services" live behind a "firewall"<br>3: (and this is the common one) The folk that run the DNS servers are not the "network security" folk. The network security folk believe that the sysadmin types are unable to run a secure service that can be exposed to the Internet. The DNS folk may / probably have tried explaining that this firewall causes more issues than it solves, but what management hear is "The DNS folk think that they can run a secure service, but network folk think that they need more security." and they err on the side of "caution"...<br></div></blockquote><div><br></div><div>You forgot one point. Each layer of firewall must implement exactly the same "security policy". Can't have outer firewalls different in order to remove ambiguity or simply to get rid of packets and protocols you are not prepared to support anyway. </div><div><br></div></div><br><div>
<span class="Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: Helvetica; font-size: medium; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; "><span class="Apple-style-span" style="border-collapse: separate; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; color: rgb(0, 0, 0); font-family: 'Helvetica Neue'; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; -webkit-text-decorations-in-effect: none; text-indent: 0px; -webkit-text-size-adjust: auto; text-transform: none; orphans: 2; white-space: normal; widows: 2; word-spacing: 0px; "><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><span class="Apple-style-span" style="border-collapse: separate; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; color: rgb(0, 0, 0); font-family: 'Helvetica Neue'; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; -webkit-text-decorations-in-effect: none; text-indent: 0px; -webkit-text-size-adjust: auto; text-transform: none; orphans: 2; white-space: normal; widows: 2; word-spacing: 0px; "><div>--</div><div>Merton Campbell Crockett</div><div><a href="mailto:m.c.crockett@roadrunner.com">m.c.crockett@roadrunner.com</a></div><div><br class="khtml-block-placeholder"></div><br class="Apple-interchange-newline"></span></div></span></span><br class="Apple-interchange-newline">
</div>
<br></body></html>