[dns-operations] Unplanned DLV zone outage on 2009-Apr-06

Edward Lewis Ed.Lewis at neustar.biz
Tue Apr 7 23:15:16 UTC 2009

At 21:52 +0000 4/7/09, Lutz Donnerhacke wrote:

>  - imports entries by crawling and user input

This makes me uncomfortable.

As an engineer with an interest in seeing DNSSEC deployed, I like 
seeing the DLVs or TARs do their thing, make mistakes, fix and learn 
from them.  Especially because I am not yet in production.

As someone in a registry that is being pressured by some to deploy 
DNSSEC, I don't like the high risk of failure DLVs are presenting me. 
The image of a thundering herd of buffalo headed for me, and me on 
the rim of a deep canyon comes to mind.

I would ask that any service (and to me DLV == TAR, TAR == iTAR, iTAR 
== DLV) that obtains keys in any manner other than explicit 
provisioning (e.g., scraping, crawling) be transparent to their 
relying parties regarding how they obtained the keys.  Check that - 
no matter how the keys are obtained, be transparent to their relying 
parties.  I'm not going to get into liability FUD, the reality is, I 
don't want to harm the image of my TLD nor inundate my help desk with 
support calls.

If I take all of the precautions I can, including vetting services 
that collect SEPs, and still there is an operational issue that 
causes my product management to call for the suspension of DNSSEC, I 
doubt I could make the case to resume deployment.  (I mean, when can 
I be certain that the root cause has been adequately addressed?) 
These services present downsides to deployment.

I don't mean to be negative about all these services.  I realize 
there are lots of good heuristics going into making sure the 
collections are beneficial.  But, from an operations point of view, 
where service level agreement misses are tangible hits and 
operational reputation is at stake, the topic is a serious matter.

Edward Lewis
NeuStar                    You can leave a voice message at +1-571-434-5468

Getting everything you want is easy if you don't want much.

More information about the dns-operations mailing list