Subject: [DNSOP] [[email-masked]: New Version Notification for draft-sullivan-dns-class-useless-01.txt]

From: Andrew Sullivan <[email-masked]>
Date: Fri, 4 Mar 2016 09:38:26 -0500

Dear colleagues,

I've submitted a draft about the general lack of utility of DNS
classes.  I am not requesting DNSOP adoption, but I'd welcome any
comments you might have.

Best regards,

A

----- Forwarded message from [email-masked] -----

Date: Fri, 04 Mar 2016 06:30:29 -0800
From: [email-masked]
To: Andrew Sullivan <[email-masked]>
Subject: New Version Notification for draft-sullivan-dns-class-useless-01.txt

A new version of I-D, draft-sullivan-dns-class-useless-01.txt
has been successfully submitted by Andrew Sullivan and posted to the
IETF repository.

Name:		draft-sullivan-dns-class-useless
Revision:	01
Title:		The DNS Is Not Classy: DNS Classes Considered Useless
Document date:	2016-03-04
Group:		Individual Submission
Pages:		7
URL:            https://www.ietf.org/internet-drafts/draft-sullivan-dns-class-useless-01.txt
Status:         https://datatracker.ietf.org/doc/draft-sullivan-dns-class-useless/
Htmlized:       https://tools.ietf.org/html/draft-sullivan-dns-class-useless-01
Diff:           https://www.ietf.org/rfcdiff?url2=draft-sullivan-dns-class-useless-01

Abstract:
   Domain Name System Resource Records are identified in part by their
   class.  The class field is not effective, and it is not used the way
   it appears to have been intended.  This memo makes no recommendation
   about the DNS parameters registry, but urges those defining new
   RRTYPEs to define them for all classes.

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

----- End forwarded message -----

-- 
Andrew Sullivan
[email-masked]

---

From: Shane Kerr <[email-masked]>
Date: Mon, 7 Mar 2016 16:50:21 +0100

Andrew,

At 2016-03-04 09:38:26 -0500
> classes.  I am not requesting DNSOP adoption, but I'd welcome any

