On Sat, Dec 14, 2013 at 08:53:14PM +0000, Viktor Dukhovni wrote: > On Sat, Dec 14, 2013 at 02:35:15PM -0600, /dev/rob0 wrote: > > > > The trick is to find tools that make operating a DNSSEC zone > > > relatively painless. You get security, but it easier to mess > > > up leaving the zone with stale signatures and thus essentially > > > invisible to all DNSSEC-aware clients. By all means deploy > > > DNSSEC, but carefully. > > > > Perhaps I am biased, but I use and recommend ISC BIND 9.9. The > > "auto-dnssec maintain;" zone option does most of the work. Used > > together with "update-policy local;" you get a simple means of > > updating your zone data with nsupdate(8). > > Thanks for the tip, the OP may find that helpful. Making use of > DNSSEC as transparent as possible to the administrator is key to > making it usable. > > Since your zone is in fact DNSSEC signed, perhaps you should > consider enabling DANE for SMTP:
I was planning to do DANE this summer when the feature was implemented, but at the time my mail host had a too-old openssl. I think we're good now: $ openssl version OpenSSL 1.0.1e 11 Feb 2013 > _25._tcp.mx3.nodns4.us. IN TLSA 3 1 1 > FDC86639033F23BAB5B24DF459DE2742CF98FCB1BD747F71807C4DF294773323 > _25._tcp.mx4.nodns4.us. IN TLSA 3 1 1 > FDC86639033F23BAB5B24DF459DE2742CF98FCB1BD747F71807C4DF294773323 Hehe, oops. This exposes my postscreen MX policy test ruse (same certificate on both IP addresses.) (Yeah, I know, it doesn't matter; spammers are not going to check my TLSA records.) Thanks for the reminder and help. I will do it this weekend. -- http://rob0.nodns4.us/ Offlist GMX mail is seen only if "/dev/rob0" is in the Subject:
