Domain Boundaries
charter-ietf-dbound-00-05

Various Internet protocols and applications require some mechanism for
determining whether two domain names are related. The meaning of
"related" in this context is not a unitary concept. The DBOUND working
group will develop one or more solutions to this family of problems,
and will clarify the types of relations relevant.

For example, it is often necessary or useful to determine whether
example.com and foo.example.com, or even example.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. The right answer is not always "compare
the rightmost two labels".

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. See the "Additional Background
Information" section, below, for more details.

For the purpose of this work, "domain names" are identifiers used by
organizations and services, independent of underlying protocols or
mechanisms, and an "organizational domain" is defined as 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.

The current way most of this is handled is via a list published at
publicsuffix.org (commonly known as the "Public Suffix List" or "PSL"),
and the general goal is to accommodate anything people are
using that for today. However, there are broadly speaking two use
patterns. The first is a "top ancestor organization" case. In this case,
the goal is to find a single superordinate name in the DNS tree that can
properly make assertions about the policies and procedures of subordinate
names. The second is to determine, given two different names, whether they
are governed by the same administrative authority. The goal of the DBOUND
working group is to develop a unified solution, if possible, for determining
organizational domain boundaries. However, the working group may discover
that the use cases require different solutions. Should that happen, the
working group will develop those different solutions, using as many common
pieces as it can.

Solutions will not involve the proposal of any changes to the DNS
protocol. They might involve the creation of new resource record types.

This working group will not seek to amend the consuming protocols
themselves (standards for any web, email, or other such protocols) under
this charter. If such work is desirable, it will be assigned to another
appropriate working group or defined as a work item in an updated charter.
Rechartering will only be considered after completion of the base work.

The working group has a pre-IETF draft to consider as a possible
starting point: draft-sullivan-dbound-problem-statement

Milestones:
- TBD

Additional Background Information

[to be moved to a Wiki on chartering]

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, therefore, unacceptable.

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, such as ".com" or ".org.uk") and
the private names (organizational names) that domain registrars create within
them. When this list is inaccurate, it exposes a deviation from reality that
degrades service to some and can be exploited by others. As the PSL is the
de-facto resource, and as there is not a more comprehensive, alternative
solution for relationship identification, the PSL has often been misused
to accomplish things beyond its capabilities. For example, there is no way
to confirm the relationship between two domain names -- the PSL may 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.

Work such as DMARC (draft-kucherawy-dmarc-base), will certainly benefit
from having this capability.