How to measure the impact of enabling DNSSEC?

[Brian Kroth]

Lawrence K. Chen, P.Eng. <lkchen at ksu.edu> 2013-01-25 17:57:
>
>
> ----- 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.

I've had a very similar experience where I'm at.

> 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.

Can you share?  It's true that usually it's some sort of email at that 
same domain, but if the resolving the domain isn't working, how are you 
going to get email there?

> 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.

Our parent zone isn't signed yet, though we do have a few domains in DLV 
which works pretty well from what I can tell.

There are a few brain dead resolvers out there (w3.org was one if I 
recall correctly), that respect the signatures of the non-DLV zones even 
though they have an incomplete chain of trust, so that's caused us a few 
problems, mostly in pointing out a few of our mistakes (eg: lazy zone 
delegation [1]).  Still, better to wade in than to jump in.  On the 
whole DNSSEC has been largely uneventful.

Key rollover is a non-trivial task though, one that I'm still working 
through automating and monitoring.

Cheers,
Brian

[1] https://www.isc.org/wordpress/dnssec-and-lazy-delegation/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20130128/9dc38e7e/attachment.bin>