Subject: [dnsext] WGLC Summary: Unknown RR's to Draft standard (rfc3597bis)

From: Olafur Gudmundsson <[email-masked]>
Date: Sat, 27 Mar 2010 22:00:19 -0400

Dear Colleagues,

The draft got review and support of many members of the working group,
with overwhelming support.

Few minor nits have been raised and will be addressed in an updated
version.

There are two open issues in this document:

- Whether to continue to allow compression of, and require support
    for decompression of, the obsolete and experimental RR types from
    RFC1035 (MD, MF, MB, MG, MR and MINFO), as discussed in
 
http://www.ops.ietf.org/lists/namedroppers/namedroppers.2010/msg00551.html

The chairs would like feedback on if the document drops the support for
compression/decompression of these types?

This should be a safe thing to do as the types are not in use by any 
protocol.

The second issue is:
  - How to deal with the possibility of two RRs in the same RRset being
    "identical" but "differing in case".  Such RRsets can be confusing
    to users, and can potentially fail DNSSEC validation if signed by
    a type-unaware server and subsequently coalesced by a type-aware
    server.

    Three options have been suggested:

    1. Make the creation of such RRsets impossible by prohibiting
       master servers from supporting RRs of unknown type.

       Pro: Fully solves both the user confusion and the DNSSEC
            validation issue

       Con: Drops support for common, safe and legitimate use cases
            along with the relatively rare problematic cases

    2. Consider such RRsets to be configuration errors, and place the
       responsibility for eliminating them on the originator of the
       zone data (the master file author or the dynamic update client).

       Pro: No changes to servers needed, fully solves both
            the user confusion and the potential DNSSEC validation issue
            assuming operational requirements are adhered to

       Con: Servers cannot guarantee adherence to operational
            requirements, therefore DNSSEC validation failures can
            still occur in practice

    3. Ensure that such RRsets can be correctly DNSSEC validated,
       by only allowing coalescing of duplicate RRs when they are
       bitwise equal or known to not (yet) be DNSSEC signed.  This
       would allow case-insensitive coalescing of duplicates when
       processing dynamic updates or signing zones, but not when
       loading master files, receiving zone transfers, or validating.

       Pro: Fully solves the DNSSEC validation issue

       Con: Does not solve the user confusion issue, and may make it
            worse because some duplicates that are currently coalesced
            when loading master files would no longer be coalesced.

Please send your opinions to the mailing list.
I will be off-the-air until April 5'th and will summarize then.

	Olafur

---

From: Dick Franks <[email-masked]>
Date: Mon, 29 Mar 2010 13:42:04 +0100

All,

> http://www.ops.ietf.org/lists/namedroppers/namedroppers.2010/msg00551.html

Like it or not, these obsolete RR types are still part of RFC1035
until formally expunged by standards action elsewhere. IMHO this seems
out of scope  for RFC3597bis.

Alfred's explicit list was a response to the absence of any definition
of the distasteful notion of "well known". I propose that we avoid the
problem entirely by rewording section 4 para 2 to read:

   To avoid such corruption, servers MUST NOT compress domain names
   embedded in the RDATA of types that are class-specific or not well-
   known.  This requirement was stated in [RFC1123] without defining the
|   term "well-known"; it is hereby specified that the RR types defined in
|   [RFC1035] section 3.3 are the only types eligible for compression.

The intention is to avoid the need to define "well known" without any
risk of inadvertently imposing new requirements on existing (albeit
obsolete) RR types or creating yet more exceptions and special cases.

Dick