Subject: Re: Signature at parent (draft-ietf-dnsop-parent-sig-00.txt)

From: [email-masked] (Ted Lindgreen)
Date: Fri, 30 Mar 2001 11:27:26 +0200

[Quoting Brian Wellington, on Mar 30,  0:03, in "Re: Signature at par ..."]
 
 <Undesired local KEY RRs in zone KEY RR set>

> A simple SHOULD in the spec would work.

OK, we will add that to the next version
of draft-ietf-dnsop-parent-sig-00.txt.

Thanks,
-- Ted.

to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.

---

From: [email-masked] (Ted Lindgreen)
Date: Fri, 30 Mar 2001 12:35:04 +0200

[Quoting Brian Wellington, on Mar 30,  0:06, in "Re: Signature at par ..."]

> The argument about about whether to store KEYs and SIG KEYs in the child
> or the parent was pretty well hashed out 3 years ago or so.  There were

I have read this statement before and tried to find out what
consensus had been achieved. However, I have not been able to
find it.

On the other side, IF consensus had been achieved in 1998, I would
expect that to be reflected in RFC 2535, which was finalized in
1999.  RFC 2535 is only specific when it comes to storing a (null)KEY
for a clue-less child (MUST be stored at the parent), for all other
cases, RFC 2535 uses frases like "normally" and "may" when it comes
to where zone KEYs and parental SIGs are stored.

So, if the definite answer is at hand, please tell what it is,
and please give me pointers where I can find more info on it.

> many reasons to go either way, but a decision was made, and there exists
> at least one implementation.  Changing this now would be a bad idea.

I am not sure what you mean by this, and certainly not why adopting
one or another scheme would conflict with existing implementations.

If you refer to named implementations:  As far as I know there are 2
and a half (see NOTE below) implementations for nameserver software,
that deal with DNSSEC. From our experiments we found, that all of
them work with the parental SIG over the childs KEY @parent, @child,
and @both.  So, I see no conflicts here to go either way.

But, perhaps you refer to registry testbeds?  I know of two
implementations: one at CAIRN and one over here at NLnet Labs.

The former uses the KEY+parentalSIG @child scheme. From private
communication during the last IETF (50th) with the
authors/zoneadministrators I know that most, of not all, of their
test child zones are currently BAD.  They told me that they consider
their setup as very difficult, if not impossible, to maintain, and
that they are considering to adopt the parental-SIG@parent scheme.

The other testbed implementation (the .nl.nl zone at NLnet Labs)
uses the parental-SIG@parent scheme with some reasonable success.

So, in conclusion:

1. The decision you refer to is, at least for some of us, unclear.
2. Clearing up this issue, whatever the decision is, seems to me
   to be a good idea.

Regards,
-- Ted.

NOTE.

The 2 working named implementations I know are:

1. bind-8.2.2p5
2. bind-9.1.x

The half implementation is bind-8.2.3. I refer to this as 1/2,
because DNSSEC in this version has effectively been disabled
(intentionally?) by inverting an if statement in the code,
invalidating positive (==valid) original TTL values.

By re-inverting this test, like it was in bind-8.2.2p5, DNSSEC
appears to be fully functional again, and in fact is used on one of
our testsystems, as we like to gain experience with as much as
systems and implementations as we can lay our hands on..

For the interested, this is the patch to re-enable DNSSEC
in bind-8.2.3:

===================================================================
RCS file: /home/ted/src/SunOS/bind-8.2.3/src/bin/named/db_load.c,v
retrieving revision 1.1
diff -u -r1.1 /home/ted/src/SunOS/bind-8.2.3/src/bin/named/db_load.c
--- 1.1	2001/02/07 17:59:36
+++ /home/ted/src/SunOS/bind-8.2.3/src/bin/named/db_load.c	2001/02/07 18:08:11
@@ -2178,7 +2178,7 @@
 	} else {
 		/* Parse and output OTTL; scan TEXP */
 		origTTL = wordtouint32(buf);
-		if (origTTL >= 0 || wordtouint32_error ||
+		if (origTTL <= 0 || wordtouint32_error ||
 		    (origTTL > 0x7fffffff))
 			ERRTO("Original TTL value bad");
 		cp = &data[i];
==================================================================