I generally consider CLASS to be 2 bytes in every RR that we'll never
get back. :(

I'm not sure about some of the details in this draft.

Section 2.1 "Class data is in the wrong part of a resource record" says
that you can't have a server for class IE at the same time as EG,
right? (At least as the protocol is currently defined.) That's not the
same as saying that if you have IE then EG is impossible, right?

Section 2.3 seems to be the most compelling to me.

I think there may also be a missing "Section 2.4", which is "most
software only supports IN with some special-casing for CH", and perhaps
"adding a new class is likely to break loads of stuff", and also "how
do I specify 'class' when I type in google.com?"

In the end, I'd suggest not including Section 4 "define new RRTYPEs for
all classes" and instead make Section 3 stronger and declare classes as
only CH for special cases, IN for everything else, and I guess don't
break on HS because MIT?

Cheers,

--
Shane

---

From: George Michaelson <[email-masked]>
Date: Mon, 7 Mar 2016 16:54:47 +0100

if we defined them as 'ignored' for now, could we repurpose them in
some mythical future?

I have a feeling we did this with things like the ToS bits in the
original v4 packet, given that diffserve didn't exist when they were
first defined, or .. did I just find the time machine?

-G

On Mon, Mar 7, 2016 at 4:50 PM, Shane Kerr <[email-masked]> wrote:
> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop
>

---

From: Mukund Sivaraman <[email-masked]>
Date: Mon, 7 Mar 2016 22:01:21 +0530

Hi Andrew

From: https://tools.ietf.org/html/draft-sullivan-dns-class-useless-01

>   Some RRTYPEs are defined in a class-dependent way.  For instance, the
>   A record (type 1) is defined in [RFC1035] to be for class IN only.
>   Perhaps unfortunately, the IANA registry for RRTYPEs (at
>   <http://www.iana.org/assignments/dns-parameters/dns-
>   parameters.xml#dns-parameters-4>) does not include an indicator for
>   the class in which the RRTYPE is defined.

Added to that, the "A" record type is also found in some places with RR
TYPE=1, with the same name "A" for the CH class, where it has a
completely different RDATA format and meaning. It isn't listed on the
DNS parameters page, but it is implemented so by BIND and you can find a
description here:

http://victor.se/bjorn/its/chaos-dns.php

		Mukund

---

From: Ray Bellis <[email-masked]>
Date: Tue, 15 Mar 2016 14:34:43 +0000

Andrew,

Thanks for writing this.

I do take minor issue with this bit:

"But given the DNS message format, the name server cannot find the class
until it knows the name."

I don't believe that this is relevant.  I do think that putting the
class and type fields after the variable length name field in a question
or in an RR was an unfortunate choice.

However I think it's a long stretch to get from there to assigning any
blame on the packet format for any failure of the class field to fulfill
its potential.

kind regards,

Ray

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 15 Mar 2016 21:05:32 -0400

Hi,

Thanks for the comments.  More inline.

> I generally consider CLASS to be 2 bytes in every RR that we'll never

Well, yes, but I guess I'm trying to take the first step on
deprecating the whole thing in an effort at least to tidy everything
else up.

> same as saying that if you have IE then EG is impossible, right?

The problem as I see it is that, while STD 13 suggests that in
principle these are parallel name spaces, there's no way actually to
ensure that; and if they really are, then the chances are excellent
that the same server _would_ end up serving both classes (since NS is
class-independent).  I guess that isn't clear in the text, so I'll try
again.

They're certainly not mutually exclusive in terms of definition, no.

> do I specify 'class' when I type in google.com?"

On the "most software" claim, I fear I haven't done the survey and
don't even know how to start.  That's why you only see the discussion
of some people hard-wiring IN.  That part I know happens, because I've
seen it.

I suspect that adding a new class would actually break nothing except
the new class: I predict that virtually nobody would be able to use it
sucessfully.

The point about most user applications assuming IN is a good one; I'll
add it.  (I am struggling to imagine the user interface that allowed a
user to do something like this.  It strikes me, actually, that the
URL/URI definition might not even consider class.  If that's true,
then it's yet another argument.  I'll check.  Thanks for the suggestion.)

> only CH for special cases, IN for everything else, and I guess don't

Are you arguing that this draft should be stronger, and recommend
closing the registry?  That's how I started out, and I shied away
because it seemed like work for little benefit.  But I could restore
that text :) It'd be a bigger deal, though, because it would then need
to update the DNS registry IANA considerations document.

Thanks very much,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 15 Mar 2016 21:09:35 -0400

> if we defined them as 'ignored' for now, could we repurpose them in

I am earnestly hoping that I will die before the time comes in which
that repurposing argument can be held; but yes, part of my goal here
is to get a document out that effectively deprecates these bits, in an
effort to lay the ground for formal deprecation later and a possible
eventual re-use in some far off future.  Before any of that can
happen, we have to admit we have a problem :)

A

-- 
Andrew Sullivan
[email-masked]

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 15 Mar 2016 21:12:20 -0400

> http://victor.se/bjorn/its/chaos-dns.php

Wow.  Well, that's helpful to know, so thanks.  The fact that people
in the world are defining RRTYPEs in a class-dependent way without
putting anything in the registry is kinda awful, though.  Certainly
another way in which classes appear to be loaded and aimed at feet.
Thanks for the reference!

A

-- 
Andrew Sullivan
[email-masked]

---

From: Mark Andrews <[email-masked]>
Date: Wed, 16 Mar 2016 12:20:40 +1100

> Thanks for the reference!

It's more that the registry failed to scoop up all the old definitions.
 
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 15 Mar 2016 21:22:27 -0400

Hi,

Thanks for the comment.

> blame on the packet format for any failure of the class field to fulfill

Well, the point is that the class can't do the job it was supposed to
(select one of many parallel delegation sets) because the names are
prior to the classes.  I didn't intend to blame anything, but to
suggest that if names were supposed to be subsidiary to classes then
being able to tell which class you were in before selecting the name
would be handy.

