Subject: [DNSOP] Problem with CLASS

From: Edward Lewis <[email-masked]>
Date: Mon, 6 Jul 2015 13:59:32 +0000

(Having quickly scanned through the thread to catch up.)

CLASS has been problematic since the start.  The first "mistake" made was
encoding the CLASS field after the OWNER NAME field in a resource record.
This meant that all domain names have to be encoded and treated the same
regardless of class, removing an important functionality that would have
encouraged better development of CLASS concepts.

Had the CLASS field come before OWNER NAME, I believe that its history
would be different.  I.e., it would have been used and not ignored.  Much
as message compression, there was a time when it was proposed and used,
then it went through an era where it was assumed/forgotten before once
again becoming an issue during the latter phases of DNSSEC development.
The result of that historical path was two sets of intertwined RFC
revisions differing on the topic before finally being discovered, if I
recall correctly, when the unknown types RFC (3597, see section 4) was
developed.  What I mean to say here is that over the decades, the
collection of volunteers that made up DNS WG, DNSSEC WG, DNSIND WG, DNSEXT
WG, and this one haven't consistently applied the same frame of reference
to the protocol.

Unless we wiped all DNS code from existence, I don't see how we could ever
engineer a path to a "Clarifications of the CLASS" in the DNS protocol.
Unlike other loosely defined items in STD 13, CLASS was so poorly formed I
can't see saving it past current use.

I wasn't aware of the mentioned (in the thread) effort to use a different
CLASS for IDN, but the idea had come to me (as in 'across my desk' from
someone else) a long time ago too.  It wasn't apparent that it could even
work given the ordering of the fields in the resource record.

---

From: manning <[email-masked]>
Date: Mon, 6 Jul 2015 07:25:26 -0700

I still need to catch up on the full weekends activity, but I’d like to suggest that, like the
v4/v6 transition, it may be time to consider revisiting the DNS protocols.  Not that there would
ever be a DNS EMP, wiping our all legacy code, but perhaps a phased migration to DNSv2 and a 
shim to ensure backwards compatibility.   In such a case, it might be reasonable to “fix” ordering
(among many other things).

Or we can continue to put bandaids over the DNS festering wounds.

manning
[email-masked]
PO Box 12317
Marina del Rey, CA 90295
310.322.8102

On 6July2015Monday, at 6:59, Edward Lewis <[email-masked]> wrote:

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

---

From: Edward Lewis <[email-masked]>
Date: Mon, 6 Jul 2015 14:35:45 +0000

Dear Sisyphus[0],

+M[1]

[0] = https://en.wikipedia.org/wiki/Sisyphus

"compelled to roll an immense boulder up a hill, only to watch it roll
back down, repeating this action forever"

[1] = https://en.wikipedia.org/wiki/Roman_numerals

"1000"

Yes, the first is Greek, the latter Roman.  I can't render Greek numerals.

On 7/6/15, 10:25, "DNSOP on behalf of manning" <[email-masked] on
behalf of [email-masked]> wrote:

>v4/v6 transition, it may be time to consider revisiting the DNS
>protocols....
>
>manning
>[email-masked]
>PO Box 12317
>Marina del Rey, CA 90295
>310.322.8102

---

From: joel jaeggli <[email-masked]>
Date: Mon, 6 Jul 2015 07:49:08 -0700

> (among many other things).

I would hope that offers to tear the temple down would come with a
proposal for the erection of a new edifice, albiet maybe not here.

> Or we can continue to put bandaids over the DNS festering wounds.

This is dnsop, addressing the condition of current patient, rather than
euthanizing it, is the remit. We do the later somewhere else.

---

From: manning <[email-masked]>
Date: Mon, 6 Jul 2015 09:46:04 -0700

agreed.   while my buddies and I push rocks around, Ed can make sure the “sleeping[*]” is not wakened.  :)

* http://www.stuff.co.nz/world/asia/10099510/Dead-guru-just-sleeping-in-a-freezer

manning
[email-masked]
PO Box 12317
Marina del Rey, CA 90295
310.322.8102

---

From: Mark Andrews <[email-masked]>
Date: Tue, 07 Jul 2015 08:26:16 +1000

In message <[email-masked]>, Edward Lewis writes:
> Content-transfer-encoding: 7bit
> 

Yet this is clearly not so.  We have had different label encodings
like bit-string labels.  Only the recursive server, zone server and
immediate parent zone were required to support the encoding.  It
was desirable for all the other parents to support the encoding.
Think qname minimisation for why this was so.  bit-string labels
were a pain for other reasons so I was happy to see them go.  I
never got around to writing the code the code to lookup the suffix
of non bitstring labels to prime the cache with the parent server's
NS records but I had thought about doing it.  It was basically self
evident that this needed to be done.

Similarly one can choose not to use compression labels all the time.
Named does this to preserve case in responses by only using compression
when the case of the suffix label sequence also matches.

One could say that class X (or a label type) uses utf8 (or any other
character encoding) without compression and just use libraries and
tools that know this.

Similarly we could have just extended the header by using a opcode
to signal a extended header structure for EDNS.  Servers that are
not aware of the extended header structure would have just returned
FORMERR.

All of these are incrementally deployable.

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

---

From: Edward Lewis <[email-masked]>
Date: Mon, 6 Jul 2015 23:58:04 +0000

On 7/6/15, 18:26, "Mark Andrews" <[email-masked]> wrote:

>like bit-string labels.

We have had 1 different label encoding, called bit-string labels.

There were only 2 bits for label type.  0b00 normal, 01 compressed.  10
was defined for a bit-string and "Future expansion."  11 has been left
untouched because bit-strings weren't workable.

>character encoding) without compression and just use libraries and

But no one did.

Once we fell into the mud over bit-strings I recall us deciding not to
burn '0b11' unless we had a really cool idea.

>All of these are incrementally deployable.

We could have done a hundred hacks.  But we didn't.

I'm theorizing we might have, had the CLASS field been before the owner
name and not needed what has amounted to be "ugly hacks" to have different
encoding schemes.  But what might have happened doesn't matter as much as
the CLASS "concept" not being really useful.

---

From: Edward Lewis <[email-masked]>
Date: Tue, 7 Jul 2015 11:34:55 +0000

But no one did.