Subject: [DNSOP] Brief addition to terminology-bis draft

From: Suzanne Woolf <[email-masked]>
Date: Mon, 3 Sep 2018 11:29:05 -0400

Hi all,

During the IESG review, Adam Roach noticed that draft-ietf-dnsop-terminology-bis talked about “class" but never defined it. This seemed to the authors and chairs like a reasonable thing to fix. It’s also important enough that we want WG review, but not extensive enough to require a new LC.

Here's the definition that the authors would like to add to the document: 

Class:
A class "identifies a protocol family or instance of a protocol" (Quoted from [RFC1034], Section 3.6). "The DNS tags all data with a class as well as the type, so that we can allow parallel use of different formats for data of type address." (Quoted from [RFC1034], Section 2.2). In practice, the class for nearly every query is "IN". There are some queries for "CH", but they are usually for the purposes of information about the server itself rather than for a different type of address.

Please let us know your opinions yea or nay by Monday, Sept. 10, midnight UTC.

Thanks,
Suzanne
(For the chairs)

---

From: Paul Vixie <[email-masked]>
Date: Mon, 03 Sep 2018 08:34:38 -0700

Suzanne Woolf wrote:
> Hi all,
>
> During the IESG review, Adam Roach noticed that
> draft-ietf-dnsop-terminology-bis talked about “class" but never defined
> it. This seemed to the authors and chairs like a reasonable thing to
> fix. It’s also important enough that we want WG review, but not
> extensive enough to require a new LC.
>
>     A class "identifies a protocol family or instance of a protocol"
>     (Quoted from [RFC1034], Section 3.6). "The DNS tags all data with a
>     class as well as the type, so that we can allow parallel use of
>     different formats for data of type address." (Quoted from [RFC1034],
>     Section 2.2). In practice, the class for nearly every query is "IN".
>     There are some queries for "CH", but they are usually for the
>     purposes of information about the server itself rather than for a
>     different type of address.
>

i don't think this def'n serves the need. we need to speak more truth:

"The Class tag was weakly defined, such that either a zone can have data 
in multiple classes, or each class can have its own zone cut hierarchy, 
and so neither interpretation can be relied upon by DNS protocol 
implementers."

then go on to "in practice..."

-- 
P Vixie

---

From: Mark Andrews <[email-masked]>
Date: Tue, 4 Sep 2018 08:49:27 +1000

RFC 1035 Section 5.2 limits a zone to be single class.

> On 4 Sep 2018, at 1:34 am, Paul Vixie <[email-masked]> wrote:
> 
> 
> 
> Suzanne Woolf wrote:
>> Hi all,
>> 
> "The Class tag was weakly defined, such that either a zone can have data in multiple classes, or each class can have its own zone cut hierarchy, and so neither interpretation can be relied upon by DNS protocol implementers."
> 
> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop

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

---

From: "StJohns, Michael" <[email-masked]>
Date: Tue, 4 Sep 2018 00:29:30 -0400

Actually, 5.2 suggests that a master  file (not zone) should contain a
single class and single SOA record.  That’s not the same thing as limiting
a zone to a single class AFAICT.

Mike

On Mon, Sep 3, 2018 at 18:49 Mark Andrews <[email-masked]> wrote:

> in multiple classes, or each class can have its own zone cut hierarchy, and
> so neither interpretation can be relied upon by DNS protocol implementers."
> >

---

From: Mark Andrews <[email-masked]>
Date: Tue, 4 Sep 2018 14:44:04 +1000

Actually it is.  A master file is a zone transfer mechanism.

Mark

> On 4 Sep 2018, at 2:29 pm, StJohns, Michael <[email-masked]> wrote:
> 
> Actually, 5.2 suggests that a master  file (not zone) should contain a single class and single SOA record.  That’s not the same thing as limiting a zone to a single class AFAICT.  
> 
> Mike
> 
>

---

