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

David Conrad drc at virtualized.org
Wed Apr 8 02:20:40 UTC 2009


On Apr 7, 2009, at 5:22 AM, Paul Vixie wrote:
>> FWIW, I now expect the root to be signed before the end of the year
> that's extraordinarily great news.  even though not a formal  
> announcement,
> the fact that you as a credible insider think that the root may  
> actually
> be signed this calendar year is newsworthy in a good way.

This isn't particularly newsworthy.  As you know, this isn't ICANN's  
decision.  I'm reading the same tea leaves I'm sure you've seen/heard.

> what would be ISC's best way to fill *those* gaps?  a tech report  
> showing the
> whole ISC DLV key management and zone management process, perhaps?

That might be a useful exercise, particularly as it might help to  
provide guidance to folks who will be accepting keys in the future.

>> I know what's in the IANA ITAR and can (if I cared) verify the entire
>> contents by hand.  No idea what is in the DLV or who put it there.
> we can also open it to AXFR if desired.

Is there a reason it isn't open for AXFR?  It used to be.  I  
personally think slaving the zone is a much better model than relying  
on ISC's infrastructure in real time, but that's probably just me.

> the ITAR for
> example is "put there" by ISC.  other keys are put there by zone  
> owners.
> if you are ever specifically unsure what's in the DLV or who put it  
> there,
> ask specific questions.

Other than the contents of the ITAR, I have no idea what's in the  
DLV.  Perhaps I'm not looking in the right place?

> but in

> the case of google, or verisign, or DLV, you can avoid fate sharing  
> by not
> using that search engine or webmail interface, by not using any domain
> names ending in .COM, and by not subscribing your validator to DLV.

While it is easy to choose a different search engine and most users  
can be reasonably be expected to deal with the fact if/when Google  
went down, I have some skepticism that (say) your average art student  
at UCB would have a clue as to how to change the caching name server  
they point to (if they are even able to).

The model you have chosen to deploy DLV in requires ISC to run a  
24x7x365 infrastructure equivalent in many ways to what the 12  
organizations providing root service collectively provide.  Failure of  
that infrastructure will result in "the Internet is broke" to all  
users of caching servers configured to use that infrastructure.  While  
I (honestly) have great respect for the folks at ISC, I personally  
find it ... questionable to entrust the operation of my infrastructure  
to you, particularly as I don't see the current business model for the  
service being viable, scalable, or even particularly rational.

However that's just me. I know other folks don't share my discomfort.   
More power to 'em.

> i understand why
> someone might prefer not to subscribe their validator to DLV.  what  
> i don't
> understand is why anyone would argue against other people using it.  
> instead
> of just saying "what a bad idea" and moving on, we seem to be  
> involved in a
> long winding debate.

I'm not arguing so much against other folks using it, rather  
explaining why I think it is a stunningly bad idea (since you keep  
attributing it to me, I feel the need to explain some of the reasons  
why I decided not to pursue it).

> if ICANN is willing to step forward and help, then you
> will find ISC extremely non-possessive about DLV.

An interesting thought, but I'm not sure how ICANN could effectively  
vet the submissions to the DLV.  We can do the ITAR because we have  
pre-existing relationships with the TLD administrators.  Such  
relationships obviously don't exist for DLV and I don't know how we  
could provide it without charging for it (which would open up a whole  
new barrel of laughs).


More information about the dns-operations mailing list