[DNSOP] Proposed charter for DBOUND WG

["Murray S. Kucherawy" <[e-mail]>]

Colleagues,

Below is a proposed charter for a working group we're calling DBOUND, which
is seeking to solve the problem of finding a way to identify
administrative/organizational boundaries in the domain namespace.  We'd
like to get some feedback from outside the team of people that's been
working on it.

For the sake of tracking the feedback, please reply only to
[e-mail] with any comments you may have.

-MSK, APPSAWG co-chair

dbound charter

Various Internet protocols and applications require some mechanism for
determining whether two domain names are related.  A popular example is
the need to determine whether example.com and foo.example.com, or
evenexample.net, are subject to the same administrative control.  To
humans,
the answer to this may be obvious.  However, the Domain Name System (DNS),
which is the service that handles domain name queries, does not provide
the ability to mark these sorts of relationships.  This makes it
impossible to discern relationships algorithmically.  For example, the
right answer is not always "compare the rightmost two labels".

The particular issue is that applications and organizations impose
policies and procedures that create additional structure in their use of
domain names.  This creates many possible relationships that are not
evident in the names themselves or in the operational, public
representation of the names.

Prior solutions for identifying relationships between domain names
have sought to use the DNS namespace and protocol to extract that
information when it isn't actually there; the concept of an administrative
boundary is by definition not present in the DNS.  Relying on the DNS to
divine administrative structure thus renders such solutions unreliable and
unnecessarily constrained.  For example, confirming or dismissing a
relationship between two domain names based on the existence of a zone
cut or common ancestry is often unfounded, and the notion of an upward
"tree walk" as a search mechanism is considered unacceptable.

For the purposes of this work, domain names are approached as identifiers
used by organizations and services, independent of underlying protocols
or mechanisms.  Specifically, the work will not propose any changes to
DNS protocols except the possible creation of new resource record types
(RRTYPES).  Furthermore, we define an "organizational domain" to be a
name that is at the top of an administrative hierarchy, defining transition
from one "outside" administrative authority to another that is "inside" the
organization.

Currently, the most well known solution in existence is the Public Suffix
List (PSL).  The PSL is maintained by a Web browser producer and is kept
current by volunteers on a best-effort basis.  It contains a list of points
in the hierarchical namespace at which registrations take place, and is
used to identify the boundary between so-called "public" names (below which
registrations can occur) and the private names (i.e., organizational names)
below them.  When this list is inaccurate, it exposes a deviation from
reality that degrades service to some and can be exploited by others.  Being
the de facto resource, and lacking a more comprehensive, alternative solution
for relationship identification, the functionality of the PSL has often been
misused to accomplish means beyond its capabilities.  For example, there
is no way to confirm the relationship between two domain names, only
signal that there is or is not a public boundary between the two.
Additionally, there are questions about the scalability, central management,
and third-party management of the PSL as it currently exists.

In terms of specific use cases: Within the realm of email, there is a
desire to link an arbitrary fully-qualified domain name (FQDN) to the
organizational domain name (at some point in the namespace above it),
in order to identify a deterministic location where some sort of statement
of policy regarding that FQDN can be found.  With respect to the
web, there is a similar need to identify relationships between different
FQDNs, currently accomplished by comparing ancestries.  However, there
is also desire to reliably identify relationships outside of the realm
and constraints of the namespace tree.

Previous work such as Author Domain Signing Practices (ADSP; RFC5617), and
current work such as DMARC (draft-kucherawy-dmarc-base), would certainly
benefit from having this capability.

The DBOUND working group will develop one or more solutions to this family
of problems.  If possible, a unified solution will be developed.  However,
the working group may discover that the email, web, equivalence, and
possibly other problems require independent solutions, in which case the
working group will follow that path.  The solutions may or may not involve
changes to the DNS, such as creation of new resource record types; in any
case, all such changes will be incremental only.

This working group will not seek to amend the consuming protocols themselves
(i.e., any web or mail standards) without rechartering, and only after
completion of the base work.  Any such work undertaken in parallel will
eeed to be done as individual or independent submissions, or in another
working group.

Milestones:
- TBD

Co-chairs:
- TBD