Subject: Re: damage - was Re: DS and cache transparency.

From: Edward Lewis <[email-masked]>
Date: Thu, 7 Nov 2002 09:57:40 -0500

At 10:48 +1100 11/7/02, [email-masked] wrote:
>	I don't believe it solves the case where the a grandparent zone
>	is being served by the child zone.  You won't get a referral
>	down to the parent zone.

Hmm, an interesting case.  You're saying that:

server:

    zone "d.e" { type master; ....}
    zone "b.c.d.e" { type master; ....}

query {b.c.d.e, DS RR, IN}

Since the authority is c.d.e for the query answer, yeah, this is scary.

What if c.d.e is run on an server not aware of the DS RR?  That 
server will then refer back to this one, and the cycle begins anew.

Even if this server sees no DS for c.d.e., this server cannot claim 
that there is no DS for b.c.d.e. because it just might be that c.d.e. 
is "privately signed" - keys distributed to resolvers - and has a DS 
for b.c.d.e.

Ugly.  U-g-l-y.  Ugly.

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
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: Olafur Gudmundsson <[email-masked]>
Date: Thu, 7 Nov 2002 10:32:52 -0500 (EST)

On Thu, 7 Nov 2002 [email-masked] wrote:

>
> > At 16:30 -0500 11/6/02, Derek Atkins wrote:
> > >Basically, yes, that's what I was asking.  Change the code so that an
> > >auth server will _ALWAYS_ recurse for _its own_ DS record?  We're
> > >already adding special-case code for DS, why not add yet another
> > >special case?
> >
> > It's possible that the server may not have a route to the parent.
> > (Even if just temporarily.)  I wouldn't want a query to it to hang in
> > that case.
> >
> > In addition - I believe[0] that the DS draft proposes a different
> > solution that what failed in August.
>

Another special case.  Real nasty, at first look I thought this was
an irrelevant case as we could safely ignore the fact that server is
authorative for the grand parent. But that makes it impossible for the
DS aware resolver to find the correct zone.

There two possible solutions come to mind:
    -   have this server hand out a delegation for the parent
    -   stick with what we have in the document return
		a no data answer (RCODE:NOERROR, Auth: SOA + NXT

The first one is identical to the 103x behavior for lookup of data in
the parent zone. BUT this may cause a non-DS aware resolver to mark
the server as lame for the child.

In the second case the server operates in an identical manner for
DS and all other types that do not exist at the apex.
BUT in this case resolver may never find the parent zone, as
the server does not hand out the delegation as it would if the query was
for a name it is not authorative for.

I think in this case we need to put logic into the resolver to discover
the zone cut, and ask explicitly for NS for one label shorter than the
name on the child zone. If the NS set returned does not include the
server queried parent resides on a different server. (YUCK).

OR do we need a EDNS0 option to inform the server the resolver is
DS aware and please put the NS for the parent in the answer?

Are there any more special cases that need to be considered ?

	Olafur

---

From: "Olaf M. Kolkman" <[email-masked]>
Date: Thu, 7 Nov 2002 18:46:38 +0100

> DS aware and please put the NS for the parent in the answer?

But we allready have a DNSSEC aware bit... (Forget RFC2535 compatibility,
RFC2535 DNSSEC has a small install base and people doing that are on top
of developments.)

--------------------------------------------| Olaf M. Kolkman
                                            | www.ripe.net/disi

---

From: Edward Lewis <[email-masked]>
Date: Thu, 7 Nov 2002 15:45:34 -0500

>Another special case.  Real nasty, at first look I thought this was
...
>		a no data answer (RCODE:NOERROR, Auth: SOA + NXT

#1 won't work and #2 may give the wrong answer.

Unfortunately I can't dwell on this now - other issues are pressing - 
but there's one idea I've been urged to mention.  At the August 
workshop, I made the comment that the DS is a significant departure 
from other types.  Because of this, addressing the odd-ball cases 
that are created may require fairly drastic changes - such as a new 
RCODE (IDONTKNOW) or some treatment in the OPT RR.

I've had some thoughts about "now it takes qname+qtype to determine 
the auth zone" and "what degrees of freedom" are available, but I 
can't spend time on it right now.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                          +1-703-227-9854
ARIN Research Engineer