DRPF Use Case

Delegated Subdomains

A domain administrator will often delegate a subdomain to a 3rd party, effectively ceding administrative control over the subdomain. This can be accomplished by the domain administrator publishing a Canonical Name (CNAME) DNS resource record, often to support services provided by the 3rd party.

Example: The domain administrator for "company.domain" may delegate "marketing.company.domain" by publishing a CNAME record pointing to a server operated by a 3rd party marketing agency so they can operate a website on behalf of the company.

Once the CNAME is put in place, however, both companies may want some of their administrative policies to be applied to the delegated domain... policies that can be published and discovered via their respective DRPF records.

To support the ability of the delegator to continue levaraging DRPF, we've introduced the ability to publish assertion records as DNS TXT RRs on attribute leaf domain labels. It adds complexity to the discovery performed by the relying party, but doing so enables both the delegator and delegate domains to publish policies.

Delegate Policy

When a subdomain is delegated to a 3rd party it enables them, as the delegate, to publish an assertion record to be discovered via the delegated domain. In the simplest case, the publishing and discovery of the assertion record, and any associated policies, is identical to if the original domain administer had published them. To clarify the use of the delegated domain, it may be useful to include in the assertion record and/or to any referenced policy documents describing the relationship between the delegator and delegate organizations.

Example: Consider the "marketing.company.domain" example discussed above. The 3rd party marketing agency may want to publish DRPF policy documents that govern the uses of the subdomain. They can simply publish a policy assertion record as a TXT RR at the FQDN targeted by the CNAME declaration to be discovered by a relying party.

To support this example, the 3rd party marketing agency delegate could publish an assertion record at the target FQDN (i.e. the domain to which the CNAME is pointing) along the lines of:

"domrel;childOf:marketing.domain;delegate:company.domain;policy:https://marketing.domain/policies.json"

In addition to specifying the parent administrative domain for the delegated FQDN, the above example identifies the administrative domain that delegated the subdomain. Noting that the publication of this assertion record and referenced policy documents are entirely under the control of the delegate, without delegator involvement.

Delegator Policy

Using a CNAME record to delegate subdomains enables an easy way to map queries to another target FQDN, but does introduce slightly more complexity to enable a relying party to discover and parse the relationships between the delegator and delegate (and any policies each would like to publish in service to the subdomain). While the delegating administrator maintains a level of control over the delegated subdomain by virtue of being in control of the CNAME declaration, the delegator does lose the ability to publish assertion records via the simple TXT RR method. And given that there are times when both the delagator and delegate want to apply appropriate policies, we need to introduce a new publishing and discovery method.

To accomplish this, in addition to the delegate being able to use the simple TXT RR method for publishing their assertion record, the delegator may also opt to publish their own assertion record as a TXT RR within an attribute leaf label associated with the subdomain that they've delegated. This would be accomplished as per RFC 8552) with the attribute leaf label being "_drpf" such that the delegating administrator would publish there assertion record to something like "_drpf.marketing.company.domain".

The ability to publish DRPF assertion records directly as a TXT RR to the CNAME target of the subdomain as well as to the "_drpf" attribute leaf, both the delegate and delegator may publish their own policies. Taken together provides the ability of a relying party to build a full picture of the relationship and authorized uses of the delegated subdomain.

CNAME Declaration

DNS CNAME declaration published by the delegator domain administrator of "company.domain"

"marketing.company.domain. CNAME company.marketing.domain."

Delegator Policy Assertion Record

Published as a DNS TXT RR to the addribute leaf: "_drpf.marketing.company.domain"

"domrel;childOf:marketing.domain;delegatedTo:marketing.domain;policy:https://company.domain/policies.json"

Delegate Policy Assertion Record

Published as a DNS TXT RR to: "company.marketing.domain"

"domrel;childOf:marketing.domain;delegateOf:company.domain;policy:https://marketing.domain/policies.json"

Discovery of Delegator and Delegate Policies

Once the administator of delegate subdomain publishes their policy assertion record as a DNS TXT RR, and the delegator publishes their assertion record to the attribute leaf domain label, it's up to the relying party to discover them. To do so, the relying party would go through the following steps:

1. Query Domain for a CNAME Declaration: The first step is for the relying party to detect if the domain they're querying has been delegated to another target domain using a DNS CNAME RR. If so, any queries for DRPF assertion records published to the DNS TXT RRs of the delegated domain would be redirected to the CNAME target which is under control of the administrator of the delegate domain. To discover DRPF assertion records published by the delegator, the relying party will need to query for an attribute leaf domain label.
2. Query Domain for DRPF Assertion Record Published to an Attribute Leaf: If the relying party detects a CNAME indicating the delegation of the domain, they can query for a DRPF asssertion record as a DNS TXT RR published to a "_drpf" attribute leaf of the domain. Doing so will enable the relying party to discover if the delegator of the domain is asserting one or more DRPF policies that are distinct from those that may be published by the delegate of the domain. Should no assertion record be found at the attribute leaf domain label, the relying party knows that the delegator is not publishing distinct DRPF policies.
3. Query Domain for DRPF Assertion Record Published as a DNS TXT RR: Regardless of whether or not the relying party retrieves an assertion record from an attribute leaf domain, they can obey the CNAME and query the domain for an assertion record as a DNS TXT RR. Doing so should result in a query being made to the target domain controlled by the delegate domain administrator where they can publish their DRPF policies.
4. Parsing and Obeying the Discovered DRPF Policies: This is the trickiest part of the entire DRPF process as it requires business logic defined by the relying party. While some of the DRPF semantics define informative declaratives, the decision about how to apply the information is up to the relying party. Doing so can be particularly complicated when two operational entities are asserting policies over a domain. Look for best practice guidance interpreting delegated policies to be published in the future.

DRPF Use Case

Delegated Subdomains

Delegate Policy

Delegator Policy

Discovery of Delegator and Delegate Policies

Example Use Cases

Questions?