Network Working Group A. Brotman
Internet-Draft Comcast, Inc
Intended status: Standards Track S. Farrell
Expires: September 7, 2019 Trinity College Dublin
March 6, 2019

Related Domains By DNS


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".

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."

This Internet-Draft will expire on September 7, 2019.

Copyright Notice

Copyright (c) 2019 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents ( in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

Table of Contents

1. Introduction

[[Discussion of this draft is taking place on the 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 and 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:

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 [RFC6376] handles public keys and signatures - a public key is hosted at the relating-domain (e.g., and a reference from the related-domain (e.g., contains a signature (verifiable with the 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 and, not and (where those latter two are hosts).

There already exists Vouch By Reference (VBR) [RFC5518], 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.

1.1. Terminology

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 [RFC2119].

The following terms are used throughout this document:

2. New Resource Record Types

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).

2.1. RDBDKEY Resource Record Definition

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. [RFC4034]

[[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 [RFC7344].)

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:-)]]

2.2. RDBD Resource Record Definition

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.

                        1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   |           rdbd-tag            |                               /
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               /
   /                         relating-domain name                  /
   |    key-tag                    | sig-alg     |                 /
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                 /
   /                            signature                          /

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:

rdbd-tag=<rdbd-tag value>

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 "" but "" 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.

3. Directionality and Cardinality

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.

4. Required Signature Algorithms

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. [RFC5702]

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). [RFC8080][RFC8032]

5. Validation

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.

6. Security Considerations

6.1. Efficiacy of signatures

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.

6.3. Lookup Loops

It's conceivable that an attacker could create a loop of relationships, such as>>> or similar. This could cause a resource issue for any automated system. A system SHOULD only perform three lookups from the first domain (>>> 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.

7. IANA Considerations

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.]]

8. Acknowledgements

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.

9. Informative References

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997.
[RFC4034] Arends, R., Austein, R., Larson, M., Massey, D. and S. Rose, "Resource Records for the DNS Security Extensions", RFC 4034, DOI 10.17487/RFC4034, March 2005.
[RFC5518] Hoffman, P., Levine, J. and A. Hathcock, "Vouch By Reference", RFC 5518, DOI 10.17487/RFC5518, April 2009.
[RFC5702] Jansen, J., "Use of SHA-2 Algorithms with RSA in DNSKEY and RRSIG Resource Records for DNSSEC", RFC 5702, DOI 10.17487/RFC5702, October 2009.
[RFC6376] Crocker, D., Hansen, T. and M. Kucherawy, "DomainKeys Identified Mail (DKIM) Signatures", STD 76, RFC 6376, DOI 10.17487/RFC6376, September 2011.
[RFC7344] Kumari, W., Gudmundsson, O. and G. Barwood, "Automating DNSSEC Delegation Trust Maintenance", RFC 7344, DOI 10.17487/RFC7344, September 2014.
[RFC8032] Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital Signature Algorithm (EdDSA)", RFC 8032, DOI 10.17487/RFC8032, January 2017.
[RFC8080] Sury, O. and R. Edmonds, "Edwards-Curve Digital Security Algorithm (EdDSA) for DNSSEC", RFC 8080, DOI 10.17487/RFC8080, February 2017.

Appendix A. Examples

[[TODO: script up generation of all samples - it's not unlikely we mucked up somewhere below when generating 'em partly-manually;-)]]

A.1. Sample Unsigned RDBD RR

When is the relating-domain and is the related-domain, an unsigned RDBD RR would look like this in a zone file: IN 3600 RDBD 0

The following is equivalent to tbe above: IN 3600 RDBD 0 0 0 ""

A.2. Sample RSA Signature

Appendix C of [RFC6376] 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:

$ openssl genrsa -out rsa.private 2048
$ openssl rsa -in rsa.private -out rsa.public -pubout -outform PEM

Sample Key:

-----END PUBLIC KEY-----

To calculate the key-tag as specified in Appendix B of [RFC4034] we used python code from: <>

