Subject: DNSSEC - Application use of Provable non-existence

From: Mike StJohns <[email-masked]>
Date: Sun, 26 Nov 2006 21:48:32 -0500

Please see also the other thread on the MX/A record issue in SO 
raised by Rob Austein.

My general question is "Are there any applications that care about 
PNE?".   In other words, if validation is done only at the 
end-client, are there any applications that will do different things 
for an output of "bogus" vs a result of "invalid" or "unknown"?

One of the folks in line kept saying that he had an application that 
cared - Mozilla.  I'm not quite prepared to agree that exposing the 
output of the validation algorithm is equivalent to having an 
application that cares about PNE.

A scenario question:

Browser has a trust anchor for .COM, and clicks on a link on a page 
targeted at "www.unknown.com".

For each of the following results, what does the operator do and why?

DNS output is "not found", validator output is "bogus"
DNS output is "not found", validator output is "didn't get all the 
DNSSEC stuff I needed" (e.g bogus)
DNS output is "not found", validator output is "validated"
DNS output is "not found", validator output is "unsecure" (e.g. 
secure unsecure delegation to unknown.com)

DNS output is "A 127.0.0.1", validator output is "validated"
DNS output is "A 127.0.0.1", validator output is "didn't get all the 
DNSSEC stuff" (bogus)
DNS output is "A 127.0.0.1", validator output is "bogus"
DNS output is "A 127.0.0.1", validator output is "unsecure"

If your answer for the last 4 has a difference in how you treat bogus 
vs unsecure, explain why?

Do your answers change if this is a zone you know (e.g. www.bankofamerica.com)?

Are there any human out of the loop applications where 
differentiating between bogus and unsecure leads to different 
behavior for the application? (but see the MX/A thread first please)

Any human in the loop applications?

