Subject: Re: damage - was Re: DS and cache transparency.

From: Paul Vixie <[email-masked]>
Date: Thu, 07 Nov 2002 04:48:14 +0000

> Having an authoritative-only server perform recursion is not a special 
> case.  It's an authoritative-only server.  By definition, it doesn't do 
> recursion.  There's no requirement that it even knows how to do recursion
> or what its parent zone is.

not only that.  authority and recursion by the same server instance is
ill defined in the 1034/1035 docs.  (if you are authoritative for vix.com
and there's a zone cut at lh.vix.com and someone asks you for xx.lh.vix.com
do you send a referral or do the recursion?)  ideally, a subsequent version
of bind9 will become strictly modal -- recursive, or authoritative, but
never both.  unfortunately, historical configs would become incompatible,
so it's unlikely to happen as soon as i'd like.

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

---

From: Paul Vixie <[email-masked]>
Date: Thu, 21 Nov 2002 20:51:19 +0000

regarding backward compatibility, let's talk about RR type codes for
SIG, NXT, KEY, etc

the deployed base of 2535 is insignificant, and no effort has been made
to try to "remain true" to the protocol as described in any earlier dnssec
specification.  therefore in each incompatible revision of dnssec, we ought
to deprecate the old type codes for dnssec-specific RRs.  this will cause
"interrim" implementations to believe that "there is no security data" and
fall back to normal, pre-dnssec operation.

naturally this also presents an unfortunate opportunity to change the rdata
format with each revision, but i hope that we can manage not to take it.

it also means that the mneumonics will change with each revision, so we may
end up with things like SIG2/KEY2/DS2 or even SIG3950/NXT3950/DS3950 if there
were a dnssec revision defined in RFC3950.

however, this is the only way to be sure of "b/w compatibility" with interrim
dnssec implementations -- and that is, to invalidate them entirely and force
them into their pre-dnssec mode.