From: p vix <[email-masked]>
Date: Tue, 4 Sep 2018 15:37:22 +0900 (GMT+09:00)

Other parts of the doc say that some rr types are class specific and others are universal. There an implication that class affects rdata format within a universal rr type. It's incoherent as hell. The reason we don't use it is it's poor definition. Incompatible implmentations could all be right according to the doc. Thus my proposed wording. Is anyone arguing that the spec is coherent on this topic? If not let's move on.

----- Original Message -----
From: "StJohns, Michael" <[email-masked]>
Sent: 9/4/18 - 1:29 PM
To: Mark Andrews <[email-masked]>
Subject: Re: [DNSOP] Brief addition to terminology-bis draft

>> >>    Section 2.2). In practice, the class for nearly every query is "IN"..
>> so neither interpretation can be relied upon by DNS protocol implementers.."
>> >

---

From: Martin Hoffmann <[email-masked]>
Date: Tue, 4 Sep 2018 11:29:24 +0200

Paul Vixie wrote:
> >     (Quoted from [RFC1034], Section 3.6). "The DNS tags all data
> > with a class as well as the type, so that we can allow parallel use
> > of different formats for data of type address." (Quoted from
> > [RFC1034], Section 2.2). In practice, the class for nearly every
> > query is "IN". There are some queries for "CH", but they are
> > usually for the purposes of information about the server itself
> > rather than for a different type of address.

I think I would call out here more clearly that CH has been "hijacked"
by name server vendors for server status information and that one cannot
expect regular DNS name resolution to be performed for queries with
this class.

> "The Class tag was weakly defined, such that either a zone can have
> data in multiple classes, or each class can have its own zone cut
> hierarchy, and so neither interpretation can be relied upon by DNS
> protocol implementers."
> 

RFC 1034, section 4.2 seems pretty clear that each class has its own
hierarchy. It also says that cuts are made within each class's
hierarchy separately. My reading is that each class has its own zones,
but that indeed isn't called out explicitly in that section.

Kind regards,
Martin

---

From: "John Levine" <[email-masked]>
Date: 9 Sep 2018 23:49:58 +0200

In article <[email-masked]> you write:
>-=-=-=-=-=-

(catching up)

NS records are class specific so, except maybe at the root, a zone
with multiple classes doesn't make any sense. There'd be no way to
find the records in any class that didn't match the NS.  RFC 1034 says
that by covention the parallel class namespaces are all the same, but
there was never anything enforcing that.

R's,
John

---

From: Andrew Sullivan <[email-masked]>
Date: Mon, 10 Sep 2018 08:55:33 -0400

Dear colleagues,

> a zone to a single class AFAICT.

I believe it is the same thing, because classes divide the database
which means that they are a division point among zones.

