Subject: [dnsext] Comments on draft-ietf-dnsext-axfr-clarify-12

From: Brian Wellington <[email-masked]>
Date: Tue, 5 Jan 2010 13:28:23 -0800

I generally approve of the document going forward, except for comments on section 3.4.

The text:

  Name compression in an AXFR message MUST preserve the case of the
  original domain name.

is unclear, and seems to make incorrect assumptions about general name
server behavior.  With respect to AXFR, the relevant point is that name
compression preserve the case of the domain name as known by the name
server, which may or may not be the original domain name as configured
by the zone operator.

RFC 1034, section 3.1 (as referenced), says:

 When you receive a domain name or label, you should preserve its case.

This says "should", so is not mandatory, and doesn't specifically refer
to AXFR, so any changes to this shouldn't be in an AXFR clarify
document.

While most name server implementations attempt to preserve case whenever
possible, making full case preservation mandatory would be a major
undertaking.

Authoritative name servers generally do not store fully qualified owner
names; they store names relative to the zone origin.  To use BIND as an
example, when configuring the zone "example.com.", it doesn't matter if
a record with the name "A.EXAMPLE.COM." is specified in the zone file;
the name will be stored relative to the zone name, and the original case
cannot be recovered for the purposes of AXFR.

Additionally, authoritative name servers generally do not store a
separate copy of the owner name for each record associated with it.  So,
if records are present for "abc.example.com.", "ABC.example.com.", and
"aBc.example.com.", there is no way to transmit each record with its
original case.

If there is a "MUST" requirement for servers to fully preserve case of
all records, that should be in a new general clarification document
(which I would think was a bad idea), not a clarification of AXFR.

Brian

---

From: Edward Lewis <[email-masked]>
Date: Wed, 6 Jan 2010 14:59:18 -0500

(First, Niall - thanks for the nits.  I'm just back from being in a 
cave for 2 weeks.)

As to what Brian raises:

We know this document has been around a while, making dredging up old 
threads on it hard.  There was something in the past that made case 
preservation a hot issue - why it was featured here with a MUST.

Looking through my archives, in March 2008 there was a message by 
Robert Elz that referred to a comment by Mark Andrews about case 
preservation being something of interest in AXFR and no where else. 
I'll lay this out in case someone has a better memory of this.

