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