Subject: wildcard optimization and b/w incompatibility

From: Edward Lewis <[email-masked]>
Date: Tue, 19 Nov 2002 21:11:49 -0500

I'm not sure, but I think this paragraph is wrong:

#   The fact that resolvers that obtain an answer with a NXT RR's NOWILD
#   set to 1 do not receive additional proof for the non-existence of
#   wildcards is incompatible with RFC2535.

This is at the end of section 2.2, "resolver side" processing discussion.

After hearing Olaf's presentation I was thinking about whether or not 
this proposal indeed lacks backwards compatibility.

For "old" = not optimizing and "new" = optimizing,  we need to look 
at four cases.

1) New signer, old server.
2) New resolver, old server.
3) Old signer, new server.
4) Old resolver, new server.

1 - a problem only if the server checks the NXT type bit map on load, 
axfr, ixfr, or dynamic update.

2 - not a problem, the resolver will "fall back" to having to handle 
the whole proof.

3 - no a problem, the server will always have to provide the full response.

4 - this is a two step problem.  Old resolvers don't look for the 
wildcard NXT anyway, as we didn't notice the omission until the 
August workshop.  If there is an old resolver that did anticipate 
this, a problem would arise only if the resolver was "lazy" in my 
words.  By this I mean - if a resolver is "missing" some expected 
data, it should go ask for it, not be lazy and give up.

Question to the implementers - are there implementation-level 
problems with the first and last case?
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                          +1-703-227-9854
ARIN Research Engineer

--
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: Brian Wellington <[email-masked]>
Date: Tue, 19 Nov 2002 23:12:50 -0800 (PST)

> data, it should go ask for it, not be lazy and give up.

Maybe you didn't notice the omission, but it's been known for years.  The 
lack of wildcard DNSSEC support has been documented in the BIND 9 README 
file since the file was written, well before 9.0.0 was released.

> problems with the first and last case?

The first case is irrelevant, as no servers do that.

The last case will affect servers that support wildcard proof, of which 
there is at least one.  No dnssec capable server that I'm aware of 
will look for missing NXT records, as this would be extremely 
complicated and would likely lead to deadlocks.

There is a backwards compatibility issue.

Brian

---

From: Edward Lewis <[email-masked]>
Date: Wed, 20 Nov 2002 09:41:46 -0500

>complicated and would likely lead to deadlocks.

By "no dnssec capable server" do you mean "no dnssec capable resolver 
in use by a server?"  The confusion is:

1) Are you talking about the problem of finding all NXT records 
needed to accomplish a validation of authenticated denial of 
existence?

2) Are you talking about the problem of locating all necessary NXT 
records when assembling a reply?

I'm assuming that you mean #1 - the "last case" was an old resolver 
and a new server.

If so - could you expand on your rationale.  "Extremely complicated" 
leaves me with not enough data to know if this is because of an 
implementation decision or a protocol definition.  Also, a phrase 
such as "likely lead" is just as hard to evaluate.

The reason I ask is that when I once wrote a non-threaded, dedicated 
resolver, discovering that some piece of data is missing and needed 
to be retrieved wasn't all that hard.  Given that BIND 9 is a much 
more complicated code base, perhaps there is some deadlock potential 
(especially if data keeps timing out before you can evaluate the 
signatures), but I'd like a deeper description.

(else - let me know if it's #2 you mean)
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                          +1-703-227-9854
ARIN Research Engineer

---

From: Brian Wellington <[email-masked]>
Date: Wed, 20 Nov 2002 18:43:32 -0800 (PST)

> in use by a server?"  The confusion is:

Yes.

> needed to accomplish a validation of authenticated denial of 

Yes.

> records when assembling a reply?

No.  For a non-SERVFAIL reply to be sent, all of the NXT records must 
already be present, since they were needed for validation.

> such as "likely lead" is just as hard to evaluate.

Writing such an implementation would be extremely difficult and not worth
it, since any compliant authoritative server should return all needed NXTs
anyway.

Yes, 'likely lead' is hard to evaluate.  Having written multiple DNSSEC 
validating resolvers, there are many things which lead to deadlock.  
Without implementing this, I can't tell you for sure, but based on prior 
experience, I think there's a very good chance that it would.  I'm not 
going to implement this just to find out.

> signatures), but I'd like a deeper description.

I'm not talking about BIND 9.  I"m talking about servers in general.  Yes, 
going out to get a missing piece of data sounds easy, but then when you 
try to validate it, you might be missing something else, or it might 
depend on the validation which is already in progress, or any of a number 
of other issues which lead to deadlock.

Brian

---

From: Edward Lewis <[email-masked]>
Date: Wed, 20 Nov 2002 22:10:21 -0500

>it, since any compliant authoritative server should return all needed NXTs

True, but, 1) "compliant" changes and 2) I know of current servers 
that don't return the wildcard NXT in NXDOMAIN answers now.  Yes, 
this is non-compliance, but there's always that discussion of 
'miscreant' elements to consider.

>going to implement this just to find out.

There are three possible responses to this.

1) Does anyone else want to try?  (As it's Brian's right to refuse a try.)
2) Can someone prove this analytically?
3) Should we drop this discussion and 'assume' backwards compatibility?

>I'm not talking about BIND 9.  I"m talking about servers in general.

I used "BIND 9" in the sense that it's code that is much more 
complicated than what I wrote, so my experience may not be applicable 
here.

---

From: Brian Wellington <[email-masked]>
Date: Thu, 21 Nov 2002 11:39:47 -0800 (PST)

> 'miscreant' elements to consider.

Yes, but at some point you need to just say that if you're getting bad 
responses to your queries, you're going to fail.

> 3) Should we drop this discussion and 'assume' backwards compatibility?

I'd vote for (3).

> complicated than what I wrote, so my experience may not be applicable 

Right.  The latest validator I've written is far simpler than BIND 9 also, 
and I still think this behavior could be problematic.

Brian

---

From: Edward Lewis <[email-masked]>
Date: Thu, 21 Nov 2002 15:51:29 -0500

>>  3) Should we drop this discussion and 'assume' backwards compatibility?

I meant 'incompatibility' (a typo) - does that change your vote?
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                          +1-703-227-9854
ARIN Research Engineer

---

From: Brian Wellington <[email-masked]>
Date: Fri, 22 Nov 2002 11:03:00 -0800 (PST)

> I meant 'incompatibility' (a typo) - does that change your vote?

Not really.  We've known all along that 2535 DNSSEC will not work when DS
is deployed, so I don't see why this is an issue at all.

Brian