Subject: [dnsext] Sidestepping the root

From: Ben Laurie <[email-masked]>
Date: Sat, 21 Feb 2009 17:11:44 +0000

So here's an idea: why don't the TLDs who have deployed or are willing
to deploy DNSSEC get together and each run a DLV zone for all the others?

Users choose their TLD and configure the appropriate DLV zone, and maybe
a backup or two, and they're done.

How hard can that be?

Cheers,

Ben.

-- 
http://www.apache-ssl.org/ben.html           http://www.links.org/

"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>

---

From: Ralf Weber <[email-masked]>
Date: Sat, 21 Feb 2009 19:58:54 +0100

MoiN!

> to deploy DNSSEC get together and each run a DLV zone for all the  
It would be far better if the TLDs willing to run DNSSEC would   
publish their Key in the IANA ITAR (https://itar.iana.org/). Some have  
already done this. The IANA ITAR is the ideal place to store the keys  
and for the resolver operators to retrieve them there.

This IMHO is far better than lookaside.

So long
-Ralf
---
Ralf Weber
Platform Infrastructure Manager
Colt Telecom GmbH
Herriotstrasse 4
60528 Frankfurt
Germany
DDI: +49 (0)69 56606 2780 Internal OneDial: 8 491 2780
Fax: +49 (0)69 56606 6280
Email: [email-masked]
http://www.colt.net/
Data | Voice | Managed Services

Schütze Deine Umwelt | Erst denken, dann drucken

*****************************************
COLT Telecom GmbH, Herriotstraße 4, 60528 Frankfurt/Main, Deutschland  
* Tel +49 (0)69 56606 0 * Fax +49 (0)69 56606 2222 *

Geschäftsführer: Dr. Jürgen Hernichel (Vors.), Rita Thies *  
Amtsgericht Frankfurt/Main HRB 46123 * USt.-IdNr. DE 197 498 400

---

From: [email-masked]
Date: Sat, 21 Feb 2009 21:41:33 +0000

Er, Ralk....   the itar -IS- lookaside...  just 'cause the
 IANA runs it doesn't make the technology any better.

--bill

On Sat, Feb 21, 2009 at 07:58:54PM +0100, Ralf Weber wrote:
> Sch|tze Deine Umwelt | Erst denken, dann drucken
> 
> COLT Telecom GmbH, Herriotstra_e 4, 60528 Frankfurt/Main, Deutschland  
> Geschdftsf|hrer: Dr. J|rgen Hernichel (Vors.), Rita Thies *

---

From: Ralf Weber <[email-masked]>
Date: Sat, 21 Feb 2009 23:20:01 +0100

Moin!

> IANA runs it doesn't make the technology any better.
Should have added dynamic or automatic. ITAR is a repository and at  
least in our operations the integration of the trust anchors is a  
manual process. And the process may be the one that will be used when  
the root get's signed.

So long
-Ralf
---
Ralf Weber

---

From: Steve Crocker <[email-masked]>
Date: Sat, 21 Feb 2009 17:29:22 -0500

Bill,

I have been listening attentively to the various points of view  
related to TARs.  Many people think it's important to distinguish  
between an external collection of trust anchors that is consulted  
during a query and an external collection of trust anchors that is  
downloaded at initialization time and/or in the background on a  
periodic basis.  DLV is an example of the first; ITAR is an example of  
the latter.  There are obvious pros and cons for each.  I think you're  
using "lookaside" to cover both of these, which is fine, but I also  
think the distinction between real-time and batch TARs is also  
important.

There is a surprising -- at least to me -- subtlety in this  
dichotomy.  One of the emergent concepts in discussions of trust  
anchors is the desire in many quarters to have permanently configured  
trust anchors, even after the entire tree is signed.  A common example  
is an enterprise might want its public key configured into the  
resolvers its employees use on the theory that even if the chain above  
it is broken or the servers are not available, it will still have a  
complete system.

An external TAR that is consulted during the lookup process won't  
serve this purpose, but an external TAR that is downloaded into the  
resolver's configuration will serve this purpose because the trust  
anchors in the local configuration will typically take precedence over  
the signatures in the chain above that point.

This leads to using an external TAR for two different purposes, either  
a temporary way of finding the key for a zone that is signed but whose  
parent is not signed, or as a permanent alternative to the keys in the  
DNS hierarchy.

The RSTEP report pointed out there is a potential problem with a TAR  
if a trust anchor is in the TAR, the parent is subsequently signed,  
and then the key expires and is replaced with a newer one, i.e.  
there's a key rollover.  As the RSTEP report noted, if that sequence  
of events takes place, resolvers will find the old key in TAR,  
assuming the TAR is downloaded, and will not find the newer key.

The surprise, at least to me, is this is actually more of a feature  
than a bug because it provides a clear way for an external batch TAR  
-- but not a real-time TAR -- to serve as either a temporary TAR or a  
permanent TAR.  The onus is on the zone owner to make sure one of two  
things happens after the parent is signed.  If the party who puts the  
trust anchor into the TAR intends for the publication of the key in  
the TAR is to take precedence on a permanent basis, then that party  
must also pay attention to key rollovers and update the TAR.  On the  
other hand, if the party who inserted the trust anchor into the TAR  
intended it as a temporary measure, then the trust anchor should  
removed when the parent is signed.

Steve

---

From: David Conrad <[email-masked]>
Date: Sat, 21 Feb 2009 13:07:00 -1000

> IANA runs it doesn't make the technology any better.

Huh?

The ITAR contents are intended to be installed as trust anchors in  
validating name server configuration.  How can this be viewed as a  
lookaside?  It facilitates early termination of the validation chain  
look_up_ (in that you don't have to go to the root).

And the reason IANA running it is perceived to be better is because  
there isn't yet another party in the chain of trust.  TLD admins  
already trust (or not) IANA.

Regards,
-drc

---

From: Mark Andrews <[email-masked]>
Date: Sun, 22 Feb 2009 10:27:39 +1100

In message <[email-masked]>, David Conrad
> already trust (or not) IANA.

	It is lookaside as it is a third party collecting the trust
	anchors.

	I should go and dig out the justification I sent in to get
	the DLV RR registered.  It argued that DLV is nothing more
	than what we now call a TAR, just the contents are fetched
	on demand and not by a process external to the nameserver.

	Mark

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: David Conrad <[email-masked]>
Date: Sat, 21 Feb 2009 13:42:15 -1000

Mark,

> 	It is lookaside as it is a third party collecting the trust

Err, no.  Same parties are involved.  IANA will be collecting the same  
data when the root is signed.  The only significant difference is that  
you have to configure the contents of the ITAR instead of simply  
configuring the single root anchor.

> 	on demand and not by a process external to the nameserver.

And as a result, it also adds a realtime dependency on the DLV provider.

Regards,
-drc

---

From: [email-masked]
Date: Sat, 21 Feb 2009 23:41:30 +0000

> already trust (or not) IANA.

	perhaps I am confused...  in the absence of a signed root,
	one may use any (number of) trust anchor repositories - yes?

	and in the case where the trust anchors are not found in
	the delegation path, one needs to "look-aside" to somewhere
	else to find the respository.  (your "early termination of the 
	validation chain").

	and since the DoC production root is not signed, one has a 
	choice of look-aside repositories - of which the IANA's is one.

	I posit that lookaside is a suboptimal technology, regardless 
	of who runs it ...  the optics from here have the ITAR being 
	just another DLV pile of goo... Some may perceive this as 
	"better" - and it may be... but its still lookaside and by its
	very nature - is suboptimal.

--bill

---

From: David Conrad <[email-masked]>
Date: Sat, 21 Feb 2009 13:54:59 -1000

Bill,

> 	else to find the respository.  (your "early termination of the

I guess it is a matter of terminology.  I don't consider the name  
server configuration to be a "look aside".  That is, if I configure my  
validating resolver with the trust anchor for virtualized.org, I don't  
feel that the validation terminating at virtualized.org to be a look  
aside.

But then again, I'm known for having odd views.

Regards,
-drc

---

From: "Jeffrey A. Williams" <[email-masked]>
Date: Fri, 20 Feb 2009 19:56:08 -0800

Ben and all,

  Not too bad of a suggestion/idea...

Regards,

Spokesman for INEGroup LLA. - (Over 284k members/stakeholders strong!)
"Obedience of the law is the greatest freedom" -
   Abraham Lincoln
"YES WE CAN!"  Barack ( Berry ) Obama

"Credit should go with the performance of duty and not with what is
very often the accident of glory" - Theodore Roosevelt

"If the probability be called P; the injury, L; and the burden, B;
liability depends upon whether B is less than L multiplied by
P: i.e., whether B is less than PL."
United States v. Carroll Towing  (159 F.2d 169 [2d Cir. 1947]
===============================================================
Updated 1/26/04
CSO/DIR. Internet Network Eng. SR. Eng. Network data security IDNS.
div. of Information Network Eng.  INEG. INC.
ABA member in good standing member ID 01257402 E-Mail
[email-masked]
My Phone: 214-244-4827

---

From: [email-masked]
Date: Sun, 22 Feb 2009 03:49:09 +0000

> But then again, I'm known for having odd views.

	as do I...   that said, the point I was trying to make was that
	there is a distinction between the delegation and validation heirarchies
	and when they diverge in points of insertion, the validation process has
	to "lookaside" to some place else to reach a sucessful termination.

	folks trying to assert that its ok, its not a big deal, its a feature
	not a bug, ad-nausea may be right.  after all, the root is kind of unique
	in the namespace and when the IANA runs the lookaside tree -AND- the delegation
	tree, then it further muddies the conversation.  but... the IANA and its
	ITAR, trust relationship w/ its children, etc... are NOT the point.

	the point is, the ITAR is a lookaside technology.
	DLV is a generic form of lookaside.  Claiming the ITAR is not lookaside
	because the layer9 stuff is congruant does not change the technological
	reality that the ITAR is a lookaside hack. 

	To your example re virtualized.org, i don't see that as lookaside.
	However, if I configure my validator to use the ISC DLV or the IANA ITAR
	to get the keys for .SE, .BR, .UM... then that -IS- lookaside, since I'm
	not configuring the .SE, .BR, .UM trustanchors directly -AND- I can't walk
	the validation chain from the root of the delegation heirarchy...  I have to
	go somewhere else.  Validation & Delegation heirarchies are not congruant and
	won't be until the root is signed.

	Lookaside SUCKS.  And I wish the IANA didnt feel like it had to bow to
	presure to run such a thing.  But apparently it did and it does.  Such is
	the state of practice.  

--bill

---

From: [email-masked]
Date: Sun, 22 Feb 2009 04:13:39 +0000

thank you for your time and consideration Paul.  
 you are more than welcome to your world view and
 are free to tell me mine is false and i am delusional.  

 it would not be the first and likely won't be the last
 time you do so.  belittling and denegrating others is always
 productive... if your ideas about productivity include
 squelching opposing views.

 To answer your single germaine question, I would rather see energy/effort 
 put to signing the root than these other tactics.  
  
 I will not argue point by point your other assertions on this list.

--bill

On Sun, Feb 22, 2009 at 03:53:19AM +0000, Paul Vixie wrote:
> > 	perhaps I am confused...
> 
> yes, i think so.  pretty much every assertion you made here is either
> provably false, or prima facie nonfalsifiable, or is a straw man fallacy.
> 
> >       in the absence of a signed root,
> no.  one may use any number of trust anchor repositories, including zero,
> whether there is a signed root or an unsigned root.  there's no relation.
> 
> no.  the IANA ITAR is not a lookaside, it is a repository of trust anchors.
> a trust anchor is a static entity which if present must be the same as what
> is seen on the network and which if present can be used to bootstrap trust
> if while swinging from signature to key you fall down empty handed.
> 
> no.  there is no DoC production root, for one thing.  and this is not a
> lookaside repository, for another thing.
> 
> > 	of who runs it ...
> the way you've tried to redefine it, anyone would have to agree with you here.
> however, your redefinition does not change the facts of reality, and so there
> is not only nothing to agree with, there is nothing to agree or disagree with.
> 
> >       the optics from here have the ITAR being 
> > 	just another DLV pile of goo...
> 
> clean your optics.  DLV doesn't look like a pile of goo to me -- it works
> fine, and we're in the process of building a better registry interface.  but
> more importantly, IANA ITAR is nothing like DLV, except that both are attempts
> to make dnssec deployable in the absence of a signed root zone.  i am VERY
> interested in whether you think this is worth doing (deploying DNSSEC in the
> absence of a signed root zone) and if so how you propose to accomplish same.
> 
> if you do not think it's worth doing, then perhaps you can remind us all of
> this frequently, so that your periodic diatribes against technology enablers
> intended to allow DNSSEC to be deployed before the root is signed, can be
> assigned an appropriate credibility level by those who read your words.
> 
> if you do think it's worth doing, but you don't think anybody has hit on the
> right way to do it yet, then please enlighten us all with your proposal, i
> know i'm not the only person here waiting breathlessly to hear better ideas.
> 
> >       Some may perceive this as "better" - and it may be... but its still
> > 	lookaside and by its very nature - is suboptimal.
> 
> nobody except ralf weber thinks IANA ITAR is better than DLV.  and as i
> explained in my response to ralf, they are not comparable, since IANA ITAR
> is static/imported and only handles TLD's, whereas DLV is dynamic/queried
> and handles any domain anywhere.
> 
> but the question you've begged is deeper: "suboptimal... compared to what?"
> that is, what would you have us do?  your alternatives are: do nothing until
> the root is signed, and put all of our dnssec-desire pressure on that one
> act; or come up with various early adoption technologies like IANA ITAR and
> ISC DLV (which are complementary -- ISC has already imported IANA ITAR into
> our DLV registry, and we'll automate that synchronization shortly -- there
> is no sence in which IANA ITAR and ISC DLV are competing solutions to the
> early deployment problem); or you can propose some other better interrim
> solution.  since you have done none of these three things, it is VERY hard
> to take you seriously when you pee all over the solutions proposed by others,
> especially those running in actual production and which appear to work, as
> does both IANA ITAR and ISC DLV.

---

From: Mark Andrews <[email-masked]>
Date: Sun, 22 Feb 2009 15:41:32 +1100

In message <[email-masked]>, David Conrad
> configuring the single root anchor.

	The difference is that it isn't in the root zone and as
	such you could, but we trust you won't, add DS records for
	any other zone you want to.
 
> And as a result, it also adds a realtime dependency on the DLV provider.

	Which is a operational choice.  You can axfr the zone and
	load it into named.  You can axfr the zone and translate
	the dlv records into DS records and load the output straight
	into unbound.  You can axfr the zone and translate use the
	dlv records to find the dnskey records and convert them
	into trusted-key statements.

	Now how is that any different to what you, as IANA, are
	offering?

	Mark

---

From: [email-masked]
Date: Sun, 22 Feb 2009 04:56:50 +0000

On Sun, Feb 22, 2009 at 04:34:30AM +0000, Paul Vixie wrote:
> and you for yours bill.  one smallish clarification remains:
> 
> do you disapprove on principle of any and all efforts toward early
> deployment aids for dnssec, by anyone and everyone, that would make it
> possible to begin dnssec deployment before the root zone is signed?
> (YES or NO.)

duh... the answer is NO. But just because some people do things for 
early deployment aids does not make them smart, scalable, or a wise use
of resources.  Nor does it make them a useful paneca for the masses.

	would you be so kind as to provide your defintion of look-aside?

I always took it ot mean that when the key/sig was -NOT- found in the 
resolution chain and there was a defined trust anchor repository -outside-
the resolution chain that could provide an answer.  that was/is look-aside.

--bill

---

From: Evan Hunt <[email-masked]>
Date: Sun, 22 Feb 2009 06:19:50 +0000

> 	would you be so kind as to provide your defintion of look-aside?

I can't give you Paul's definition, but you're welcome to mine.

Lookaside is when a particular location on the internet, with which your
server has a pre-configured trust relationship, takes the place of a signed
parent during validation.  Example: foo.com is signed, com isn't, so you go
check foo.com.dlv.isc.org, which validates foo.com.  dlv.isc.org is signed
and you know its key, so you're done.

ITAR is when you download a bunch of trust anchors to your server in
advance.  Example: foo.br is signed, and br is signed, and you already
know the key for br... so you're done.

There's no "looking aside" in the latter case, because you never had to do
any "looking"--everything you needed for the validation was already in your
possession.

(Note that there's a hybrid case:  dlv.isc.org can--and in fact does--
contain all the keys in the ITAR.  So you could skip downloading the keys,
and the second example now goes like this:  foo.br is signed, br is
signed, the root zone is *not* signed--but br.dlv.isc.org exists and
validates br, so you're done.)

--
Evan Hunt -- [email-masked]
Internet Systems Consortium, Inc.

---

From: "Jeffrey A. Williams" <[email-masked]>
Date: Sat, 21 Feb 2009 00:25:20 -0800

Bill, Paul and all,

  Always nice to hear form you Bill!  >:)  I am sure that Paul
will come around to recognizing that alternitive views are not
necessarly delusional, always false, prima facie nonfalsifiable,
or a a straw man fallacy.  So please be patient with such
utterances, and give them the consideration that such would
otherwise suggest, and leave it be at that...

Regards,

---

From: "Jeffrey A. Williams" <[email-masked]>
Date: Sat, 21 Feb 2009 00:35:12 -0800

Bill and all,

> the resolution chain that could provide an answer.  that was/is look-aside.

  This necessarly requires to ask what is your difinition of a "trust anchor
repository --outside-the resolution chain" is?  Or is that a matter of, first
what the repositories anchor contains, or whom/what that trust anchor
repository is recognized and by whom?  Ergo, is such a political/social
determination or a technical one?

Regards,

---

From: "Jeffrey A. Williams" <[email-masked]>
Date: Sat, 21 Feb 2009 00:44:02 -0800

Evan and all,

  Execellent examples, well done!  Now, how does any of the examples
except the second, do for trusted verification and in essance the basis
for what DNSSEC is in part, supposed to provide for?  Seems like
negating the hiarcial structure of the current legacy DNS.

  So what I think Bill and Paul were getting at, however round the bend
they approched it, was that if the Roots aren't signed, than they are not
trusted appropriately, and as a look-aside than another or more than one
other, set of servers supplements those legacy roots, which sort of defeats
the hiarcial trust model all together.  Ergo, layering of Root servers than
becomes viable, if signed and therefor trusted of course, irregardless of
whos signed servers or Roots they may be.

Regards,

---

From: Evan Hunt <[email-masked]>
Date: Sun, 22 Feb 2009 07:49:54 +0000

> for what DNSSEC is in part, supposed to provide for?

I'm sorry, I'm having a bit of trouble understanding the question.  Are you
asking where the trust comes from for the DLV repository (dlv.isc.org in my
example)?  If so, the answer is that you have to pre-configure a public key
for the repository into your server.

(In the specific case of dlv.isc.org, a PGP-signed key can be downloaded
from our website.  In the future, for convenience, we plan to include a
copy of the key in PGP-signed BIND release tarballs.)

> Seems like negating the hiarcial structure of the current legacy DNS.

Yes, that's true.  It doesn't change the structure of the DNS itself,
but it's the equivalent of getting a DS record from a source other than
the delegating zone--which is odd, and somewhat inefficient.  However,
neither the root zone nor very many TLD's are signed, so we do what we
must until they are.

---

From: "Jeffrey A. Williams" <[email-masked]>
Date: Sat, 21 Feb 2009 03:21:42 -0800

Evan and all

> for the repository into your server.

  No I was asking in refrence to your first and third examples.  However
you partly answered for your original third example, but than that isn't
really a side-stepped alternitive, or at least not fully.  Seems to me though
that your third example was the best of the three, FWIW.  Basically
what you are doing is setting up a alternitive to the Legacy Roots, until
DNSSEC is implimented on them, which is fine, but as such than, any other
set of servers could serve as Roots, and as such than, it is not necessary
for anyone to necessarly point to them depending on whos other servers
they TRUST, if you catch my drift.

> neither the root zone nor very many TLD's are signed, so we do what we

  Right, DNS structure itself is not actually changed, only a different
temporary hiarchy is established for purposes of operational stability,
or whatever else that may be advantagious.  And yes very few TLD's
are signed, but that is mostly a Root server operational determination
or problem.

  Now all this established, of assuming it is or will be shortly, than there
really is no reason to have one set of Legacy Roots, except to determine
a particular trust model and hiarcial broad structure, which is preferred,
but not etched in stone.

  So next I am compelled to consider/ask/contemplate if indeed DNSSEC
without a single TRUST model and DNS fully and reliably implimented
across TLD's and Root servers, legacy or otherwise, how is stability
and security to be relied upon, either operationally, or as a matter of
trusted usability?

Regards,

---

From: [email-masked]
Date: Sun, 22 Feb 2009 10:14:45 +0000

> static trust anchors are not lookasides, as i've repeatedly explained, but
> i'll do so again.  static trust anchors can give you recourse against failure
> if you are validating a signature and cannot discover a key for it.  one
> example of this is the static trust anchor for "." that we all think will be
> needed some day when the root is signed.  RFC 5011 talks about how to track
> and roll with changes to static trust anchors such as the one for "." that
> might exist some day.  i don't think any of us are ready to call the "."
> trust anchor a lookaside.  nor are any of us ready to say that a "." trust
> anchor isn't a lookaside but that any non-"." trust anchor is a lookaside.

	some of us are ready (and have always asserted) that the trust
	anchor for "." is a lookaside, since you can't find it in the
	parent zone (the root being the apex of the namespace).

	as one of the authors of the draft (Olaf, Johan and I) of an 
	alternative to what became RFC 5011, I do understand the problem 
	space.

> the other think static trust anchors can do (depending on implementation
> and on config knobs) is to REQUIRE that the network have a certain key, to
> effectively say that a given validator knows something about a zone key and
> that if the zone comes in with some other key then there's been a failure,
> an error, or a compromise.  this again is not a lookaside, it's a static
> trust anchor.

	the use of the term "static" is intriging.  if it truely is static,
	then there should be no issue in burning it into silicon.  One of the
	real issues is dealing w/  key rollover.  RFC 5011 talks to a scheduled
	rollover of the trust anchor for "." - managing unscheduled rolls is
	left as an exercise.  I posit there is no such thing as a static 
	trust anchor, nee key.  They are -ALL- dynamic, but on different time
	scales.

	the crux of the problem is -where- does the validator get the information
	about trust anchors?  And what (if any) is the trust relationship?  (and
	no, "trust me" isn't much better than what we have today).

> "lookaside" in the sense popularized by DLV and widely understood within
> the DNSSEC community means a dynamic trust anchor for a zone, that does not
> come from that zone's parent zone.  it's "aside" because it's not parental.

	good, your on the right track.

> it's "lookaside" because you have to look for it you don't get it during
> the delegation.  

	bingo!  glad you agree with me. :)

> note that while i've popularized this, i didn't invent it,
> i heard it from david conrad, and i later found out that sam weiler had
> written a whole masters thesis on it and perhaps conrad heard it from
> weiler.  

	and weiler got some of it from me... the jist of the idea was part 
	of the TBDS project done for DARPA's active nets program last century.

> dunno.  but i didn't invent it, nor the terminology, i just put
> some structure around it and got it into BIND and created a registry for it.

	Yeah!  

--bill

---

From: [email-masked]
Date: Sun, 22 Feb 2009 10:26:29 +0000

> I can't give you Paul's definition, but you're welcome to mine.

	thanks Evan.
> know the key for br... so you're done.

	where did you download the keys for .BR from?
	if you got them from .BR, using secure channels, then
	i'm ok w/ that.  if you got them from somewhere else, then
	I'd posit that its lookaside.  you have no way to independently
	verifying the trust relationship on how that party got the
	keys from the delegation holder.

> any "looking"--everything you needed for the validation was already in your

	er - yes i did... I had to get the keys from someone other than the
	delegation holder -AND- i have to trust them that they have the authority
	to do so and the integrity to not muck w/ the data.  

	One of my security oriented buddies beat me over the head for years 
	until I learned this lesson...  

		TRUST IS -NOT- TRANSITIVE.

> Evan Hunt

---

From: [email-masked]
Date: Sun, 22 Feb 2009 10:30:01 +0000

On Sun, Feb 22, 2009 at 07:49:54AM +0000, Evan Hunt wrote:
> the delegating zone--which is odd, and somewhat inefficient.  

	bingo! (again) 

	that is lookaside.  getting the DS record from a source
	other than the delegation zone.

	it may or may not be odd, but it is inefficent (which is one
	of the reasons I stated that lookaside sucks).

---

From: Chris Thompson <[email-masked]>
Date: 22 Feb 2009 18:27:38 +0000

On Feb 22 2009, Evan Hunt wrote:

>contain all the keys in the ITAR.  

Well, no, actually it doesn't. dlv.isc.org only has two TLDs in it at
the moment (br and cz). (The experimental signed root at ns.iana.org
does contain DS records for all TLDs in the ITAR, and more besides.)

>                                   So you could skip downloading the keys,

There's another case which might be considered intermediate between
statically configuring trust anchors and dynamically querying lookaside
zones. If one were allowed to stealth slave dlv.isc.org (say), then
one could consider refreshing one's copy of that zone as updating one's
local set of trust anchors.

Incidentally, it's a mystery to me why this discussion is taking place
on namedroppers rather than on [email-masked] ...

-- 
Chris Thompson
Email: [email-masked]

---

From: Evan Hunt <[email-masked]>
Date: Sun, 22 Feb 2009 18:43:33 +0000

> 	I'd posit that its lookaside.

The validation protocol is the same whether you got the key from .BR, IANA,
or some guy on the street with an overcoat full of Rolexes.

Your point here is that ITAR is less trustworthy than a signed root zone--
and I shan't argue the point.  (Though the root zone is a bit more of a
leap of faith than you may have considered.)   But your terminology sows
confusion.  "DNSSEC Lookaside Validation" is a specific query/validation
protocol, which is not being employed in the ITAR case, so using the word
"lookaside" is misleading.

> 	delegation holder -AND- i have to trust them that they have the
> 	authority to do so and the integrity to not muck w/ the data.  

You have to get root hints from somewhere, too.  If you trust IANA (and
of course the various root server operators) to give you the addresses for
.BR's nameservers, and you trust IANA to put trust anchors for .BR into the
root zone, then why *don't* you trust IANA to provide you with those
selfsame trust anchors via a side-channel?

> 		TRUST IS -NOT- TRANSITIVE.

So, you do the best you can with what you have.

---

From: Evan Hunt <[email-masked]>
Date: Sun, 22 Feb 2009 18:45:31 +0000

> does contain DS records for all TLDs in the ITAR, and more besides.)

My mistake, I thought it was already done.  If it isn't, it will be soon.

---

From: David Conrad <[email-masked]>
Date: Sun, 22 Feb 2009 09:20:32 -1000

On Feb 21, 2009, at 6:41 PM, Mark Andrews wrote:
> 	load it into named.

Oh?

> 	Now how is that any different to what you, as IANA, are

How does ISC get the trust anchors?

Thanks,
-drc

---

From: "Jeffrey A. Williams" <[email-masked]>
Date: Sat, 21 Feb 2009 17:08:16 -0800

Bill and all,

  Indeed, lookaside sucks.  Yet when there are few other good,
if any alternitives, they become a necessary evil, as it were... >:)

Regards,

---

From: [email-masked]
Date: Mon, 23 Feb 2009 00:38:51 +0000

> or some guy on the street with an overcoat full of Rolexes.

	er... not really, but run w/ it.

> leap of faith than you may have considered.)   

	possiblely true. but I have considered the problem for more
	than a decade.

> But your terminology sows

	lookaside != DLV...  lookaside is exactly what you and others stated,
	getting the DS/keys from somewhere else, other than the delegation.

> selfsame trust anchors via a side-channel?

	I trust some root operators more than others. :)

	the root data is easly verifiable from multiple sources.
	the ITAR data isn't.

	why I *don't* trust the IANA...  well, thats a long story.
	
