From weiler@tislabs.com Tue Jul 16 02:08:24 2002 From: weiler@tislabs.com (Sam Weiler) Date: Mon, 15 Jul 2002 21:08:24 -0400 (EDT) Subject: [vet-DS]DS mini-workshop results Message-ID: 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 From david.conrad@nominum.com Tue Jul 16 02:36:40 2002 From: david.conrad@nominum.com (David Conrad) Date: Tue, 16 Jul 2002 10:36:40 +0900 Subject: [vet-DS]DS mini-workshop results In-Reply-To: Message-ID: Not to be too pedantic, but in a recent message on namedroppers regarding RFC 1886 interoperability testing, the following was stated: >> 1) The data is most peculiar since nowhere that I could find are X, Y and Z >> identified. If they are somewhere I couldn't find it. Is there a reason >> to keep them obscured? > This is standard procedure in DNSEXT interop testing and reporting. Yet, Nominum gets identified in DS testing: On 7/16/02 10:08 AM, "Sam Weiler" wrote: > 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. Might I suggest a bit of consistency here? I'm very much in favor of interop testing, but I'd prefer to avoid the hassle of defending our participation in informal interop events to my marketing/pr folks. Tnx, -drc From randy@psg.com Tue Jul 16 03:40:32 2002 From: randy@psg.com (Randy Bush) Date: Tue, 16 Jul 2002 11:40:32 +0900 Subject: [vet-DS]DS mini-workshop results References: Message-ID: the ietf, itself, does not do interop testing. we do solicit and file interop testing reports. we ask that those reports anonymize the implementations. randy From weiler@tislabs.com Tue Jul 16 07:26:49 2002 From: weiler@tislabs.com (Sam Weiler) Date: Mon, 15 Jul 2002 23:26:49 -0700 (PDT) Subject: [vet-DS]Re: DS code & testing day Message-ID: vet-ds-listMany thanks to those who sent feedback. We'll be hosting a one-day DS workshop on Wednesday, July 3rd in Rockville, Maryland starting at 9:45AM. The main purpose is to get people working with Nominum's DS code and doing routine zone operations. Some participants will have other implementations and tools, so there'll be a bit of interoperability testing. Please drop a note to dstest@tislabs.com if you'd like to attend. I'll send out trusted keys, delegations, IP assignments, and directions in advance -- let me know if you need any additional information or accomodations. -- Sam On Thu, 20 Jun 2002, Sam Weiler wrote: > I'm pleased to announce the availability of Nominum's BIND DS > implementation. I'll try to send some documentation in the next few > days. > > ftp://ftp.isc.org/isc/bind9/snapshots/bind-9.3.0s20020618.tar.gz > > We (Network Associates Laboratories) have done some testing of this > code, and I think it's ready for more widespread testing. In > particular, I'd like to hold a one (or maybe two) day mini-workshop > before the IETF at our offices in Rockville, Maryland. I understand > that many who would otherwise attend a workshop may be unable to do so > on such short notice and so close to the IETF, but I think there's > much to be gained even if we can't get the usual broad participation. _______________________________________________ dnssec mailing list dnssec@mailman.isi.edu http://mailman.isi.edu/mailman/listinfo/dnssec