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 of the working group wiki for more details:
https://trac.tools.ietf.org/wg/dbound/trac/wiki/AdditionalBackgroundInformation

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