Subject: [DNSOP] Minor editorial change to draft-ietf-dnsop-sutld-ps

From: Warren Kumari <[email-masked]>
Date: Mon, 3 Jul 2017 17:13:19 -0400

Hi all,

The Special-Use Domain Names Problem Statement document unsurprisingly
contains a list of problems.

This was an unordered list of 21 problems, including descriptions and
sub-bullets.

While trying to write another draft referring to specific problems it
became clear that it would be much better to have this as a *numbered*
list, so that one can refer to specific problems and say thing like
"This helps address problem #17" instead of "This helps address the
problem in the list which begins with the text "foo bar baz"...

I have checked with my co-authors, the DNSOP chairs, IESG and
responsible AD, and have updated the document changing the list from
unordered to numbered (and adding "This is not an ordered list, it is
numbered merely to facilitate referencing specific problems:").

The consensus was that this is a purely editorial change, but please
scream if you disagree -- the document is on Thursday's telechat, and
Benoit is the responsible AD.

W

On Mon, Jul 3, 2017 at 2:56 PM, <[email-masked]> wrote:
>
>
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> This draft is a work item of the Domain Name System Operations of the IETF.
>
>         Title           : Special-Use Domain Names Problem Statement
>         Authors         : Ted Lemon
>                           Ralph Droms
>                           Warren Kumari
>         Filename        : draft-ietf-dnsop-sutld-ps-07.txt
>         Pages           : 29
>         Date            : 2017-07-03
>
> Abstract:
>    The Special-Use Domain Names IANA registry policy defined in RFC 6761
>    has been shown through experience to present unanticipated
>    challenges.  This memo presents a list, intended to be comprehensive,
>    of the problems that have been identified.  In addition it reviews
>    the history of Domain Names and summarizes current IETF publications
>    and some publications from other organizations relating to Special-
>    Use Domain Names.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-dnsop-sutld-ps/
>
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-ietf-dnsop-sutld-ps-07
> https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-sutld-ps-07
>
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-sutld-ps-07
>
>
> 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.
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop

-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf

---

From: Randy Bush <[email-masked]>
Date: Tue, 04 Jul 2017 09:39:25 +0200

> contains a list of problems.

is there a companion document with the list of benefits/advantages?  or
is thins just one of those ietf documents from on high meant to kill
something?

randy, who does not have a dog in this fight, just smells dog poop

---

From: Ralph Droms <[email-masked]>
Date: Tue, 4 Jul 2017 07:28:12 -0400

> On Jul 4, 2017, at 3:39 AM, Randy Bush <[email-masked]> wrote:
> 
> is there a companion document with the list of benefits/advantages?

It's a list of problems, not solutions, so there aren't benefits and/or advantages.

>  or

It's not intended as a dead-end, either.  It is intended as a reference document for solution documents to point at.  Warren add numbering to the list so the problems could be referenced more easily by solutions documents, such as draft-ietf-dnsop-alt-tld-08 

> randy, who does not have a dog in this fight, just smells dog poop

- Ralph

---

From: Randy Bush <[email-masked]>
Date: Tue, 04 Jul 2017 14:14:34 +0200

> It's a list of problems, not solutions, so there aren't benefits

so there are no advntages to special use domain spaces.  got it.

>> or is thins just one of those ietf documents from on high meant to
>> kill something?

i guess so, eh?

randy

---

From: Ted Lemon <[email-masked]>
Date: Tue, 4 Jul 2017 09:23:37 -0400

> is thins just one of those ietf documents from on high meant to kill

This is a very good question. We weren’t asked to answer that question, so we didn’t.  It is assumed throughout the document that various proponents of special use domains have good reasons for wanting them, and further that it is already accepted in principle that if their reason for wanting them is valid, they can have them (modulo technical constraints like delegation). So we didn’t delve into that. But perhaps we should have.

---

From: Randy Bush <[email-masked]>
Date: Tue, 04 Jul 2017 15:37:02 +0200

> This is a very good question.  We weren’t asked to answer that
> question, so we didn’t.

how depressing.  one obvious curiousity is who asked the one-sided
question?  otoh, maybe i don't want to know.  but i wish you had
perceived a wider responsibility to the community.

randy

---

From: Ted Lemon <[email-masked]>
Date: Tue, 4 Jul 2017 09:42:07 -0400

> perceived a wider responsibility to the community.

It was discussed at length in the working group, so I would say that you could In principle have raised this concern sooner. However, I will admit that it didn’t occur to me to do so either. In any case, it really is a separate issue from that covered by this draft, and so there’s no reason why we can’t do this work if you think it’s worth doing. Given the situation with ICANN and GTLD, it may be moot, but I wouldn’t mind writing it down.

---

From: Randy Bush <[email-masked]>
Date: Tue, 04 Jul 2017 15:53:24 +0200

> It was discussed at length in the working group, so I would say that
> you could In principle have raised this concern sooner.  However, I
> will admit that it didn’t occur to me to do so either. In any case, it
> really is a separate issue from that covered by this draft, and so
> there’s no reason why we can’t do this work if you think it’s worth
> doing. Given the situation with ICANN and GTLD, it may be moot, but I
> wouldn’t mind writing it down.

we really should not cover our eyes when we send in the assassins.

i would offer to put my keyboard where my mouth is.  but i fear that, at
the bottom, i would have the unreasonable desire for dns classes to
support these kinds of things.  i.e. i don't think we have a clean fix.
but it would be nice to document the good with the bad.

randy

---

From: Ted Lemon <[email-masked]>
Date: Tue, 4 Jul 2017 10:01:21 -0400

> but it would be nice to document the good with the bad.

That sounds like a solution, not a motivation. That is, you care about the problem hypothetically, and have a hypothetical solution. In practice when we’ve talked about using dns classes to solve problems that have motivated rfc6761 allocations, it hasn’t really helped, because the infrastructure required to use them this way is not present, and this isn’t how they were originally intended to be used.

For example, is ICANN.org with a different class not a subdomain of the .org TLD? Would ICANN not object to us designating it for use by someone else?  I suspect yes, and I wouldn’t blame them.

---

From: Randy Bush <[email-masked]>
Date: Tue, 04 Jul 2017 16:03:35 +0200

>> i would offer to put my keyboard where my mouth is.  but i fear that,
>> at the bottom, i would have the unreasonable desire for dns classes
>> to support these kinds of things.  i.e. i don't think we have a clean
>> fix.  but it would be nice to document the good with the bad.
> 
> That sounds like a solution, not a motivation. That is, you care about
> the problem hypothetically, and have a hypothetical solution. In
> practice when we’ve talked about using dns classes to solve problems
> that have motivated rfc6761 allocations, it hasn’t really helped,
> because the infrastructure required to use them this way is not
> present, and this isn’t how they were originally intended to be used.
> 
> For example, is ICANN.org with a different class not a subdomain of
> the .org TLD? Would ICANN not object to us designating it for use by
> someone else?  I suspect yes, and I wouldn’t blame them.

sorry.  maybe it would have helped if i had put UNREASONABLE DESIRE in
upper case.

randy

---

From: Ted Lemon <[email-masked]>
Date: Tue, 4 Jul 2017 10:05:53 -0400

On Jul 4, 2017, at 10:03 AM, Randy Bush <[email-masked]> wrote:
> maybe it would have helped if i had put UNREASONABLE DESIRE in
> upper case.

My point was just that this wouldn’t be a description of what we might want to accomplish with special-use names.

---

From: william manning <[email-masked]>
Date: Tue, 4 Jul 2017 10:32:58 -0700

I find Randys line of discussion mirroring my own thoughts.
And to answer your question above, technically, the TLD  org.  is a member
of the IN class, so in the OF class, it is credible to posit the existence
of  a org. TLD.   TLDs are per class... :)

/Wm

On Tue, Jul 4, 2017 at 7:01 AM, Ted Lemon <[email-masked]> wrote:

> That sounds like a solution, not a motivation. That is, you care about the
> problem hypothetically, and have a hypothetical solution. In practice when
> we’ve talked about using dns classes to solve problems that have motivated
> rfc6761 allocations, it hasn’t really helped, because the infrastructure
> required to use them this way is not present, and this isn’t how they were
> originally intended to be used.
>
> For example, is ICANN.org with a different class not a subdomain of the
> .org TLD? Would ICANN not object to us designating it for use by someone
> else?  I suspect yes, and I wouldn’t blame them.

---

From: Ted Lemon <[email-masked]>
Date: Tue, 4 Jul 2017 13:39:53 -0400

On Jul 4, 2017, at 1:32 PM, william manning <[email-masked]> wrote:
> And to answer your question above, technically, the TLD  org.  is a member of the IN class, so in the OF class, it is credible to posit the existence of  a org. TLD.   TLDs are per class... :)

Technically, yes. Would ICANN object?  I’d be astonished if they did not. Is there any practical value in an alternative class hierarchy?  No. So it’s moot.

---

From: Paul Vixie <[email-masked]>
Date: Tue, 04 Jul 2017 10:49:50 -0700

Ted Lemon wrote:
> On Jul 4, 2017, at 1:32 PM, william
> manning<[email-masked]>  wrote:
>> I find Randys line of discussion mirroring my own thoughts. And to
>> answer your question above, technically, the TLD  org.  is a member
>> of the IN class, so in the OF class, it is credible to posit the
>> existence of  a org. TLD.   TLDs are per class... :)
>
> Technically, yes. Would ICANN object?  I’d be astonished if they did
> not. Is there any practical value in an alternative class hierarchy?
> No. So it’s moot.

while IETF governs the protocol, ICANN only governs the IN class. i 
expect that there will be other classes some day, in order to avoid some 
aspect of ICANN. but this is not that.

-- 
P Vixie

---

From: Jim Reid <[email-masked]>
Date: Tue, 4 Jul 2017 18:53:38 +0100

> On 4 Jul 2017, at 18:49, Paul Vixie <[email-masked]> wrote:
> 
> while IETF governs the protocol, ICANN only governs the IN class. i expect that there will be other classes some day, in order to avoid some aspect of ICANN.

Attempts have already been made to do just that. It would be nice not to have to put out those fires all over again.

---

From: Ted Lemon <[email-masked]>
Date: Tue, 4 Jul 2017 13:58:29 -0400

> Attempts have already been made to do just that. It would be nice not to have to put out those fires all over again.

Realistically, at some point the damage the ICANN process has done will have to get fixed, just like the damage the itu did got sort of fixed.  Like that case, the results will be messy. But we’ll all be gone by then, I suspect.

---

From: Paul Vixie <[email-masked]>
Date: Tue, 04 Jul 2017 10:59:15 -0700

Jim Reid wrote:
>> On 4 Jul 2017, at 18:49, Paul Vixie<[email-masked]>  wrote:
>>
>> expect that there will be other classes some day, in order to avoid
>> some aspect of ICANN.
>
> Attempts have already been made to do just that. It would be nice not
> to have to put out those fires all over again.

nobody ever got a bonus for making things simpler. so, look for growth, 
and look for it in complexity.

-- 
P Vixie

---

From: David Conrad <[email-masked]>
Date: Tue, 4 Jul 2017 11:07:30 -0700

Paul,

On Jul 4, 2017, 10:59 AM -0700, Paul Vixie <[email-masked]>, wrote:

> > > while IETF governs the protocol, ICANN only governs the IN class.

Sorry, could you point me to anything that documents this?  My impression has always been that ICANN governs (I'd prefer the term coordinates myself) what "the community" feels it should coordinate. I don't recall this being limited to a particular DNS class, but I might have missed it.

> nobody ever got a bonus for making things simpler.

Oh sure they have.

Thanks,
-drc

---

From: John C Klensin <[email-masked]>
Date: Tue, 04 Jul 2017 14:21:35 -0400

--On Tuesday, July 04, 2017 6:53 PM +0100 Jim Reid
<[email-masked]> wrote:

>> while IETF governs the protocol, ICANN only governs the IN
>> class. i expect that there will be other classes some day, in
>> order to avoid some aspect of ICANN.
> 
> Attempts have already been made to do just that. It would be
> nice not to have to put out those fires all over again.

Jim, Paul,

First of all, if only because "QCLASS=ANY" is supposed to do
something sensible, one really cannot have different, per-Class,
roots (more of that argument and the difficulties for many of
the things people have wanted to use CLASSes for in recent years
appears in draft-sullivan-dns-class-useless).   While I don't
believe "useless", I don't see any hope for using the CLASS
mechanism to "avoid ... ICANN".

More important, given historical difficulties with adoption and
broad deployment of new features, I suggest that anyone who sees
ICANN avoidance as am important goal would find establishing an
alternate root and building support for it far easily and more
plausible than anything that could be done with CLASSes, if only
because an ICANN-free class mechanism would, AFAICT, require a
root (even for Class=IN) that was not controlled by ICANN
anyway.  

Having enough of the world get aggravated enough at ICANN (or
some other entity of one's choice) to make general adoption of
an alternate root plausible is another matter and I don't think
we are there, at least yet.  The level of confusion and global
inconsistencies that would accompany any transition to a
different root and root management structure would be bad enough
that I hope the day at which that aggravation threshold is
reached does not come even if, ICANN seems to be trying some
days.

Those who are contemplating that sort of adventure might find at
least parts of draft-klensin-dns-function-considerations amusing
reading.  In particular, Section 3.6 briefly addresses the topic
of different CLASSes as a mechanism for doing new and different
things (technical or administrative). 

best,
    john

---

From: Paul Vixie <[email-masked]>
Date: Tue, 04 Jul 2017 11:39:17 -0700

> mechanism to "avoid ... ICANN".

half of the foundational specification of the dns protocol assumes that 
classes are inside rrsets. the other half assumes that zones are inside 
classes. when i started on bind in 1990 or so it tried to do both. by 
1995 i had disambiguated in favour of zones-in-classes, and all others 
since then have done likewise. qtype=any was a casualty of that work.

separately, i agree that using class to avoid icann would be useless, if 
by useless you mean "there's no way to create a competitor to IN". 
however, the chaos and hesiod classes did get used at varying times, and 
i can easily imagine something like bluetooth or appletalk or lopan 
(each of which has its own naming system, so, these aren't practical 
examples but rather theoretical ones) using the dns protocol on a 
different class, and passing ICANN like ships in the night.

> Having enough of the world get aggravated enough at ICANN ...

for those keeping score, i have been aggravated at ICANN, but am not 
now. i consider the recent transition away from NTIA, and the corporate 
governance changes made to enable that transition, to have been well 
considered and well executed, and to have benefited from almost two 
decades of experience and evolution. if i were designing a replacement 
for the dns protocol today, i would do all in my power to keep the "one 
internet, one namespace" element reflected by ICANN's current role. so, 
please don't misunderstand my participation in this thread as agitation 
for further evolutionary change. i think we're in a good place now.

-- 
P Vixie

---

From: Mark Andrews <[email-masked]>
Date: Wed, 05 Jul 2017 09:33:15 +1000

> mechanism to "avoid ... ICANN".

draft-sullivan-dns-class-useless has lots provably invalid assumptions
in it that it is worthless in determining if new classes could be
deployed.  The only thing useful in it is the warning not to make
all new type allocations class independent as it chews through the
<type,class> tuple space too fast.  We should be updating the
instructions to IANA to allocate types as class dependent unless
it can be show that they should be class independent.  Note we can
always type X class A is identical to type X class B in the future.

As to whether a class has a parallel heirachy or not depends on
how we define the use of the class.

> root (even for Class=IN) that was not controlled by ICANN

Getting new features support into name servers hasn't actually been
hard.  All STD 13 compliant name servers and resolvers *already*
support new classes.

What's hard to do is to get GoDaddy and ilk to update their web
interfaces.

-- 
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: Wed, 05 Jul 2017 10:02:29 +1000

In message <[email-masked]>, Ted Lemon writes:
> > And to answer your question above, technically, the TLD  org.  is a
> > member of the IN class, so in the OF class, it is credible to posit the
> Technically, yes. Would ICANN object?  Id be astonished if they did not.
> Is there any practical value in an alternative class hierarchy?  No. So
> its moot.

Actually there is practical value in an alternative classes if only
to make the type space effectively 32 bits and implicit with that
is a alternative class hierarchy (delegation may exist in one that
do not exist in the other and they may point to other servers).

Who owns a name is a different question to what machines serve the
<name,type,class> tuple and how do you reach those machines.  There
is absolutely no reason why the zones <name,IN> and <name,CLASS56>
need to be served by the same machines.  There is a argument for
them both being under control of the same people.

Mark

---

From: Matthew Kerwin <[email-masked]>
Date: Wed, 5 Jul 2017 12:23:53 +1000

> them both being under control of the same people.

Hi, I'm jumping in at a random time with a possibly dumb question, but
the talk of <name,type> and <name,type,class> tuples got me wondering
about representation in general, and URLs in particular.

RFCs 3986 and 7230 say[*] that every 'host' in a HTTP URL that looks
like a DNS name is a DNS name, and that they have to be resolved to IP
addresses if you want to fetch them, but they don't talk meaningfully
about how to do that resolution. Given that we always assume class=IN
(not to mention type=A|AAAA via happy eyeballs), how would we go about
practically presenting an alternative class in things like URLs?
(Registering a new "alt-http" URL scheme doesn't strike me as a great
idea.)

Because it's all well and good setting up your own .org hierarchy
under class=FOO or whatever, but there's not much point if you can't
send people to www.not-icann.org using it. Unless you don't want to
expose your new hierarchy to the web ...?

Cheers

[*] https://tools.ietf.org/html/rfc3986#section-3.2.2 :

   """A registered name intended for lookup in the DNS uses the syntax
   defined in Section 3.5 of [RFC1034] and Section 2.1 of [RFC1123]."""

I read that as: "if it matches RFC1034 (and isn't overridden by the
specific URI scheme's rules) it's a DNS name."  It could be read the
other way, but that just adds more assumptions.

-- 
  Matthew Kerwin
  http://matthew.kerwin.net.au/

---

From: william manning <[email-masked]>
Date: Tue, 4 Jul 2017 19:36:43 -0700

Most of the other application (besides dns) presume a single class, IN,
hence the URL presumption of "DNS name" will -always- be in the IN class.
Technically imprecise and sloppy, but pragmatically it works...  until some
loons come along and do something creative with classes.   Then all bets
are off.
RFC 1034 also uses IN in its examples and most folks forget inheritence
rules.

/Wm

---

From: Mark Andrews <[email-masked]>
Date: Wed, 05 Jul 2017 13:19:57 +1000

> (Registering a new "alt-http" URL scheme doesn't strike me as a great

mailto: is tied to <MX,IN> then <A,IN> and <AAAA,IN> directly or indirectly.
http: is tied to <A,IN> or <AAAA,IN> and perhaps in the future <SRV,IN>

Note the linkage is not in the name but in the definition of the
scheme.

If some scheme needs <type56000,CLASS100> it will be defined in
that scheme and you will call the resolver with <name,type56000,CLASS100>
to lookup data.  That may then result in a call to lookup
<name2,AAAAA,IN> to get the addresses of the servers based on the
data returned.

Remember we call resolvers most of the time with <name,type,IN>
today.  Changing IN to something else is not hard.  You just need
to know to do that and when people write the code to support the
scheme they will do that.

When a new globally resolvable class becomes active whois will show
a set of nameservers for class IN and a set of nameservers for class
FOO.  They may be the same or they may be different.  One set may
be empty.

Remember this in not new stuff.  HS was used this way but without
central delegations.  You were still expected to use the namespace
delegated to you.  The recursive servers knew how to locate the HS
data.  getpwnam() knew how to map from user name to <domain name,
TXT, HS> and lookup the data by calling the resolver with those
values.

---

From: Matthew Kerwin <[email-masked]>
Date: Wed, 5 Jul 2017 14:23:56 +1000

> Note the linkage is not in the name but in the definition of the

In the case of http it seems to be by convention, because I can't find
anything anywhere that specifies it.  That said, my actual experience
in resolving URLs only goes as deep as gethostbyname() so it's never
mattered to me.

At a similar level, I *get* how RFC 6761 sits between the 'host' name
and the IP address, but it's far enough outside my expertise that I
don't see how all the bits fit together in any detail.

[snip]

> TXT, HS> and lookup the data by calling the resolver with those

I'm not really a DNS person -- nor am I enough of a sysadmin (nor old
enough) to know much about HS -- which is why I asked.  I guess that
means if someone wanted to wrest control of the names used on the web
from ICANN, they'd have to set up alt-http and alt-https schemes, and
convince everyone that they're better (and to update all their
existing bookmarks, links, templates, etc.)

I guess that's one way of future-proofing us against such an event.
(That's slightly back toward the track of the original discussion,
isn't it?)

Cheers

---

From: Randy Bush <[email-masked]>
Date: Wed, 05 Jul 2017 10:47:41 +0200

i think avoiding icann is a red herring.  if the draft in question had
done a decent job of exploring the taxa of needs for name resolution
outside of the 'normal' topology, we would have the start of a base on
which to discuss this.

randy

---

From: Suzanne Woolf <[email-masked]>
Date: Wed, 5 Jul 2017 08:01:30 -0400

(not sure which hat. Probably doc shepherd.)

> On Jul 4, 2017, at 9:23 AM, Ted Lemon <[email-masked]> wrote:
> 

> This is a very good question. We weren’t asked to answer that question, so we didn’t.  It is assumed throughout the document that various proponents of special use domains have good reasons for wan…

I’d go a step further: RFC 6761 alludes to some general reasons, but assumes people who’d go through the IETF standards process or an IESG approval process to get an entry in the special use names registry have good enough reasons that the special handling requested should be accepted as part of the DNS protocol. (I’m one of the people who isn’t comfortable with this assertion, but we’re living with what RFC 6761 says, not what I think it should have said.) 

That is, RFC 6761 leaves to other processes to assess the value of the request and the reasons offered, but strictly speaking doesn’t require them to be documented or evaluated; required documentation for the registry entry consists mostly of assessing how it interacts with the DNS, not its primary use. (Sec. 4 starts by saying “If it is determined that special handling of a name is required in order to implement some desired new functionality,” the registry entry policy applies, but openly avoids describing how that determination should be made.)

This isn’t really strange— plenty of registries don’t require any particular discussion of the merits of an entry; ISTM that “standards action” presumes such evaluation as part of IETF consensus. But it does seem like a significant part of the observed problem— there are only subjective and ad hoc bases for evaluation for a request that’s not otherwise justified by a standards track document, leading to endless repetitions of discussions like whether a new CLASS would be a “better” way to solve a problem that isn’t actually documented in the request.

I think the observation that people aren’t really required to document what problem they are trying to solve with their special use name is in the draft, but perhaps could be more explicit. 

Some few people already have been convinced that there should be some general guidance available for making the determination that a domain name requires special handling in the DNS. But that also seems to be a different document.

Suzanne

---

From: John C Klensin <[email-masked]>
Date: Wed, 05 Jul 2017 08:49:14 -0400

--On Wednesday, July 05, 2017 8:01 AM -0400 Suzanne Woolf
<[email-masked]> wrote:

>...

>> This is a very good question. We weren't asked to answer
>> that question, so we didn't.  It is assumed throughout the
>> document that various proponents of special use domains have
>> good reasons for wanting them, and further that it is already
>> accepted in principle that if their reason for wanting them
>> is valid, they can have them (modulo technical constraints
>> like delegation). So we didn't delve into that. But perhaps
>> we should have. 
> 
> I'd go a step further: RFC 6761 alludes to some general
> reasons, but assumes people who'd go through the IETF
> standards process or an IESG approval process to get an entry
> in the special use names registry have good enough reasons
> that the special handling requested should be accepted as part
> of the DNS protocol. (I'm one of the people who isn't
> comfortable with this assertion, but we're living with what
> RFC 6761 says, not what I think it should have said.) 
> 
> That is, RFC 6761 leaves to other processes to assess the
> value of the request and the reasons offered, but strictly
> speaking doesn't require them to be documented or evaluated;
> required documentation for the registry entry consists mostly
> of assessing how it interacts with the DNS, not its primary
> use. (Sec. 4 starts by saying "If it is determined that
> special handling of a name is required in order to implement
> some desired new functionality," the registry entry policy
> applies, but openly avoids describing how that determination
> should be made.)
>...
> I think the observation that people aren't really required
> to document what problem they are trying to solve with their
> special use name is in the draft, but perhaps could be more
> explicit. 
> 
> Some few people already have been convinced that there should
> be some general guidance available for making the
> determination that a domain name requires special handling in
> the DNS. But that also seems to be a different document.

Suzanne,

Independent of "general guidance", I think the combination of
the I-D, this thread to date, and your comments above make an
extremely strong case for updating RFC 6761 to require
documentation of the problem and discussion of other
alternatives and why they are unworkable.  Whatever else the
problem statement does, I think it makes it clear that yet
another special name should be viewed as a preference only if
there are no reasonable alternatives rather than, e.g., an
option for global vanity names.  

While "general guidance for making the determination" would be,
IMO, desirable, I can imagine months (or years) of quibbling
before agreement could be reached on such criteria.  In the
interim, I'd think a requirement for documentation and
explanation sufficient to satisfy the IETF would be in order if
only as an interim measure to prevent proposals whose main
justification is "because I want one of my very own".

Anyone in DNSOP want to write a one-page RFC?

   john

---

From: Warren Kumari <[email-masked]>
Date: Wed, 5 Jul 2017 08:54:47 -0400

Been trying to figure out where to insert this.

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

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 suspends additions to
   the DNS class registry pending greater clarity on how classes might
   be used, and until such clarification requires those defining new
   RRTYPEs to define them for all classes.

Answer wrote a draft about this a few months / years ago.
W

On Tue, Jul 4, 2017 at 10:36 PM, william manning
<[email-masked]> wrote:
> loons come along and do something creative with classes.   Then all bets are
> off.

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 5 Jul 2017 11:15:36 -0400

Hi Mark,

On Wed, Jul 05, 2017 at 09:33:15AM +1000, Mark Andrews wrote:
> deployed.

What are the "lots of provably invalid assumptions in it"?  As far as
I know, I incorporated changes that were an attempt to address
comments you sent me; perhaps I didn't understand you at the time.
But this is the first time I've ever heard about provably invalid
assumptions.  

Anyway, I abandoned the effort because it became clear to me that
there wasn't going to be any consensus around this: there were too
many people too wedded to keeping classes around despite the obvious
problem that they haven't actually been used when the obvious
opportunities arose.

I cheerfully predict that the DNS will be replaced before we ever have
a significant deployment of a class that even remotely rivals the
deployment of IN.  But I'm not going to waste a lot of effort trying
to forge a consensus about that.

Best regards,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Ted Lemon <[email-masked]>
Date: Wed, 5 Jul 2017 13:22:08 -0400

> about representation in general, and URLs in particular.

This is an interesting topic, but out of scope for the document being discussed.   There was discussion of this topic at a BoF a couple of IETFs ago, I think run by Andrew Sullivan and Suzanne Woolf, but I may be misremembering.

---

From: "Roy T. Fielding" <[email-masked]>
Date: Wed, 5 Jul 2017 10:29:18 -0700

> On Jul 4, 2017, at 9:23 PM, Matthew Kerwin <[email-masked]> wrote:
> 

No, RFC3986 does not say anything of the sort.  Neither does 7230.

>>> other way, but that just adds more assumptions.

Just read the text as written:  "A registered name intended for lookup in DNS ..."
which doesn't limit much at all, and certainly doesn't say that all dot-notations
are DNS names.

The sentence immediately preceding that one is:

   A host identified by a registered name is a sequence of characters
   usually intended for lookup within a locally defined host or service
   name registry, though the URI's scheme-specific semantics may require
   that a specific registry (or fixed name table) be used instead.

with both "usually" and "locally defined" being relevant.

And two paragraphs later it has:

   This specification does not mandate a particular registered name
   lookup technology and therefore does not restrict the syntax of reg-
   name beyond what is necessary for interoperability.  Instead, it
   delegates the issue of registered name syntax conformance to the
   operating system of each application performing URI resolution, and
   that operating system decides what it will allow for the purpose of
   host identification.  A URI resolution implementation might use DNS,
   host tables, yellow pages, NetInfo, WINS, or any other system for
   lookup of registered names.  However, a globally scoped naming
   system, such as DNS fully qualified domain names, is necessary for
   URIs intended to have global scope.  URI producers should use names
   that conform to the DNS syntax, even when use of DNS is not
   immediately apparent, and should limit these names to no more than
   255 characters in length.

And that's exactly how it works, in practice.

....Roy

---

From: Mark Andrews <[email-masked]>
Date: Thu, 06 Jul 2017 09:11:01 +1000

In message <[email-masked]>, "Roy T. Fielding" writes:
> > On Jul 4, 2017, at 9:23 PM, Matthew Kerwin <[email-masked]> =
> wrote:
> >=20
> >>=20
> >> In message =
> <CACweHNCAi7JcOW9CX=[email-masked]>, =
> Matthew Kerwin writes:
> >>>>=20
> >>>>=20
> >>>>=20
> >>>=20
> >>> Hi, I'm jumping in at a random time with a possibly dumb question, =
> but
> >>> the talk of <name,type> and <name,type,class> tuples got me =
> wondering
> >>>=20
> >>> like a DNS name is a DNS name, and that they have to be resolved to =
> IP
> >>> addresses if you want to fetch them, but they don't talk =
> meaningfully
> 
> >>>=20
> >>>   """A registered name intended for lookup in the DNS uses the =
> syntax
> >>>   defined in Section 3.5 of [RFC1034] and Section 2.1 of =
> [RFC1123]."""
> >>>=20
> Just read the text as written:  "A registered name intended for lookup =
> in DNS ..."
> which doesn't limit much at all, and certainly doesn't say that all =
> dot-notations
> are DNS names.
> 

And the actual presentation limit for LDH with DNS is 253 (encodes
as 255 octets on the wire).  Remember URI names do not have a final
period and the each label has length octet when encoded as a DNS
name and the name is terminated by the root label (0x00) in DNS
wire form and the DNS wire name is limited to 255 octets.

The name "a" is 0x01 0x61 0x00 on the wire when encoded in the DNS.
The name "a.b" is 0x01 0x61 0x01 0x62 0x00 on the wire when encoded
in the DNS.

An arbitary DNS name may be up to 1004 ascii characters when converted
to presentation format.  0x00 has a presentation format of "\000"
and this may occur up to 250 times as the maximum label length is
63.  Add in seperating periods (3) and a final period the becomes
1004 in absolute form.  As a C NUL terminated string you need a
buffer of 1005 bytes to hold it.

Mark

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 6 Jul 2017 00:36:13 -0400

There are changes to the DNS that are practical and those that are not. For
better or worse, I can't see any way that teaching DNS to use new classes
makes any sense at this point. The only point at which it would have made
sense was when internationalization happened. But the path chosen makes
more sense.

ICANN will manage whatever bits of the DNS consensus agrees it should
manage. The only events likely to break consensus would be an attempt by
some government to strong arm ICANN into a breach of faith with the
community and succeeding or some really spectacular peculation.

It seems to me that if people want to do anything new with DNS that they
should use prefixes, new RRs or both as the mechanism, not the class which
is limited anyway.

DNS is not a full service directory. Nor does it need to be. A UDP packet
is big enough for a link, a fingerprint and a digital signature. That is
all that you ever need.

The X.500 and UDDI models were broken because there is no point in putting
information into a directory if the service can return it in a service
handshake.

---

From: John C Klensin <[email-masked]>
Date: Thu, 06 Jul 2017 11:15:34 -0400

--On Thursday, July 6, 2017 00:36 -0400 Phillip Hallam-Baker
<[email-masked]> wrote:

> There are changes to the DNS that are practical and those that
> are not. For better or worse, I can't see any way that
> teaching DNS to use new classes makes any sense at this point.
> The only point at which it would have made sense was when
> internationalization happened. But the path chosen makes more
> sense.

As the author of the I-D that proposed using a Class to deal
with internationalization, it would not have worked, and the two
important reasons are perhaps worth understanding.   First, that
approach included a transition strategy that permitted legacy
clients and registrations to keep working in a way that users
would see as normal.  But that strategy depends on CLASSes
sharing the same root and hierarchy.  At Paul points out, that
interpretation of 1034/1035 is not universally accepted and
implemented.  Second, IIR, we intended that the different CLASS
allow a different set of matching rule assumptions and
conditions.  Because labels must generally be interpreted and
compared before CLASS values are accessed and, perhaps more
important, in optimization of databases, one probably needs
label types to do that, not CLASSes.   And label types don't
have a good history.

> ICANN will manage whatever bits of the DNS consensus agrees it
> should manage. The only events likely to break consensus would
> be an attempt by some government to strong arm ICANN into a
> breach of faith with the community and succeeding or some
> really spectacular peculation.

We disagree about that, but I no proof that my impressions/
predictions are any better than yours.

> It seems to me that if people want to do anything new with DNS
> that they should use prefixes, new RRs or both as the
> mechanism, not the class which is limited anyway.
> 
> DNS is not a full service directory. Nor does it need to be. A
> UDP packet is big enough for a link, a fingerprint and a
> digital signature. That is all that you ever need.

As I think you know, I just love "all you will ever need"
statements about the Internet (and its predecessors) although my
favorite remains "we will never need more than 8 bits of address
space".

> The X.500 and UDDI models were broken because there is no
> point in putting information into a directory if the service
> can return it in a service handshake.

The X.500 and UDDI approaches failed because... sorry, I lost
count of the reasons :-(

    john

---

From: Nico Williams <[email-masked]>
Date: Thu, 6 Jul 2017 10:39:56 -0500

> The X.500 and UDDI approaches failed because... sorry, I lost

The complexity and general ugliness of x.400/x.500 naming (indeed, the
inability to correctly and canonically represent such names in TEXT!)
are all the reason anyone ever should have needed.  (See what I did
there?)  And yet some bits of that horrible thing are still with us
(PKIX, LDAP), though of course with various adaptations (eg, SANs) to
make them suck less and more Internet-like.

DNS is not a directory, but when your only off-the-shelf choices are DNS
or LDAP...

I'll contribute this extension to your earlier argument about root
sharing/non-sharing.  I think new classes will only ever be feasible
provided that a) they share roots with IN, or b) are like a local HS not
really meant to federate at all (thus root sharing / alt. roots would be
moot).  (a) classes would basically be an RR type extension field for
IN.  (b) is probably not worth considering -- the lack of security in HS
was a big reason for not using it, and so DNSSEC (or something like it)
would be a requirement in order to use an HS-like class, but if you'll
want DNSSEC then you'll want delegation hierarchy anyways and thus
you'll want shared roots, making any HS-like classes just IN-class RR
type extension fields.  It's easier to develop a new protocol for (b)
than to shove whatever it is into DNS.

So new classes will only be useful to extend the IN-class RR type
namespace.  We won't get there.  New RR types can be very difficult to
deploy due to lack of interest by registrars and domain hosting
services.  TXT RRs forever.  :(

Cheers,

Nico
--

---

From: Randy Bush <[email-masked]>
Date: Thu, 06 Jul 2017 18:06:39 +0200

> DNS is not a directory, but when your only off-the-shelf choices are DNS

this is the ietf.  do not ignore bgp and ldp.

---

From: [email-masked]
Date: Thu, 6 Jul 2017 12:34:23 -0400 (EDT)

> this is the ietf.  do not ignore bgp and ldp.

+1

---

From: John C Klensin <[email-masked]>
Date: Thu, 06 Jul 2017 14:04:10 -0400

--On Thursday, July 6, 2017 09:11 +1000 Mark Andrews
<[email-masked]> wrote:

>...
> And the actual presentation limit for LDH with DNS is 253
> (encodes as 255 octets on the wire).  Remember URI names do
> not have a final period and the each label has length octet
> when encoded as a DNS name and the name is terminated by the
> root label (0x00) in DNS wire form and the DNS wire name is
> limited to 255 octets.

Mark,

My apologies for nit-picking, but RFC 3986, Section 3.2.2 is
quite clear than DNS names in URIs are permitted to have a final
period and encouraged to do so under some circumstances.
Specifically,

	"The rightmost domain label of a fully qualified domain
	name in DNS may be followed by a single "." and should
	be if it is necessary to distinguish between the
	complete domain name and some local domain."

I don't think that changes the 253 octet limit, but the comment
about URIs is misleading and could contribute to an, IMO,
already high level of confusion about what RFC 3986 does or does
not specify.

The same subsection of RFC 3986 also uses the term "host
subcomponent" for what you are referring to as a name and allows
it to be a "registered name" (or <reg-name>) that might not be a
DNS name or reference at all -- whether it is or not is
scheme-dependent. 

best,
   john

---

From: [email-masked] (Martin Rex)
Date: Thu, 6 Jul 2017 22:32:38 +0200 (CEST)

> 	complete domain name and some local domain."

Also apologies from my side for nitpicking.

While I do believe that final periods on DNS names in URLs should work,
they still seem somewhat unusual, and there is a varing amount of breakage
around _matching_ DNS names with a final period to names without one
in various areas of communication protocols.

example: rfc2818 section 3.1 server endpoint identification
While _recent_ versions of Firefox & Chrome seem to no longer fail to
match them to TLS server certs, users of the blue stuff from Redmond
seem to be less lucky and still face cert hostname mismatch errors.

(but Google Chrome started delibertatly violating a MUST requirement from
 rfc2818 3.1 for certs without SANs, so name matching in Chrome _is_ broken,
 just differently broken).

There are other places where the DNS names from URLs will be placed,
e.g. TLS extension SNI client-side, TLS extension SNI server-side (virtual
hosts), HTTP Host: header fields, Cookies?, Same-origin-policies?

and I would not be surprised about more failures comparing DNS names
where one carries a final period.

-Martin

---

From: Mark Andrews <[email-masked]>
Date: Fri, 07 Jul 2017 07:52:36 +1000

> services.  TXT RRs forever.  :(

Or you could stop trying to reinforce the myth that new RR types
are hard to deploy.  They really aren't.  They actually get used
all the time.

---

From: Mark Andrews <[email-masked]>
Date: Fri, 07 Jul 2017 10:42:59 +1000

> DNS name or reference at all -- whether it is or not is

Which really should never have been allowed.  Beyound the UI
everything should be absolute.  Relative names in URI really don't
work in practice because search lists are not constistent even
inside a single organisation.

I had my ISP hand me a relative link for their support pages.  IT
DID NOT WORK.  There support line got a call complaining about it.

Mark

---

From: John C Klensin <[email-masked]>
Date: Thu, 06 Jul 2017 23:36:21 -0400

--On Friday, July 7, 2017 10:42 +1000 Mark Andrews
<[email-masked]> wrote:

>> subcomponent" for what you are referring to as a name and
>> allows it to be a "registered name" (or <reg-name>) that
>> might not be a DNS name or reference at all -- whether it is
>> or not is scheme-dependent. 
>...

> everything should be absolute.  Relative names in URI really
> don't work in practice because search lists are not
> constistent even inside a single organisation.

Mark, it is no secret that I'm not a fan of relative URIs or of
3986 generally.  But the latter is, for better or worse, a full
standard that went through the IETF process.   If you think it
is seriously flawed, I'd encourage you to write in I-D to fix it
and see if you can get it through the system.  My experience
predicts that any attempt to do such a thing will produce an
outcry about the astronomical number of web pages that contain
and depend on such references and the only slightly smaller
number of them that are used every day, but maybe you will do
better than I did when I tried to get something with far
narrower scope through the system.

> I had my ISP hand me a relative link for their support pages.
> IT DID NOT WORK.  There support line got a call complaining
> about it.

With the above in mind, so?  The number of links most of us see
a week that don't work --whether the references are relative or
absolute-- is rather too large to view one failure as horrible
breakage in the model.

    john

---

From: Nico Williams <[email-masked]>
Date: Fri, 7 Jul 2017 00:53:16 -0500

> are hard to deploy.  They really aren't.  They actually get used

I'm well aware that as to clients and servers, deploying new RR types is
easy.  The hard part is the management backend and UIs.  Not all of them
allow you to enter raw RDATA (hex-encoded or whatever).

We've struggled with this in KITTEN WG.  Deploying the URI RR type when
you're using a hosting service can be anywhere from annoying (must enter
raw RDATA) to impossible (the hosting service doesn't give a damn).  I
suppose it's just a matter of time; perhaps things have improved since
we last looked.

Nico
--

---

From: Mark Andrews <[email-masked]>
Date: Fri, 07 Jul 2017 16:56:37 +1000

> suppose it's just a matter of time; perhaps things have improved since

Then change domain hosting providers and tell them why or run you
own master server or use a service which allows for dynamic updates
which shouldn't care about the record types.  There are plenty of
DNS providers that will slave content.

As a DNS server vendor we get requests to add the new type within
days the type being allocated.  We usually already have code written
and merged to support the new type in all current branches before
those request come in as we poll the type registry daily.  It is
available over git to anyone that wants to pull it down support for
the new type prior to the next maintainence releases.  Adding a new
type is as simple as adding to files to the source tree and rebuilding
the tools.  Once that is done all the tools we ship support it.

Mark

---

From: David Cake <[email-masked]>
Date: Fri, 7 Jul 2017 15:32:21 +0200

If you have a single centralised root for your new class, you will probably either recreate the problems of ICANN, or create one or more of the problems that ICANN has very consciously tried to avoid.
If you have a system of name resolution that avoids the need for a centralised root, you probably don’t need a new class to implement it. 
The few marginal cases that need to interact with the one root but not be ICANN controlled are why we have the RFC 6761 process. 

I agree a taxa of needs that do not fit within those three cases would have been useful. 

David

> On 5 Jul 2017, at 10:47 am, Randy Bush <[email-masked]> wrote:
>

---

From: Paul Vixie <[email-masked]>
Date: Fri, 07 Jul 2017 08:09:30 -0700

> suppose it's just a matter of time; perhaps things have improved since

that would be a prior restraint, and bad for innovation. just like 
middle boxes or the nearly universal assumption that ip means tcp or 
udp. i know this kind of thinking is common. but there is a stark choice 
for all of us: do all of our future protocol work on tcp/80 and make 
everything fit in JSON, so that we can get our work done; or keep doing 
what the internet used to mean, and eventually put enough stress on 
middle box makers, isp's, and in your case dns hosting services, that 
they have to learn about the internet rather than just the web.

i know which future i'd rather live in. i also feel in-year pressure to 
get my work done. i vacillate as to who gets to receive which burdens.

-- 
P Vixie

---

From: Nico Williams <[email-masked]>
Date: Fri, 7 Jul 2017 11:35:13 -0500

> DNS providers that will slave content.

That's easy enough if *I* am the user.  Of course I can change hosting
providers.  However, it's NOT easy when your *customer* is the user that
has to change hosting providers -- they'll balk, and you'll just work
around it.

In the KITTEN WG case there definitely was a vendor who needed to
support customers who use hosting providers that didn't support the URI
RR type.  Can you blame them for not wanting to go with the URI RR type?

Sure we should do it anyways -- it might help.  But that vnedor will
still have to cope with cases where URI is not available, and that
actually means falling back onto alternative, possibly slower, methods
that need to be specified too and which might have annoying knock-on
effects.

(In the KITTEN WG case the idea is to improve discovery of Kerberos KDC
services.  We currently use SRV RRs, but this requires multiple
requests, and every time we add a new transport we need to add more
requests.  One could parallelize the requests, but that's not
necessarily very nice, and anyways, it sucks from a resolver API
perspective.  A URI RR type would solve the problem.  But if you have to
fallback then you've slowed things down for what might be the common
case.)

> the tools.  Once that is done all the tools we ship support it.

Of course.  *You* are NOT the problem.  That's great.  The problem is
always some knucklehead somewhere who doesn't care to fix *their* system.

Nico
--

---

From: Nico Williams <[email-masked]>
Date: Fri, 7 Jul 2017 11:37:39 -0500

On Fri, Jul 07, 2017 at 08:09:30AM -0700, Paul Vixie wrote:
> that would be a prior restraint, and bad for innovation. just like middle
> boxes or the nearly universal assumption that ip means tcp or udp. i know
> this kind of thinking is common. but there is a stark choice for all of us:
> do all of our future protocol work on tcp/80 and make everything fit in
> JSON, so that we can get our work done; or keep doing what the internet used
> to mean, and eventually put enough stress on middle box makers, isp's, and
> in your case dns hosting services, that they have to learn about the
> internet rather than just the web.
> 
> i know which future i'd rather live in. i also feel in-year pressure to get
> my work done. i vacillate as to who gets to receive which burdens.

I'm with you on this.  I badly want to be able to use new RR types
without further ado.  I would prefer to push on the middleboxes and
middlepeople -- but we need to do a better job of this altogether so
that we don't have to wait a decade.  We don't have a spec police, so
all we can do is nag.

Nico
--

---

From: Nico Williams <[email-masked]>
Date: Fri, 7 Jul 2017 11:46:41 -0500

On Fri, Jul 07, 2017 at 11:37:39AM -0500, Nico Williams wrote:
> I'm with you on this.  [...]

I should add too that in order to do better at pushing on middleboxes we
need to acknowledge the problem.  Please don't tell me to stop spreading
the myth that it's difficult to deploy new RR types!  Work with us to
fix the problem, and recognize that it is largely a social one.

If we ever want to use CLASSes to expand the RR type namespace, we'll
definitely need even more support from clients/servers/providers.  So
it's worth considering that now rather than later, because we shouldn't
want to have to go through this middlebox un-break exercise multiple
times.

I would even suggest that we immediately add such a new class or three
just to be able to test compliance.  This wouldn't preclude new classes
that aren't IN RR type namespace extension classes.

Nico
--

---

From: Nico Williams <[email-masked]>
Date: Fri, 7 Jul 2017 11:55:14 -0500

On Fri, Jul 07, 2017 at 03:32:21PM +0200, David Cake wrote:
> If you have a single centralised root for your new class, you will
> probably either recreate the problems of ICANN, or create one or more
> of the problems that ICANN has very consciously tried to avoid.  If
> you have a system of name resolution that avoids the need for a
> centralised root, you probably don’t need a new class to implement it.
> The few marginal cases that need to interact with the one root but not
> be ICANN controlled are why we have the RFC 6761 process. 
> 

Well, there's a) the rooted hierarchy of the public DNS (IN class),
b) mDNS (which isn't really DNS, just a local discovery mechanism based
on the DNS protocol), c) the HS class, which traditionally wasn't used
in a federated manner (but maybe I'm wrong about that), so it doesn't
need a rooted hierarchy, though it also could use one.  (b) and (c) are
niches, with no real place on the open, public Internet.

One could use something like HS as an alternative to LDAP, say, but
recall that the vision of a world of federated and open directories
never materialized NOT because of limitations of DAP/LDAP, but because
of confidentiality/ privacy considerations.  Such a class would really
need to use the same rooted hierarchy, and, really, the same root, as
the public DNS IN class -- i.e., an IN RR type namespace extension
class, so it's best to consider such a class in those terms rather than
as a "directory class".

I am having a very difficult time imagining, say, a peer-to-peer or
web-of-trust DNS (other than mDNS).  Perhaps my imagination fails me.

A rooted hierarchy is and has been incredibly useful, and the simplest
method of providing a consisten Internet to all users.  It seems to me
very unlikely that we'll ever move from that.  At most we may have
alternative roots, but a mostly common set of TLDs (e.g., as happens in
many private (corporate) networks).

Nico
--

---

From: David Conrad <[email-masked]>
Date: Fri, 7 Jul 2017 09:32:09 -0700

Mark,

On Jul 6, 2017, 11:56 PM -0700, Mark Andrews <[email-masked]>, wrote:
> > > are hard to deploy. They really aren't.

Please stop trying to minimize the amount of work here. They really are. Not for you, but for the folks who make domain names available for use by non-technical types.

> DNS providers that will slave content.

The number of folks who even understand what you've written above, much less can actually do it, is insignificant in the context of seeing significant adoption of new RRs.

> As a DNS server vendor

You need to look at the wider world.

The DNS server side of deploying a new RR is the easiest part and while necessary, it's no where even close to sufficient to getting a new RR deployed. It's like trying to move the automobile industry to hydrogen fuel: building a car that runs on hydrogen is easy, relatively speaking. However to actually do anything useful with that car, you need need to modify the fuel delivery infrastructure, which is vastly harder, involves a vastly larger set of players, very few of which have any sort of financial incentive to make the change. Standard chicken-or-egg problem.

ICANN funded John Levine to develop https://metacpan.org/release/JRLEVINE/Net-DNS-Extlang-0.1 to try to make it easier to break the chicken-or-egg problem by hopefully giving the folks who provide the UIs by which domain names are managed by non-geeks better tools. However, that's just the first step -- the domain name managers still need to be encouraged to use them.  Pretending this is an easy problem isn't helping.

Regards,
-drc

---

From: william manning <[email-masked]>
Date: Fri, 7 Jul 2017 11:27:45 -0700

You need a better imagination then.   mDNS is a crippled DNS implementation
that was hobbled on purpose.   HS was/is an entirely different addressing
scheme that emerged from project Athena @ MIT.  To the extent that when all
you have been given is the IN class and it's associated rooted hierarchy,
you first,second,&third inclination is to treat EVERYTHING as being easily
integrated into that model.  And the ietf is going to go right along with
you.   After all, when all you have is a hammer, everything looks like a
nail.

On Saturday, July 8, 2017, Nico Williams <[email-masked]> wrote:

> > > On 5 Jul 2017, at 10:47 am, Randy Bush <[email-masked] <javascript:;>>
> wrote:
> > >
> [email-masked] <javascript:;>

---

From: Pete Resnick <[email-masked]>
Date: Fri, 7 Jul 2017 13:41:24 -0500

[Apologies for the re-send. Using the correct address.]

> are hard to deploy.  They really aren't.  They actually get used

I'm running the latest version of MacOS Server. I can't get a new RR 
type into the UI. Even if I use the command line "dnsconfig" tool, I 
can't add a record of a type it doesn't know about; I only get A, AAAA, 
CNAME, NS, MX, PTR, SRV, and TXT. Yes, I could go hacking around in the 
BIND configs that underly their implementation. And at that point I say, 
"New RR types are hard to deploy; not a myth." Telling me I can use a 
different operating system or not use a validating UI is not a 
reasonable response.

The fact is the DNS doesn't provide a way for implementations to 
dynamically update the RR types to provide sensible UI; it's left as an 
exercise for each individual implementer. (Yes, I know about 
draft-levine-dnsextlang; it doesn't seem to have gotten anywhere.) You 
can't much complain about the difficulty of deployment when the 
community won't provide the tools to make deployment easier.

pr
-- 
Pete Resnick <http://www.qualcomm.com/~presnick/>
Qualcomm Technologies, Inc. - +1 (858)651-4478

---

From: Nico Williams <[email-masked]>
Date: Fri, 7 Jul 2017 14:14:47 -0500

> you.   After all, when all you have is a hammer, everything looks like a

Did you read what I wrote??

The thing I'm having trouble imagining is distinct from the things that
you list that I also listed (and then lecture about as if I had no idea
what they were).  A peer-to-peer DNS might be mDNS-like without whatever
crippling you have in mind, but it's still difficult to imagine how to
organize a coherent Internet around it.  And as to web of trust, I don't
see how that would work either.  You decry my lack of imagination but
provide none of your own.

Nico
--

---

From: Mark Andrews <[email-masked]>
Date: Sat, 08 Jul 2017 10:18:25 +1000

> different operating system or not use a validating UI is not a 

Well use nsupdate.  That also ships with the Mac.  The version Apple
ships is a little bit old but it can still handle unknown types and
classes.  It can also use SIG(0) or TSIG to sign the updates messages.
It also supports the following types if I've matched the version
of BIND correctly (BIND 9.8.3.P1).  

a, a6, aaaa, afsdb, apl, cert, cname, dhcid, dlv, dname, dnskey,
ds, gpos, hinfo, hip, ipseckey, isdn, key, keydata, kx, loc, mb,
md, mf, mg, minfo, mr, mx, naptr, ns, nsap, nsap-ptr, nsec, nsec3,
nsec3param, null, nxt, ptr, px, rp, rrsig, rt, sig, soa, spf, srv,
sshfp, tkey, tlsa, txt, unspec, wks, x25

[rock:~/git/bind9] marka% /usr/bin/nsupdate 
> update add xxxxx 0 class40 type9000 \# 1 00
> show
Outgoing update query:
;; ->>HEADER<<- opcode: UPDATE, status: NOERROR, id:      0
;; flags:; ZONE: 0, PREREQ: 0, UPDATE: 0, ADDITIONAL: 0
;; UPDATE SECTION:
xxxxx.			0	CLASS40	TYPE9000 \# 1 00

> quit
[rock:~/git/bind9] marka% uname -a
Darwin rock.dv.isc.org 16.6.0 Darwin Kernel Version 16.6.0: Fri Apr 14 16:21:16 PDT 2017; root:xnu-3789.60.24~6/RELEASE_X86_64 x86_64
[rock:~/git/bind9] marka% 

> community won't provide the tools to make deployment easier.

Well BIND is designed to allow new types to be added easily.  It
may require recompiling rather than updating a text file but it is
not beyond people to do because we see people doing just that.  All
the record types are defined in a single place and adding in a new
type is usally as simple as cutting and pasting bits from the
existing type definitions to make a new one.

We also ship a tool which only purpose is to translate between
unknown record format and known record format.  You don't need to
update you whole web api to add in a new type.  Just update the
tool.  It also provides a list of known types it supports so you
can use it to update the web api's list of supported types at
runtime.

[rock:~/git/bind9] marka% echo in a 1.2.3.4 | named-rrchecker -u
CLASS1	TYPE1	\# 4 01020304
[rock:~/git/bind9] marka% 

[rock:~/git/bind9] marka% named-rrchecker -T | fmt
A NS MD MF CNAME SOA MB MG MR NULL WKS PTR HINFO MINFO MX TXT RP
AFSDB X25 ISDN RT NSAP NSAP-PTR SIG KEY PX GPOS AAAA LOC NXT EID
NIMLOC SRV ATMA NAPTR KX CERT A6 DNAME SINK APL DS SSHFP IPSECKEY
RRSIG NSEC DNSKEY DHCID NSEC3 NSEC3PARAM TLSA SMIMEA HIP NINFO RKEY
TALINK CDS CDNSKEY OPENPGPKEY CSYNC SPF UINFO UID GID UNSPEC NID
L32 L64 LP EUI48 EUI64 URI CAA AVC TA DLV
[rock:~/git/bind9] marka% 

Mark

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Sat, 8 Jul 2017 08:04:26 -0400

> label types to do that, not CLASSes.   And label types don't

​My point was that all the reasons not to use class for
internationalization are likely general and apply to any attempt to use
class.

> favorite remains "we will never need more than 8 bits of address

​The question that always comes up in a directory service is how much
service description information to put in the ​directory and whether the
service itself should provide some of the description.

DNS is irritatingly constraining when it comes to distributing information
like a digital certificate. But we have managed to live in those
constraints for the past 20 or so years after they started to be an issue.

What you need and what you might want are different things.

​If people find that they do need 'more than 8 bits', then ​I guess we end
up having to design DNS/2 protocol. But I think it unlikely we get there
anytime soon.

---

From: Pete Resnick <[email-masked]>
Date: Sat, 8 Jul 2017 11:05:01 -0500

On 7 Jul 2017, at 19:18, Mark Andrews wrote:

> Well use nsupdate.  That also ships with the Mac.

Of course doing that likely means I'll have records that don't show up 
in the server UI. Not entirely thrilling. And I could accomplish exactly 
the same thing by directly editing the BIND config files, so I'm not 
sure what that gains me in terms of "not hard to deploy".

> not beyond people to do because we see people doing just that.

¬(∃𝑥𝐶(𝑥) → ∀𝑥𝐶(𝑥))

Just because you you see some people recompiling does not mean that all 
(or most, or a significant number) can. Set that aside, it is nowhere 
near reasonable for knowing how to recompile a piece of code to be 
required in order for me to add a new RR type. Set that aside, this is 
the epitome of "hard to deploy": Some implementations can't do it at 
all, some implementations you have to go hacking around in hidden config 
files, and some implementations you have to recompile the binary to get 
a reasonable UI experience.

This is the problem with DNS being considered a system service rather 
than a user application. It's got both aspects. Until the user 
experience for configuring the DNS with a new RR type does not require 
the skills of someone able to recompile code, it is absolutely going to 
be the case that new RR types are hard to deploy, and calling it a myth 
is not helpful.

pr

---

From: Mark Andrews <[email-masked]>
Date: Sun, 09 Jul 2017 11:58:51 +1000

In message <[email-masked]>, Pete Resnic
> sure what that gains me in terms of "not hard to deploy".

Given Macs can register their own addresses in the DNS using UPDATE
I doubt that the strawman you are attempting to raise here happens
and if it does log a bug with Apple.  Log a bug with Apple that the
tool doesn't support all known types and that it doesn't support
unknown types.

> be the case that new RR types are hard to deploy, and calling it a myth 

We supply user applications to manipulate the DNS.  Those tools are
capable of updating yet to be defined types.  Putting a front end
on those tools that takes the new type someone dreams up is easy.

We also supply C libraries that can do the same thing.  No one needs
to wait to use a new type.

There are python and perl tools available that can also send update
messages.

If you just want the new records to be a blob of text a shell script
like this will convert the record to unknown format suitable to be
used by nsupdate.

% sh junk
hello world
\# 11 68656C6C6F20776F726C64
% cat junk
read record
hex=`printf "%s" "$record" | hexdump -ve '/1 "%02X"'`
length=`printf "%s" "$hex" | wc -c`
length=`expr $length / 2`
echo '\#' $length $hex
% 

You can create all DNS records similarly.  Building them up
field by field.

One can do something similar in any scripting language.

So no it isn't hard to use a new type.  You just need to stop waiting
for the stupid DNS hoster to do it for you and organise to do it
yourself.

---

From: Nico Williams <[email-masked]>
Date: Sun, 9 Jul 2017 00:55:27 -0500

> One can do something similar in any scripting language.

Sure.  The people on this list can, and many others too.  Still, all of
us together are a tiny proportion of the users that would need to be
able to.

> for the stupid DNS hoster to do it for you and organise to do it

Stop.  Don't tell us.  Don't tell the customers.  Start writing emails
and making calls to hosting providers instead; get them to fix their
crap.  Make, publish, and keep up to date a list of viable providers.

Nico
--

---

From: Pete Resnick <[email-masked]>
Date: Sun, 9 Jul 2017 11:44:02 -0500

On 8 Jul 2017, at 20:58, Mark Andrews wrote:

> Given Macs can register their own addresses in the DNS using UPDATE...

You mean an A or AAAA record, which the UI does support?

> ...Log a bug with Apple that the

And in the meanwhile, you still say, "new RR types are not hard to 
deploy"?

> on those tools that takes the new type someone dreams up is easy.

To quote a favorite line of mine, I grant the point: If things were 
different, they wouldn't be the same.

Creating these front ends apparently has not happened, so how does this 
address the point that new RR types are hard to deploy?

> to wait to use a new type.

I refer the honourable gentleman to the answer I gave some moments ago.

Sure, it would be easy to write code to make tools exist that would make 
it be easy to deploy. Those tools do not currently exist. It is 
therefore still hard to deploy.

> There are python and perl tools available that can also send update

I refer the honourable gentleman to the answer I gave some moments ago.

> One can do something similar in any scripting language.

I think you have proved my point exceedingly well there.

> So no it isn't hard to use a new type.

Nobody said "use". The word was "deploy". Until a huge number of hosting 
providers and OS vendors and tool writers get their act together writ 
large (and that includes tool vendors who require recompiles and/or fun 
shell scripts in order to have a remotely sane UI experience), 
deployment of a new RR type is hard.

> You just need to stop waiting

That does not solve the deployment problem.

pr

---

From: Randy Bush <[email-masked]>
Date: Sun, 09 Jul 2017 21:26:43 +0200

while i enjoy berating vendors for bugs and poor feature sets as much as
the next person, well maybe more, it's a target rich environment.  if we
could come to agreement on what the right thing is, what we actually
want here, we could at least beat them on the right vector.

but as i said at the beginning, i am not even sure dns classes are the
answer.  this is exacerbated by the draft in question trying to shoot
down the users' needs without even exploring them.  and that is still my
main issue.  we're shooting down solutions when we have not yet defined
the problem.

30c in praha today

randy

---

From: Mark Andrews <[email-masked]>
Date: Mon, 10 Jul 2017 11:14:26 +1000

> want here, we could at least beat them on the right vector.

a) For DNS tools to support unknown types and classes (RFC 3597).

b) For DNS tools to add support for allocated data types within X
   months of them being assigned by IANA.  Allocated types are
   supposed to have stable wire and presentation formats.

for a reasonable value of X (<= 12?).

---

From: Andrew Sullivan <[email-masked]>
Date: Mon, 10 Jul 2017 12:06:48 -0400

> for a reasonable value of X (<= 12?).

With all due respect, that sounds like you want to make some sort of
expectation of people on the Internet -- one requiring that they spend
time or money or both to solve a problem that they apparently don't
have.  If they _did_ have it, they would already be solving it.

For instance, infrastructure operation on the Internet provides thin
profit margins.  If a customer requires a lot of attention or
hand-holding then the profit margin on that customer can disappear
pretty quickly.  Therefore, it is of critical importance to have a lot
of automated checking in place that ensures that the customer's
expectations are met.  Tools to smooth the rough edges need to be
foolproof -- customers don't want to do "rocket science" or even
"appliance science".  The tools must not only to handle a user's
input, but to be able to be pretty confident that it is going to do
something like what they wanted it to do (or else give them a hint).
Otherwise, the angry customer contacts support and wipes out the
profit on them.  The natural consequence of that is just that the more
obscure RRs are just not going to be supported in those kinds of
tools.  The risk to companies' reputations and customer satisfaction
is too great for the meagre reward.

Is this bad for the Internet?  Yes.  But that's what you get in a
system that depends on voluntary participation: sometimes other people
don't want to play your game, and unless it seems like it will be
rewarding enough most of them aren't even going to bother asking what
the rules are.

And that's just for RRTYPEs.  There is no evidence whatever that a new
CLASS is of any utility at all to anyone except maybe DNS nerds.

It is ridiculous to claim that everyone else on the Internet is wrong
and, if they would just do what we say, everything would be good.  The
Internet did not eat every other communication technology because
people found it hard to follow the Official Rules Made Up By Netgods.
It took over because it worked well enough for most people most of the
time without too much effort.  Everything actually deployed on the
Internet scratches someone's itch.  Adding support for stuff to the
DNS is a hair shirt.

Best regards,

A

-- 
Andrew Sullivan
[email-masked]