But, consider this too - "original" was probably the wrong term to 
use, as I was thinking "original wrt AXFR server" and not original 
wrt zone admin (aka DNSSEC's "original").

What I had envisioned was if the AXFR server sees 
AbC.server.example., aaa.server.example., back.SERVER.example. and 
cab.SERVER.example., then there would be two "compression chains:

position in message     label
20                      example.
100                     aaa.server."20"
200                     aBc."104" (100+"aaa" = position 104)
300                     back.SERVER."20"
400                     cab."305" (300+"back" = position 305)

Maybe that's unrealistic too.  But that's what I had meant.  Brian - 
is this also unrealistic?  Should this discussion just be dropped? 
Can we do anything to promote case preservation in AXFRs at all or is 
it a lost cause?

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis
NeuStar                    You can leave a voice message at +1-571-434-5468

As with IPv6, the problem with the deployment of frictionless surfaces is
that they're not getting traction.

---

From: Brian Wellington <[email-masked]>
Date: Wed, 6 Jan 2010 12:24:23 -0800

On Jan 6, 2010, at 11:59 AM, Edward Lewis wrote:

> (First, Niall - thanks for the nits.  I'm just back from being in a cave for 2 weeks.)
> 
> As to what Brian raises:
> 
> We know this document has been around a while, making dredging up old threads on it hard.  There was something in the past that made case preservation a hot issue - why it was featured here with a MUST.
> 
> Looking through my archives, in March 2008 there was a message by Robert Elz that referred to a comment by Mark Andrews about case preservation being something of interest in AXFR and no where else. I'll lay this out in case someone has a better memory of this.

The only messages I'm seeing from then are related to 0x20, which shouldn't have any effect on AXFR, but I'm also not seeing a reference to a comment from Mark Andrews.  Was this on namedroppers or some other list?

> But, consider this too - "original" was probably the wrong term to use, as I was thinking "original wrt AXFR server" and not original wrt zone admin (aka DNSSEC's "original").

OK.  If the wording was clearer, it would be better.

> What I had envisioned was if the AXFR server sees AbC.server.example., aaa.server.example., back.SERVER.example. and cab.SERVER.example., then there would be two "compression chains:
> 
> Maybe that's unrealistic too.  But that's what I had meant.  Brian - is this also unrealistic?  Should this discussion just be dropped? Can we do anything to promote case preservation in AXFRs at all or is it a lost cause?

I believe this is realistic, but am having trouble figuring out why this is important, given that even if the case is preserved across AXFR, it's not going to be preserved in query responses.  In order for this to be meaningful, we'd also need to change IXFR, DDNS, and who knows what else.

This also (to me, at least) falls outside of the scope of a clarification, as I don't know of any servers that do this currently.  Maybe the right solution is to remove this from axfr-clarify, and create a document clarifying name compression in general (if there is a compelling reason to make this change at all).

Brian

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 6 Jan 2010 15:49:08 -0500

> OK.  If the wording was clearer, it would be better.

It seems to me the intention is that the server providing the AXFR
answer should provide the entire zone in exactly the case it holds the
data.  It should not transmit the zone such that case distinctions
that are in the server's copy of the zone are lost.  Is that right?
And if so, is just saying it that way enough of a clarification?

A

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

---

From: Edward Lewis <[email-masked]>
Date: Wed, 6 Jan 2010 15:52:40 -0500

At 12:24 -0800 1/6/10, Brian Wellington wrote:

1.

>...but am having trouble figuring out why this is important...

2.

>I don't know of any servers that do this currently.

Good reasons for:

>remove this from axfr-clarify

and if there's a desire then:

>create a document clarifying name compression in general (if there 
>is a compelling reason to make this change at all).

;)

Thanks.

---

From: Paul Vixie <[email-masked]>
Date: Wed, 06 Jan 2010 21:12:54 +0000

> Date: Wed, 6 Jan 2010 15:49:08 -0500
> From: Andrew Sullivan <[email-masked]>
> 
> It seems to me the intention is that the server providing the AXFR answer
> should provide the entire zone in exactly the case it holds the data.  It
> should not transmit the zone such that case distinctions that are in the
> server's copy of the zone are lost.  Is that right?  And if so, is just
> saying it that way enough of a clarification?

if that's the intent, then the language should explicitly require that dns
compression be done casefully, that is, if one is looking for a backpointer
to replace label "FooBar" then one should not accept the address of label
"foobar" or "FOOBAR" or any other except literally "FooBar".  this is in my
opinion a reasonable practice for AXFR but i would not like to see similar
requirements for normal queries.  (speaking now for 0x20.)

---

From: Brian Wellington <[email-masked]>
Date: Wed, 6 Jan 2010 13:33:22 -0800

> requirements for normal queries.  (speaking now for 0x20.)

Unless I'm missing something, this is unrelated to 0x20.  0x20 requires that the case of the name in the question section of the response matches the case of the name in the question section of the query, and this name will never be compressed (as it's the first name in the packet).

Brian

---

From: Mark Andrews <[email-masked]>
Date: Tue, 19 Jan 2010 08:39:47 +1100

> >...but am having trouble figuring out why this is important...

* People like seeing names with the case they expect.
* Software that isn't completely as case insensitive as it should be.
 
> >I don't know of any servers that do this currently.

Named as of BIND 9.4.0 does case sensitive compression in response
to bug reports that case was no longer preserved in IN-ADDR.ARPA
zone transfers as a result of switching from one record per message
to multiple records per message.

1811.   [func]          Preserve the case of domain names in rdata during
                        zone transfers. [RT #13547]

Mark
-- 
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, 19 Jan 2010 09:12:03 +1100

In message <[email-masked]>, Brian Wellington
 writes:
> I believe this is realistic, but am having trouble figuring out why this =
> is important, given that even if the case is preserved across AXFR, it's =
> not going to be preserved in query responses.  In order for this to be =
> meaningful, we'd also need to change IXFR, DDNS, and who knows what =
> else.

AXFR is bulk.  QUERY is individual.  
IXFR should also do case preserving compression.

DDNS should send the additions such that the case in rdata is
preserved.  To change the case of a record you remove and add it
with the correct case.
 
RFC 1034 and RFC 1035 says case should be preserved.  You fix the parts of
the specification that are broken or need to be made clearer / explicit as
you go.  This is one of those places.

Mark

---

From: Brian Wellington <[email-masked]>
Date: Tue, 19 Jan 2010 14:16:43 -0800

> * Software that isn't completely as case insensitive as it should be.

Unless I'm missing something, the "software that isn't as case insensitive as it should be" is going to be doing queries, and this draft doesn't change any behavior for queries, so that software will still fail.

And if there is some change made to query processing, broken software is still going to be broken; it's pretty easy to imagine software which expects the answer to have the same case as the query.

>                        zone transfers. [RT #13547]

Point taken, but a clarification based on a change made fairly recently to BIND still isn't a clarification.   Do any other servers do this?

Brian

---

From: Mark Andrews <[email-masked]>
Date: Wed, 20 Jan 2010 17:32:23 +1100

In message <[email-masked]>, Brian Wellington
 writes:
> >=20
> > In message <a06240803c76aa819e967@[10.31.200.252]>, Edward Lewis =
> writes:
> >>=20
> >>=20
> >=20
> Unless I'm missing something, the "software that isn't as case =
> insensitive as it should be" is going to be doing queries, and this =
> draft doesn't change any behavior for queries, so that software will =
> still fail.

If I have a reverse zone with 

	9 PTR foo.Example.net.

I then add a record

	8 PTR bar.ExAmPle.net.

If you don't preserve case the 9 record may suddenly change case to
foo.ExAmPle.net which breaks anything which was case sensitvely
comparing against foo.Example.net without you ever touching
foo.Example.net.  If you preserve case you still get some compresion
(net) rather than (ExAmPle.net).  You also don't tickle the bug in
the broken software.

Similarly when records move from one DNS message to another in the
AXFR stream the case may change as you end up using different
compression tables.

> And if there is some change made to query processing, broken software is =
> still going to be broken; it's pretty easy to imagine software which =
> expects the answer to have the same case as the query.
>
> >> 2.
> >>=20
> >=20
> >=20
> > 1811.   [func]          Preserve the case of domain names in rdata =
> during
> Point taken, but a clarification based on a change made fairly recently =
> to BIND still isn't a clarification.   Do any other servers do this?
> 
> Brian

They all SHOULD be doing this as case preservation is a SHOULD in RFC 103[45].

Mark

---

From: Brian Wellington <[email-masked]>
Date: Tue, 19 Jan 2010 23:25:13 -0800

> AXFR stream the case may change as you end up using different

Ah, this clears things up.  The important point is that it's the rdata where case is important, not the owner names, and this likely wouldn't be affected by any compression done as part of query processing.

> They all SHOULD be doing this as case preservation is a SHOULD in RFC 103[45].

RFC 1034 says:

but also:

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.

RFC 1035 says:

In this scheme, an entire domain name or a list of labels at
the end of a domain name is replaced with a pointer to a prior occurance
of the same name.

Case preservation is a SHOULD, but it can also be reasonably inferred from the latter two blocks of text that two names with different case are the same, and compression should be applied to them.

Brian