Re: USADOTGOV.NET Root Problems?
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 W Danny ___ 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: Multiple masters expected behavior?
In article mailman.83.1279918361.15649.bind-us...@lists.isc.org, Peter Laws pl...@ou.edu wrote: On 07/22/10 19:57, Barry Margolin wrote: In articlemailman.65.1279835965.15649.bind-us...@lists.isc.org, Peter Lawspl...@ou.edu 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
Re: USADOTGOV.NET Root Problems?
On Sat, 24 Jul 2010, Warren Kumari wrote: On Jul 23, 2010, at 2:37 PM, Danny Mayer wrote: 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 The Cisco PIX/ASA has horrible bugs in its SMTP inspection code, some also related to packet boundaries. http://fanf.livejournal.com/102206.html Tony. -- f.anthony.n.finch d...@dotat.at http://dotat.at/ FORTIES CROMARTY FORTH TYNE DOGGER: MAINLY SOUTH OR SOUTHWEST 3 OR 4, OCCASIONALLY 5 LATER. SLIGHT OR MODERATE. RAIN OR SHOWERS. MODERATE OR GOOD. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: zone syntax question
On Tue, Jul 20, 2010 at 10:07:54AM +0100, Sam Wilson wrote: ... I *would* recommend using @ everywhere possible - it's so much less liable to typos than using the real domain and unnecessary obfuscation is not your friend when it comes to DNS administration. :) :) ... Seconded. I would also recommend using human-readable times, even though they're converted to numbers internally [which is of course what 'dig' reads]. Similarly, less likely to errors. Quick, knee-jerk, which of these is one day? 86300 68300 863000 What I would recommend is getrting rid of those ugly $ORIGINs and sticking to the original @. -- /*\ ** ** Joe Yao j...@tux.org - Joseph S. D. Yao ** \*/ ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: zone syntax question
On 24/07/2010 16:17:13, Joseph S D Yao wrote: Quick, knee-jerk, which of these is one day? 86300 68300 863000 It's a trick question, right? Matthew -- Dr Matthew J Seaman MA, D.Phil. 7 Priory Courtyard Flat 3 PGP: http://www.infracaninophile.co.uk/pgpkey Ramsgate JID: matt...@infracaninophile.co.uk Kent, CT11 9PW signature.asc Description: OpenPGP digital signature ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: zone syntax question
On Sat, Jul 24, 2010 at 04:32:21PM +0100, Matthew Seaman wrote: On 24/07/2010 16:17:13, Joseph S D Yao wrote: Quick, knee-jerk, which of these is one day? 86300 68300 863000 It's a trick question, right? Very good! ;-) -- /*\ ** ** Joe Yao j...@tux.org - Joseph S. D. Yao ** \*/ ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
dnssec-signzone gets verbose
After upgrading to bind 9.7.1 recently, some of my scripts started to output text when they shouldn't. Digging a little, I quickly found that dnssec-signzone now unconditionally writes information like this on stderr: Verifying the zone using the following algorithms: RSASHA1. Zone signing complete: Algorithm: RSASHA1: KSKs: 1 active, 0 stand-by, 0 revoked ZSKs: 0 active, 0 stand-by, 0 revoked I can understand this information is useful. But why is it printed unconditionally, even on verbosity level 0? And why is it written to stderr rather than stdout? My scripts can of course be rewritten so this output is thrown away. But it seems a little strange I would have to do that. To me, it looks like this output would be appropriate only when verbose output is explicitly requested. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: USADOTGOV.NET Root Problems?
On Sat, 24 Jul 2010, 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 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: USADOTGOV.NET Root Problems?
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. Danny ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
