Re: [dnsext] stub validation

[David Conrad <[e-mail]>]

On Oct 24, 2010, at 6:24 PM, Paul Vixie wrote:
> among many critical defects in DNSSEC as specified, there's no good model
> for stub validation,

Stub validation never really made a lot of sense to me since it implies the stub to do all the work of an iterative resolver each and every time a lookup is done for each application that links in the stub resolver library.  It seems to me that a local rdns server makes way more sense.

> and as time goes on there are fewer and fewer trustworthy rdns servers.  

A separate issue. I have as much trust in the rdns server that runs on my local machine as I do in the application that linked the stub resolver library.  I have slightly less trust in the remote rdns server that exists within my administrative realm (assuming I can communicate with it via a trusted channel, e.g., (GSS-)TSIG, SIG(0), IPSEC, TLS, etc).  Even less for the remote rdns server outside of my administrative realm but with which I have some sort of contractual relationship (and a trusted channel).  Etc. 

> let me say that until DNSSEC is commonplace, DNSSEC is a failure.

I would argue that DNSSEC is a success if it protects against a cache poisoning attack in which a high value target is involved.  As DNSSEC deployment becomes more commonplace, the probability that it will be successful increases.

> but please everybody, don't dilute the DMNF thread with this argument.

Right.  Completely separate topics.

Regards,
-drc