On Fri, Jan 25, 2013 at 2:57 PM, Lawrence K. Chen, P.Eng.
lkc...@ksu.edu wrote:
- 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 yearbecause 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 completelybecause 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
rolloverBut, 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 yearI 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