For example, suppose that instead of the IDNA kludge (I think even the
authors will concede this description -- no disrespect to the effort
intended), we had used a class to indicate additional conventions for
name matching and so on.  This would have been a big help, if only
because case folding outside ASCII is sort of a pain in the neck.  But
you can't do any of that, because instead of classes actually
differentiating name spaces, the whole tree is expected to be
basically the same across classes.

I suspect that the real goal was to make the DNS useful for
non-Internet networking technologies, and the idea was that anyone
using these various other technologies would likely have Internet
presence as well.  As a practical matter, though, the Internet
technology basically swallowed everything else anyway.  The one
counter-example that's widely deployed we have is mDNS -- it basically
uses a piece of the Internet technology that doesn't really work at
Internet scale and effectively makes the network function differently.
Yet a different class was not selected; instead, we got a new protocol
with a wire format and operational conventions very similar to
traditional DNS.

I'll try to make all of this clearer in the next go-round.  Thanks for
the comment!

A

-- 
Andrew Sullivan
[email-masked]

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 15 Mar 2016 21:24:53 -0400

> It's more that the registry failed to scoop up all the old definitions.

Perhaps.  The documentation I could find for chaosnet is pretty thin,
and STD 13 is pretty clear that A records are only defined for IN.
I'm not really interested in figuring out who is to blame, though.
I'm more worried that we have this quite old example sitting there
festering, and even it isn't handled right in the registries.  What
hope does a new class have?

Best regards,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Mark Andrews <[email-masked]>
Date: Wed, 16 Mar 2016 14:14:38 +1100

> being able to tell which class you were in before selecting the name

No.  The order in RRset is irrelevent.  It is the <qname,qtype,qclass>
tuple that is used to select answers.  The <qname,qclass> tuple is
used to select the zone (which is defined to be single class).

> basically the same across classes.

No, the problem was that rules for name matching are independent
of the class.  This is not the same as names come first.  Now it
would be possible to define that class X names are UTF-8 strings
with 'a' - 'z' being case folded when matching.  We could even do
that for class IN.

One could easily have XXX (code point 1000) and YYY (code point
1000) where both XXX and YYY are class specific and the two classes
are different.

If we want to achieve this then we need to be stricter on allocating
class independent RR types or else there will be no codepoints to
share across classes.  We still have room for ~4 billion record
types.  Only a couple of 100000 <qtype,qclass> are currently
specified.

NXDOMAIN means the name is not in that qclass (qclass != *).

---

From: Rob Austein <[email-masked]>
Date: Tue, 15 Mar 2016 23:32:24 -0400

> and STD 13 is pretty clear that A records are only defined for IN.

RFC 882, page 10; RFC 1034, page 13.

---

From: Tony Finch <[email-masked]>
Date: Wed, 16 Mar 2016 08:04:45 +0000

> On 16 Mar 2016, at 01:22, Andrew Sullivan <[email-masked]> wrote:
> 

By that argument, DNS names should be reversed to big-endian order.

(I think the argument that the syntactic position of the class somehow affects its meaning is silly.)

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at

---

From: Shane Kerr <[email-masked]>
Date: Wed, 16 Mar 2016 13:38:15 +0100

Andrew,

At 2016-03-15 21:05:32 -0400
> of some people hard-wiring IN.  That part I know happens, because I've

Hm... good point. I also haven't done a survey, although I have seen
hard-wired IN and CH on occasion.

[...]

> to update the DNS registry IANA considerations document.

As you point out, from a practical point of view the registry is
pointless because you really can't add classes to DNS. So I think that
closing the registry is a good idea.

Cheers,

--
Shane

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 16 Mar 2016 17:56:35 -0400

> RFC 882, page 10; RFC 1034, page 13.

Well, duh.  I've read that at least a dozen times in the past couple
months, and still got it wrong, so I'm a moron (as though we needed
more evidence).

This does suggest a worse structural problem in the IANA registry,
however, because here's what the registry says (comma-separated):

TYPE,Value,Meaning,Reference,Template,Registration Date 
A,1,a host address,[RFC1035],,

