[Dnssec-deployment] Analysis of NASA.GOV DNSSEC Issue 18-Jan-2012

[Edward Lewis]

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

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 
was "blocked"?

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis
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"