Subject: Re: DS and cache transparency.

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
>	answer to such a cache that will not result in it treating
>	the server as lame.

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

--
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: 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: 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