> So, you do the best you can with what you have.

	amen.  but that does not mean I should beleive ernest, sincere folks who
	insist that they should be beleived - just because.

---

From: Michael Graff <[email-masked]>
Date: Sun, 22 Feb 2009 19:15:26 -0600

[email-masked] wrote:
>       but that does not mean I should beleive ernest, sincere folks who

I'm not a moron, and I would not believe someone just because.

However, in this situation, we get what I see as a "better" end result.
 It isn't perfect, but then again none of this is.  I've trusted people
I do not personally know every day to not cause me harm -- I put money
in a bank, after all.  Just because I don't know the teller doesn't mean
I should not trust the bank.

In this case, I've trusted that the root will delegate to a TLD, and
that TLD will delegate to me, for a very long time now.  Adding a little
authentication to that hand-off is not going to cause me to loose sleep.

Of course, as I'm the one working on the dlv.isc.org registry, perhaps
I'm biased.  I believe that just about any tool that causes the DNSSEC
"critical mass" threshold to be reached is generally a good thing.

--Michael

---

From: [email-masked]
Date: Mon, 23 Feb 2009 01:33:48 +0000

> "critical mass" threshold to be reached is generally a good thing.

        i -wish- that the ISC folk would not see my concerns about lookaside
        as an attack on their systems/tools.   but apparently that is not to
        be.  sigh.

        the POINT is that when one goes outside the delegation heirarchy
        to get trust anchors or keys, that is a lookaside.  its outside
        the DNSSEC protocol.   DLV is a lookaside as is the IANA ITAR..
        I'm not saying those are bad, evil, etc... I'm saying they are
        examples of lookaside technologies.

        and for ME - I don't like lookaside.

