[dns-operations] Online DNSSEC debugging tool now availalbe

[bmanning at vacation.karoshi.com]

On Mon, Jul 19, 2010 at 11:14:42AM -0400, Andrew Sullivan wrote:
> On Mon, Jul 19, 2010 at 03:04:36PM +0000, bmanning at vacation.karoshi.com wrote:
> > 	because I don't know where the one trying to validate is coming from.
> 
> I have no idea what that has to do with this.  There is no sense of
> the "DNS location" of the originating requester being significant
> anywhere in any of the DNSSEC RFCs that I can see, but I'm probably
> missing something.  Do you have a passage I should read?
> 
> > 	if the origin of the validation request (the I in "I want to 
> > 	validate www.example.org") is  laptoy.example.org, then I 
> > 	can't see how the TA for . would validate and the TA for .org would
> > 	not.
> 
> Because .org rolled their key, changed the DS in ., and didn't publish
> a new TA?


	sounds irresponsible to me.  when I get new crypto tokens from 
	my employer, I expect them to work.  if my employer changes the 
	crypto tokens and fails to tell me then I might suspect that I am
	no longer employed.  Or if I get crypto tokens from my bank and
	they fail to tell me that they have changed them - as a customer
	who no longer has access to my funds, I mght be unhappy. And just 
	because someone else _can_ validate that keyset doesn't mean that
	I should trust that third party, esp if I have no defensible business case to
	trust a third party with whom I have no binding service agreements.
	Do you want to hang your corporate success on a third party?


	on a global scale, I have found that always-on, always-connected
	is increasingly not the norm.  I expect to have a populous keyring
	with dozens of keys for different SEPs.
> 
> A
> 
> 
> -- 
> Andrew Sullivan
> ajs at shinkuro.com
> Shinkuro, Inc.
> _______________________________________________
> dns-operations mailing list
> dns-operations at lists.dns-oarc.net
> https://lists.dns-oarc.net/mailman/listinfo/dns-operations