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

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

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

	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.

> [0] The editor told me it does.
> -- 
> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
> 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/>
--
Mark Andrews, Internet Software Consortium
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

--
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: 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: Edward Lewis <[email-masked]>
Date: Fri, 15 Nov 2002 17:14:35 -0500

This seems to have not made it to the list/it's not in the archives...

>Date: Fri, 8 Nov 2002 08:35:01 +0100
>From: "Olaf M. Kolkman" <[email-masked]>
>To: Edward Lewis <[email-masked]>
>Cc: [email-masked]
>Subject: Re: damage - was Re: DS and cache transparency.
>Organization: RIPE NCC
>X-RIPE-Spam-Status: NONE ; -1004
>Status:
>
>
>Ed wrote, in somewhat different context:
>
>>  Ugly.  U-g-l-y.  Ugly.
>
>
>This is just a thought, it relates to the subject and qualifies as
>Ugly U-g-l-y. Ugly. It is only to be considered if we find the
>'damaging' corner cases important enough to be solved and introduce
>yet new delays. While most probably not The Solution(TM), it may
>inspire to better solutions.
>
>
>It seems that most DS corner-cases are caused by the fact that a
>resolver ends up at the child and does not know how to get to the
>parent. Besides, 'classic' resolvers may mark servers as lame because
>the DS is not served from servers that are, in the eyes of the classic
>resolver, authoritative for the namespace.
>
>A way out of this is to have the DS on both sides of the zone cut but
>in two incarnations indicated by a flag. In normal cases you would
>(should) get an authoritative DS RR from the parent with the hash of
>the child's key. If for some reason the server authoritative for the
>child zone is queried for the DS it hands out a DS in the second
>incarnation, that DS's rdata contains the name of the parent
>zone. Resolvers that get this DS incarnation back will know where to
>go for the 'real answer' directly.
>
>
>                       Incarnation flag
>                           |
>                           V
>
>foo.example. 3600  IN  DS 1  42495  1  1  0123abc(....)
>
>foo.example. 3600  IN  DS 2  example.
>
>
>This scheme may also be useful in situations where the parent's NS and
>the child's DS RRs have expired from the cache and you want to get to
>the DS without traversing the namespace from the root in the hope
>that the parent passes you a new DS RR.
>
>In the Mark's example of the server authoritative for grand-parent and
>child zone, a resolver would get the 2nd incarnation that would point
>you to the parent. The resolver could go out to the parent and query
>for the DS directly.
>
>
>
>--Olaf
>
>
>
>
>--------------------------------------------| Olaf M. Kolkman
>                                             | www.ripe.net/disi
>