--bill

---

From: Michael Graff <[email-masked]>
Date: Sun, 22 Feb 2009 19:46:41 -0600

>         as an attack on their systems/tools.   but apparently that is not to

I was talking about the ITAR, not dlv.isc.org.  Sorry to confuse you.

>         and for ME - I don't like lookaside.

Then don't use it.  Easy!  I promise not to hack into your resolvers and
reconfigure them.

- --Michael

---

From: Evan Hunt <[email-masked]>
Date: Mon, 23 Feb 2009 03:39:45 +0000

>From the resolver's point of view, how is it different?  You gave it a key
when you configured it.  It doesn't care where you got the key, unless you
have an unusually sophisticated name server, and I hope you're not relying
on it to open any pod-bay doors for you. :)

> 	getting the DS/keys from somewhere else, other than the delegation.

I don't think many other people are using the term in that broad a sense.
DNSSEC, after all, *relies* on getting at least one trust anchor from a
source other than the delegation, since the root zone has no delegation.
Therefore, by your lights, *all* DNSSEC is lookaside--which renders the
word "lookaside" into a content-free redundancy, a distinction without
any meaning.

ITAR and DLV are fundamentally different from each other, and each of them
is fundamentally different from signed-root DNSSEC.  It muddies the water
to use terminology that confuses them.

