Subject: Jakob's bug

From: Edward Lewis <[email-masked]>
Date: Thu, 3 Apr 2003 11:27:32 -0500

There has been a debate on whether the bug that Jakob Schlyter 
identified some months ago is a problem with the code base he was 
testing or if the problem is rooted in the specifications.

The bug is that referrals from test servers using the DS RR code 
(only some testing snapshot releases) confuses some recent versions 
of BIND software (BIND 9.1, 9.2.)  Now, no one uses DS RR code in 
production, so this isn't an immediate problem and the bug isn't a 
threat to current stability of the production DNS, but the bug is an 
obstacle to rolling out the DS RR version of DNSSEC.

The problem associated with the bug is that when being referred down 
the tree from a zone signed by DNSSEC to a zone that is not signed, 
the referral is required to prove the non-existence of the DS RR at 
the cut point.  The BIND code bases referenced above see the NXT 
stating that there is no DS RR and assumes that the referral is a 
negative answer for the delegated name.

On the surface that sounds like a code bug, but in researching the 
specifications, it was thought that the combination of a negative 
answer (the DS RR) and a referral (the NS RR's) hadn't been described 
before.  I.e., an under specification existed.

I was just reading RFC 2308 (NCACHE) and looked at section 6, 
"Negative answers from the cache."  (Note to my boss: I needed to 
look at this for the lameness requirements.  Honest! ;))  In this 
section:

    "As with all answers coming from the cache, negative answers SHOULD
    have an implicit referral built into the answer."

This points to a specification-based problem.  In RFC 2308, 
cache-sourced negative answers are supposed to look like a referral. 
In the DS RR proposal, a referral will appear as a negative answer in 
some instances.

Perhaps one adjustment needed to the DS RR proposal is to acknowledge 
what a referral from a signed zone to an unsigned zone looks like 
when it comes from a third-party cache.

Whether or not this issue is specification based is a dependency of 
the proposal to change the type codes and mnemonics for the DNSSEC 
types that exist in RFC 2535 (KEY, NXT, and SIG).  If the problem is 
truly based in the specifications and we determine that the 
specifications are insufficient in detail, then it's best to wipe the 
table clean of the old code paths.  That's why this matters.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                            +1-703-227-9854
ARIN Research Engineer

I've had it with world domination.  The maintenance fees are too high.

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