dbound start

dbound-charter-2.0.txt

Various Internet protocols and applications require some mechanism for determining whether two domain names have some
relation.  The DBOUND working group will develop one or more solutions to this family of problems, and will clarify the 
types of relations relevant.

Some examples of the type of relations we are looking to address

* Cookie that have same origin in browsers, as Paul described.

* CA wildcards, it's OK to sign a cert for *.mycompany.co.uk or *.mycompany.com but not for *.co.uk or *.com.

* DMARC organizational domains, if you get mail from sales.bigcorp.com and that domain doesn't have a DMARC record, 
you look for a record at bigcorp.com.

    The current version of DMARC winks and nods and tells you to use the
    PSL to find the org domain, but the new version we're working on
    switches to a tree walk. The tree walk works for DMARC but it's not
    plausible for other uses that don't already put their own policy
    records in the DNS or that have time constraints -- nobody cares if it
    takes an extra quarter of a second to process an incoming mail
    message.

Applications and organizations impose policies and procedures that create additional structure that create many possible relationships. These are not always evident in the names themselves. 

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. 

The goal of the DBOUND working group is to develop a solution to define these relationships.