Date: Fri, 8 Nov 2002 08:35:01 +0100
From: "Olaf M. Kolkman" <olaf@ripe.net>
To: Edward Lewis <edlewis@arin.net>
Cc: namedroppers@ops.ietf.org
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