DRPF Use Case

Parked Domains

Possibly one of the simplest DRPF use cases is in protecting parked domains that the company explicitly declares as being inactive. Sometimes the domains are parked when registered for future use, while others are domains that have been retired from service, and others are registered to keep them away from malicious actors abusing them. Whatever the reason, the company can publish a policy assertion record at "parked.domain" pointing back to the parent domain where the relationship can be confirmed and the policy document retrieved.

Why "Park" a Domain?

There are innumerable reasons why a domain may be registered only to be immediately parked and declared "inactive". And when we talk about a "parked" domain, we mean to say it is a domain that isn't currently being used for any valid / authorized purpose. It's essentially a domain that has been registered and set off to the side (i.e. "parked") for some reason or another. In some cases, the domain is being parked for some furture authorized use, while in other cases the domain is anticipated to be permanently parked in the domain graveyard. Perhaps it was of use at one time, but no longer active, or maybe it was taken over from an abusive registration. Even if a parked domain may rise from the grave at some point in the future, it's useful to know when a domain is currently sidelined in the virtual parking lot.

Regardless of the past use of the domain, or a projected future use, it is useful to know the current status of a domain that has been parked. In most cases, a parked domain should be treated as dormant, serving no current activity. Thus, if a relying party encounters activity related to a parked domain, they should treat that interaction with a heavy dose of suspicion. Currently, there is really no way for a domain administrator to announce that a domain is parked, and a simple DRPF assertion record and, optionally, an associated parent policy would be useful to all relying parties.

Declaring a Parked Relationship

In order to declare that a domain has been "parked", or otherwise "inactive," it's important for a Relying Party to know both that it has been parked, and who has made the declaration (i.e. who the administrative "parent" is of the domain). That means that both the Parked Domain (i.e. the "Child Domain") and the administrative domain (i.e. the "Parent Domain") must confirm the relationship. This can be accomplished by the the domain administrator (i.e. whoever has access to add DNS TXT RRs to each domain) publishing bi-directionally confimative statements. There are essentially two methods by which this can be accomplished: Domain Inference, and direct Policy Reference.

Domain Inference Method

In this simple method, the inactive "parked" Child Domain publishes an Assertion Record declaring nothing more than the domain is parked and who is the administrative Parent Domain. The Relying Party retrieves the Assertion Record, then pings the Parent Domain for its Policy Document which is then retrieved and parsed to confirm the relationship. Depending upon the depth of the embedded Policy Documents (e.g. in which Child Domains are declared in linked policies), this may incur additional retrieval steps. While potentially incurring additional DNS lookups and HTTPS retrievals/parsing, it enables the Child Domain to publish nothing more than the Parent Domain. This is useful when the related Policy Document is unknown or changes frequently.

By way of example using this method, the parked Child Domain (parked.domain) may publish an Assertion Record that looks something as simple as:

"domrel;childOf:parent.domain;status:inactive;"

There are likely few reasons a malicous actor would declare a domain "inactive" if they wanted to use it, so the Relying Party might simply trust such an assertion without confirming it with the declared Parent Domain. Should they want to do so, however, the Relying Party can retrieve the Assertion Record for the referenced Parent Domain that might look something like:

domrel;apex:parent.domain;policy:https://parent.domain/relationships.json

Without going into too much detail about the structure, syntax, and semantics of the Policy Document, the JSON-LD snippet below illustrates the minimal information necessary to confirm the asserted relationship:

{
  "@context": [
    "https://domainrelationships.org/",
    {
      "schema": "https://schema.org/"
    }
  ],
  "@type": "schema:Organization",
  "schema:legalName": "Parent Company LLC Inc.",
  "isApex": true,
  "schema:url": "https://www.parent.domain",
  "hasChildRelation": [
    {
      "relation": "isChild",
      "adminDomain": "parent.domain",
      "domain": "brand.domain",
      "schema:description": "Domain is parked for future use.",
      "status": "inactive"
    }
  ]
}

You'll notice that the snippet references both "Schema.org" and "domainrelationships.org" schemas, and it should be clear a lot more useful information can be published in the Policy Document. For now, we'll focus on the relationship declaration confirming that "parked.domain" is, in fact, an inactive, parked child of the Parent Domain. Of course additional related domains can be declared, and this simple example only illustrates the one relationship. More detail about domain policies, their semantics, syntax, and uses will be discussed elsewhere.

The swimlane diagram for the discovery exchange may then look something like:

Sequence Diagram of Parent-Child Relationship - Inference Method

Policy Reference Method

This more direct method includes, in addition to declaring the Parent Domain, the Child Domain publishing an Assertion Record identifying the URL for the relevant Policy Document published by the Parent Domain. In this case, the Relying Party retrieves and parses the relevant Policy Document without having to first query the Parent Domain for the relevant Policy Document. While adding slightly more administrative burden to the Child Domain (i.e. requiring that the Assertion Record be updated if/when the relevant Policy Document location moves), it decreases the discovery burden of the Relying Party.

Using this method, the Child Domain publishes an Assertion Record that also includes a direct link to the relevant Policy Document such as:

"domrel;childOf:parent.domain;policy=https://parent.domain/relationships.json;status=inactive;"

The retrieved Policy Doument is identical to and would look the same as the one illustrated above. This method just simplifies the path to identifying and retrieving the relevant relationship policy with the discovery exchange simplified to something like:

The Relying Party may also perform a comparison between the declared domains and where the policies are retrieved as further signal confirming the relationship. If the referenced Policy Document(s) are hosted by different domains, it may be useful for the evaluating Relying Party to build (and cache according to the stated expiration directive) a relationship graph. But that's more sophisticated than is likely to be immediately useful and is left to be discussed in more detail elsewhere.