Since 1034 says that A in CH is "a domain name followed by a 16 bit
octal Chaos address," but 882 sais "it might have the phone number of
the host" (and gives the example

       +----------+--------+--------+----------------------------+
       |F.ISI.ARPA|   A    |   CS   |         213-822-2112       |
       +----------+--------+--------+----------------------------+

) I'm not sure what to think.  It isn't at all obvious that the RRTYPE
registry is correct.  I think this is _yet another_ reason to
deprecate non-IN classes and just specify that new things are
class-independent, period.  Alternatively, we could make the RRTYPE
registry clearer about the definition of a given type by class; but
since the other classes don't work for the other reasons discussed,
that would be complicating the registry to no benefit.

Thoughts?

A

-- 
Andrew Sullivan
[email-masked]

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 16 Mar 2016 18:00:19 -0400

Hi,

On Wed, Mar 16, 2016 at 02:14:38PM +1100, Mark Andrews wrote:
> of the class.

Yes, that's a much better way of putting the thrust of the argument
I'm tring to make.  When stated like that, it's obvious that the
position is not important as such.

Thanks,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 16 Mar 2016 18:04:52 -0400

> By that argument, DNS names should be reversed to big-endian order.

When you try to explain to novices that the DNS matches going down the
tree, label by label, and that the top-most label is at the end, you
immediately get a question as to why the labels are in the wrong
order.  I've answered this question from people new to the DNS dozens
of times.  It might be, of course, that I am exceptionally bad at
explaining the concepts.  But it might be that JANET had it right.

Anyway, I think Mark's argument has convinced me that there's a much
better way to lay this out.  Thanks for the comments.

A

-- 
Andrew Sullivan
[email-masked]

---

From: "John Levine" <[email-masked]>
Date: 16 Mar 2016 22:53:57 -0000

>the host" (and gives the example

Not to niggle on details, but that's CS as in CSNET, not CH as in
Chaos, and the phone number was the number of the host's dialup modem.

The 16 bit addresses for Chaosnet sound right.

Details aside, I entirely agree with your point that classes are
useless, and we should shut down registries, deprecate classes other
than IN, and so forth.  For classes to be useful, they'd have needed
well defined per-class boostrap and delegation, which they've never
had.

Whatever classes were supposed to provide we now get with separate DNS
trees with their own roots.  I gather there's a very widely used one
that supports GSM mobile phone roaming, with the root at Neustar.

R's,
John

PS: We briefly had a Chaosnet at Yale around 1980, for which I have
memories of one weekend when we wrestled the amusingly named
semi-rigid cable (semi-rigid in the same sense that a tire iron is
semi-rigid) through utility closets.

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 16 Mar 2016 19:51:35 -0400

> Chaos, and the phone number was the number of the host's dialup modem.

I'm apparently having a hard time reading this month :-/ But your
point makes the problem yet worse, since there's no sense that in the
CS net class here the RDATA of an A record is a host address.  I
suppose that, since it's in 882 (which is obsoleted) that doesn't
matter.  But in CH according to the definition it's not just a host
addressm but "a domain name followed by a 16 bit" address.  (Maybe
that actually means that the domain name is not in the RDATA.  Since
I'm having so much trouble reading this month, it's probably better
that I not form an opinion.)

Thanks for the correction.

A

-- 
Andrew Sullivan
[email-masked]

---

From: Mark Andrews <[email-masked]>
Date: Thu, 17 Mar 2016 11:24:57 +1100

> that I not form an opinion.)

RFC 1034 has:

  Similarly we might see:

      XX.LCS.MIT.EDU. IN      A       10.0.0.44
                      CH      A       MIT.EDU. 2420

Which breaks the rule of a zone being all of one class as the owner
name here is clearly inherited.

A may have been better subtyped but that is water under the bridge now.

      XX.LCS.MIT.EDU. IN      A       IN 10.0.0.44
                      IN      A       CH MIT.EDU. 2420
                      IN      A       IN6 2001:0DB8::2c

Mark

---

From: Rob Austein <[email-masked]>
Date: Thu, 17 Mar 2016 00:06:42 -0400

At Thu, 17 Mar 2016 11:24:57 +1100, Mark Andrews wrote:
> > point makes the problem yet worse, since there's no sense that in
> > the CS net class here the RDATA of an A record is a host address.
> > I suppose that, since it's in 882 (which is obsoleted) that
> > doesn't matter.

RFC 973 deprecated the CS class.

> > But in CH according to the definition it's not just a host

From which point people with sufficiently long memories can probably
tell you whose fault this is.

PVM and I came up with the CH class A RDATA layout over lunch one day
in 1985 when he happened to be visiting LCS.  Chaosnet is strictly a
LAN protocol (well, OK, if anybody had ever actually implemented
anything using IP protocol number 16, it would have been an Internet
protocol running somewhere around OSI layers 4+5, but I digress), so
the idea was that the RDATA contains a DNS name naming the LAN and a
16-bit address naming the node on that LAN.  We already had CS A RRs
as a precedent for class-specific RDATA, so we just followed that.

This was long enough ago that Chaosnet was in much wider use within
MIT than TCP/IP, and it was not yet a foregone conclusion that the
Internet would grow to subsume all other networking technologies on
the planet.  So we were trying to plan ahead.  Then stuff happened.

MIT's Chaosnet ended up sticking with host tables until we shut it
off, so we never did implement this in JEEVES or CHIVES.  Symbolics
may have gotten as far as using CH A RRs as one of the many inputs to
their Namespace system, but that was pretty late in their corporate
life cycle, so I doubt many users ever saw it in the wild.

---

From: Jim Reid <[email-masked]>
Date: Thu, 17 Mar 2016 08:21:06 +0000

> On 17 Mar 2016, at 04:06, Rob Austein <[email-masked]> wrote:
> 

Yeah. Though IIRC, a handful of universities dabbled with Hesiod in the late 80s or theresabouts and that used the Chaosnet Class. That stuff should be long dead and buried by now.

---

From: Tony Finch <[email-masked]>
Date: Thu, 17 Mar 2016 10:56:21 +0000

Andrew Sullivan <[email-masked]> wrote:
> order.

Like postal addresses :-)

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
North Fitzroy, Sole: Easterly or southeasterly 5 or 6, occasionally 7 in west.
Moderate or rough. Showers. Good.

---

From: Rob Austein <[email-masked]>
Date: Thu, 17 Mar 2016 08:03:44 -0400

At Thu, 17 Mar 2016 08:21:06 +0000, Jim Reid wrote:
> 
> Though IIRC, a handful of universities dabbled with Hesiod in the
> late 80s or theresabouts and that used the Chaosnet Class. That
> stuff should be long dead and buried by now.

No, that was yet another class, HS.

Hesiod was an MIT Project Athena thing, and arguably was the first
example of "screw it, just encode it in DNS TXT RRs" syndrome.  IIRC
the only RR types ever used in class HS were NS, TXT, and (maybe) A; I
have a vague recollection that they just looked for IN A RRsets
corresponding to the names in the RDATA of HS NS RRs.  And yeah, a few
other universities did pick up Hesiod, but I'd be astonished if there
were any surviving instances today.

---

From: Andrew Sullivan <[email-masked]>
Date: Thu, 17 Mar 2016 12:17:08 -0400

> life cycle, so I doubt many users ever saw it in the wild.

[…]

> were any surviving instances today.

These considerations, however, both again make me think it'd be ok to
deprecate classes formally and close the registry.

