Subject: Re: [dnsext] AD bit

From: Alfred Hönes <[email-masked]>
Date: Thu, 8 Mar 2012 16:31:53 +0100 (MEZ)

At Mon, 05 Mar 2012 09:11:52 +1100, Mark Andrews wrote:
> In message <20120304205347.GA17454 at miek.nl>, Miek Gieben writes:
>> Hello,
>>
>> As RFC 4035 obsoletes both RFC 3655 and RFC 2535, what document should
>> be used to find the definition of the AD and CD bits in the message header?
>>
>>  Regards,
>>
>> --
>>     Miek Gieben
>
> Currently RFC 2535.

I don't think so.

RFCs 4033 and 4035 have obsoleted RFCs 2535 and 3655.  We should
not give citations of obsolete documents as normative sources.

And we _do_ have such sources in this case:

Section 3 of RFC 4033 says (emphasis added):

|3.  Services Provided by DNS Security
|
|  The Domain Name System (DNS) security extensions provide origin
|  authentication and integrity assurance services for DNS data,
|  including mechanisms for authenticated denial of existence of DNS
|  data.  These mechanisms are described below.
|
|> These mechanisms require changes to the DNS protocol.  DNSSEC adds
|  four new resource record types: Resource Record Signature (RRSIG),
|  DNS Public Key (DNSKEY), Delegation Signer (DS), and Next Secure
|> (NSEC).  It also adds two new message header bits: Checking Disabled
|> (CD) and Authenticated Data (AD).  In order to support the larger DNS
|  message sizes that result from adding the DNSSEC RRs, DNSSEC also
|  requires EDNS0 support ([RFC2671]).  Finally, DNSSEC requires support
|  for the DNSSEC OK (DO) EDNS header bit ([RFC3225]) so that a
|  security-aware resolver can indicate in its queries that it wishes to
|  receive DNSSEC RRs in response messages.
|
|  [...]

RFCs 4033-4035 (+ some more) are the current DNSSEC specifications,
and this should make clear that this document set is authoritative
for these bits now.

RFC 4035 contains copious text in multiple sections specifying the
AD and CD bits, in particular Sections 3.1.6, 3.2.2, 3.2.3, 4.6,
4.9.2, 4.9.3.  Furthermore, RFC 4035 contains (emphasis added):

|6.  IANA Considerations
|
|  [RFC4034] contains a review of the IANA considerations introduced by
|  DNSSEC.  The following are additional IANA considerations discussed
|  in this document:
|
|> [RFC2535] reserved the CD and AD bits in the message header.  The
|> meaning of the AD bit was redefined in [RFC3655], and the meaning of
|> both the CD and AD bit are restated in this document.  No new bits in
|> the DNS message header are defined in this document.
|
|  [...]

I guess this qualifies for quoting RFC 4035 (or RFCs 4033 and 4035)
as the authoritative definition of these bits.

The IANA assigned placement information for both bits has been
maintained in RFC 6195 and its predecessors as well.

Kind regards,
  Alfred.

-- 

+------------------------+--------------------------------------------+
| TR-Sys Alfred Hoenes   |  Alfred Hoenes   Dipl.-Math., Dipl.-Phys.  |
| Gerlinger Strasse 12   |  Phone: (+49)7156/9635-0, Fax: -18         |
| D-71254  Ditzingen     |  E-Mail:  [email-masked]                     |
+------------------------+--------------------------------------------+

_______________________________________________
dnsext mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dnsext

---

From: Mark Andrews <[email-masked]>
Date: Fri, 09 Mar 2012 08:12:52 +1100

In message <[email-masked]>, Alfred =?hp-roman8?B?SM5uZXM=?= w
> not give citations of obsolete documents as normative sources.

[snip]

> maintained in RFC 6195 and its predecessors as well.

I wasn't worried about the use, just the location.

	The bits locations were defined in RFC 2535.

	RFC 2535 -> RFC 2929 -> RFC5395 -> RFC6195

	When 403[45] replaced RFC 2535 the definition of the
	location of the bits got orphaned.

I guess RFC 4034 should have had RFC 2929 as a normative reference for
the location of AD and CD.  The rest of the header bits are defined in
RFC 1035.

Mark

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]
_______________________________________________
dnsext mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dnsext