---

From: "Jeffrey A. Williams" <[email-masked]>
Date: Sat, 21 Feb 2009 22:48:53 -0800

Bill and all,

  There is on old saying, "it;s not what you like that makes you fat,
it's what you get".  Perhaps thining in those terms as it applies to
lookaside is unfortunately necessary.

Regards,

---

From: Ondřej Surý <[email-masked]>
Date: Mon, 23 Feb 2009 08:11:22 +0100

>        the root data is easly verifiable from multiple sources.

That's not true. You can still go and lookup DNSKEYs either directly
from TLD zones, or from .cz, .se and .br webpages (where you can
verify GPG signature).

Ondrej
-- 
 Ondrej Sury
 technicky reditel/Chief Technical Officer
 -----------------------------------------
 CZ.NIC, z.s.p.o.  --  .cz domain registry
 Americka 23,120 00 Praha 2,Czech Republic
 mailto:[email-masked]  http://nic.cz/
 sip:[email-masked] tel:+420.222745110
 mob:+420.739013699     fax:+420.222745112
 -----------------------------------------

---

From: Florian Weimer <[email-masked]>
Date: Mon, 23 Feb 2009 11:22:58 +0100

> 	Which is a operational choice.  You can axfr the zone and

I trieed this; it doesn't work with 9.5.0-P2 because there's a bug in
the DLV implementation related to empty nonterminals.  (This might be
bug 2422--if you could provide an isolated patch, we could fix that
even in Debian stable.)