Does anyone want to argue _against_ that direction?  Otherwise, the
next version of the draft will propose that.  (It's a much bigger
change, I think, and probably requires this WG to process the draft,
which is part of the reason I didn't try that before.)

Best regards,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Mark Andrews <[email-masked]>
Date: Fri, 18 Mar 2016 07:33:37 +1100

> which is part of the reason I didn't try that before.)

There is nothing stopping a second class working.  Absolutely
nothing.  You just have to want to set up a parallel heirarchy which
does not have to be complete or maintain a lot more top of namespaces.

Hesiod worked for those institutions that decided to use it.  They
maintained their own top of namespace.  They could have use the TXT
record better but it worked.

Just because we can't think of a good way to use class today is not
a good reason to shut down the registry.  It really doesn't cost
to maintain a registry that is not being actively updated.

Mark

---

From: Shane Kerr <[email-masked]>
Date: Fri, 18 Mar 2016 14:53:49 +0100

Mark,

At 2016-03-18 07:33:37 +1100

> to maintain a registry that is not being actively updated.

Closing the registry sends a clear message: don't use class. That
matches the best understanding today.

If someone thinks of a good way to use class tomorrow, the registry can
be re-opened, right?

Cheers,

--
Shane

---

From: Paul Vixie <[email-masked]>
Date: Fri, 18 Mar 2016 12:10:03 -0700

Shane Kerr wrote:
> Mark Andrews<[email-masked]>  wrote:

what's stopping a second $class from working is STD 13, half of which 
says that zones and rrsets span classes, and half of which says that 
each class has its own zone cut hierarchy. we would have to decide, and 
revise.

>> record better but it worked.

every hesiod installation maintained its own class=HS root name servers; 
there was never a way to access example2.edu's resources using an 
example1.edu client.

> If someone thinks of a good way to use class tomorrow, the registry can

i think mark is right-- the cost of this registry is low, and the 
reservations for HS and CHAOS are in use, though interoperability is 
low. we should leave the registry in place until there's some need 
beyond cleanliness to remove it. (for example, if we revise STD 13 in a 
way that makes $class useful.)

-- 
P Vixie

---

From: Suzanne Woolf <[email-masked]>
Date: Fri, 18 Mar 2016 15:51:52 -0400

On Mar 18, 2016, at 3:10 PM, Paul Vixie <[email-masked]> wrote:

> i think mark is right-- the cost of this registry is low, and the reservations for HS and CHAOS are in use, though interoperability is low. we should leave the registry in place until there's some need beyond cleanliness to remove it. (for example, if we revise STD 13 in a way that makes $class useful.)

<Chair hat>

As a matter of process, "close the registry" doesn't mean "remove it from the IANA repository". We don't do that, for exactly the reason you stated. It means "state formally we have no process for updating it further."

</chair hat>

IMO a reason beyond "cleanliness" to close the registry is to pave over an entry point for bad ideas. Periodically, $thing_someone_wants_to_do looks like something they could do with a new class, at which point they try to suggest it, are angry when DNS experts say "This only looks like a way to do what you want, it won't work," etc.  

There's an argument to be made that "People considered carefully and don't believe any amount of tinkering will make an idea that depends on CLASS workable, so the option isn't available" will result in shorter conversations about those ideas.

Suzanne

---

From: David Conrad <[email-masked]>
Date: Fri, 18 Mar 2016 16:13:29 -0400

Suzanne,

> There's an argument to be made that "People considered carefully and don't believe any amount of tinkering will make an idea that depends on CLASS workable, so the option isn't available" will resu…

I love your optimism, however I am skeptical that closing the registry will have the desired effect.  I suspect a more likely outcome is that the conversations will instead get longer as they become heated as to whether or not the registry should be reopened.  I suspect a better answer for the desired effect you are hoping for by closing the registry would be an RFC that says "Classes Are Not The Droids You're Looking For" that would allow "DNS experts" to simply point to that document whenever someone suggests classes are a solution to any particular problem.

And no, I'm not offering to write said document :)

Regards,
-drc

---

From: "John Levine" <[email-masked]>
Date: 18 Mar 2016 21:53:57 -0000

>each class has its own zone cut hierarchy. we would have to decide, and 

If we spent a year arguing about what STD 13 should really have said
about classes, there's two places we could end up:

1) There's one name tree, and classes provide variant meanings
   of some RRTYPEs.

b) Every class has a separate name tree.

In the first case, classes buy you nothing.  If you want RRTYPEs that
mean something different from existing ones, define some new ones.
It's not like we're in any danger of running out of RRTYPE code
points.  (We can argue about how hard it really is to implement new
RRTYPEs, but I doubt the answer would change much with or without
classes.)

