A Method for Identifying the Administrative Boundaries of DNS Names

Two or more DNS names may have the same administrative boundaries. If they share the same DNS administrative boundaries, we regard that they have a relationship. Otherwise they have not a relationship. This document describes a method for using dbound resource record for judging domain name administrative boundaries. The Domain Name System (DNS) currently lacks a standardized method to identify administrative boundaries between domain names owned by the same entity. While multiple domains may belong to the same registrant, DNS does not natively express these relationships. The drafts list many use cases where some applications may use domain name administrative boundaries. With the growth of Internet, there should have more Internet applications which will use domain name administrative boundaries technology. As the ICANN new gTLD program has expanded, registrants frequently obtain multiple domain names serving a common purpose. Consequently, there is a need to develop a mechanism for determining when two or more domain names share administrative boundaries. This requirement is equally critical for second-level domains (SLDs) within the same top-level domain (TLD). Numerous organizations manage multiple SLDs (e.g., variant1.tld, variant2.tld, variant3.tld) that operate under unified administrative control, yet lack a DNS-native means to express this relationship.

The basic DNS terms used in this specification are defined in the documents and . The shared administrative boundaries of DNS names imply, at minimum, that such names are under the control of either the same registrant or cooperating registrants.

This section presents a mechanism to lookup of the administrative boundary between two domains. The mechanism defines a new resource record type (RRTYPE) called as Dbound to satisfy the requirements specified in the previous section. The RDATA for an Dbound RR consists of a 1 octet Flag field, a 1 octet Reserved 1 field, a 1 octet Reserved 2 field, and a Anchor Name / Name Collection field.

Flag: The Flag field identifies the usage of Anchor Name / Name Collection field.

If flag=0, the Anchor Name / Name Collection is the anchor name, and the anchor name will be the string of PSL. Through it, the DNS administrators can configure the relationship between the owner name and PSL. Those which point to the PSL will share the same DNS administrative boundaries;

If flag=1, the Anchor Name / Name Collection is the anchor name, and it means that dbound record is to try to build a connection between the owner name and the anchor name which is a FQDN. Through it, the DNS administrators can configure the relationship between the owner name and the anchor name. Those which share the same anchor name will share the same DNS administrative boundaries;

If flag=2, the Anchor Name / Name Collection is the name collection, and the Name Collection will be a collection of names which are supposed to share the same DNS boundaries under the same anchor name and will be separated by comma(,). The owner name is some names' anchor name in other dbound RR. Through it, the application can learn how many names share the same DNS boundaries under the owner name (some names' anchor name in other dbound RRs)
Reserved 1 field and Reserved 2 field: These two fields will be kept for the future use. Anchor Name / Name Collection: There are two kinds of relationship mechanism, one is controlled by PSL; the other is specified by building the connection among names.

If Flag is 0, the Anchor Name / Name Collection field will have the value of PSL;

If Flag is 1, the Anchor Name / Name Collection field will have the value of the anchor name. The anchor name acts like a middleman. All names sharing the same administrative boundaries will point to the same anchor name;

If Flag is 2, the Anchor Name / Name Collection field will have the value of name collection with names separated by comma (,).

Given two domain names A and B There are two cases where application can determin whether domain names A and B share the same administrative boundaries.

Case 1: If A and B's flag value in the dbound record are 0, application should confirm that the Anchor Name / Name Collection fields of both names have the value of PSL.

Case 2: If A and B's flag value in the dbound record are 1, application should check whether the names point to the same anchor. Algorithm 1:
1)When the application needs to know whether two names A and B share the same administrative boundary, it needs to do the following steps to confirm it.

Step 1, the application sends the query of A for dbound record to the DNS servers, and analyzes the response. If the application gets the dbound RR for A, it checks whether there is a dbound record with the flag value of 0 or 1. If the value of flag of A's dbound records is 0, go to step 2; If the value of flag of A's dbound records is 1, go to step 3; Otherwise, go to step 4;

Step 2, the application sends the query of B for dbound record to the DNS servers, and analyzes the response. If the application gets the dbound RR, it checks this RR. If the value of flag of B's dbound records is 0, check whether the value of anchor name of A and B's dbound records are PSL. If yes, it means that A and B tend to enjoy the same administrative boundaries under the PSL. Then check the PSL to confirm whether A and B enjoy the same administrative boundaries. If yes, return the response and exit. Otherwise go to step 4

Step 3, the application sends the query of B for dbound record to the DNS servers, and analyzes the response. If the application gets the dbound RR, it checks this RR. If the value of flag of B's dbound records is 1, check whether the value of anchor name of A and B's dbound records are same. If yes, it means that A and B tend to enjoy the same administrative boundaries under the same anchor name. Then check the anchor name to confirm whether A and B enjoy the same administrative boundaries. That means If yes, the application should send the query of the anchor name for dbound record to the DNS servers, and analyzes the response. If the application gets the dbound RR, it checks this RR. If the value of flag of anchor's dbound records is 2, check whether the dbound record's value include A and B in its name collection. If yes, ten return the response and exit. Otherwise go to step 4

