Subject: Re: DS and cache transparency.

From: Edward Lewis <[email-masked]>
Date: Mon, 4 Nov 2002 09:15:04 -0500

At 14:37 -0500 10/28/02, Ólafur Guðmundsson wrote:
>At 14:12 2002-10-28, Olaf Kolkman wrote:
>
>>  >>  > My question is did we ever consciously decide to live with the
>>  >>  > architectural constraints or is there still work to do on defining the
>>  >>  > label magic?
>>  >>
>>  >>  I'd rather live with the constraints and avoid the label voodoo.
>>
>>Perfect...
>>
>>Should the 'only DNSSEC in line of sight" constrain be made explicit
>>in the DS draft?
>
>This is applies not just to DS but all DNSSEC Records and should
>be mentioned in the DNSSEC-bis protocol document.

Well, only the DS RR is the problem, but it condemns the other DNSSEC 
RR's as well.  Because it may happen that a cache with a resolver 
that is unaware of the implications of the DS RR just might get asked 
to retrieve a DS RR for an aware resolver, I'm afraid that such a 
constraint is needed.  (I hate constraints.)

Because a resolver seeking a DS RR has to be smart enough to ask the 
parent and not the child zone, only aware resolvers should ever have 
to go look for a DS RR.  And without the DS RR's available, the other 
records become useless.

I hope this comment is in-line with the discussion.  I'm not 
completely sure I grok the intent, but I think this is what is being 
asked here.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
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: [email-masked]
Date: Tue, 05 Nov 2002 07:20:39 +1100

> completely sure I grok the intent, but I think this is what is being 

	Getting only DS aware servers in the line of site is the small
	part of the problem.

	The main problem however is that you can't stop a non DS
	aware cache being asked about DS.  You need to give back a
	answer to such a cache that will not result in it treating
	the server as lame.

	Mark

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

---

From: Edward Lewis <[email-masked]>
Date: Mon, 4 Nov 2002 17:19:52 -0500

At 7:20 +1100 11/5/02, [email-masked] wrote:
>	...  You need to give back a

I agree, but I stopped short of saying that because it's not a 
foregone conclusion that this will happen - I think.  The code in one 
snapshot is susceptible to this because of how the code works, but my 
understanding is that this can be fixed.

You're right, the problem is that a non-DS aware resolver will ask 
the child and not the parent, which leads to the problem.  If nothing 
else, the resolver will get the wrong impression from the child, up 
to the possiblity that the child is lame.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                          +1-703-227-9854
ARIN Research Engineer

---

From: Derek Atkins <[email-masked]>
Date: 04 Nov 2002 19:44:00 -0500

Well, we can do the obvious "be liberal in what you accept" and if the
child gets a request for its own DS it can recurse, response with the
DS, and perhaps log the 'broken cache'.

-derek

Edward Lewis <[email-masked]> writes:

> You're right, the problem is that a non-DS aware resolver will ask the
> child and not the parent, which leads to the problem.  If nothing
> else, the resolver will get the wrong impression from the child, up to
> the possiblity that the child is lame.
> -- 

-- 
       Derek Atkins
       Computer and Internet Security Consultant
       [email-masked]             www.ihtfp.com

---

From: Olaf Kolkman <[email-masked]>
Date: Tue, 05 Nov 2002 07:41:35 +0100

* You're right, the problem is that a non-DS aware resolver will ask 
 * the child and not the parent, which leads to the problem.  If nothing 
 * else, the resolver will get the wrong impression from the child, up 
 * to the possiblity that the child is lame.

I think it's safe to conclude that we do not want to 'fix' this
problem with a namespace hack so that the parent becomes authoritive
for DS RRs. (e.g. by adding a null byte to the first label as somebody
(Derek???) suggested)

That was my initial question after all :-)

--Olaf

---

From: [email-masked]
Date: Tue, 05 Nov 2002 17:52:49 +1100

> That was my initial question after all :-)

	I think that was the feeling of everyone that responded.

	Mark

---

From: Edward Lewis <[email-masked]>
Date: Tue, 5 Nov 2002 09:55:31 -0500

>	I think that was the feeling of everyone that responded.

me too.

---

From: Edward Lewis <[email-masked]>
Date: Tue, 5 Nov 2002 10:02:49 -0500

First - see my response to Mark...

>DS, and perhaps log the 'broken cache'.

This doesn't apply here.  Let me whiteboard it:

   resolver ------> old cache -------> authoritative server

The liberal in what you accept policy would protect the resolver. 
But the entity at risk here is the old cache.  The problem is that if 
the authoritative server answers as the BIND 7/22 snapshot[0] does, 
it is possible that a cetain sequence of queries by the resolver will 
"break" the old cache.  The old cache will mark (all of) the 
authoritative server(s) as lame for "the" zone.  Others then asking 
the old cache for data from that same zone will be told that the zone 
can't be found.

[0] For those wanting to giggle at BIND, keep in mind that this is a 
snapshot, meaning it contains experimental code.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                          +1-703-227-9854
ARIN Research Engineer