In the latter case, classes still buy you nothing.  Set up some root
servers for your new name tree and you're done.  I suppose one might
argue that gives an unfair advantage to the IN class and we should
instead have the existing roots serve different answers to queries for
different classes, but good luck with that.

Deprecate this vermiform appendix and be done with it.

R's,
John

---

From: Michael StJohns <[email-masked]>
Date: Fri, 18 Mar 2016 18:44:44 -0400

> RRTYPEs, but I doubt the answer would change much with or without

Disclaimer:  I am NOT arguing to retain classes - especially as CLASSes.

For your case (1) above, I occasionally thought about trying to write an 
ID which redefined classes as a way of expanding the search terms for 
DNS to allow differentiation for example between "internal" and 
"external" address records attached to a name.  Or "preferred" and 
"non-preferred"  or "virtual" and "non-virtual" addresses.  It mostly 
didn't go anywhere.

DNS only has name/type/class in the query tuple.   I've sometimes wished 
for the ability to say "I only want a few of the records at this name 
with this type and here's how you figure out which ones" - especially to 
keep the responses within the UDP sizes.    The class field might have 
been a useful way to do that, especially for things related to keys and 
signatures.

Mike

---

From: "Paul Hoffman" <[email-masked]>
Date: Fri, 18 Mar 2016 20:29:14 -0400

On 18 Mar 2016, at 16:13, David Conrad wrote:

>> There's an argument to be made that "People considered carefully and 
>> don't believe any amount of tinkering will make an idea that depends 
>> on CLASS workable, so the option isn't available" will result in 
>> shorter conversations about those ideas.
>
> I love your optimism, however I am skeptical that closing the registry 
> will have the desired effect.  I suspect a more likely outcome is that 
> the conversations will instead get longer as they become heated as to 
> whether or not the registry should be reopened.  I suspect a better 
> answer for the desired effect you are hoping for by closing the 
> registry would be an RFC that says "Classes Are Not The Droids You're 
> Looking For" that would allow "DNS experts" to simply point to that 
> document whenever someone suggests classes are a solution to any 
> particular problem.

A better answer would be to do both. That captures those people who come 
into the solution space via publishing a draft and those people who 
start at the IANA registry (yes, there are plenty of those). The 
security world has gotten good milage about putting things in an IANA 
registry hinting that the viewer is there because of the Bad Idea Fairy.

> And no, I'm not offering to write said document :)

Andrew is already doing that.

--Paul Hoffman

---

From: Andrew Sullivan <[email-masked]>
Date: Sat, 19 Mar 2016 19:53:33 -0400

On Fri, Mar 18, 2016 at 06:44:44PM -0400, Michael StJohns wrote:
> responses within the UDP sizes.    The class field might have been a useful
> way to do that, especially for things related to keys and signatures.

There are lots of things the class field _might_ have been useful for.
What I've been trying to suss out in this conversation is whether
there is any way to make that potential utility actual.  Do you think
the repurposing you're mentioning is a realistic hope, or just a road
not taken?

Best regards,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Paul Vixie <[email-masked]>
Date: Sat, 19 Mar 2016 17:18:38 -0700

> the repurposing you're mentioning is a realistic hope, or just a road

my own view is that it's impossible to negotiate new data patterns end 
to end. EDNS allows negotiation hop by hop, but recall that extended 
label types was removed because it would have allowed data to enter the 
system in authorities which could not be expressed other than hop by hop 
(to the first recursive in the data path.)

thus, we used the class field in the OPT RR for hop by hop signaling, 
but there is no analogous end-to-end use whereby a zone or an rrset 
might be extended to have another dimension, that of class.

-- 
P Vixie

---

From: joel jaeggli <[email-masked]>
Date: Sat, 19 Mar 2016 17:47:00 -0700

> the repurposing you're mentioning is a realistic hope, or just a road

IMHO any effort that expects end users (humans) to differentiate by
class seems like a fools errand; machines perhaps. If by road not taken
we mean user interface disaster avoided then yes, we avoided that.