[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


To: <dnsop@cafax.se>
cc: <dnssec@cafax.se>, <dnssec@ISI.EDU>, <namedroppers@ops.ietf.org>
From: Sam Weiler <weiler@tislabs.com>
Date: Mon, 15 Jul 2002 21:08:24 -0400 (EDT)
Sender: owner-dnsop@cafax.se
Subject: DS mini-workshop results

A small DS workshop was held in Rockville on Wednesday, July 3, 2002.
Our main goal was to try to identify any showstopper bugs in Nominum's
code prior to holding a larger workshop.  Attendees included Russ
Mundy, Sam Weiler, Scott Rose, Ed Lewis, Wes Griffin, Andy Vaskys,
Olafur Gudmundsson, Roger Hartmuller, Lindy Foster, Tom Newell, and
Rip Loomis.

Quick summary: Nominum's and Olafur's authoritative servers worked and
interoperated, to the extent of our testing.  There were bugs in
Nominum's recursive resolver, but basic cases generally worked as
expected.  I've listed some of the issues raised.  Bug reports have
been passed back to Nominum, and a more detailed report may be
available later.


Item 1:  TTLs v. SIG lifetimes.  If the SIG on an RRset expires sooner
than its TTL, what should the TTL for the cached RRset be?  Someone
(Ed?) proposed that the TTL should be the minimum of: the TTL on the
incoming RR, the original TTL in the SIG, or the remaining time on the
SIG.

Item 2:  TTLs in chains.  If you set the TTL to the smallest remaining
TTL of all the RRs needed to validate an RRset, then you're restricted
to the shortest of the parents' (including the root's) timeouts.
Delegations can't set longer timeouts, and, worse, everything under
.com will time out at once, pounding the nameservers.  Perhaps the TTL
should be set to that minimum less some random amount.

Item 3:  Erroneous AA bits with CNAMES.  Assume islands of trust, with
a CNAME in one and the associated A in another.  Query for the
(non-existent) A at the first zone.  With no DNSSEC checking enabled,
asking a recursive server that's also authoritative for the CNAME zone
returns BOTH CNAME and A and sets AA.  With DNSSEC, also get AA.  In
the first case, you're not AA for the A record.  In the second, you
should be saying AD for the A record, not AA.  Asking a recursive only
server with only the first zone's key configured gives neither AA nor
AD.  (perhaps correct) If both keys are configured, you get AD.
(correct)

Item 4:  When DS records or KEYs changed, recursive resolvers that had
cached the old records still answered, but gave no AD.  Why the
change?  Shouldn't they still give out ADs until the cache expires?

Item 5:  Unexplained and inconsistent SERVFAILs asking for DS records
from recursive servers, especially when testing islands of trust (see
below).

Some things tested:
DS delegations
key rollover
AXFR
islands of trust:
          [ signed ]
                \
                [ signed ]
                /         \
      [ unsigned ]        [ signed ]
        /
    [ signed ]
        /
  [ signed ]

Not tested:
deep DS delegations
TSIG





Home | Date list | Subject list