-- 
Florian Weimer                <[email-masked]>
BFK edv-consulting GmbH       http://www.bfk.de/
Kriegsstraße 100              tel: +49-721-96201-1
D-76133 Karlsruhe             fax: +49-721-96201-99

---

From: Paul Vixie <[email-masked]>
Date: Sun, 22 Feb 2009 04:34:30 +0000

[ Moderators note: Post was moderated, either because it was posted by
   a non-subscriber, or because it was over 20K.  
   With the massive amount of spam, it is easy to miss and therefore 
   delete relevant posts by non-subscribers. 
   Please fix your subscription addresses. ]

and you for yours bill.  one smallish clarification remains:

>  ...  belittling and denegrating others is always productive... if your
>  ideas about productivity include squelching opposing views.

i welcome opportunities to listen to opposing views.  but so far i've not
heard one from you, and my criticism is therefore not of your opposing view
but rather that you're opposing without stating any coherent reasons or any

>  put to signing the root than these other tactics.  

that must not be an answer to my question, because that view is universal.
yes, it's true: all of us would rather see effort expended toward signing
the root than working around the fact that the root's not signed.

however, that amounts to pushing on a rope.  since i want results, i choose
to expend effort where some results might be possible.  i understand that my
efforts could forestall the signing of the root since workarounds now exist;
please understand that my efforts could also accelerate signing of the root
by those who don't want to become irrelevant.  it could also be that the root
will be signed (or never) in spite of anything i (or anybody) does.  since i
want dnssec for my own purposes and since the hidden risks appear in balance,
i choose ACTION, and i choose it NOW (actually four years ago and counting),
and i will be OPPOSED to those who tell me i should do nothing.

