[apps-discuss] draft-sullivan-domain-origin-assert-01.txt

[John C Klensin <[e-mail]>]

Andrew,

I find this document fairly troubling, largely for the reasons
we discussed briefly in Vancouver.  I think your explanation of
the problem(s) and what you are trying to do is muddy, in part
because it seems to me that you are trying to solve too many
problems, some of them simply incompatible with the architecture
of the DNS.  To make things worse, the terminology is confusing,
perhaps because of the old problem that existing DNS terminology
usage is, bluntly, a mess. In particular, the boundaries that
are more specifically discussed in "zone cut" terms (delegation
records and a requirement for an SOA record in the subsidiary
domain (and zone) are widely known as "administrative
boundaries".  Your using that term, or even "administrative
realm" is an invitation to confusion and trouble, especially in
the absence of text that explicitly repudiates the earlier usage.

More broadly, what you are trying to do here is to overlay an
entirely different data structure --really a mesh-- on top of
the strict hierarchy (with weak aliases) DNS structure. That
mesh is multidimensional with the potential for arrangements by
related domain names, by ports, and by scheme/protocol.  If very
much of that is used, one could easily end up with a lot of
these records at a given node, far exceeding the UDP limit and
possibly causing other problems.  Worse, if a node makes an
assertion about some set of other nodes and they make
contradictory assertions (whether through malice, configuration
error, or attempts at cleverness the spec doesn't anticipate),
one could end up with a rather interesting mess.  I note in that
regard that, in the general case, nothing ensures, or even
predicts, that port numbers of interest to a particular
situation will occupy continuous ranges.  If they do not, even
an attempt to make an assertion about port numbers could result
in a lot of records.

Putting aside the nomenclature issues with "administrative"
mentioned above for a moment, I suggest that one could get a
good 90% solution simply by defining a "policy authority origin"
record that parallels the function and definition of the "DNS
administrative authority origin" indication and information
provided by the SOA record.  That model fits nicely with the DNS
hierarchy (rather than trying to superimpose a new mesh on top
of it) -- it just clearly defines the two types of boundaries
separate from each other (which they are, of course).

The missing 10% includes protocol-sensitive machinery
("schemes"), and port-sensitive machinery, both of which we've
tended to avoid in the DNS architecture unless the relevant
records really are bound to particular protocols.  It also
includes the ability for one node to make assertions about a
node elsewhere in the hierarchy without necessarily having
permission from the target node -- effectively repeating and
extending the problem we have with aliases (reinforced by the
limitations of DNSSEC in those cases).  I think (although I'm
not yet ready to try to convince others), that it puts us
further into the situation of trying to build a trust model on
the integrity of registrars -- in today's environment, that
isn't a risk factor but a certain problem.

I can suggest some specific language to clarify the current
draft if that were appropriate, but I think you should consider
whether a much simpler model with provide most of the
functionality you are looking for with considerably less
potential complexity and the introduction of new risks.
Conversely, I think you should be required to really justify the
importance of port ranges, lists of URI schemes, and lists of
names that share owners rather than just putting those
capabilities in because (maybe) we know how.  

While aspects of the "variant" story are clearly in your mind
(and I fear contributing to assorted fantasies of what the DNS
can do to help with that without getting any real value in
return), your one clear use case is the public suffix list and
related cookie issues -- and those do not require port ranges,
scheme lists, or identification of other domains with the same
ownership -- it only requires clear identification of the
administrative/control/ policy boundary.

   best,
    john