PNE is used to differentiate between "unsecure" and "bogus" (e.g. 
that the DS record didn't exist), and as a way of securely 
determining that a negative answer you got was valid at the time you 
got it.  For the latter, repeating a query at a later time is built 
into the protocol - PNE may provide more efficiency, but may not be a 
cost effective increase.  For the former, see the questions above.

Mike

--
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: Shane Kerr <[email-masked]>
Date: Mon, 27 Nov 2006 12:25:13 +0100

Mike StJohns wrote:
> Please see also the other thread on the MX/A record issue in SO raised
> by Rob Austein.
> 
> PNE?".   In other words, if validation is done only at the end-client,
> are there any applications that will do different things for an output
> of "bogus" vs a result of "invalid" or "unknown"?

<snip/>

> PNE is used to differentiate between "unsecure" and "bogus" (e.g. that
> the DS record didn't exist), and as a way of securely determining that a
> negative answer you got was valid at the time you got it.  For the
> latter, repeating a query at a later time is built into the protocol -
> PNE may provide more efficiency, but may not be a cost effective
> increase.  For the former, see the questions above.

I admit not to really understanding this stuff, so apologies for my ignorance.

Anyway, shouldn't the resolver handle the cases of bogus and unsecure
differently? That is, if I get a bogus answer, shouldn't the resolver assume
that this is an attacker, and wait for the valid response to appear or perhaps
try a different name server?

My understanding is a typical timeline for querying each delegation point would
look something like this:

   while (NS left to query) and (time left) {
      query to unused NS for zone
      do {
         receive signed list of NS from root
      } while not (good signature) and (time left)
   }

Basically, if we get a reply with a bad signature we just ignore it (well, log
it maybe). So, with PNE we avoid a class of DoS.

With a resolver that works like this, the application would never get a bogus
answer, or at least not until a bit of work has been done trying to get a
non-bogus answer. So it's not really fair to ask "how would the application
handle it differently", because the circumstances in which you get one or the
other are slightly different.

But maybe it doesn't work like this, and I'm just confused. :)

- --
Shane

---

From: Suresh Krishnaswamy <[email-masked]>
Date: Mon, 27 Nov 2006 09:55:29 -0500

> PNE?".   In other words, if validation is done only at the end- 
> client, are there any applications that will do different things  

The general answer is that all applications, including Mozilla, may  
care about PNE (depending on local policy). For instance I have local  
policy on my machine configured like so:

mozilla: zone-security-expectation
	. 					   ignore
	dnssec-tools.org		   validate;

On my machine Mozilla performs no validation by default. It returns  
answers under the dnssec-tools.org domain only if they "validate ok"  
or if the zone (under dnssec-tools.org), from where the data was  
received, is provably insecure (PNE of the delegation's DS).

I see a distinction between the PNE case above (where the parent has  
made an explicit statement about the verifiability of data in the  
child zone) and that of receiving a bogus or indeterminate answer.

Also, the trust anchor setting should not be the only mechanism to  
decide the "zone security expectation" IMHO. Trusting or not trusting  
the data under a provably insecure zone may also, similarly, be a  
matter of policy.

---

From: Edward Lewis <[email-masked]>
Date: Tue, 28 Nov 2006 09:30:46 -0500

At 21:48 -0500 11/26/06, Mike StJohns wrote:

>My general question is "Are there any applications that care about PNE?".
>In other words, if validation is done only at the end-client, are there
>any applications that will do different things for an output of "bogus" vs
>a result of "invalid" or "unknown"?

That question ought to be sent to the Apps ADs.

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                +1-571-434-5468
NeuStar

Dessert - aka Service Pack 1 for lunch.

---

From: Ted Hardie <[email-masked]>
Date: Tue, 28 Nov 2006 10:21:30 -0800

>That question ought to be sent to the Apps ADs.

Also the RAI ADs, and the [email-masked] list, and possibly to the
main IETF list as well.

My personal, not-wearing hats answer to this is that the DNS model
many applications  have had in the past is to treat non-existence as an
error conditions which is reflected to the user, if there is a
human user.  Those error conditions (like "Safari can't open the page
"http://www.faurlsknjn.com/" because it can't find the server
"www.faurlsknjn.com". ) prompt the user to check for mis-typings
and other errors.  I believe that once we see more deployment of DNSSEC,
similar errors reflected to the user will distinguish between bogus
and the secured equivalent of the current non-existence.  There
are already mailers and browsers which warn users if the strings in
URIs may be attempts to confuse, and making the error conditions
"bogus", "invalid", and "unknown" visible and distinguishable seems
to me like a reasonable extension of the efforts already in place.

Just my personal opinion,
			Ted

---

From: Peter Koch <[email-masked]>
Date: Tue, 28 Nov 2006 20:11:18 +0100

> human user.  Those error conditions (like "Safari can't open the page

this is true in this particular case, but many name resolutions involve
steps not directly visible to the user, where NXDOMAIN (or NOERROR/NODATA)
is not an error, but a point of information. Consider DNS search path
evaluation, for one.

Also, multiple applications that make use of the SRV RR have defined "fallback
schemes" in case an SRV RRSet cannot be found (SOAP/BEEP, XMPP, ...).
And even if an SRV RRSet exists, a target host name might be spoofed away.
Whether that's "only" a DoS or can actually be exploited is a different issue.

ENUM also uses the implicit fallback to the PSTN. Again, whether that's
"just" a DoS is an open issue.

Others with a need of authenticated denial include applications that use
"DNS tree climbing" (bad habit, glad it breaks ...) or the recently
developed mail sender authentication schemes of different flavor.
Anything that uses a default as a consequence of a negative response can
fooled.

-Peter

PS: I'd love to see "MX, then A" vanish, but I doubt it would solve this
    problem.

---

From: Mike StJohns <[email-masked]>
Date: Tue, 28 Nov 2006 13:50:30 -0500

At 06:25 AM 11/27/2006, Shane Kerr wrote:
>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA1
>
>Mike StJohns wrote:

In both cases, the answers are unsigned.  The question is not so much 
what I do for the bogus answer, but why I wouldn't do the same thing 
for the unsecure answer.  But the general policy in intermediate 
validating resolvers is to block bogus answers, but pass answers with 
a validation status of unsecure and unknown (e.g. no trust anchor).

>-----BEGIN PGP SIGNATURE-----
>Version: GnuPG v1.4.5 (GNU/Linux)
>Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>
>iD8DBQFFassYMsfZxBO4kbQRAlTFAKDnyv/aQQwKnRGAdDro66fUGHsPrgCg2wgC
>s7jhrOHjhaLvuFd+CEf+KDQ=
>=tFW/
>-----END PGP SIGNATURE-----
>
>--

---

From: Mike StJohns <[email-masked]>
Date: Tue, 28 Nov 2006 15:35:23 -0500

>to me like a reasonable extension of the efforts already in place.

Hi Ted -

Without DNSSEC, if I type an invalid name, I get a DNS answer that 
suggests I should try again.

With a browser capable of PNE DNSSEC, if I type an invalid name I get 
a signed DNS answer that says the name doesn't exist at this time and 
suggests I should try again...

Hmm...

Or I can type an invalid name and get a bogus answer that suggests I 
should try again.

Or I can type an invalid name and get an unsecure answer that suggest 
I should try again.

Hmm...

Or I can type a valid name and both PNE and SO say its OK so I connect...

Or I can type a valid name, but the response comes back as 
unvalidated (missing sigs, etc) - I treat it with suspicion and maybe 
try again.

Both PNE and SO both agree that if a positive answer is signed all 
the way then you should use it - its all the other cases I can't 
quite get people to enumerate what they'll do.

As I said - PNE does provide more capability, but I can't get a 
consistent statement on what to do with that capability.

Mike

---

From: Mike StJohns <[email-masked]>
Date: Tue, 28 Nov 2006 14:32:47 -0500

At 09:55 AM 11/27/2006, Suresh Krishnaswamy wrote:

>>end-client, are there any applications that will do different 
>>things for an output of "bogus" vs a result of "invalid" or "unknown"?
>>
>
>care about PNE (depending on local policy). For instance I have 
>local policy on my machine configured like so:
>

OK - so you return data under dnssec-tools.org where you get a 
validated answer, where you get an unsigned answer with a proof of an 
unsecure delegation.  You also return data for every other point in 
the tree.  You only block data under dnssec-tools.org where it fails 
to validate, but there's not proof of an unsecure validation.

This still doesn't answer my general question.  You're setting policy 
for a zone you know about - you're not trusting the delegation from 
.org to make a decision about the zone.  Instead, if .org were 
signed, and you clicked into dnssec-tools.org - would you still use 
this policy (e.g..  ".org validate")?  How about for 
unknown-zone.org?  If its *you* making the decision rather than the 
browser, then you're really not having the browser do anything with PNE.

>decide the "zone security expectation" IMHO. Trusting or not 
>trusting the data under a provably insecure zone may also, 
>similarly, be a matter of policy.

I don't disagree here - but that then begs the question of whether or 
not you'd ever trust a provably unsecure zone as a matter of policy 
without knowing more about the zone than the secure/unsecure delegation policy.

E.g. how do you decide to trust or not trust?  If you're using data 
other than the secure/unsecure delegation, then why wouldn't you just 
use that other data and not even bother with the secure/unsecure stuff?

I'd really like it if about a dozen people answered the questions at 
the end of the email that started this thread and sent them to me 
privately so I could tabulate the answers and make them available to 
the list.  It would be helpful to understand how people intend to use 
the secure/unsecure indications.

Mike

---

From: Edward Lewis <[email-masked]>
Date: Tue, 28 Nov 2006 15:58:42 -0500

I'll take Academy-Award Winners of 1974, Alex...

Reading this thread and something I already posted, I'm reminded of 
this movie quote:

She's my sister...
[slap]
She's my daughter...
[slap]

I'll leave out the movie name and the rest of the quote to keep from 
spoiling the scene in case you stumble across the movie sometime.

I mentioned that DNSSEC was always meant to protect the end unit. 
DNSSEC was originally pitched as a solution to cache poisoning, some 
in the security arena still claim that motivation.  DNSSEC was also 
at one time pitched as the security from the authoritative server 
outward to the fringe of the DNS constellation.  When the SIKED BoF 
as pitched it pushed forward the idea that DNSSEC could be leveraged 
for application security and the BoF was a smashing failure (if you 
measure success as achieving WG-hood).

Cache poisoning was "solved" by the trustworthiness rules and other 
clean up in RFC 2181.  Cache poisoning is still a vulnerability but 
much harder and less effective if the caches in the pipeline all 
implement RFC 2181 rules cleanly.  I.e., the protocol "fix" is done, 
it's up to implementations.

DNSSEC is only effective until the last validator (last in the path 
from authoritative server to the application using the data).  When 
DNS becomes the application, such as following a referral, the 
validator is in the application, meaning that DNSSEC would be fine 
way to secure the guts of the DNS.  ("Daughter, sister.")  This is 
why TSIG and TKEY were connived.

Given other discussions never recorded and then the SIKED (or was it 
SYKED?) BoF, DNSSEC has never successfully been integrated into the 
non-DNS application space.

I said that DNSSEC was about protecting the consuming side of the 
data.  I should have said the consuming DNS side of the data, not the 
application.

Given that, my impression of the PNE vs. SO debate is that the two 
approaches are solving different problems and as long as that is the 
case, we'll never have an end to the debate over the two.  PNE (aka 
DNSSEC) is what the servers need to protect themselves.  SO is 
optimized for what an application would want to know.  PNE is 
optimized for DNS, SO for applications.  The two have different needs.

I'm not trying to argue that we stay true to the DNSSEC/PNE 
principles.  And I'm not arguing against SO.  What I am trying to say 
is that debating between the two is not going to lead to a 
conclusion.  They are apples and oranges.

---

From: Ted Hardie <[email-masked]>
Date: Tue, 28 Nov 2006 13:06:34 -0800

At 3:35 PM -0500 11/28/06, Mike StJohns wrote:
>
>Hi Ted -
>
>Without DNSSEC, if I type an invalid name, I get a DNS answer that suggests I should try again.

Not really. "try again" implies "try the same name again".  The answer you get
back from the DNS tells you that the name does not exist.  "Check your input" would
be a better quick summary of the advice to the user.     I think in the
message below, you're basically eliding the differences among the error messages
which are possible--making "Someone may be fooling you, try to get past it"
and "Check your input" and "This was asserted, but it may or may not be true"
all be the same.  While you can imagine that being the case (especially with a limited
UI), my personal take is that there are already programs which are provided
error-checking that is rich enough that providing distinguishable errors among
those will be done by some applications.   If you are arguing that helping people
create useful error messages from those conditions would be a good thing, I agree.
We have a lot of badness in the browser world because people collapsed
a whole set of security checks into a single token (the whole/broken key,
for example).

My personal opinion, as I said.

				Ted Hardie

>With a browser capable of PNE DNSSEC, if I type an invalid name I get a signed DNS answer that says the name doesn't exist at this time and suggests I should try again...
>
>Hmm...
>
>Or I can type an invalid name and get a bogus answer that suggests I should try again.
>
>Or I can type an invalid name and get an unsecure answer that suggest I should try again.
>
>Hmm...
>
>Or I can type a valid name, but the response comes back as unvalidated (missing sigs, etc) - I treat it with suspicion and maybe try again.
>
>
>Both PNE and SO both agree that if a positive answer is signed all the way then you should use it - its all the other cases I can't quite get people to enumerate what they'll do.
>
>As I said - PNE does provide more capability, but I can't get a consistent statement on what to do with that capability.
>
>Mike
>
>
>
>
>--

---

From: Suresh Krishnaswamy <[email-masked]>
Date: Tue, 28 Nov 2006 16:36:36 -0500

> validated answer, where you get an unsigned answer with a proof of  
> an unsecure delegation.  You also return data for every other point  
> in the tree.  You only block data under dnssec-tools.org where it  
> fails to validate, but there's not proof of an unsecure validation.
>
> This still doesn't answer my general question.  You're setting  
> policy for a zone you know about - you're not trusting the  
> delegation from .org to make a decision about the zone.  Instead,  
> if .org were signed, and you clicked into dnssec-tools.org - would  
> you still use this policy (e.g..  ".org validate")?  How about for  

I will still trust the delegation from 'dnssec-tools.org' to  
'test.dnssec-tools.org' to make a decision about data within the  
test.dnssec-tools.org zone. Same thing for 'insecure-ns.test.dnssec- 
tools.org', which is an example of a provably insecure delegation  
under test -- there's no specific statement of trust I make for the  
'insecure-ns.test.dnssec-tools.org' zone. If org were signed, my  
policy would change to "org. validate".  I'd then trust org to give  
me either a secure entry point to (or a PNE for) unknown-zone.org  
before I'd be willing to trust any data from it.  I need to have some  
knowledge of where the roots of the trust-islands  lie, but nothing  
beyond that. I can choose to trust or not trust other zones beyond  
what PNE gives me, but that's again local policy.

The main point here is that I am treating PNE differently from bogus  
and indeterminate.

> I don't disagree here - but that then begs the question of whether  
> or not you'd ever trust a provably unsecure zone as a matter of  
> policy without knowing more about the zone than the secure/unsecure  
> delegation policy.
>

I would, indeed. If the parent zone has specifically marked a zone as  
unsigned, I may want to defer to its judgement. I think this just  
scales much better. I can always override this policy if I need to  
for specific zones that I have knowledge about, but I expect this to  
only happen for the initial couple of years when deployment is still  
sparse. The policy knob that decides whether the provably insecure  
delegation is trusted or not, is again something I see as being used  
only in specialized environments -- certainly the exception, not the  
rule.

---

From: [email-masked] (Andreas Gustafsson)
Date: Wed, 29 Nov 2006 02:45:37 +0200

Edward Lewis wrote:
> implement RFC 2181 rules cleanly.

I agree that the cache poisoning problem has been solved, for most
practical purposes, by caching servers implementing anti-poisoning
rules.

However, I must point out that the specific rules in RFC2181 are in
fact not an effective defense against cache poisoning, and that the
immunity against poisoning enjoyed by current caching servers stems
from a completely different rule that is still not stated in any IETF
document.

There are several variations of this rule, but in its simplest form,
it says that when a caching server queries the authoritative servers
of a given domain, it must discard all response records whose owner
name is outside that domain.

IMO, not only do we need to put this rule in a standards document, 
but RFC2181 section 5.4.1 should go away.
-- 
Andreas Gustafsson, [email-masked]

---

From: David Blacka <[email-masked]>
Date: Tue, 28 Nov 2006 20:52:02 -0500

> name is outside that domain.

Yes!

And for this reason, authoritative servers shouldn't bother following  
CNAME chains outside the zone, since resolvers will just discard  
those records.

> but RFC2181 section 5.4.1 should go away.

It is useful to point out that caches should not promote additional  
section data to authority or answer sections, though.

--
David Blacka    <[email-masked]>
Sr. Engineer    VeriSign Applied Research

---

From: bert hubert <[email-masked]>
Date: Wed, 29 Nov 2006 12:04:25 +0100

> name is outside that domain.

Just to rehash, this could be added to chapter 3 of
http://www.ietf.org/internet-drafts/draft-hubert-dns-anti-spoofing-00.txt

	Bert

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

---

From: Shane Kerr <[email-masked]>
Date: Wed, 29 Nov 2006 13:12:11 +0100

Mike StJohns wrote:
>> what I do for the bogus answer, but why I wouldn't do the same thing for
>> the unsecure answer.  But the general policy in intermediate validating
>> resolvers is to block bogus answers, but pass answers with a validation
>> status of unsecure and unknown (e.g. no trust anchor).

I don't understand.

- - If "unsecure" means "an unsigned response that should have been signed", then
it is the same as "bogus". I'd expect the resolver to drop these.

- - If "unsecure" means "no signed DS chain from a trust anchor", then I would
expect the resolver to use these. A browser could handle this the same as SSL
certificates, and let the user know whether or not the DNS is secure.

If there is PNE, then the nice dialog that Firefox throws up can have a shining
picture indicating that the not only is there no address for this name, but that
we're "sure". I guess this is what was meant when the speaker said "I have an
application today... Firefox!"

For non-interactive applications... I don't know. The possible attack is DoS,
right? I guess some analysis of classes of non-interactive applications can be
made, but my intuition tells me that most applications will need to handle this
attack in a unique way.

- --
Shane

---

From: Mike StJohns <[email-masked]>
Date: Thu, 30 Nov 2006 13:06:57 -0500

>optimized for DNS, SO for applications.  The two have different needs.

It's unclear from the discussion that the folks 'supporting' (maybe 
too weak or too strong) PNE believe PNE is only for DNS.  It is true 
that when designing SO I looked mainly to application needs.

>principles.  And I'm not arguing against SO.  What I am trying to 
>say is that debating between the two is not going to lead to a 

You may be right - but its unclear we have the data to make that determination.

Just to clarify, I'm not arguing that PNE be abandoned, but I'm 
trying to inject some rigor into the process of reasoning about 
DNSSEC.  It is clear from the various discussion threads that there 
isn't a common understanding about the use of DNSSEC even after 14 
years - and that may be because of the complexity of the system.

Just about the only thing I've been able to glean from the 
discussions over the years is that most people believe that being 
able to validate a piece of DNS data is *good* - the rest is all over 
the place.

---

From: Mike StJohns <[email-masked]>
Date: Thu, 30 Nov 2006 13:34:35 -0500

Hi Ted -

Sorry - I was a bit flippant here.  The issue is that there are 
something like a dozen distinct things that can happen when you make 
a DNS query for a label that may or may not be DNSSEC signed.  Here's 
the enumeration as best I can make it.

- not under a trust anchor  (e.g. query for example.com when the only 
trust anchor you have is for .org)
   -- no answer various failure codes - maybe try again (check 
spelling etc), maybe give up
   -- an answer, unvalidated, saying it doesn't exist - maybe try 
again, maybe give up
   -- an answer, unvalidated, but correct - you connect
   -- an answer, unvalidated and wrong - you connect because you 
don't know the difference and maybe get sent to a fake or malicious site

- under a trust anchor (e.g. query for example.com with a trust 
anchor for .com)
-- no answer, various failure codes - maybe try again
-- an answer, validated, saying it doesn't exist - maybe try again in 
a while, maybe give up
-- an answer, validated, and correct - you connect
-- an answer, validated, and wrong - you connect, the zone owner screwed up
-- an answer, unsecure delegation, and correct - you connect
-- an answer, unsecure delegation, saying it doesn't exist - maybe 
try again, maybe give up
-- an answer, unsecure delegation, and wrong - you connect because 
you can't tell the difference...
-- an answer, unvalidated and correct - you don't connect because you 
weren't able to get a signature - but you maybe requery trying to get 
a signed answer
-- an answer, unvalidated and wrong - you don't connect because you 
weren't able to get a signature - but you maybe requery trying to get 
a signed answer
-- an answer, unvalidated, saying it doesn't exist - you maybe requery

- under SO
-- no answer, various failure codes - maybe try again
-- an answer, validated, correct - connect
-- an answer, validated, wrong - connect - zone owner screwed up
-- an answer, unvalidated, correct or wrong - you may decided to 
connect if you have an alternate means of validation or if the site 
is non-critical

Pretty much everywhere I've got "maybe" it really means - the human 
in the loop makes a decision. "try again" above means "check the 
spelling and retype, or click the link again, or wait a while and try again"

At 04:06 PM 11/28/2006, Ted Hardie wrote:
> >With a browser capable of PNE DNSSEC, if I type an invalid name I 
> get a signed DNS answer that says the name doesn't exist at this 
> time and suggests I should try again...
> >
> >Hmm...
> >
> unvalidated (missing sigs, etc) - I treat it with suspicion and 
> maybe try again.
> >
> >

---

From: Mike StJohns <[email-masked]>
Date: Thu, 30 Nov 2006 14:36:25 -0500

> >> status of unsecure and unknown (e.g. no trust anchor).

Sorry - nomenclature issues here.

>it is the same as "bogus". I'd expect the resolver to drop these.

Unsecure is data under a trust anchor where there was a secure 
delegation into an unsecure zone (e.g. proof at the parent that the 
DS record didn't exist)

>application today... Firefox!"

All you can say about data in an unsecure zone was that the parent 
said it was unsecure.  A response of non-existence is no better or 
worse than without DNSSEC or data not subordinate to a trust anchor.

If you say a site doesn't exist securely of course you know that the 
data doesn't exist - now.  The question is how long you wait until 
you decide that it might exist (e.g. TTLs)?  And how does that differ 
from what you do with DNS today (e.g. negative caching ttls)?  I know 
that if I get an answer like that regardless of whether its validated 
or unvalidated, I'm probably going to try and force a DNS lookup past 
the cache, especially if I *know* (someone told me, someone wrote it 
down, it was on a web page, etc) it existed.

If you say a site doesn't exist insecurely, you don't have the data 
to connect (i.e. no return of a A record) so you can't connect.  You 
might want to try again - and if you get a validated answer that it 
does exist (either PNE or SO) at a later time you connect.

I can't see any difference on the final result or even much on how I 
got there...

>made, but my intuition tells me that most applications will need to 

Yes.  I'd really like someone to make and publish analyses for 
several applications rather than assume a field of dreams 
approach.  At the very least it would silence some of the DNSSEC 
critics who ask "What's the value-add for DNSSEC?"

Later, Mike

>iD8DBQFFbXkbMsfZxBO4kbQRAqmLAJ9bYaDeZkTzEPDPF8Y5QQcCFw8EMQCgmO8g
>IIFL+nqnCmLETPfd7lpGQu4=
>=BuiG

---

From: Mike StJohns <[email-masked]>
Date: Thu, 30 Nov 2006 13:50:58 -0500

Take a look at my response to Ted's note with the enumeration of the 
various cases - if you could,I'd appreciate your comments on what 
you'd do for each case and why.  I'm not trying to get away from 
commenting on the below, I just think the two have converged enough.

Mike

---

From: "william(at)elan.net" <[email-masked]>
Date: Thu, 30 Nov 2006 13:28:51 -0800 (PST)

On Thu, 30 Nov 2006, Mike StJohns wrote:

> Sorry - I was a bit flippant here.  The issue is that there are something 
> like a dozen distinct things that can happen when you make a DNS query for a 
> label that may or may not be DNSSEC signed.  Here's the enumeration as best I 
> can make it.

So if you have PNE then NXDOMAIN answer would be "signed" where as NODATA
would not be?

-- 
William Leibzon
Elan Networks
[email-masked]

---

From: Mark Andrews <[email-masked]>
Date: Fri, 01 Dec 2006 10:03:23 +1100

> So if you have PNE then NXDOMAIN answer would be "signed" where as NODATA

	NODATA is signed.  See the NSEC record.
 
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]