let me rephrase the question you thought you might be willing to answer,
which was:

> > i am VERY interested in whether you think (deploying DNSSEC in the
> > absence of a signed root zone) is worth doing and if so how you propose
> > to accomplish same.

since you answered by saying what you preferred, you evidently thought that
i was asking for a rank ordering.  i'm not.  so i will ask again.

---

From: Paul Vixie <[email-masked]>
Date: Sat, 21 Feb 2009 23:21:48 +0000

what we all want is a signed root and then RFC 5011 for trust anchor
tracking.  what we all believe is that the root won't be signed soon
enough to help us deploy dnssec.  what many of us also believe is that
our particular TLD won't be signed soon enough to help us deploy dnssec.
what we're all looking for is a way to begin deploying dnssec anyway.

after that there's not much agreement.  but i'll speak up for DLV here.
i'm responding to four different messages here, to amortize per-message
costs better.  (from ben laurie, ralf weber (twice), and bill manning.)

(note that any thread touching both namedroppers@ and dnssec-deployment@
is offtopic in at least one of those places, and whoever started this
thread on those places, please reconsider your choices in the future --
but like everyone else, i will now reply in both places because i don't
want to be the one who isn't heard by half the audience.  what a mess.)

On 21.02.2009, at 18:11, Ben Laurie wrote:
> 
> So here's an idea: why don't the TLDs who have deployed or are willing to
> deploy DNSSEC get together and each run a DLV zone for all the others?

candidly, it's because of the trust problem.  ISC operates a DLV registry
and it has a few TLDs in it (more now that we've imported IANA's ITAR) but
the TLD operators are terribly concerned about kingmaking and not even ISC
is trustworthy enough to make that concern go away.  truthfully: *noone* is.

i understood this better after the man from .RU shook his fist at the room
down in atlanta, apparently the idea of russia depending on the united
states (which is how the world sees ICANN) to authenticate their own names
to their own users flies in the face of national sovereignty.  i expect
that most nations feel that they should run, or no doubt plan to run, their
own root name server system, and use a combination of laws and firewalls to
ensure that all eyeball carriers doing business in those countries use
those root name server systems.  letting the current united states ruling
party decide whether .XXX can exist or not, or who gets .IQ at any given
moment, seems to be intolerable outside "the beltway".  those of us in the
technology business wish we didn't have to care about this and have continued
building technology that deliberately ignores this reality, at the peril of
our own relevance.

so while the world of validators doesn't care much about national
sovereignty, the world of nations does.  i used to take it personally when
CCTLD folks would more or less ignore ISC's efforts with DLV, but finally i
sort of understand that it's not an ISC problem.  the CCTLD's can't depend
on anybody, not ISC, not eachother, for their key introduction.  i am very
happy to see CCTLD's giving keys to ICANN, and once we automate the PGP
checking we will do a nightly synchronization run of IANA ITAR -> DLV.  but
of course DLV includes many non-TLD keys, which is why i'm surprised at the
next two comments in this thread.

> From: Ralf Weber <[email-masked]>
> Date: Sat, 21 Feb 2009 19:58:54 +0100
> 
> It would be far better if the TLDs willing to run DNSSEC would publish
> their Key in the IANA ITAR (https://itar.iana.org/). Some have already
> done this. The IANA ITAR is the ideal place to store the keys and for the
> resolver operators to retrieve them there.
> 

better for whom?  better for CCTLDs, due to sovereignty concerns, yes.  and
perhaps better for someone with a small number of validators or perhaps a
set of validators that can be easily and continuously updated.  but since
IANA ITAR hasn't invited me to put VIX.COM's key in there, lookaside is the
only hope for domain holders such as myself whose parent and grandparent are
unsigned (and likely to remain so).

for the average validator operator, continuous updates along the lines of
IANA ITAR is not as practical as lookaside.  speaking for ISC DLV, we are
now importing IANA ITAR (manually now; automated soon), so validator
operators who just want interrim trust until everything's signed and RFC
5011 can synchronize them thereafter, will probably prefer lookaside to
ITAR.  (but i understand that for political reasons, this is not the course
that CCTLD operators can actually be seen supporting.)

> Date: Sat, 21 Feb 2009 21:41:33 +0000
> From: [email-masked]
> 

actually, ITAR is static, not a lookaside.  

> From: Ralf Weber <[email-masked]>
> Date: Sat, 21 Feb 2009 23:20:01 +0100
> 
> Should have added dynamic or automatic. ITAR is a repository and at least
> in our operations the integration of the trust anchors is a manual
> process.  And the process may be the one that will be used when the root
> get's signed.

i fear for any business or community who depends on continuous manual
processing, and i strongly urge that anyone with a non-trivial number of
validators use lookaside.  if you're not comfortable with ISC's DLV then
make your own and import keys into it by local policy.

---

From: Paul Vixie <[email-masked]>
Date: Sun, 22 Feb 2009 03:53:19 +0000

---

From: Paul Wouters <[email-masked]>
Date: Sat, 21 Feb 2009 19:02:18 -0500 (EST)

> 	very nature - is suboptimal.

The ITAR is for priming resolvers with TLD's. The DLV is for larger
scale dynamic priming of signed domains within an unsigned parent.

It's the same thing, but one is small and very static, the other
large and dynamic. And both can go away when the parent signed its
zone.

Paul

---

From: Paul Vixie <[email-masked]>
Date: Sun, 22 Feb 2009 05:40:58 +0000

> of resources.  Nor does it make them a useful paneca for the masses.

since the masses do not by definition adopt things early, i think that we
are in agreement that interrim or early-adopter technologies are not useful
for the masses, and i think there's universal agreement that early
deployment technologies do not scale and do not need not scale.  now as to
whether it's smart, that's for each early adopter to decide for themselves.
finally as to "wise use of resources" i appreciate your concern but i feel
that i am the one of us best informed as to the use-wisdom of my resources
for ISC DLV, and i have not asked for anyone else to use their resources
merely to depend on my resources if such an act suits their purposes.  IANA
has said the same, though i suppose you could argue that IANA controlled
and funded by two tax authorities (USG and ICANN) and that the resources
used to produce IANA ITAR are public in some way and so perhaps your
open question as to the wisdom of using resources in this way pertains to
IANA rather than to ISC.

"lookaside" in the sense popularized by DLV and widely understood within
the DNSSEC community means a dynamic trust anchor for a zone, that does not
come from that zone's parent zone.  it's "aside" because it's not parental.
it's "lookaside" because you have to look for it you don't get it during
the delegation.  note that while i've popularized this, i didn't invent it,
i heard it from david conrad, and i later found out that sam weiler had
written a whole masters thesis on it and perhaps conrad heard it from
weiler.  dunno.  but i didn't invent it, nor the terminology, i just put
some structure around it and got it into BIND and created a registry for it.

---

From: Daniel Kalchev <[email-masked]>
Date: Mon, 23 Feb 2009 10:01:56 +0200

Bill,

If we take this as our only belief, then there is no point in DNSSEC at 
all, because unless you get the .BG keys directly from me (assuming you 
know me and can verify my identity at the time I give you the keys) you 
are always getting these keys from a third party. In the case of IANAs 
iTAR, you trust them they know me. In the case of ISCs DLV, you trust 
them they know me. In case of signed DNSSEC root, you have to trust 
whoever gave you the root key.

And even then, you have to accept, that the chain of trust goes with the 
certifying signature of the parent on the child's key (hash). What is 
different with the chain of trust in the case of lookaside? You still 
have the 'parent' signatures. If you trust the parent, you should trust 
the children.

With the IANA operated iTAR things are as simple as they may get -- it 
is very likely that whatever goes to the IANA iTAR, will go to the 
signed root. I can speculate, that it is also likely that the same 
authentication/submission procedure will be used (or it could be 
extended, doesn't matter). You trust IANA to provide you with the set of 
nameservers for a TLD, right? Then why not trust IANA to provide you 
with a set of DNSSEC keys for the signed TLDs? Properly verified and 
authenticated. It would be ideal to have the root zone signed, but there 
is much unneeded politics around there.

With other TARs things are a bit different, but again come to the same 
basics: do you trust the publisher?

I still fail to see, why people do not perceive the DS records in DNS 
the same way they perceive the NS records in DNS. If you do not have the 
IP addresses of the root servers, how do you resolve anything? The same 
with the root DNSSEC key - or in absence of the signed root, the static 
trust anchors for TLDs and other level domains.

Even more, many operating system setups encourage the running of a slave 
'root' , instead of keeping up to date cache of the root name servers. 
How is this different from the iTAR/DLV based lookaside? Millions of 
hosts use this technique. Is it wrong? If yes, I believe we have bigger 
problem in DNS now, even without DNSSEC.

Hope you won't imagine I propose creating more and more TARs -- these 
will exist no matter what we do or tell people. I would rather see a 
signed root and be done with it.

Best Regards,
Daniel Kalchev
Register.BG

---

From: Chris Thompson <[email-masked]>
Date: 23 Feb 2009 15:04:39 +0000

On Feb 23 2009, Paul Vixie wrote:

[...]
>                                              ISC operates a DLV registry
>and it has a few TLDs in it (more now that we've imported IANA's ITAR)
[...]
>                                             speaking for ISC DLV, we are
>now importing IANA ITAR (manually now; automated soon), 

Maybe it's something to do with your update cycle for dlv.isc.org, but
I again have to point out out that this hasn't actually happened yet, as
seen by us mortals outside ISC. (Check for se.dlv.isc.org, for example.)

I am sure it will happen Real Soon Now... (and I *am* looking forward
to it).

-- 
Chris Thompson
Email: [email-masked]

---

From: Mark Andrews <[email-masked]>
Date: Tue, 24 Feb 2009 08:51:05 +1100

> bug 2422--if you could provide an isolated patch, we could fix that
 
	Please just move to the latest maintenance release of BIND 9.5,
	BIND 9.5.1-P1.  You *really* will want the other fixes.

	Mark

---

From: "Jeffrey A. Williams" <[email-masked]>
Date: Sun, 22 Feb 2009 16:51:48 -0800

Paul and all,

  Execellent remarks and observations.  I for one am glad that you
in particular have come around to my way of looking at things in
this regard, and hopefully others will do so as well.

  The world has grown and therefore changed, and you either change
with it, of are doomed to eventual obscurity.

Regards,

---

From: Paul Vixie <[email-masked]>
Date: Tue, 24 Feb 2009 14:43:46 +0000

> what we all want is a signed root and then RFC 5011 for trust anchor

From: bert hubert <[email-masked]>
> Just for the record, please exclude me and a lot of others from sweeping
> statements like these.

i apologize to all, and specifically to bert, for my sloppiness there.  i
should have said "what everyone who wants dnssec also wants is...".  i did
forget that not everyone wants dnssec.

---

From: Florian Weimer <[email-masked]>
Date: Wed, 25 Feb 2009 14:33:15 +0100

> 	BIND 9.5.1-P1.  You *really* will want the other fixes.

Hmm.  Turns out we already did that.  I guess I'm too used to the
glacial speeds at which things change for Debian, so I didn't bother
to recheck.  Thanks for the fix.

---

From: [email-masked]
Date: Sat, 28 Feb 2009 00:16:01 +0000

> forget that not everyone wants dnssec.

	sorry, i didn't get your doodle poll - so i echo burts concerns
	about your sweeping statements of inclusion/exclusion.

	but - if you can make sweeping statements, so can I.  
	I'll put the following words in -everyones- mouth, so open wide.

----

	dnssec, signed roots, RFC 5011 implementations are tools.  tools
	are not what we want.

	what WE all want is INTEGRITY in the data from the DNS.

----

--bill

---

From: "Jeffrey A. Williams" <[email-masked]>
Date: Thu, 26 Feb 2009 18:31:33 -0800

Bill and all,

  Exactly right Bill!  Thank you!  >:)  But we also need/require
openness and transparency as well as accountability.

Regards,

---

From: [email-masked]
Date: Sat, 28 Feb 2009 10:57:28 +0000

On Sat, Feb 28, 2009 at 10:10:35AM +0100, bert hubert wrote:
> As Ben Laurie said:
> 
> 	Does DNSSEC have any other uses? OK, it would be nice to know that
> 	the A record you just got back corresponds to the server you were
> 	looking for, but if you trust a connection just on the basis that
> 	you used the right address, you are dead meat [..]
> 
> 	For me, the real value in DNSSEC is cryptographic key distribution.
> 
> It is interesting to note that other possible uses of DNSSEC are now being
> proposed which do justify its complexity and overhead.
> 
> Perhaps we lost sight of what people currently do with DNS, and are now
> trying to secure possible new uses? 
> 
> 	Bert

	anyone remember the HINFO record?  thats the one where the zone admin
	could list the services running on the target node.

	kind of like an SRV precursor.

	the problem i have with these records is they presume that the DNS zone
	admin -knows- what is running at the target and is willing to keep the
	data current/correct.

	in 85% of the cases of my experience, the zone admin has little communications
	with the system admin of the target. ... so letting the zone admin code 
	system capabilities in an external database (the DNS) and having the world
	expect those assignments to be accurate is a great leap of faith.  this is
	one more place where my "transitive trust" mantra comes into play.

	sure, you could have absolute trust in the data origin and the integrity of
	the data ...  BUT - we have zero proof of the accuracy of the data for -anything-
	other than channel protection.

	to get beyond channel protection, to be truely effective for things like application
	key distribution, a couple of things would have to be true:

	) the target node admin is completely authoritative for the RRset data that
	  describes the target and its capabilities - e.g. full bore secure dynamic update 
	  of all zones :)

	) dnssec would need to be re-architected (yeah for job security!) to secure 
	  at the RRset level, not the zone level.

