Subject: OPT == type 41?

From: Brian Wellington <[email-masked]>
Date: Tue, 7 Sep 1999 14:46:23 -0400 (EDT)

RFC2671 has assigned the OPT record type code 41.

The OPT record is a meta/pseudo record, in that it cannot be cached.  
Therefore, like other meta/pseudo records (TSIG, TKEY), it should be
assigned a type code value in the 128-255 range.  This non-cacheability
cannot be derived from the TTL field, since OPT overloads the TTL field to
contain version, extended rcode, and flags.

No document formally specifies 128-255 as the range for meta types.  BIND
8 enforces this, and it seems to be current practice.  Should this be
formalized?  It would be nice to have this specified somewhere.

Should the OPT be renumbered (to 248, for example) and RFC2671 be
reissued?

This is an urgent issue.  There are no released implementations of EDNS0
as of yet, but there will be soon.

Thanks...

Brian

---

From: Paul A Vixie <[email-masked]>
Date: Tue, 07 Sep 1999 13:35:49 -0700

note that bind8.2.2, the first implementation which even knows the OPT RTYPE,
no longer treats (rtype<128) specially in any way.  unless there are known
defects in other (or older) implementations that would cause a meta-RR having
a type less than 128 to be a problem, i think we should just leave this alone.

/* Exclusively a QTYPE? (not also an RTYPE) */
#define	ns_t_qt_p(t) (ns_t_xfr_p(t) || (t) == ns_t_any || \
		      (t) == ns_t_mailb || (t) == ns_t_maila)
/* Some kind of meta-RR? (not a QTYPE, but also not an RTYPE) */
#define	ns_t_mrr_p(t) ((t) == ns_t_tsig || (t) == ns_t_opt)
/* Exclusively an RTYPE? (not also a QTYPE or a meta-RR) */
#define ns_t_rr_p(t) (!ns_t_qt_p(t) && !ns_t_mrr_p(t))
#define ns_t_xfr_p(t) ((t) == ns_t_axfr || (t) == ns_t_ixfr)

---

From: "Donald E. Eastlake 3rd" <[email-masked]>
Date: Tue, 07 Sep 1999 17:19:28 -0400

I think it should be re-assigned.  I don't think the RFC can be
re-issued, although that's for the RFC editor to decide.  If not, a
new one should be issued obsoleting the current one.

I can update the IANA DNS considerations draft to indicate that some
implementations don't cache 128-255...

Donald

From:  Brian Wellington <[email-masked]>
Date:  Tue, 7 Sep 1999 14:46:23 -0400 (EDT)
To:  [email-masked]
Message-ID:  <[email-masked]>

---

From: Olafur Gudmundsson <[email-masked]>
Date: Tue, 07 Sep 1999 17:46:42 -0400

>a type less than 128 to be a problem, i think we should just leave this alone.

No we should do this right, meta records SHOULD be grouped together.

	Olafur 
----------------------------------------------------
Olafur Gudmundsson - NAI Labs 
the Security Research Division of Network Associates, Inc.
3060 Wasthington Road, Rt 97, Glenwood MD 21738
[email-masked]  [email-masked]
443-259-2389 
Private: [email-masked]

---

From: [email-masked]
Date: Tue, 7 Sep 1999 15:36:52 -0700 (PDT)

>> note that bind8.2.2, the first implementation which even knows the OPT
>> RTYPE, no longer treats (rtype<128) specially in any way.  unless there
>> are known defects in other (or older) implementations that would cause a
>> meta-RR having a type less than 128 to be a problem, i think we should
>> just leave this alone.
>

perhaps an update should be in order for this RFC. 

--bill

---

From: Paul A Vixie <[email-masked]>
Date: Tue, 07 Sep 1999 16:31:12 -0700

> No we should do this right, meta records SHOULD be grouped together.

why is that?

(we're putting everything under 255 in a 16-bit field, so why do we care?)