Subject: [DNSOP] What can be done with the DNS and what should be done elsewhere [draft-klensin-dns-function-considerations]

From: Stephane Bortzmeyer <[email-masked]>
Date: Tue, 6 Jun 2017 22:04:37 +0200

draft-klensin-dns-function-considerations is an interesting document
so I take the liberty to copy dnsop, which may be interested.

A few remarks about the -01 version:

It does not seem to mention other naming systems, except a short
reference to "blockchains" (there are many of naming systems, each
with different strengthes and weaknesses than the DNS). I do not
suggest to enumerate them all, rather to note they exist, and The
Solution may not be a replacement of the DNS but a coexistence of the
DNS with other naming systems (I have trouble believing that one day,
we will have One Perfect Naming System).

> 3.1.  Multiple address types

In this section, and in some others, I think that you mix problem
description and solutions. For this problem (getting both A and AAAA
records with a single query), there is the solution you mention
(QTYPE=ADDR) but there is also having several questions in the
Question section.

Same issue in "3.13.2.  Extensions and Deployment Pressures -- The TXT
RRTYPE" where you mention a solution (new RR types) and not another
one (TXT records below the apex).

> perceived discrimination against some languages

Scripts, not languages. And "perceived" is offensive: it _is_ a
discrimination (although we agree there is no obvious solution).

> it does not appear that any of them are as satisfactory as a system
> with query privacy designed in might be.

Both QNAME minimization (RFC 7816) and DNS encryption (RFC 7858) have
seen very little deployment today, so I don't think we can already
conclude they are not satisfactory.

> The DNS model of master and slave servers, with the latter
> initiating updates based on TTL values,

The slaves don't use the TTL values, don't they?

> a subject that is intensely controversial with regard to who should
> control those servers [the root name servers], how they should be
> distributed and where they should be located.

The problem is only partly technical. For instance, with today's DNS,
it is already possible to have more root name servers (not thousands,
OK, because of the size of the priming response, but dozens,
certainly). This would partially address the problem.

> A key design element of the original network object naming systems
> for the ARPANET, largely inherited by the DNS, was that the names
> were identifiers and their being highly distinguishable and not
> prone to ambiguity was important.

If the main (and may be only) goal were to have unambiguous
identifiers, digits would have been sufficient (a SHA-256 hash is an
unambigous identifier, see RFC 6920). Unlike what you say, from the
beginning, domain names have been expressing "thoughts and
concepts". With a few exceptions, nobody registers "opaque" domain
names.

Editorial:

> including a model for negotiating extended functionality [RFC2671]

It is now RFC 6891.

> and hard to illustrate in ASCII-only Internet-Drafts and RFCs

We now have RFC 7997 :-)

> Whether that would be desirable on not

Or not?

---

From: John C Klensin <[email-masked]>
Date: Tue, 06 Jun 2017 17:05:05 -0400

Stephane,

Thanks for reading the draft and for your comments.  I will
study them and see what I can do and will get back to you if I
have questions.  One general observation: I've tried, when
mentioning possible alternate approaches, to provide a partial
existence proof that alternatives are possible that could do the
job or improve things, not to propose solutions or to be
comprehensive able possibilities.  Fro example, the blockchain
example was mentioned because it is one way -- a way that has
gotten a lot of attention lately -- to have an authoritative
structured name system without having a hierarchical system and
centrally-managed root.   I didn't mean to suggest that it was
the only such option (it isn't) or the best one (I suspect it is
not).

As to whether DNSOP wants to get involved, while there are
operational issues in the summary I'm trying to make, I see most
of them as being consequences of protocol choices that were
either poor to start with (like the underspecification of
CLASS), poor (more historically than at present)
implementations, or that just have not held up (i.e., failed
30-odd years ago to adequately predict the present).   So, while
I'm sure there are people on the DNSOP list who are, or should
be, very interested in the question of whether we are pushing
the DNS past its practical limits, I don't see that as
specifically an operational problem.  Instead, I see it as an
issue that affects much of the IETF.   That is especially true
if, as one person who commented believes, a transition to a
DNSng could be more difficult and take longer than the IPv4->
IPv6 transition.   In addition, while I would welcome help or
even a contributor or co-author or two, I think there are a
number of reasons why the contents of this I-D are more
appropriately an Independent Submission than any sort of IETF
stream document (even an Informational one) that would require a
consensus determination.

best,
   john

--On Tuesday, June 6, 2017 22:04 +0200 Stephane Bortzmeyer
<[email-masked]> wrote:

> draft-klensin-dns-function-considerations is an interesting
> document so I take the liberty to copy dnsop, which may be
> interested.
> 
> It does not seem to mention other naming systems, except a
> short reference to "blockchains" (there are many of naming
> systems, each with different strengthes and weaknesses than
> the DNS). I do not suggest to enumerate them all, rather to
> note they exist, and The Solution may not be a replacement of
> the DNS but a coexistence of the DNS with other naming systems
> (I have trouble believing that one day, we will have One
> Perfect Naming System).
> 
> In this section, and in some others, I think that you mix
> problem description and solutions. For this problem (getting
> both A and AAAA records with a single query), there is the
> solution you mention (QTYPE=ADDR) but there is also having
> several questions in the Question section.
> 
> Same issue in "3.13.2.  Extensions and Deployment Pressures --
> The TXT RRTYPE" where you mention a solution (new RR types)
> and not another one (TXT records below the apex).
> 
>> it does not appear that any of them are as satisfactory as a
>> system with query privacy designed in might be.
> 
> Both QNAME minimization (RFC 7816) and DNS encryption (RFC
> 7858) have seen very little deployment today, so I don't think
> we can already conclude they are not satisfactory.
> 
>> a subject that is intensely controversial with regard to who
>> should control those servers [the root name servers], how
>> they should be distributed and where they should be located.
> 
> The problem is only partly technical. For instance, with
> today's DNS, it is already possible to have more root name
> servers (not thousands, OK, because of the size of the priming
> response, but dozens, certainly). This would partially address
> the problem.
> 
>> A key design element of the original network object naming
>> systems for the ARPANET, largely inherited by the DNS, was
>> that the names were identifiers and their being highly
>> distinguishable and not prone to ambiguity was important.
> 
> identifiers, digits would have been sufficient (a SHA-256 hash
> is an unambigous identifier, see RFC 6920). Unlike what you
> say, from the beginning, domain names have been expressing
> "thoughts and concepts". With a few exceptions, nobody
> registers "opaque" domain names.
> 
> Editorial:
>

---

From: Tony Finch <[email-masked]>
Date: Wed, 7 Jun 2017 12:48:03 +0100

> The slaves don't use the TTL values, don't they?

That section is a bit weird.

                                                     Efforts to use very
   short (or zero) TTLs to simulate nearly-simultaneous updating may
   work up to a point but appear to impose very heavy loads on servers
   and distribution mechanisms that were not designed to accommodate
   that style of working.  Similar observations can be made about
   attempts to use dynamic, "server-push", updating rather than the
   traditional DNS mechanisms.  While those might work better than
   ordinary short TTLs and update mechanisms as specified in RFC 1034
   and 1035, they imply that a "master" server must know the identities
   of (and have real time access to all of) its slaves, defeating many
   of the advantages of caching, particularly those associated with
   reduction of query traffic across the Internet.

It doesn't mention the venerable and widely-deployed NOTIFY, and seems to
muddle up replication to authoritative servers and cacheing in resolvers.
If it is supposed to be talking about somthing of current relevance, it
should refer explicitly to draft-ietf-dnssd-push or whatever other
developments the author has in mind.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/  -  I xn--zr8h punycode
Trafalgar: Northerly 5 or 6, becoming cyclonic 5 to 7, perhaps gale 8 later in
southeast. Moderate or rough. Fair. Good.

---

From: John C Klensin <[email-masked]>
Date: Wed, 07 Jun 2017 10:16:30 -0400

--On Wednesday, June 7, 2017 12:48 +0100 Tony Finch
<[email-masked]> wrote:

>                                                      Efforts
> to use very    short (or zero) TTLs to simulate
> nearly-simultaneous updating may    work up to a point but
> appear to impose very heavy loads on servers    and
> distribution mechanisms that were not designed to accommodate
>    that style of working.  Similar observations can be made
> about    attempts to use dynamic, "server-push", updating
> rather than the    traditional DNS mechanisms.  While those
> might work better than    ordinary short TTLs and update
> mechanisms as specified in RFC 1034    and 1035, they imply
> that a "master" server must know the identities    of (and
> have real time access to all of) its slaves, defeating many
> of the advantages of caching, particularly those associated
> with    reduction of query traffic across the Internet.
> 
> It doesn't mention the venerable and widely-deployed NOTIFY,
> and seems to muddle up replication to authoritative servers
> and cacheing in resolvers. If it is supposed to be talking
> about somthing of current relevance, it should refer
> explicitly to draft-ietf-dnssd-push or whatever other

It is indeed muddled.  Thanks to both of you for pointing that
out.  I will try to fix.  The references are another issue -
while I've tried to pick up references as I went along, there
are _many_ things that have been discussed, proposed, or even
adopted that I haven't picked up, partially because I just don't
follow some of the work closely enough.  Pointers to them would
be appreciated, as would text to go with them.

At least in retrospect, someone closer to DNS issues than I am
should have written the document I hope this will become and
written it several years ago.   No one did.  The IAB Identifier
Program could have taken it on, but they didn't (mostly, AFAICT,
for good reasons) and the IAB has now closed it.    I don't
believe that posting a note to the IETF (or DNSOP) list saying
"someone should do this" has ever been particularly productive,
especially not in the last few years.  WGs like DNSOP appear to
be focused on responses to demands for services and behavior
from the DNS that can be defined, implemented, and deployed in
the relatively short term (as I think they should be -- see
earlier response to Stephane).  Because I am concerned about
weakening the DNS for its original function and the amount of
time and energy that appears to be going into "solutions" that
just cannot work (the quest for fully-equivalent names, not even
limited to pointers to subtrees, comes to mind), my view is that
we need to start asking fundamental questions about how far it
is sensible to push the boundaries of the DNS, saying in essence
about many things that "we need a naming system and database for
something, the DNS is out there, so let's put it in the DNS".
So, driven by some other issues, including concerns that some of
the proposals to "fix" the DNS (or just "fix" IDNs) could weaken
it for other purposes, some apparent real disconnects in the
broader Internet community about the purpose of the DNS and
criteria for DNS success, and the degree to which I believe that
some of the requirement are real but that trying to make
proposed solutions fit in the DNS prevents work on more
comprehensive and effective solutions, I finally started
writing.    Again, if anyone with the right background wants to
be more actively involved, I would really welcome that.

best,
   john