Re: USADOTGOV.NET Root Problems?
Michael, Do you have a standard template that you use for your Cisco firewall devices? Or are you just disabling the fixup protocol's? Jerry On 07/24/10 15:16, Michael Sinatra wrote: That's true, but it doesn't quite explain why the "DNS Inspection Policy," turned on by default on the PIX/FWSM/ASA, continued to have a default maximum DNS message size of 512 bytes more than a decade after EDNS0 became a standards-track RFC. In this case, Cisco's defaults are brain-dead. Whether that had an impact here or the issue was due to mere fragmentation isn't clear, but those default values have had an impact on DNSSEC deployment. michael ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Multiple masters expected behavior?
It makes it really hard to follow the thread. > Why not? > > Please don't top post! > From: "Laws, Peter C." > Date: Sun, 25 Jul 2010 16:56:26 + > Sender: bind-users-bounces+oberman=es@lists.isc.org > > Well aware of that, but we have RedHat support so we're stuck with > that given that the alternatives are self-supporting BIND (which you > could argue I'm doing right now!) or going with a 3rd party. Given > the economy, I'm pleased we're keeping RH support. While all of our (public) servers run on FreeBSD which has not shipped with 9.3 for a long time, we always run a near-current ISC release of BIND. The amount of support needed is trivial and I sleep much better at night that way. Yes, depending on the integration of your back-office DNS management/DNSSEC, it might be less so for some. Keeping the support of BIND on our public servers mostly unrelated to the IPAM and DNSSEC stuff has really not been hard. In the time it took me to send my reply, I could have updated BIND on all of our public servers and I don't have to upgrade all that often. I think running 9.3 is false economy. DNS is just too important. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: ober...@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: USADOTGOV.NET Root Problems?
> From: Warren Kumari > Date: Sun, 25 Jul 2010 11:22:46 +0200 > Sender: bind-users-bounces+oberman=es@lists.isc.org > > > On Jul 25, 2010, at 4:33 AM, Danny Mayer wrote: > > > On 7/24/2010 5:10 AM, Warren Kumari wrote: > >> > >> On Jul 23, 2010, at 2:37 PM, Danny Mayer wrote: > >> > >>> On 7/22/2010 11:08 PM, Merton Campbell Crockett wrote: > Thanks for the confirmation that the problem was related to DNSSEC. > > I didn't see your message until I got home from work; however, I did > find the root of the problem late this afternoon. At each of our > Internet egress and ingress points, we have Cisco ASA devices sitting in > front of a pair of redundant firewalls. Each ASA is configured with the > default DNS inspect policy that doesn't accept fragmented UDP packets. > >>> > >>> Why would any inspection policy not allow fragmented UDP packets? > >>> There's nothing wrong with that. > >> > >> > >> Because it's "hard" The issue is that then you need to buffer > > fragments until you get a full packet -- which leaves you open to > > attacks that send a bunch of fragments but leave one of them out. > >> > >> Vendors like to avoid reassembling fragments by default, because it > > makes their performance numbers better > > > > At the expense of correct behavior and loss of real performance. > > Yes. > > Sorry, if I gave the impression that I was condoning this -- I'm not. > > Vendors exist to sell boxen -- tuning for the test cases at the > expense of correctness often wins And, as tests start to include DNSSEC (and EDNS0) tests, the vendors will likely adjust defaults. Tests for DNSSEC are already appearing on federal systems (not a trivial part of the business) and will likely become general test in the procurement process in the next year. Of course, changing defaults will take longer to change. Now to a more basic question...why the ^...@#$ does everyone put STATEFUL firewalls in front of servers. They are a denial of service attack waiting to happen. I don't know of any highly regarded security expert who recommends them and most object to them rather strongly. I will admit to once having stateful firewalls in front of my DNS servers, but after an unfortunate case of a badly written application DOSing ourselves, stateful firewalls have been removed. Yes, the software needed fixing, but the software was not enough to cause any problem for the servers...just the firewall. And, yes, we still have stateless firewalls in front of our DNS servers and other public servers as well as an aggressive IDS/IPS system. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: ober...@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
RE: Multiple masters expected behavior?
Well aware of that, but we have RedHat support so we're stuck with that given that the alternatives are self-supporting BIND (which you could argue I'm doing right now!) or going with a 3rd party. Given the economy, I'm pleased we're keeping RH support. -- Peter Laws / N5UWY National Weather Center / Network Operations Center / Web University of Oklahoma Information Technology pl...@ou.edu From: Doug Barton [do...@dougbarton.us] Sent: Friday, July 23, 2010 19:23 To: Laws, Peter C. Cc: bind-us...@isc.org Subject: Re: Multiple masters expected behavior? On Thu, 22 Jul 2010, Peter Laws wrote: > BIND 9.3.6-P1-RedHat-9.3.6-4.P1.el5_4.2 9.3.x has been EOL for a long time now, FYI. -- Improve the effectiveness of your Internet presence with a domain name makeover!http://SupersetSolutions.com/ Computers are useless. They can only give you answers. -- Pablo Picasso ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
RE: Multiple masters expected behavior?
Understood, but what I'm asking about is that the slave does not appear to be losing contact with the first-listed master. In fact, from the logs, it appears to be flipping back and forth (though not round-robinning). Someone else asked, essentially, "why?" ... The network paths are diverse to the different interfaces so, while I'm not protecting against failure of the master, I am protecting against network path failure. -- Peter Laws / N5UWY National Weather Center / Network Operations Center / Web University of Oklahoma Information Technology pl...@ou.edu From: bind-users-bounces+plaws=ou@lists.isc.org [bind-users-bounces+plaws=ou@lists.isc.org] on behalf of Barry Margolin [bar...@alum.mit.edu] Sent: Saturday, July 24, 2010 07:09 To: comp-protocols-dns-b...@isc.org Subject: Re: Multiple masters expected behavior? In article , Peter Laws wrote: > On 07/22/10 19:57, Barry Margolin wrote: > > In article, > > Peter Laws wrote: > > > >> I have multiple interfaces on my master and multiple interfaces on most of > >> my slaves. > >> > > > >> > >> Is that expected behavior? > > > > Yes. What if the first server stops getting updates, but the second one > > does and has a higher serial number? Don't you want the slaves to check > > the SOA record on it to pick up these changes? > > Except that the 2 "masters" are simply different interfaces on the same > master ... so the serial number *better* always be the same! That's true in *your* case. But BIND was designed to handle the more general case, where the masters can be different machines. -- Barry Margolin, bar...@alum.mit.edu Arlington, MA *** PLEASE don't copy me on replies, I'll read them in the group *** ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: USADOTGOV.NET Root Problems?
On Jul 25, 2010, at 4:33 AM, Danny Mayer wrote: > On 7/24/2010 5:10 AM, Warren Kumari wrote: >> >> On Jul 23, 2010, at 2:37 PM, Danny Mayer wrote: >> >>> On 7/22/2010 11:08 PM, Merton Campbell Crockett wrote: Thanks for the confirmation that the problem was related to DNSSEC. I didn't see your message until I got home from work; however, I did find the root of the problem late this afternoon. At each of our Internet egress and ingress points, we have Cisco ASA devices sitting in front of a pair of redundant firewalls. Each ASA is configured with the default DNS inspect policy that doesn't accept fragmented UDP packets. >>> >>> Why would any inspection policy not allow fragmented UDP packets? >>> There's nothing wrong with that. >> >> >> Because it's "hard" The issue is that then you need to buffer > fragments until you get a full packet -- which leaves you open to > attacks that send a bunch of fragments but leave one of them out. >> >> Vendors like to avoid reassembling fragments by default, because it > makes their performance numbers better > > At the expense of correct behavior and loss of real performance. Yes. Sorry, if I gave the impression that I was condoning this -- I'm not. Vendors exist to sell boxen -- tuning for the test cases at the expense of correctness often wins W > > Danny ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
