Subject: Re: the DS deployment problem

From: Ólafur Guðmundsson<[email-masked]>
Date: Sun, 12 Jan 2003 21:01:02 -0500

At 20:07 2003-01-12, Michael Richardson wrote:
>-----BEGIN PGP SIGNED MESSAGE-----
>
>
>So, I didn't realize that there was already a document specifying some more
>details about how to handle DS for the ancestor problem. But that -12 of the
>DS draft now has:
>
>313a315,333
> > 2.2.1.2 Special processing when child and an ancestor share server
> >
> >    When a child zone and a ancestor other than parent share an
> >    authorative server, a DS aware server MUST answer with information
> >    from child zone, as specified in section 2.2.1.1. This is to prevent
> >    the server to be marked as lame for child.
> >
> >    This answer can cause problem for a DS aware resolver that is
> >    traversing this branch of the DNS tree for the first time. The
> >    resolver is expecting to get back either DS record or a delegation
> >    information. The SOA with same name as QNAME informs the resolver
> >    that the answer orignated from the zone below the one where the DS
> >    resides. At this point the resolver has no information on how to get
> >    from the ancestor to the parent. In this case the resolver SHOULD
> >    attempt to fetch the delegation information by issuing a query with a
> >    QNAME one label shorter and type NS. This will yield the NS set for
> >    the parent, allowing the resolver to query for the DS record.
> >
>
>I want to make sure that I understand this.  It seemed too simple to me!

Thank you simple is good.

>Given two name servers:
>
>        NS-A                                NS-B
>    +------------+                      +--------------+
>    |    example.|                      |   b.example. |
>    |a.b.example.|                      |              |
>    +------------+                      +--------------+
>
>with records:
>
>      example.     NS NS-A                b.example.    NS NS-B
>                   SOA foo                              SOA bar
>                   KEY xxxxx                            KEY yyyyy
>      b.example.   NS NS-B                a.b.example.  DS  hash(zzzzz)
>                   DS hash(yyyyy)                       NS  NS-A
>      a.b.example. NS NS-A
>                   SOA baz
>                   KEY zzzzz
>
>So, if I ask NS-A, for a.b.example DS, then I get "a.b.example. SOA baz", and
>I get no other information, because the DS doesn't reside there.
>I do not get "b.example. NS NS-B", because I didn't ask for that.  So, the
>instructions say, as for "b.example. NS", and we can make progress.
>
>Now, part of the problem was, what if there was a recursive resolving DNS
>server in front of the querier, that didn't know about DS. And one was forced
>to use this. (A proxy DNS server in a firewall for instance)
>
>So, I think that this doesn't screw anything up as well.
>
>I think, that one has to do queries with one shorter label recursively in the
>situation where maybe a server is authoritative for example. and
>a.b.c.example. I may be wrong here - I have to think about it some more.

This problem has been flagged as a DS problem but it is not, it is a
general DNSSEC problem.
In your example if you had asked for "a.b.example. KEY"
you got back signed answer, but the resolver has to go back and construct
the key chain from . to a.b.example. in order to verify the result.
If there had not been a ancestor in the path, the key chain is
constructed while traversing down the referral chain.

         Olafur

--
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: Edward Lewis <[email-masked]>
Date: Mon, 13 Jan 2003 11:02:28 -0800

>details about how to handle DS for the ancestor problem. But that -12 of the

I sent some suggested text for the section in a message:
   http://ops.ietf.org/lists/namedroppers/namedroppers.2002/msg02256.html

But there's been no discussion of it.  (The text was prompted by some 
confusion a few of us had regarding great-great-*-great-grandparents 
and the 'strip a label' instruction.)
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                          +1-703-227-9854
ARIN Research Engineer