I will note that I attempted a little while ago to explore this space
more completely, but nobody liked my idea of effectively closing the
class registry.  See
https://tools.ietf.org/html/draft-sullivan-dns-class-useless-03.  If
someone wanted to pick up that document, I wouldn't discourage them
(but I don't think I have time any more to work on it).

I agree with Paul Vixie that classes were never defined well enough to
be made to work properly, at least at Internet scale.

Best regards,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Mark Andrews <[email-masked]>
Date: Mon, 10 Sep 2018 23:42:18 +1000

I have to disagree. Classes could quite easily be made to work at internet scale. 

The only thing that would cause issues is vendors that have taken short cuts.   Is it that hard to add root.hint for class10 when we want to use class10?

-- 
Mark Andrews

> On 10 Sep 2018, at 22:55, Andrew Sullivan <[email-masked]> wrote:
> 
> Dear colleagues,
>

---

From: Paul Vixie <[email-masked]>
Date: Mon, 10 Sep 2018 09:48:05 -0700

Andrew Sullivan wrote:
> ...

this thread has further cemented my prejudice against CLASS. however, it 
has also motivated me to define it well enough that we can create a 
global "CHAOS" system, with very different zone cuts, which seems like 
an idea bad enough to be good.

for the terminology-bis draft, is it enough to use andrew's words above?

-- 
P Vixie

---

From: Evan Hunt <[email-masked]>
Date: Mon, 10 Sep 2018 16:59:22 +0000

> an idea bad enough to be good.

This is not in any way an *urgent* consideration, but I do sometimes
wonder what we (or, y'know, our grandchildren) are going to do if we
ever run short of type codes.

The obvious thing would be to expand into the CLASS field.  Someone in
the future might be grateful if we avoid making that too difficult.

-- 
Evan Hunt -- [email-masked]
Internet Systems Consortium, Inc.

---

From: Mark Andrews <[email-masked]>
Date: Tue, 11 Sep 2018 06:38:40 +1000

And part of not making that too difficult is making new types IN specific by default. You need to argue for class agnostic.

You can always replicate a class specific type in a new class. You can’t go from class agnostic to class specific. 

-- 
Mark Andrews

> On 11 Sep 2018, at 02:59, Evan Hunt <[email-masked]> wrote:
>

---

From: "John Levine" <[email-masked]>
Date: 10 Sep 2018 17:39:02 -0400

>> > be made to work properly, at least at Internet scale.

Agreed.  Since it's a different name space, there wouldn't be any
point since you can get the same effect without any software changes
by starting from a different root.

>ever run short of type codes.

Since the type code is a 16-bit field, if we allocate a new type every
week, it'll take over a thousand years to run out.  I think this is one we
can safely ignore.

R's,
John

---

From: Mark Andrews <[email-masked]>
Date: Tue, 11 Sep 2018 08:15:53 +1000

> On 11 Sep 2018, at 7:39 am, John Levine <[email-masked]> wrote:
> 

If we end up with a type per protocol because people want wildcards to work
we will burn through types much faster.  We don’t know exactly what the future
will bring.  I do know that burning then 65000 times as fast as we *need* to
is not a good idea.  I do know that saying that classes can’t work is self
defeating and will take a lot, lot, lot more of work to undo than just continuing to support multiple classes.

---

From: Suzanne Woolf <[email-masked]>
Date: Mon, 10 Sep 2018 18:22:04 -0400

Hi,

> On Sep 10, 2018, at 12:48 PM, Paul Vixie <[email-masked]> wrote:
> 
> Andrew Sullivan wrote:
>> ...
>> 
> this thread has further cemented my prejudice against CLASS. however, it has also motivated me to define it well enough that we can create a global "CHAOS" system, with very different zone cuts, which seems like an idea bad enough to be good.

Note that RFC 6895 ("Domain Name System (DNS) IANA Considerations”), Section 3.2, has some observations about CLASS as well. 

> for the terminology-bis draft, is it enough to use andrew's words above?

I think this discussion demonstrates that it would be controversial to attempt to go beyond the original proposed wording, and we can’t really do something controversial at this stage unless we’re willing to re-open the approval process for the document (pull it back to the WG, then re-run IETF LC).  I’m not inclined to do that.

Warren, anything to add?

Suzanne

---

From: "John R Levine" <[email-masked]>
Date: 10 Sep 2018 18:51:42 -0400

On Tue, 11 Sep 2018, Mark Andrews wrote:
> will bring.

Uh, what?  In the past 30 years we've assigned under 100 rrtypes.  If that 
rate increases by an order of magnitude, we still have a thousand years of 
them.  Sure we don't know exactly what the future will bring, but we can 
make some reasonable guesses.

> I do know that saying that classes can’t work is self defeating and will 
> take a lot, lot, lot more of work to undo than just continuing to 
> support multiple classes.

Classes were a mistake.  We should deprecate every class except IN, 
perhaps keeping the one special case for CH server.bind.  That doesn't 
require changing any of the bits on the wire.

R's,
John

---

From: Joe Abley <[email-masked]>
Date: Mon, 10 Sep 2018 19:12:15 -0400

On Sep 10, 2018, at 18:51, John R Levine <[email-masked]> wrote:

> Classes were a mistake.  We should deprecate every class except IN, perhaps keeping the one special case for CH server.bind.

FWIW,

[monster:~]% strings $(which named) | egrep 'zone .* chaos '
        zone "version.bind" chaos {
        zone "hostname.bind" chaos {
        zone "authors.bind" chaos {
        zone "id.server" chaos {
[monster:~]% 

Of those, authors is a bit verdantly ovine but the others have operational utility (id.server is implemented in other software, like NSD, to provide the same kind of functionality as version.bind).

Joe

---

From: Mark Andrews <[email-masked]>
Date: Tue, 11 Sep 2018 09:53:56 +1000

> On 11 Sep 2018, at 8:51 am, John R Levine <[email-masked]> wrote:
> 
> Uh, what?  In the past 30 years we've assigned under 100 rrtypes.  If that rate increases by an order of magnitude, we still have a thousand years of them.  Sure we don't know exactly what the future will bring, but we can make some reasonable guesses.

We have assigned 100 types with the myth that it is hard to deploy a new type slowing
down the rate of assignment.

>> I do know that saying that classes can’t work is self defeating and will take a lot, lot, lot more of work to undo than just continuing to support multiple classes.
> 
> Classes were a mistake.  We should deprecate every class except IN, perhaps keeping the one special case for CH server.bind.  That doesn't require changing any of the bits on the wire.

And keeping classes working doesn’t changing any bits on the wire.  Using a second
class is almost all administrative.  The resolver libraries I’ve been using for last
30 years have supported lookups in different classes.  The recursive servers we have
been delivering support multiple classes.  Now the one thing that needs to be done
with a new class is to define what a A record means in that class.

QUERY supports multiple classes.
UPDATE supports multiple classes.
DNSSEC supports multiple classes.
NOTIFY supports multiple classes.

There are no reasons to kill multiple class support.  

Mark

---

From: "John Levine" <[email-masked]>
Date: 11 Sep 2018 01:07:51 -0000

In article <[email-masked]>,
Mark Andrews  <[email-masked]> wrote:
>> Uh, what?  In the past 30 years we've assigned under 100 rrtypes.  If that rate increases by an order of
>magnitude, we still have a thousand years of them.  Sure we don't know exactly what the future will bring, but
>we can make some reasonable guesses.
>

I suppose it's a myth if you hand-edit your zone files with vi.  If
you have to use the web provisioning crudware that everyone else uses,
they are still quite a challenge.  I've tried to fix that with my
extension language proposal but its uptake remains small.  Even so, if
types were really easy to add, I've never seen any proposal that would
use a thousand new types, much less 50,000.

>There are no reasons to kill multiple class support.  

There's really a lot more DNS software than bind.  If nobody's found a
practical use for classes after 30 years, I think we have a result
from the experiment.

In any event, I agree with Suzanne, we're not going to resolve this in
time for the terminology-bis RFC.

R's,
John
-- 
Regards,
John Levine, [email-masked], Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly

---

From: Suzanne Woolf <[email-masked]>
Date: Fri, 14 Sep 2018 17:08:37 -0400

All,

Thanks for the lively discussion on this point….after reviewing the thread, the editors, the chairs, and the AD (Warren) felt that there was consensus support for the new language proposed by the editors defining “class," but controversy about the additional language proposed by Paul.

Rather than re-open the document in the WG and pursue a new WGLC and IETF LC, we decided to forward the document on with the brief change proposed by the editors.

Personally, I figure the controversy over the use and meaning of “class” in the DNS won’t go away, and I wouldn’t oppose someone reviving Andrew’s draft or writing another one.

Suzanne

> On Sep 3, 2018, at 11:29 AM, Suzanne Woolf <[email-masked]> wrote:
> 
> Hi all,
>