--bill

---

From: Paul Vixie <[email-masked]>
Date: Sat, 28 Feb 2009 14:01:43 +0000

> proposed which do justify its complexity and overhead.

i'm glad to hear it.

> trying to secure possible new uses? 

i don't think so, no.  most of us who have been pushing dnssec up various
hills for the last 13 years or so have a keen understanding of what people
currently do with DNS.  some of us also foresee new applications once we
get end to end data integrity in DNS.

> 	Bert

paul

---

From: Donald Eastlake <[email-masked]>
Date: Sat, 28 Feb 2009 08:58:31 -0500

So why not delegate to the end host as primary and have it create /
serve / manage its own SRV RRs? Or, alternatively, have it do dynamic
updates to the zone that contains it?

Donald

-- 
=============================
 Donald E. Eastlake 3rd   +1-508-634-2066 (home)
 155 Beaver Street
 Milford, MA 01757 USA
 [email-masked]

---

From: [email-masked]
Date: Sat, 28 Feb 2009 15:11:28 +0000

actually, i do do that (the delegation trick)... but i think you'd have a tough time getting
 the commodity folks to support that. comcast (for example) has a tough time
 with the idea that  some service classes should even run servers.

--bill

---

From: "Jeffrey A. Williams" <[email-masked]>
Date: Fri, 27 Feb 2009 13:05:11 -0800

