[Dnssec-deployment] Analysis of NASA.GOV DNSSEC Issue 18-Jan-2012
Ed.Lewis at neustar.biz
Fri Jan 27 09:19:43 EST 2012
No engineer/operator worth their salt would say there's no pain for
any operational misstep on their part. I think the more important
issue is how to prevent blame from being laid at the wrong foot.
I look at the process that was followed to design DNSSEC, looking for
ways to improve on what was produced. The "hard fail" option that
resulted, upon reflection is still the best option in my opinion.
(I'll leave off elaborating here.)
It's been known that the brunt of a DNSSEC incident would be on the
ISP helpdesk. Incident covers operational errors and security
events. What the COMCAST report highlights is that not everything
was envisioned in the design phase of the protocol. Not that this
would change the protocol as is, but opens the door for some more
work opportunities. Here's a short list of what was not foreseen.
First, since DNSSEC started appearing in the TLDs and root, all
validation errors resulted from operational mistakes. The slow roll
out of the technology helps here, lets us burn it in. Lacking a
security event-related validation error makes it harder to show
DNSSEC in operation to the non-technical audience. Outside of
launching a fake real event, all we can do is shore up the tool kit.
Second, the rise of social media, the un-edited, un-vetted channel,
permits rumors to be elevated to facts quickly. The complaint
channel is now way more powerful than the reporting channel. (E.g.,
twitter vs. whois.) There's never been a way to report problems back
the source - I recall being stymied by that when I wrote my first
Third, everything DNS is now under a microscope. This is the price
of "success" in that what engineers have wrought feeds a need of the
general economy and is becoming something folks depend upon - in the
same manner they depend upon brake linings in moving vehicles. When
the system works, it's silent, When it doesn't things screech and
people get hurt. And, there's a market of people just working on,
developing, and even "branding" the system.
The question is - how can it be made more clear the reason for a DNS
failure? I don't mean inside the protocol, using EDNS0 options to
expand on the RCODE. I mean what reporting tools can be deployed so
that users who care and get a rational explanation of why a lookup
NeuStar You can leave a voice message at +1-571-434-5468
Vote for the word of the day:
"Papa"razzi - father that constantly takes photos of the baby
Corpureaucracy - The institution of corporate "red tape"
More information about the Dnssec-deployment