Related Domains By DNSComcast, Incalex_brotman@comcast.comTrinity College Dublinstephen.farrell@cs.tcd.ie
Applications
This document outlines a mechanism by which a registered domain can
publicly document a relationship with a different registered domain, called
"Related Domains By DNS", or "RDBD".
[[Discussion of this draft is taking place on the dbound@ietf.org mailing list.
There's a github repo for this draft at
-
issues and PRs are welcome there.]]
Determining relationships between registered domains can be one of the more difficult
investigations on the Internet. It is typical to see something such as
example.com and dept-example.com and be unsure if there is an actual
relationship between those two domains, or if one might be an attacker
attempting to impersonate the other. In some cases, anecdotal evidence from
the DNS or WHOIS/RDAP may be sufficient. However, service providers of various
kinds may err on the side of caution and treat one of the domains as
untrustworthy or abusive because it is not clear that the two domains are in
fact related. This specification provides a way for one domain to
explicitly document a relationship with another, utilizing DNS records.
Possible use cases include:
where a company has websites in different languages, and would like to
correlate their ownership more easily, consider example.de and example.ie
registered by regional offices of the same company;following an acquisition, a domain holder might want to indicate that
example.net is now related to example.com in order to make a later migration
easier;when doing Internet surveys, we should be able to provide more accurate results
if we have information as to which domains are related.It is not a goal of this specification to provide a high-level of
assurance that two domains are definitely related, nor to provide
fine-grained detail about the kind of relationship that may
exist between domains.
Using "Related Domains By DNS", or "RDBD", it is possible to
declare that two domains are related.
We include an optional digital signature mechanism that can somewhat improve the
level of assurance with which an RDBD declaration can be handled.
This mechanism is partly modelled on how DKIM handles public
keys and signatures - a public key is hosted at the relating-domain
(e.g., example.com) and a reference from the related-domain
(e.g., dept-example.com) contains a signature (verifiable with
the example.com public key) over the text representation ('A-label') of
the two domain names (plus a couple of other inputs).
RDBD is intended to demonstrate a relationship between registered
domains, not individual hostnames. That is to say that the
relationship should exist between example.com and dept-example.com,
not foo.example.com and bar.dept-example.com (where those latter
two are hosts).
There already exists Vouch By Reference (VBR) , however
this only applies to email. RDBD could be a more general purpose solution
that could be applied to other use cases, as well as for SMTP transactions.
This document describes the various options, how to
create records, and the method of validation, if the option to
use digital signatures is chosen.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in
.
The following terms are used throughout this document:
Relating-domain: this refers to the domain that is
declarating a relationship exists. (This was called the
"parent/primary" in -00).Related-domain: This refers to the domain that is
referenced by the relating-domain, such as dept-example.com.
(This was called the "secondary" in -00.)We define two new RRTYPES, an optional one for the relating-domain (RDBDKEY)
to store a public key for when signatures are in use and one for use in
related-domains (RDBD).
The RDBDKEY record is published at the apex of the relating-domain zone.
The wire and presentation format of the RDBDKEY
resource record is identical to the DNSKEY record. [[All going well, at some point we'll be able to say...]]
IANA has allocated RR code TBD for the RDBDKEY resource record via Expert
Review.
The RDBDKEY RR uses the same registries as DNSKEY for its
fields. (This follows the precedent set for CDNSKEY in .)
No special processing is performed by authoritative servers or by
resolvers, when serving or resolving. For all practical purposes,
RDBDKEY is a regular RR type.
The flags field of RDBDKEY records MUST be zero. [[Is that correct/ok? I've
no idea really:-)]]
The RDBD resource record is published at the apex of the related-domain zone.
[[All going well, at some point we'll be able to say...]]
IANA has allocated RR code TBD for the RDBD resource record via Expert
Review.
The RDBD RR is class independent.
The RDBD RR has no special Time to Live (TTL) requirements.
The wire format for an RDBD RDATA consists of a two octet rdbd-tag, the
relating-domain name, and the optional signature fields which are: a two-octet
key-tag, a one-octet signature algorithm, and the digital signature bits.
The rdbd-tag field MUST contain the value zero. Later specifications
can define new rdbd-tag values.
If an optional signture is included, the sig-alg field MUST contain
the signature algorithm used, with the same values used as would be
used in an RRSIG. The key-tag MUST match the RDBDKEY RR value for
the corresponding public key.
If the optional signature is omitted, then the presentation form of the
key-tag, sig-alg and signature fields MAY be omitted. If not omitted then the
sig-alg and key-tag fields MUST be zero and the signature field MUST be a an
empty string. [[Is that the right way to have optional fields in RRs? Not
sure.]]
The input to signing ("to-be-signed" data) is the concatenation of the
following linefeed-separated (where linefeed has the value '0x0a') lines:
The relating-domain and related-domain values MUST be the 'A-label'
representation of these names.
The trailing "." representing the DNS root MUST NOT be included in
the to-be-signed data, so a relating-domain value above might be
"example.com" but "example.com." MUST NOT be used as input to
signing.
A linefeed MUST be included after the "sig-alg" value in the
last line.
[[Presentation syntax and to-be-signed details are very liable to change.]]
See the examples in the Appendix for further details.
RDBD relationships are uni-directional. If bi-directional relationships
exist, then both domains can publish RDBD RRs and optionally sign those.
If one domain has relationships with many others, then the relevant
RDBD RRs (and RDBDKEY RRs) can be published to represent those.
Consumers of RDBD RRs MAY support signature verification. They
MUST be able to parse/process unsigned or signed RDBD RRs even if they
cannot cryptographically verify signatures.
Implementations producing RDBD RRs SHOULD support optional signing of those
and production of RDBDKEY RRs.
Implementations of this specification that support signing or verifying
signatures MUST support use of RSA with
SHA256 (sig-alg==8) with at least 2048 bit RSA keys. RSA keys SHOULD use a 2048 bit or longer modulus.
Implementations of this specification that support signing or verifying
signatures SHOULD support use of Ed25519
(sig-alg==15). A validated signature is solely meant to be additional evidence that the two domains
are related. The existence of this relationship is not meant to
state that the data from either domain should be considered as more trustworthy.
The optional signature mechanism defined here offers no
protection against an active attack if both the RDBD and
RDBDKEY values are accessed via an untrusted path.
If the RDBDKEY value has been cached, or is otherwise
known via some sufficiently secure mechanism, then the
RDBD signature does confirm that the holder of the
private key (presumably the relating-domain) considered
that the relationship with the related-domain was real
at some point in time.
RDBD does not require DNSSEC. Without DNSSEC it is possible for an
attacker to falsify DNS query responses for someone investigating a
relationship.
Conversely, an attacker could delete the response that would
normally demonstrate the relationship, causing the investigating party to
believe there is no link between the two domains.
An attacker could also replay an old RDBD value that is
actually no longer published in the DNS by the related-domain.
Deploying signed records with DNSSEC should allow for detection
of these kinds of attack.
If the relating-domain has DNSSEC deployed, but the related-domain
does not, then the optional signature can (in a sense) extend the
DNSSEC chain to cover the RDBD RR in the related-domain's zone.
If both domains have DNSSEC deployed, and if the relating-domain public key has
been cached, then the the signature mechanism provides additional protection
against active attacks involving a parent of one of the domains. Such attacks
may in any case be less likely and detectable in many scenarios as they would
be generic attacks against DNSSEC-signing (e.g. if a regisgtry injected a bogus
DS for a relating-domain into the registry's signed zone). If the
public key from the relevant RDNDKEY RRs is read from the DNS at the
same time as a related RDBD RR, then the signature mechanism provided here
may provide litle additional value over and above DNSSEC.
It's conceivable that an attacker could create a loop of relationships, such as
a.com->b.com->c.com->a.com or similar. This could cause a resource issue for
any automated system. A system SHOULD only perform three lookups from the
first domain (a.com->b.com->c.com->d.com). The related and relating-domains
SHOULD attempt to keep links direct and so that only the fewest number of
lookups are needed, but it is understood this may not always be possible.
This document introduces two new DNS RR types, RDBD and RDBDKEY. [[Codepoints
for those are not yet allocated by IANA, nor have codepoints been requested
so far.]]
[[New rdbd-tag value handling wll need to be defined if we keep
that field. Maybe something
like: 0-255: RFC required; 256-1023: reserved; 1024-2047: Private
use; 2048-65535: FCFS.]]
Thanks to all who commented on this on the dbound and other lists,
in particular to the following who provided comments that caused us
to change the draft:
Bob Harold,
John Levine,
Andrew Sullivan,
Suzanne Woolf,
and
Paul Wouters.
(We're not implying any of these fine folks actually like this
draft btw, but we did change it because of their comments:-)
Apologies to anyone we missed, just let us know and we'll add
your name here.
[[TODO: script up generation of all samples - it's not unlikely
we mucked up somewhere below when generating 'em partly-manually;-)]]
When example.com is the relating-domain and dept-example.com
is the related-domain, an unsigned RDBD RR would look like this in a zone file:
The following is equivalent to tbe above:
Appendix C of has some reference material on
how to create a set of keys for use in this type of use case. The RSA key
length is recommended to be at least 2048 bits instead of the 1024
recommended in that appendix.
Creation of keys:
Sample Key:
To calculate the key-tag as specified in Appendix B of
we used python code from: File containing to-be-signed data:
To sign that file:
The presentation fom of a signed RDBD record (with a 3600 TTL) would be:
The base64 encoded value for the signature can be produced using:
To verify, with "rsa.sig" containing the above signature:
The RDBDKEY RR for this example would be:
Since OpenSSL does not yet support Ed25519 singing via its command
line tool, we generate our example using the python script below.
This uses the python library from Appendix A of .
The to-be-signed-15.txt file contains:
The output when the above code is run (with some spacing added) is:
The presentation form for an RDBD RR would then be:
The RDBDKEY for this example would be:
[[RFC editor: please delete this appendix ]]
Changed from primary/secondary to relating/related (better suggestions
are still welcome)Moved away from abuse of TXT RRsWe now specify optional DNSSEC-like signatures (we'd be fine with moving
back to a more DKIM-like mechanism, but wanted to see how this looked)Added Ed25519 optionRe-worked and extended examplesCurrent open github issues include:
#5: specify input for signing more precisely - e.g. is there a CR or NULL or not#6: what, if anything, does rdbd for example.com mean for foo.example.com?These can be seen at: