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

[Stephane Bortzmeyer <[e-mail]>]

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?