step 4, Exit and display some error information 2)Given name A, check who shares the same administrative boundaries with A. The application sends the query of A for dbound record to the DNS servers, and analyzes the response. If the application gets the dbound RR for A, it checks whether there is a dbound record with the flag value of 2. If yes, check the value of name collection of A's dbound record, find name list, check every name on the name list with A to confirm whether they enjoy the same administrative boundaries via the method 1) which describes the case of two domain names A and B. 3)Given more names than two, check whether they shares the same administrative boundaries. The application selects one of the names as A and check whether every other name share the same administrative boundaries with A via the the method 1) which describes the case of two domain names A and B. For examples: EXAMPLE 1, if a.example and b.exmaple want to share the same DNS administrative boundaries, it can configure the following RRs:

a.example dbound 1 c.example
b.example dbound 1 c.example
c.example dbound 2 a.example,b.example

or the anchor name can also be one of the names who share the same DNS administrative boundaries:
a.example dbound 1 b.exmaple
b.example dbound 1 b.example
b.example dbound 2 a.example,b.example USAGE: if the application wants to check whether a.example and b.example share the same DNS boundaries, it find a.example and b.example share the same anchor under the flag's value of 1 under the RRs above, and verify that a.example and b.example share the same DNS boundaries.

if the application wants to check which domain names share the same DNS boundaries with a.example, it find a.example and b.example are supposed to have the same DNS boundaries under the flag's value of 2, and verify that a.example and b.example share the same DNS boundaries through checking a.example and b.example sharing the same anchor under the flag's value of 1 . EXAMPLE 2, if a.example and b.exmaple want to share the same DNS administrative boundaries under PSL, it can configure the following RRs:
a.example dbound 0 http://mxr.mozilla.org/mozilla-central/source/netwerk/dns/ effective_tld_names.dat?raw=1
b.example dbound 0 http://mxr.mozilla.org/mozilla-central/source/netwerk/dns/ effective_tld_names.dat?raw=1
USAGE: if the application wants to check whether a.example and b.example share the same dns boundaries, it find a.example and b.example share the same anchor under the flag's value of 0, and verify that a.example and b.example share the same dns boundaries via the PSL link. ADVANTAGES: This new mechanism builds a relationship through the anchor name (middleman) to avoid to construct too many pairwise relationship. It will help to reduce the RRs configuration and checking when there are many domain names which are supposed to share the same DNS boundaries.

The parent name may announce that all names under it to share the same administrative boundaries with itself, but it needs two-way assertion here. Parents can say all its children are under its control and share the same boundaries. In the other hand, the children should confirm that they share the same boundary with its parents too.

For example:
example.com dbound 1 example.com
*.example.com dbound 1 example.com
example.com dbound 2 example.com, *.example.com
It means that example.com and its children share the same administrative boundaries. In some cases, the children may lose its parent's control by configure some DNS records for themselves. The debound record has similar same limitation with the wildcard. Wildcards work for the non-configured sub-domain names only. Those names which can not queried through wildcard will not work for dbound too. Those names should configure their own dbound record separately instead of wildcard dbound configuration. For example:
If there is an A record at a.b.example.com, the wildcard will not match a.b.example.com or b.example.com. In this exmaple, quering c.example.com will work if c.example.com is not configured in some ways. If there is a A record for a.b.example.com, it indicates that the a.b.exmaple.com or b.exmaple.com might exist. so under this situation, a.b.exmaple.com or b.exmaple.com should configure their own dbound record since a.b.exmaple.com or b.exmaple.com may be out of control of the parents.

The IANA should allocate the new DNS type for DBOUND.

The template is as follows:

The introduction of the DBOUND (Domain Boundary) Resource Record (RR) to identify administrative boundaries in the DNS raises several security considerations that should be addressed. Registrars and DNS operators should ensure that DBOUND records are correctly provisioned to avoid misconfigurations that could break domain validation logic. Since DBOUND records define administrative ownership boundaries, they must be protected by DNSSEC to ensure data origin authentication and integrity. Without DNSSEC, an attacker could forge or modify DBOUND records, leading to incorrect assumptions about domain ownership.

Thanks a lot for WG discussion in dbound WG. Especially thanks for Andrew Sullivan and John R Levine's kind comments and helpful debate.

RFC Editor: Please remove this section.

draft-yao-dbound-dns-solution

A Resource Record for DNS Administrative Boundaries
This draft was creaded during the old DBOUND WG

This draft was orginally discussed in IETF dbound working group. It is one potential solution for DBOUND problem. The dbound WG closed without publishing any RFC. The WG suggested the drafts in this WG to pursue the publication through independent stream. Since the ICANN's new gTLD program is coming in 2026 and many proposed IDN TLDs are name variants, the topic about how to identify DNS Administrative Boundaries becomes very important. So the author decides to update the draft.