----- Original Message ----- > On Wed, Jan 23, 2013 at 11:38 AM, Augie Schwer > <augie.sch...@gmail.com> wrote: > > > > On Tue, Jan 22, 2013 at 2:32 PM, Mark Andrews <ma...@isc.org> > > wrote: > >> > >> > >> In message > >> <ca+fq9b-ym5w+ndxzzndzwnnqk-v29s19enb_myjbk-jrgbj...@mail.gmail.com>, > >> Augie > >> Schwer wri > >> tes: > >> > > >> > Would measuring the number of SERVFAIL entries in the > >> > "query-errors" > >> > category be a good indicator of what impact enabling DNSSEC has? > > > > > >> > >> DNSSEC is like wearing a seatbelt. 99.99% of the time it has no > >> impact. And like a seatbelt it can save you (reject spoofed > >> answers) > >> or hinder you (lookups fail due to the zone not being re-signed) > >> on rare occasions. > > > > > > That makes sense to me; I was looking for a way to quantify the > > affect > > enabling DNSSEC validation in a Bind server. > > > > Measuring SERVFAILs seems to be a good proxy to measure DNSSEC's > > impact. > > > > Thanks for the reply. > > SERVFAILS are not rare and come from many things. Looking at the > delta > after enabling validation might be interesting, but in my experience > you are unlikely to see any difference beyond the jitter that will > always be there. Except for a couple of major goofs early on by a few > large orgs (e.g. NASA), the impact of validation is about zip. > -- > R. Kevin Oberman, Network Engineer > E-mail: kob6...@gmail.com
I heard a presentation from NIST on the .gov DNSSEC deployment last month...which was quite interesting on the kind of DNSSEC errors they been having. For me, users will frequently show up complaining at certain times of the year that they can't get to a .gov site from campus, but the site works fine on their home computer. Usually, when I dig through the logs, I will see its either they've stopped signing their zone or they got the rollover wrong. Of course, the users blame me for having DNSSEC validation on for our DNS servers and not that the .gov site made an error. Especially since they've waited to the last minute to submit a grant proposal to some .gov and waiting for the .gov site to fix the problem would probably take to long. At least from the NIST presentation, I got information on how to contact somebody about these problems since its usually hard to send email to the listed RNAME. OTOH, our domain went dark on August first of this year....because a non-DNS administrator takes care of all the registry accounts (because we don't have the authority to pay for registrations.) And, even though the DS line I sent her had the number for RSASHA256...she picked the wrong number on the registry's site. Not entirely sure...but got the impression that the website form said "8 - RSASHA256" so it should've been obvious. But, I've never seen that page. This was the first year that we have published our DS with our registry. Though things didn't break completely....because I maintain our record on ISC's DLV. And, resolvers set to use DLV could validate our domain. Things from my home were kind of weird, because I found out that one of my broadband connections uses DLV while the other doesn't. What was fun was that I had done a 2 month window for the KSK rollover....But, the person that updates our registry record waited to the end of July to finally update it. I did the DLV update on July 1st. Mainly because the year before I had used a shorter window, and I forgot to update DLV which I seem to recall required a bit of extra work to get it to validate my domain with them again. Plus I was doing a transition from RSASHA1 to RSASHA256. Not sure how I'm going to do rollover next year....I debating going to a longer lifetime KSK. -- Who: Lawrence K. Chen, P.Eng. - W0LKC - Senior Unix Systems Administrator For: Enterprise Server Technologies (EST) -- & SafeZone Ally Snail: Computing and Telecommunications Services (CTS) Kansas State University, 109 East Stadium, Manhattan, KS 66506-3102 Phone: (785) 532-4916 - Fax: (785) 532-3515 - Email: lkc...@ksu.edu Web: http://www-personal.ksu.edu/~lkchen - Where: 11 Hale Library _______________________________________________ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