---

From: Derek Atkins <[email-masked]>
Date: 06 Nov 2002 15:57:49 -0500

Let me alter your whiteboard drawing:

   resolver --> old-cache --> auth-server(child) --> auth-server(parent)

If the auth-server(child) received a query for "IN DS" it can recurse
the query to its parent and send the response back to the old-cache.
In other words, as far as the old-cache is concerned, the
auth-server(child) _IS_ responding with data.  The "resolver" need
never know the difference, and the old-cache will never mark
auth-server(child) as lame.

How does this not work (except for the fact that it breaks the
authority abstraction, but there is no reason a child cannot 'cache'
the DS from its parent as any over resolver/cache would).

-derek

Edward Lewis <[email-masked]> writes:

> The liberal in what you accept policy would protect the resolver. But
> the entity at risk here is the old cache.  The problem is that if the
> authoritative server answers as the BIND 7/22 snapshot[0] does, it is
> possible that a cetain sequence of queries by the resolver will

---

From: Edward Lewis <[email-masked]>
Date: Wed, 6 Nov 2002 16:07:48 -0500

>the query to its parent and send the response back to the old-cache.

True, but we've (or I've) left out part of the story.

>auth-server(child) as lame.

The discussion on this kind of brokenness has assumed that the 
auth-servers are running in nonrecursive mode.  Recursive ones did 
not have a problem during the workshop.

>the DS from its parent as any over resolver/cache would).

I'm sorry, I can't parse the above paragraph.

Are you asking why, with a recursive child auth-server, is there a 
problem?  There ain't any.  If you turn recursion off, like any good 
auth-server operator should (;)), you'll have a problem - IF we stick 
with the failed-experimental code that kicked this all off in August.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                          +1-703-227-9854
ARIN Research Engineer

---

From: Derek Atkins <[email-masked]>
Date: 06 Nov 2002 16:30:54 -0500

> with the failed-experimental code that kicked this all off in August.

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?

-derek

---

From: Edward Lewis <[email-masked]>
Date: Wed, 6 Nov 2002 16:53:55 -0500

>already adding special-case code for DS, why not add yet another

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.

[0] The editor told me it does.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                          +1-703-227-9854
ARIN Research Engineer

---

From: Brian Wellington <[email-masked]>
Date: Wed, 6 Nov 2002 14:48:16 -0800 (PST)

> already adding special-case code for DS, why not add yet another

You've got to be kidding.

Having an authoritative-only server perform recursion is not a special 
case.  It's an authoritative-only server.  By definition, it doesn't do 
recursion.  There's no requirement that it even knows how to do recursion
or what its parent zone is.

Note that this also causes other problems, since even if the server did 
the recursion, it would respond with AA=0, since it's not authoritative 
data, which would confuse the requestor, who was asking what it thought 
was the authoritive server.

Brian

---

From: [email-masked]
Date: Thu, 07 Nov 2002 10:48:58 +1100

> solution that what failed in August.

	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.

---

From: Bill Manning <[email-masked]>
Date: Wed, 6 Nov 2002 17:30:27 -0800 (PST)

% > 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?
% 
% You've got to be kidding.
% 
% Having an authoritative-only server perform recursion is not a special 
% case.  It's an authoritative-only server.  By definition, it doesn't do 
% recursion.  There's no requirement that it even knows how to do recursion
% or what its parent zone is.
% 
% Note that this also causes other problems, since even if the server did 
% the recursion, it would respond with AA=0, since it's not authoritative 
% data, which would confuse the requestor, who was asking what it thought 
% was the authoritive server.
% 
% Brian

	sorry for the clueless post, but isn't authority
	based on zone, not server.

-- 
--bill

---

From: Brian Wellington <[email-masked]>
Date: Wed, 6 Nov 2002 17:34:53 -0800 (PST)

> 	based on zone, not server.

Yes, but it's very common for a server to be authoritative for one or more 
zones and not support recursion at all.  Presumably a server that acts as 
both an authority and a recursive server could do this, but would hit the 
second problem described above.

Brian

---

From: Paul Vixie <[email-masked]>
Date: Thu, 07 Nov 2002 04:48:14 +0000

> or what its parent zone is.

not only that.  authority and recursion by the same server instance is
ill defined in the 1034/1035 docs.  (if you are authoritative for vix.com
and there's a zone cut at lh.vix.com and someone asks you for xx.lh.vix.com
do you send a referral or do the recursion?)  ideally, a subsequent version
of bind9 will become strictly modal -- recursive, or authoritative, but
never both.  unfortunately, historical configs would become incompatible,
so it's unlikely to happen as soon as i'd like.

---

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

>	is being served by the child zone.  You won't get a referral

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.

---

From: Olafur Gudmundsson <[email-masked]>
Date: Thu, 7 Nov 2002 10:32:52 -0500 (EST)

> 	is being served by the child zone.  You won't get a referral

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