Subject: Re: Error codes and SIG(0)

From: Paul Vixie <[email-masked]>
Date: Thu, 07 Aug 2003 21:15:24 +0000

> However, there seems to be a problem.  The TSIG extended rcode values are
> stored in the TSIG, while the "extended RCODE" value is in the OPT RR.
> According to the IANA database, both have reserved the code 16 for BADVERS
> and BADSIG.  There is no space for an extended rcode value in the SIG(0) RR,
> unless the spec is changed to give remap a field to that purpose.
> 
> Or else the two competing rcode assignments be reconciled somehow.

the original edns proposal had a major and a minor version number, with
the intent that minor version numbers could indicate understanding of
(and therefore an implicit solicitation of) more OPT's without changing
the encoding format of anything in the opt-rdata.  this got taken out,
and our only method of indicating an initiator's ability to understand
a new OPT (like an extended error code blob) would be to negotiate a
higher edns version number.  this seems like overkill, but could be done.

--
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: Mon, 25 Aug 2003 18:22:36 +0000

> The rationale is basically to reduce ambiguity.  Both bits have a DNSSEC
> meaning, so the editors though it would be a good idea to hammer down the
> order for bit flags in a query.  Since it was never mentioned in previous
> docs, we have to get WG consensus for this issue.

to that end, i support the additional text:

> > >    The sense of the CD bit is only considered when a query also has
> > >    the DO bit set.  A security-aware recursive name server MUST ignore
> > >    the sense of the CD bit if the DO bit is not set.