Bill and all,

  Doing a re-architect of DNSSEC to secure the RRset level isn't
all that difficult, and has been done already, but of course is not
have the IETF's "Stamp of approval".  As far as I am concerned,
So what?!

  None the less, overall I for one agree with your remarks, comments,
and stated observations/opinions below...  As such a FULL implementation
of DNSSEC with RRset level security is advisable, if not actually necessary
if one is going to rely on reasonable data integrity.

Regards,

---

From: bert hubert <[email-masked]>
Date: Tue, 24 Feb 2009 07:26:16 +0100

People and organizations have a limited security budget, as expressed in
money, time and attention span, and I consider DNSSEC an inefficient way to
spend that budget.

Ben expressed the limited "pure DNS" utility of DNSSEC pretty well on
http://www.links.org/?p=553 , listing lots of novel ways of using DNSSEC
before stating:

 "Does DNSSEC have any other uses? OK, it would be nice to know that the A
  record you just got back corresponds to the server you were looking for,
  but if you trust a connection just on the basis that you used the right
  address, you are dead meat - [..]" 

Combine this limited utility with the maintenance headaches needed to offset
the severe risk of downtime if any number of (small) mistakes is made, and I
find that DNSSEC requires a lot of effort, for little gain.

	Bert

-- 
http://www.PowerDNS.com      Open source, database driven DNS Software 
http://netherlabs.nl              Open and Closed source services

---

From: bert hubert <[email-masked]>
Date: Sat, 28 Feb 2009 10:10:35 +0100

> 	what WE all want is INTEGRITY in the data from the DNS.

Yes! Where 'the DNS' in this case really stands for the deployed Domain Name
System, and not just the protocol.

And departing from what 'everybody' probably agrees on, integrity in DNS for
the use of DNS as *currently happens*, should not make life a lot more
complex for zone operators, domain owners or end-users. The 'care level' is
simply not there to justify more work.

As Ben Laurie said:

	Bert

---

From: "Jeffrey A. Williams" <[email-masked]>
Date: Fri, 27 Feb 2009 14:05:38 -0800

Donald and all,

  What you suggest could be one approach, but it's kind of a
kluge.

Regards,

---

From: "Jeffrey A. Williams" <[email-masked]>
Date: Fri, 27 Feb 2009 16:58:38 -0800

Bert and all,

  Ok, your right that not everyone necessarily "Wants" what Paul
contends.  But it is in the greater good that Pauls contention should
be implemented.  Yes cost of DNSSEC can be significant and if
not managed properly from time to time can be detrimental.  But
as a professional that goes with the territory and any pro should
step up to the plate, or seek alternative employment in a very different
area of endeavor.

Regards,