[dnssec-deployment] Future applications?
regnauld+dnssec at catpipe.net
Wed Jan 16 18:14:47 EST 2008
Dave Piscitello (dave) writes:
> I would be very interested in seeing your presentation.
So would I in fact.
> I think this is an important issue for DNSSEC advocates. I don't want to
> appear negative or alarmist and I am certain many of you hear the same
> chatter I've been hearing, especially lately: "DNSSEC doesn't solve enough
> problems and the ones it solves can be mitigated using other methods" and
> "DNSSEC doesn't bring enough to the table to justify the implementation and
> deployment costs". I'm not saying these are true claims, but they are made
> loudly and frequently.
... The only way you can counter that is by doing relentless promotion
of DNSSEC at conferences, NOG meetings and workshops.
For instance at the most recent ccTLD workshop organized by NSRC/ISOC/
we had almost a day of DNSSEC (intro + basic hands-on signing), to get
administrators from the Region familiarized with the concepts, and show
that it wasn't as complicated (from a technical point of view) as it seemed.
There's been entire workshops on the topic:
... and some of the materials have been translated to other languages:
So what's missing now is to give people a good argument why they should
go through with the extra work and administrative overhead that signing
zones and delegations implies. I'm a bit stumped on that one :)
> An article that identifies the kinds of applications DNSSEC can support and
> why those applications are important would be *extremely* valuable.
A point was made that DNSSEC doesn't function as some kind of PKI that
you can build on (it's not a signature framework for the rdata), so
it's not easy to "sell" DNSSEC as an enabler of new applications/features.
Even the added validation is not visible: if we take the case of typical
end-users (read: web surfers :), failure to validate the origin of DNS
answers (and the ensuing failure of resolution, as seen by the
client) does not automatically generate a warning in the application,
since there's no vertical mechanism to push a qualified error condition
back to the application, unless the application actively checks DNS
data (and that's not its job). See http://www.dnssec-tools.org/ and
http://www.dnssec-tools.org/whybad.html for a good example).
> it must be written in language that average people and executives can
> understand. I am certain I could get an editor at a quality publication
> like ENISA Journal, USENIX, or BCR to publish something like this and would
> be happy to lend my pen to the task.
Same here, but we've got a silver bullet looking for a werewolf, is
the perceived attitude.
_ _ |_ |
(_(_||_ | regnauld at catpipe.net - www.catpipe.net
More information about the Dnssec-deployment