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

From: Olafur Gudmundsson <[email-masked]>
Date: Thu, 25 Feb 2010 07:09:31 -0500

Dear Colleagues,

This message starts a Working Group last call on draft "Handling of 
Unknown DNS Resource Record (RR) Types" located at:
http://tools.ietf.org/wg/dnsext/draft-ietf-dnsext-rfc3597-bis/

This WGLC will conclude on midnight March 13'th 2010 UTC.

This draft is a replacement for RFC3597, and is being advanced as
a Draft Standard document. RFC3597 is one of the more significant
DNS RFC's, that has enabled more rapid introduction of new types.
Support for RFC3597 is quite common in DNS software and the working
group conducted an interoperabilty test some time ago and submitted an
interoperabilty report as a part of advancing RFC3597 in place. That
attempt failed due to "down-ref" issues.

This document was issued to take care of the issues identified in
RFC3597, and reflect that DNSSEC-bis RFC's now specify the DNSSEC
cannonical rules.

This document is fully compatible with RFC3597 and does not require
any changes in RFC3597 compliant systems.
Interoperational report is available at:
http://tools.ietf.org/html/draft-ietf-dnsext-interop3597-02

Please send statements that you have reviewed this document and if it 
raised any issues.

     Olafur and Andrew

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 25 Feb 2010 07:43:12 -0800

I have read this document, compared it to RFC 3597, and support its adoption.

--Paul Hoffman, Director
--VPN Consortium

---

From: Matthew Dempsky <[email-masked]>
Date: Thu, 25 Feb 2010 10:40:15 -0800

On Thu, Feb 25, 2010 at 4:09 AM, Olafur Gudmundsson <[email-masked]> wrote:
> Please send statements that you have reviewed this document and if it raised
> any issues.

I've read this document and support its adoption.

---

From: Nicholas Weaver <[email-masked]>
Date: Thu, 25 Feb 2010 11:04:52 -0800

Read it, no issues, support adoption

---

From: "George Barwood" <[email-masked]>
Date: Thu, 25 Feb 2010 21:34:45 -0000

> Please send statements that you have reviewed this document and if it 

I reviewed the document, and found no issues.

---

From: Mark Andrews <[email-masked]>
Date: Fri, 26 Feb 2010 09:22:35 +1100

6. Equality Comparison

   Certain DNS protocols, notably Dynamic Update [RFC2136], require RRs
   to be compared for equality.  Two RRs of the same unknown type are
   considered equal when their RDATA is bitwise equal.  To ensure that
   the outcome of the comparison is identical whether the RR is known to
   the server or not, specifications for new RR types MUST NOT specify
   type-specific comparison rules.

   This implies that embedded domain names, being included in the
   overall bitwise comparison, are compared in a case-sensitive manner.

   As a result, when a new RR type contains one or more embedded domain
   names, it is possible to have multiple RRs owned by the same name
   that differ only in the character case of the embedded domain
   name(s).  This is similar to the existing possibility of multiple TXT
   records differing only in character case, and not expected to cause
   any problems in practice.

This section has definitely resulted in bug reports where domain
names are not compared as domain names but are compared as bit
strings by UPDATE.

Users assume domainnames can be used in a case insensitive maners.
Users don't expect record that differ only in case to exist in a
RRset.

e.g.

If you add HIP record that only differs in the case of the 
rendezvous server from one that already exists there is really
no reason why a HIP aware server couldn't silently ignore the
add.

This leaves you with non-minimal RRsets if they are added to a
server that is not aware of the type.  This difference however
is not a bad thing.

Obviously one needs to preserve records that differ only the case
of the domain names when loading zone as the zone may have been
signed with a type unaware server.   A type aware signer however
can collapse a RRset where there are records that only differ in
case.  A validator however would not collapse multiple records that
differ only in case.

That which is writing the RRset can collapse the RRset.

Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: JINMEI Tatuya / 神明達哉 <[email-masked]>
Date: Thu, 25 Feb 2010 16:24:58 -0800

At Thu, 25 Feb 2010 07:09:31 -0500,

> http://tools.ietf.org/wg/dnsext/draft-ietf-dnsext-rfc3597-bis/

[snip]

> Please send statements that you have reviewed this document and if it 

I've not (yet) read all of the text, but I have one point that may be
helpful to clarify using the opportunity of revising RFC3597.

In Section 5, it states:

   In the "type" field of a master file line, an unknown RR type is
   represented by the word "TYPE" immediately followed by the decimal RR
   type number, with no intervening whitespace.  In the "class" field,
   an unknown class is similarly represented as the word "CLASS"
   immediately followed by the decimal class number.

I recently had an opportunity to implement this and noticed that "the
decimal RR type number" is a bit ambiguous.  That is, it's not clear
whether "the decimal number" can contain leading 0's.  For example, is
this a valid representation of "unknown RR type"?

TYPE05300

If it is, what about this?

TYPE0000000000000000000000000000000000000000000000000000000005300

I checked two independent implementations (nsd's zonec and BIND9 if
that matters), and found that both accepted the former but not the
latter.  More specifically, both implementations allow leading 0's as
long as the total number of decimal characters <= 5.  I wasn't sure
whether that's intentional or not from the code, but made my
implementation compatible with these.

Admittedly this is a quite minor point, and perhaps no one else cares.
If many others in the wg think it's too minor to address, I'm fine
with leaving this undefined.  But since being clear is generally a
good thing (IMO), I think it's worth clarifying using this
opportunity.

---
JINMEI, Tatuya
Internet Systems Consortium, Inc.

---

From: John Levine <[email-masked]>
Date: 26 Feb 2010 04:18:52 -0000

I've reviewed the draft and it looks good to me.

R's,
John

---

From: Brian <[email-masked]>
Date: Fri, 26 Feb 2010 00:22:04 -0500

I have reviewed this draft and approve of its adoption.

-brian

On Thu, Feb 25, 2010 at 7:09 AM, Olafur Gudmundsson <[email-masked]> wrote:
>
>
> Dear Colleagues,
>
> This message starts a Working Group last call on draft "Handling of Unknown
> DNS Resource Record (RR) Types" located at:

---

From: Olaf Kolkman <[email-masked]>
Date: Fri, 26 Feb 2010 07:52:16 +0100

On Feb 25, 2010, at 11:22 PM, Mark Andrews wrote:

> case.

But that would be erroneous behavior because those new RRs MUST NOT specify type-specific comparison rules. (Correct?)

>  A validator however would not collapse multiple records that
> differ only in case.

A validator however MUST not collapse multiple records if its aware of type.

Begs the question whether the RR type specifications with domainnames in them should have been explicit and if there are types out there that do specify case-insensitive comparison?

But more importantly, have interoperable implementations been found (which is an indication that the spec is clear), I do not see that in the interoperability report. (I have not checked the canonicalization routines in Net::DNS before writing this, but I wouldn't be surprised if there would be a bug or two lurking, caused by oversight not by clarity in the specs).

--Olaf

________________________________________________________ 

Olaf M. Kolkman                        NLnet Labs
                                       Science Park 140, 
http://www.nlnetlabs.nl/               1098 XG Amsterdam

---

From: Dick Franks <[email-masked]>
Date: Fri, 26 Feb 2010 10:50:20 +0000

Clarification needed at para 2 of section 4.

|  4. Name Compression
=
|   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 only the RR types
|   defined in [RFC1035] are to be considered "well-known".

Does this mean "all RR types defined in RFC1035", or the much smaller
list defined in RFC1035 3.3 para 1?

Propose revised wording:

... hereby specified that all RR types defined in [RFC1035] are
eligible for compression.

--Dick Franks

---

From: Patrik Fältström <[email-masked]>
Date: Fri, 26 Feb 2010 13:02:17 +0100

On 25 feb 2010, at 13.09, Olafur Gudmundsson wrote:

> Please send statements that you have reviewed this document and if it raised any issues.

I have read the document, and have the following comment:

At least in one place in the document where there are statements about case (in)sensitive comparisons, I would like either a reference to, or explicit copying of text from, RFC 1034, section 3.1:

> By convention, domain names can be stored with arbitrary case, but
> domain name comparisons for all present domain functions are done in a
> case-insensitive manner, assuming an ASCII character set, and a high
> order zero bit.

The important part is "...assuming an ASCII character set, and a high order zero bit...".

   Patrik

---

From: Andreas Gustafsson <[email-masked]>
Date: Fri, 26 Feb 2010 14:49:41 +0200

Mark,

> names are not compared as domain names but are compared as bit

Do you know of any specific operational or interoperability problems
underlying these bug reports, or are they just reporting behavior that
users find unexpected or confusing?

> no reason why a HIP aware server couldn't silently ignore the

It seems to me that RFC3597 and the current draft already allow a HIP
aware server to ignore an add of a HIP record that only differs in
character case: for a HIP aware server, the section 6 rules about
comparing unknown types do not apply, because to that server, it's not
an unknown type.

> case.  A validator however would not collapse multiple records that

I agree, I think...  If clarification is needed regarding the DNSSEC
implications of coalescing duplicate RRs, it should probably be done
as an update to the parts of the DNSSEC specification that superseded
RFC3597 section 7.

I'm not sure how to interpret your message in terms of the process;
are you opposing the publication of the draft as an RFC, requesting
changes to the draft, (if so, please suggest specific text), or just
making some general observations?
-- 
Andreas Gustafsson, [email-masked]

---

From: Andreas Gustafsson <[email-masked]>
Date: Fri, 26 Feb 2010 15:10:47 +0200

> good thing (IMO), I think it's worth clarifying using this

This is a good point, but as you say, a minor one.  The principle of
"be conservative in what you send, and liberal in what you accept"
certainly applies here.

In general, I don't see other IETF documents explicitly addressing
this issue.  To pick a random example, defining the DNSKEY RR
presentation format, RFC4034 says "The Flag field MUST be represented
as an unsigned decimal integer" without explicitly discussing whether
or not redundant leading zeros are allowed.
-- 
Andreas Gustafsson, [email-masked]

---

From: "George Barwood" <[email-masked]>
Date: Fri, 26 Feb 2010 14:22:48 -0000

----- Original Message ----- 
From: "Andreas Gustafsson" <[email-masked]>
To: "JINMEI Tatuya / 神明達哉" <[email-masked]>
Cc: "namedroppers" <[email-masked]>
Sent: Friday, February 26, 2010 1:10 PM
Subject: Re: [dnsext] WGLC: Unknown RR's to Draft standard (rfc3597bis)

> or not redundant leading zeros are allowed.

I have always understood that leading zeroes are not used
when writing a decimal integer (unless some fixed format applies).
I think that is implicit, and doesn't need clarification here.

Another example would be the TTL in a master file.
If this is to be clarified, it should apply generally to decimal integers
in master files, not just this case, so this document is not the place IMO.

George Barwood

---

From: Andreas Gustafsson <[email-masked]>
Date: Fri, 26 Feb 2010 16:27:09 +0200

Olaf Kolkman wrote:
> But that would be erroneous behavior because those new RRs MUST NOT
> specify type-specific comparison rules. (Correct?)

The words "type-specific comparison rules" were not intended to refer
to the case-insensitive comparison of embedded domain names in RRs of
known type, but to special-case rules such as those defined for the
SOA, WKS, and CNAME types in RFC2136 section 1.1.5.

RFC3597 and the current draft are admittedly somewhat unclear on this
point.  In particular, the phrase "to ensure that the outcome of the
comparison is identical whether the RR is known to the server or not"
should probably be dropped because I don't think the spec actually
ensures that.

I'm contemplating rewriting Section 6 as follows; would this be
clearer?

   Certain DNS protocols, notably Dynamic Update [RFC2136], require
   RRs to be compared for equality.  Two RRs of the same unknown type
   are considered equal when their RDATA is bitwise equal.  This
   implies that embedded domain names are compared in a case-sensitive
   manner by servers for which the type is unknown, as they are
   included in the overall bitwise comparison.

   As a result, for RRs containing embedded domain names, the outcome
   of a comparison can depend on whether the RR type is known to the
   server or not.  Furthermore, it is possible to have multiple RRs
   owned by the same name that differ only in the character case of
   the embedded domain name(s).  This is similar to the possibility of
   multiple TXT records differing only in character case, and not
   expected to cause any problems in practice [or perhaps it is; 
   see the ongoing discussion with Mark Andrews].

   [RFC2136] section 1.1.5 defined special type-specific comparison
   rules for a number of RR types.  Specifications of new RR types
   MUST NOT require the use of such type-specific comparison rules as
   they cannot be implemented by servers for which the type is
   unknown.

---

From: Andrew Sullivan <[email-masked]>
Date: Fri, 26 Feb 2010 09:37:45 -0500

No hat.

> 6. Equality Comparison

[…]

> no reason why a HIP aware server couldn't silently ignore the

This sounds to me like a provisioning-side bug, not a problem with the
specification for unknown.  In other words, the mechanism for creating
the HIP record (in the example) needs to be aware of this quirk,
because (owing to the needs of the unknown type and the possibility of
bit strings in the DNS) the DNS _can't_ be aware of it.  That "can't"
is precisely what the current text of the draft is calling out, and I
don't see any way around it without changing the rules about what
could be added to the DNS.  The provisioning side, however, could do a
lookup, realise that the cases are not going to match, and make them
match before performing the update.

A

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

From: Paul Vixie <[email-masked]>
Date: Fri, 26 Feb 2010 15:06:52 +0000

> Date: Fri, 26 Feb 2010 09:37:45 -0500
> From: Andrew Sullivan <[email-masked]>
> 
> the HIP record (in the example) needs to be aware of this quirk, ...

it's not a quirk.  this is why RFC 2136 has a top-down model where updates
are only applied at the primary master and then trickle back down in ixfr.

the primary master MUST silently discard the new record in this example.

---

From: Andreas Gustafsson <[email-masked]>
Date: Mon, 1 Mar 2010 09:41:27 +0200

> list defined in RFC1035 3.3 para 1?

The intended meaning is "all RR types defined in RFC1035".  I'm not
convinced this actually needs clarification; the latter interpretation
seems a bit far-fetched to me.  Besides, in the unlikely event that
an implementer were to use the latter interpretation, the
implementation would still interoperate correctly; the only practical
consequence would be the loss of compression in the the MX RR, as all
the other types not in the list are either class-specific, obsolete,
experimental (and in practice obsolete), or lack embedded domain
names.

> eligible for compression.

That wording would imply that even the class-specific types defined in
RFC1035 are eligible for compression, which is incorrect.  Also, by
dropping the word "only", it would weaken one of the main points of
the document, namely that types not defined in RFC1035 MUST NOT be
compressed.
-- 
Andreas Gustafsson, [email-masked]