How to measure the impact of enabling DNSSEC?

[Kevin Oberman]

On Fri, Jan 25, 2013 at 2:57 PM, Lawrence K. Chen, P.Eng.
<lkchen at ksu.edu> wrote:
>
>
> ----- Original Message -----
>> On Wed, Jan 23, 2013 at 11:38 AM, Augie Schwer
>> <augie.schwer at gmail.com> wrote:
>> >
>> > On Tue, Jan 22, 2013 at 2:32 PM, Mark Andrews <marka at isc.org>
>> > wrote:
>> >>
>> >>
>> >> In message
>> >> <CA+fq9b-ym5w+NDXzZNDZWNnqk-V29S19eNB_myJBK-JRGBj9Wg at 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: kob6558 at 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.

At the time of the US Federal mandate for DNSSEC, most tools were just
not ready. BIND had only limited and entirely manual procedures and
several vendors with announced DNSSEC appliances had delays and were
not ready at the deadline.

The result was a lot of problems for those who went ahead and
published DS records to their parent zones to comply with the mandate.
This was compounded by some rather broken tools at GSA for updating DS
records. This took a while to clean up and there continue to be some
errors in the KSK rollover dance. Also, if you are not in .gov, you
have to hope that your registrar gets things right and I'll admit that
this remains a problem

I am concerned by your last statement..."I debating going to a longer
lifetime KSK". Keys don't expire. Signatures expire, and a set of keys
in use can re-sign the data with new expiration dates without a key
roll. The idea that keys expire seems very common and leads to
unneeded failures.This confusion is a combination of confusion on how
DNSSEC actually works and careless wording by people who do
understand. I suspect that this was the latter )(careless wording),
but it still contributes to the continuing meme that keys expire.

If your registrar does not get the new DS in place, just sign the data
again with the old key and a later expiration date. You can delay a
key roll indefinitely..
-- 
R. Kevin Oberman, Network Engineer
E-mail: kob6558 at gmail.com