Subject: the DS deployment problem

From: Michael Richardson <[email-masked]>
Date: Sun, 12 Jan 2003 17:07:16 -0800

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

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.

]       ON HUMILITY: to err is human. To moo, bovine.           |  firewalls  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net architect[
] [email-masked] http://www.sandelman.ottawa.on.ca/ |device driver[
] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [

--
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: Ólafur Guðmundsson<[email-masked]>
Date: Sun, 12 Jan 2003 21:01:02 -0500

>I want to make sure that I understand this.  It seemed too simple to me!

Thank you simple is good.

>        NS-A                                NS-B

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

---

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

---

From: Michael Richardson <[email-masked]>
Date: Mon, 13 Jan 2003 14:32:17 -0800

-----BEGIN PGP SIGNED MESSAGE-----

>>>>> "Edward" == Edward Lewis <[email-masked]> writes:
    >> details about how to handle DS for the ancestor problem. But that -12 of the

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

    Edward> But there's been no discussion of it.  (The text was prompted by some 
    Edward> confusion a few of us had regarding great-great-*-great-grandparents 
    Edward> and the 'strip a label' instruction.)

Here are your comments, again:

    Edward> 1) If the server is authoritative for the zone that holds the DS RR
    Edward>    set (i.e., the zone that delegates <QNAME> away, aka the "parent"
    Edward>    zone), the response contains the DS RR set as an authoritative answer.

    Edward> 2) If the server is offering recursive service, the server performs
    Edward>    the query itself (according to the rules for resolvers described
    Edward>    below) and returns it's findings.

    Edward> 3) If the server is authoritative for the zone that holds the
    Edward>    <QNAME>'s SOA RR set, the response is an authoritative negative answer
    Edward>    as described in 2.2.1.1.

    Edward> 4) If the server is authoritative for a zone above the QNAME, a
    Edward>    referral to a more enclosing zone's servers is made.

    Edward> 5) If the server is not authoritative for any part of the QNAME, a
    Edward>    response indicating a lame server for QNAME is given.

I can not argue with any of these. Maybe I'm just too dead for too many late
nights recently, to think these through. Can you tell me what problems each
one of these points addresses?

Olafur's rather simple suggestion, which I think was originally proposed for
the DNSSEC work way back when (I spent yesterday in long meetings with John
Gilmore, and we discussed this), gets rid of any issues with dealing with
caches, since you do not depend upon them fetching the right stuff, you just
keep asking on the way up the chain.

---

From: Edward Lewis <[email-masked]>
Date: Mon, 13 Jan 2003 16:17:19 -0800

I jumbled your words to present a better response

>keep asking on the way up the chain.

What I suggested should be the same as Olafur's suggestion, just more 
tersely and concretely written.  (The motivation of the suggestion 
was to clear up the text in -12, not conflict/change the strategy.)

>one of these points addresses?

Sure, I'll hit them line by line.

>  Ed> 1) If the server is authoritative for the zone that holds the DS RR
>  Ed>    set (i.e., the zone that delegates <QNAME> away, aka the "parent"
>  Ed>    zone), the response contains the DS RR set as an authoritative answer.

The best of all possible situations is that the query has hit the (or 
a) "right" server.  If a server holds the answer, there's no reason 
to withhold it.

>  Ed> 2) If the server is offering recursive service, the server performs
>  Ed>    the query itself (according to the rules for resolvers described
>  Ed>    below) and returns it's findings.

I think this is the next step - regardless of any other 
configuration.  (I can be argued over this.)  I notice that I missed 
a doing a cache lookup, but that should probably be done here as well 
(cache then recurse) under the theory - if you have the answer, send 
it.

>  Ed> 3) If the server is authoritative for the zone that holds the
>  Ed>    <QNAME>'s SOA RR set, the response is an authoritative negative answer
>  Ed>    as described in 2.2.1.1.

If the server serves the zone for which you want the DS, answer negatively.

>  Ed> 4) If the server is authoritative for a zone above the QNAME, a
>  Ed>    referral to a more enclosing zone's servers is made.

If the server is a grand*parent of the zone, refer down.

>  Ed> 5) If the server is not authoritative for any part of the QNAME, a
>  Ed>    response indicating a lame server for QNAME is given.

Otherwise, indicate lameness as traditional.

The reason the above works is that there are instructions that the 
DS-seeker must follow.  These include:

If getting a negative answer for the DS, look at the SOA in the 
negative answer.  This will give you the name of the zone where the 
query is returning from (the context of the answer).  (This isn't a 
complete answer.)  Strip one label, ask for the NS - ask there for 
DS. if there's no NS (and the answer has the next up SOA), ask for 
the the NS there etc.

I'm losing focus in answering this...it's obvious.

The "fear" is that zones may have multilabel deep 
delegations...that's where the confusion comes in.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                          +1-703-227-9854
ARIN Research Engineer