File containing to-be-signed data:

$ cat to-be-signed-8.txt
$ od -x to-be-signed-8.txt
0000000 6572 616c 6974 676e 653d 6178 706d 656c
0000020 632e 6d6f 720a 6c65 7461 6465 643d 7065
0000040 2d74 7865 6d61 6c70 2e65 6f63 0a6d 6472
0000060 6462 742d 6761 303d 6b0a 7965 742d 6761
0000100 363d 3435 3839 730a 6769 612d 676c 383d
0000120 000a

To sign that file:

$ openssl dgst -sha256 -sign rsa.private \
    -out rsa.sig to-be-signed-8.txt
$ od -x rsa.sig 
0000000 087c d5c9 375f dcba 9edf ce25 e353 9fb9
0000020 6ef4 ca9f a167 6d91 71bb 7487 5edd fe30
0000040 452e d104 724f f593 009b be3f 6006 ba77
0000060 c1f5 edc6 e207 7ab0 69a1 79bf 18e6 eea3
0000100 3562 6ca4 dc73 22c3 1e35 d15c 44be 5f63
0000120 ac68 f61e ea34 432d 9e12 2325 d48c 2fd9
0000140 330d 1caf 5761 6714 eed2 c7e2 4f71 2c1a
0000160 c35b e45e 833b e343 a8e2 3dbf 1a73 02a8
0000200 c686 7240 aa69 df68 a086 8e3e 2a02 ad57
0000220 32df 0e62 4679 3f4e 8afb 0716 1ad6 4300
0000240 03c6 429f 7b6e bf4d ecae d074 9158 99be
0000260 ab0e 3d49 bb42 a84a 071a b959 2d27 3eea
0000300 c9de 0781 dc5b e205 7708 e50b e485 0cdb
0000320 2fbe adee f521 3b75 9c67 66a8 d217 4f6e
0000340 90da 9423 9d8d e683 7110 4368 f70e 80a2
0000360 3a8c 25f1 3655 44a2 a585 d87d ca99 aac9

The presentation fom of a signed RDBD record (with a 3600 TTL) would be: 3600 RDBD 0 65498 8 ( 
    fPNpvg== )

The base64 encoded value for the signature can be produced using:

$ base64 -w48 rsa.sig 

To verify, with "rsa.sig" containing the above signature:

$ openssl dgst -sha256 -verify rsa.public \ 
    -signature rsa.sig to-be-signed.txt
Verified OK

The RDBDKEY RR for this example would be: 3600 RDBDKEY 0 3 8 (
    TkQgUFVCTElDIEtFWS0tLS0tCgo= )

A.3. Sample Ed25519 Signature

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 [RFC8032].

#!/usr/bin/env python3
import sys, binascii
from eddsa2 import Ed25519

# secret chosen to be 32 octets funnily enuugh:-)
privkey,pubkey = Ed25519.keygen(secret)
signature = Ed25519.sign(privkey, pubkey, msg)

print("private:"+ str(binascii.hexlify(privkey)))
print("public:"+ str(binascii.hexlify(pubkey)))
print("sig:"+ str(binascii.hexlify(signature)))
print("to-be-signed:" + str(msg))

with open("ed25519.sig", "wb") as sigf:
with open("","wb") as pubf:


The to-be-signed-15.txt file contains:

$ cat to-be-signed-15.txt

The output when the above code is run (with some spacing added) is:

$ ./ 

The presentation form for an RDBD RR would then be: 3600 RDBD 0 35988 15 (
                    ILWa+WJ4QKwxL1q1XhG+Bw== )

The RDBDKEY for this example would be: 3600 RDBDKEY 0 3 15 (
                s+yGvo01tkg= )

Appendix B. Changes and Open Issues

[[RFC editor: please delete this appendix ]]

B.1. Changes from -00 to -01

B.2. Open Issues

Current open github issues include:

These can be seen at: <>

Authors' Addresses

Alex Brotman Comcast, Inc EMail:
Stephen Farrell Trinity College Dublin EMail: