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

From: Andreas Gustafsson <[email-masked]>
Date: Mon, 1 Mar 2010 15:23:34 +0200

Patrik Fältström wrote:
> 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 draft doesn't actually make statements about case-insensitive
comparisons, only about the case-sensitive comparisons that arise as a
necessary consequence of comparing opaque data in a bitwise manner.

Therefore, if a reference to RFC1034 section 3.1 is added, it should
be in the negative, such as changing

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

into

   This implies that embedded domain names, being included in the
   overall bitwise comparison, are compared in a case-sensitive manner
   rather than using the case-insensitive comparison specified in
   RFC1034 section 3.1.

As to the details of how case-insensitive comparisons are made
("assuming an ASCII character set", etc), I don't think those are
within the scope of the draft, especially given that the draft is
specifically talking about the *in*applicability of such comparisons
to unknown RR types.  Also, those details are already discussed at
great length in RFC4343.
-- 
Andreas Gustafsson, [email-masked]

---

From: Patrik Fältström <[email-masked]>
Date: Mon, 1 Mar 2010 14:48:27 +0100

> to unknown RR types.  Also, those details are already discussed at

Ok, fair. What I want to be crystal clear is that this draft does not EXTEND the case insensitivity/sensitivity outside of the ASCII space.

If the authors and others that read this draft see that as absolutely clear already now, then of course nothing has to be added.

I am after all work with IDNA extremely sensitive to any ability to do anything else than binary matching in DNS (yes, I do not even like the case insensitivity we have there today -- as it has implications on how lookups in DNS are interpreted).

   Patrik

---

From: Mark Andrews <[email-masked]>
Date: Tue, 02 Mar 2010 11:27:20 +1100

In message <[email-masked]>, Olaf Kolkman wr
ites:
> 
> On Feb 25, 2010, at 11:22 PM, Mark Andrews wrote:
> 
> >=20
> > 6. Equality Comparison
> >=20
> >   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.
> >=20
> >=20
> >   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.
> >=20
> > 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.
> >=20
> > 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.
> >=20
> > e.g.
> >=20
> > If you add HIP record that only differs in the case of the=20
> > rendezvous server from one that already exists there is really
> > no reason why a HIP aware server couldn't silently ignore the
> > add.
> >=20
> > 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.
> >=20
> > 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.
> 
> 
> But that would be erroneous behavior because those new RRs MUST NOT =
> specify type-specific comparison rules. (Correct?)

They are not so much type specific but domain/content aware.
Different parts of a nameserver naturally compare records differently
as they are doing different jobs.  In some parts a strict binary
compare in necessary.  In some part a type aware compare is necessary.

DNSSEC comparision is different to plain DNS comparision.

I would expect a type ware server to reject a update where the
content is malformed according to the type's rules but a server
that was not type aware would just accept the update hoping the
operator knows what they are doing.

> >  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
> 
> ________________________________________________________=20
> 
> Olaf M. Kolkman                        NLnet Labs
>                                        Science Park 140,=20
> http://www.nlnetlabs.nl/               1098 XG Amsterdam
> 
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Mark Andrews <[email-masked]>
Date: Tue, 02 Mar 2010 11:54:07 +1100

In message <[email-masked]>, Andreas Gustafsson writes
:
> Mark,
> You wrote:
> >    the outcome of the comparison is identical whether the RR is known to
> >    name(s).  This is similar to the existing possibility of multiple TXT
> 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?
> 
> > If you add HIP record that only differs in the case of 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.

What about prerequisites?

	rrexist www.example cname ExaMple

and

	rrexist www.example cname example

are the same but

	rrexist www.example HIP ..... ExaMple

and

	rrexist www.example HIP ..... example

differ.  That's not intuitive.

> > case.  A validator however would not collapse multiple records that
> > differ only in case.
> 
> 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?

I think this section needs more discussion.  It currently leads to
unexpected consequences.

---

From: Mark Andrews <[email-masked]>
Date: Tue, 02 Mar 2010 12:00:32 +1100

In message <[email-masked]>, Andrew Sullivan writes:
> No hat.
> 
> On Fri, Feb 26, 2010 at 09:22:35AM +1100, Mark Andrews wrote:
> > 
> > 6. Equality Comparison
> 
> 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.

Which leads to race's that UPDATE is designed to prevent.

Having a type aware server behave slighty differently to a type
unaware server is not necessarially a bad thing.

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

---

From: Paul Vixie <[email-masked]>
Date: Tue, 02 Mar 2010 01:14:50 +0000

trying again.

> > > 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.

the primary master is the only place where updates can be applied, and the
primary master must be aware of all rdata internals including embedded names
that must be compared case insensitively.  there is no bug to fix here.

---

From: Andreas Gustafsson <[email-masked]>
Date: Tue, 2 Mar 2010 18:36:20 +0200

> differ.  That's not intuitive.

That's a good point, and it should probably be mentioned in the draft.
But again, this problem only applies to HIP-unaware servers.
-- 
Andreas Gustafsson, [email-masked]

---

From: Mark Andrews <[email-masked]>
Date: Wed, 03 Mar 2010 10:06:08 +1100

In message <[email-masked]>, Andreas Gustafsson write
> But again, this problem only applies to HIP-unaware servers.

I beg to differ.  Section 6 makes it apply to ALL servers.

Mark

6.  Equality Comparison

---

From: Andreas Gustafsson <[email-masked]>
Date: Wed, 3 Mar 2010 10:43:31 +0200

> I beg to differ.  Section 6 makes it apply to ALL servers.

That was not the intent, but the draft is less than clear on this
point.  I already suggested new text for section 6 to clarify this in
my earlier response to Olaf Kolkman:

  http://ops.ietf.org/lists/namedroppers/namedroppers.2010/msg00515.html

Would the text in that message (plus some notes about prerequisites)
address your concerns?
-- 
Andreas Gustafsson, [email-masked]

---

From: Olafur Gudmundsson <[email-masked]>
Date: Tue, 09 Mar 2010 23:07:18 -0500

> that must be compared case insensitively.  there is no bug to fix here.

As chair

should the document point this out explicitly ?

But this is not possible when we are using dynamic update or the unknown 
textual form to overcome lack of type support by the server in use.

	Olafur

---

From: Olafur Gudmundsson <[email-masked]>
Date: Tue, 09 Mar 2010 23:12:32 -0500

Reminder of this WGLC in progress, at this point not enough
people have stated that they support the document and have reviewed it.
Following message proposes changes to section 6 please read the draft
text before making comments on section 6
http://ops.ietf.org/lists/namedroppers/namedroppers.2010/msg00515.html

	Olafur

On 25/02/2010 7:09 AM, Olafur Gudmundsson wrote:
>
>
> 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 Vixie <[email-masked]>
Date: Wed, 10 Mar 2010 05:39:49 +0000

> Date: Tue, 09 Mar 2010 23:07:18 -0500
> From: Olafur Gudmundsson <[email-masked]>
> ...
> > the primary master is the only place where updates can be applied, and
> > the primary master must be aware of all rdata internals including
> > embedded names that must be compared case insensitively.  there is no
> > bug to fix here.
> 
> As chair
> 

i think so.

> textual form to overcome lack of type support by the server in use.

i never considered dynamic update as a way to overcome lack of type support
in the primary master.  similarly, i always thought of the unknown textual
form as a way to overcome type support in secondary servers or in "dig", not
for the primary master.  i think we should make the very broad assumption
that the primary master can't support unknown types, and we should restate
that assumption in rfc3597bis, and that if justification is somehow needed,
then the justification should be that duplicate rdata's are not permitted in
any zone, so a primary server must be able prevent them, and that a primary
master must also do rdata matching for dynamic update purposes, where rdata
can include domain names, which even if uncompressed, must be case insensitive.

---

From: Olafur Gudmundsson <[email-masked]>
Date: Fri, 19 Mar 2010 15:54:16 -0400

On 10/03/2010 12:39 AM, Paul Vixie wrote:
>> From: Olafur Gudmundsson<[email-masked]>
>> ...

<no-hat>

I think making that this assumption is a severe impediment to
the usefulness of new RRtypes given the long release cycles of
certain DNS vendors + slow adoption of new version in OS
distributions.

Furthermore do we want to demand "type awareness" for all types or can
Authoritative severs only be "type ignorant" if the servers are in
"secondary/slave" role ?

For experimenting with new types dynamic update is a great tool?
	
	Olafur

---

From: Paul Vixie <[email-masked]>
Date: Fri, 19 Mar 2010 20:19:51 +0000

> Date: Fri, 19 Mar 2010 15:54:16 -0400
> > i never considered dynamic update as a way to overcome lack of type
> > support in the primary master.  similarly, i always thought of the
> > unknown textual form as a way to overcome type support in secondary
> > servers or in "dig", not for the primary master.  i think we should
> > make the very broad assumption that the primary master can't support
> > unknown types, and we should restate that assumption in rfc3597bis, and
> > that if justification is somehow needed, then the justification should
> > be that duplicate rdata's are not permitted in any zone, so a primary
> > server must be able prevent them, and that a primary master must also
> > do rdata matching for dynamic update purposes, where rdata can include
> > domain names, which even if uncompressed, must be case insensitive.
> 
> <no-hat>
> 
> I think making that this assumption is a severe impediment to the
> usefulness of new RRtypes given the long release cycles of certain DNS
> vendors + slow adoption of new version in OS distributions.

this assumption is already implicit in the design of UPDATE.  i err'd
in not documenting this properly when editing RFC 2136.

> Authoritative severs only be "type ignorant" if the servers are in

only the servers who apply updates have to be type-aware.  so, secondary
servers who aren't participating in some kind of private multimastering
scheme can be type-ignorant.  IXFR/AXFR and QUERY are type-ignorant ops.
UPDATE is type-ignorant for a forwarder, but is type-aware at the
endpoints (initiator and "primary master").

> For experimenting with new types dynamic update is a great tool?

no, at present, it is not.  wherever RFC 2136 talks about RDATAs or RRsets
being equal or being the same, embedded domain names inside RDATA must be
compared case insensitively.  2136-bis should make this explicit, but it's
an editorial correction to a rule already implicitly mandated in the
protocol.

DNSSEC expresses the same mandate, by the way.  the signer has to be type-
aware, since the data covered by a signature has all of its embedded domain
names presumed to be lower case, even though the data itself can be mixed
case.

---

From: Matthew Dempsky <[email-masked]>
Date: Fri, 19 Mar 2010 14:24:08 -0700

> endpoints (initiator and "primary master").

I like this distinction (i.e., QUERY vs UPDATE) much more than the
master vs. slave one on whether a server can be type-ignorant or not.

> names presumed to be lower case, even though the data itself can be mixed

That means verifiers have to be type-aware too then, doesn't it?

---

From: Paul Vixie <[email-masked]>
Date: Fri, 19 Mar 2010 21:39:28 +0000

> Date: Fri, 19 Mar 2010 14:24:08 -0700
> From: Matthew Dempsky <[email-masked]>
> 
> > DNSSEC expresses the same mandate, by the way.  the signer has to be
> > type-aware, since the data covered by a signature has all of its
> > embedded domain names presumed to be lower case, even though the data
> > itself can be mixed case.
> 

yes, but we're assuming that verifiers are close to clients and thus if
the client is type-aware then its validator will also be type-aware.

---

From: "George Barwood" <[email-masked]>
Date: Fri, 19 Mar 2010 22:33:49 -0000

> names presumed to be lower case, even though the data itself can be mixed

Hold on, we have from

http://tools.ietf.org/html/rfc4034#section-6

       if the type of the RR is NS, MD, MF, CNAME, SOA, MB, MG, MR, PTR,
       HINFO, MINFO, MX, HINFO, RP, AFSDB, RT, SIG, PX, NXT, NAPTR, KX,
       SRV, DNAME, A6, RRSIG, or NSEC, all uppercase US-ASCII letters in
       the DNS names contained within the RDATA are replaced by the
       corresponding lowercase US-ASCII letters;

But only for these types, so to sign (or verify) new types, the structure does not need to be known.

I have no problem with the the draft. It's unlikely that having near-duplicates, which differ
in the case of embedded DNS names, will be a problem.  If for a new RR type it could be
a problem, then a canonical form should be defined ( say lower-case ), and alternate forms
should be made illegal for that RR type, to avoid any confusion.

---

From: Paul Vixie <[email-masked]>
Date: Fri, 19 Mar 2010 22:39:47 +0000

> From: "George Barwood" <[email-masked]>
> Date: Fri, 19 Mar 2010 22:33:49 -0000
> 
> Hold on, we have from
> 

that'll be an interesting nightmare when we start signing zones with new
types in them.  who will take my bet (USD 1.00) that many signers and
verifiers will downcase embedded domain names in RDATA for all types they
recognize, not just the set called out in the 4034 snippet above?

> I have no problem with the the draft. It's unlikely that having
> near-duplicates, which differ in the case of embedded DNS names, will be
> a problem.  If for a new RR type it could be a problem, then a canonical
> form should be defined ( say lower-case ), and alternate forms should be
> made illegal for that RR type, to avoid any confusion.

+1.

---

From: Mark Andrews <[email-masked]>
Date: Sun, 21 Mar 2010 11:43:45 +1100

In message <[email-masked]>, Matth
ew Dempsky writes:
> > only the servers who apply updates have to be type-aware. =A0so, secondar=
> y
> > scheme can be type-ignorant. =A0IXFR/AXFR and QUERY are type-ignorant ops=
> .
> > DNSSEC expresses the same mandate, by the way. =A0the signer has to be ty=
> pe-
> > aware, since the data covered by a signature has all of its embedded doma=
> in
No.

---

From: Andreas Gustafsson <[email-masked]>
Date: Mon, 22 Mar 2010 17:28:34 +0200

> can include domain names, which even if uncompressed, must be case insensitive.

Let's not throw out the baby with the bathwater.  Primary master
servers have never been able to detect or correct all possible errors
in a zone; it is unfortunate that fewer errors can be detected in data
of unknown type than in data of known type, but it's still more useful
to support unknown types with limited checking than to not support
them at all.

I think there are two possible approaches to this issue: either we
outlaw RRsets where the RRs differ only in the character case of
embedded domain names, and note that they will cause undefined
behavior including DNSSEC validation failures, or we allow them and
make sure they work and validate correctly.

Outlawing them would mean saying that the administrator authoring a
zone (or a program doing the same, perhaps by dynamic update) MUST NOT
create them; it would not mean a server MUST detect the error.

Allowing them would mean prescribing some rules like the ones Mark
Andrews proposed in earlier discussion:

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