[Docs] [txt|pdf|xml|html] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03

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


                         Related Domains By DNS
                         draft-brotman-rdbd-03

Abstract

   This document describes a mechanism by which a DNS domain can
   publicly document the existence or absence of a relationship with a
   different 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 https://datatracker.ietf.org/drafts/current/.

   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 March 21, 2020.

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
   (https://trustee.ietf.org/license-info) 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.




Brotman & Farrell        Expires March 21, 2020                 [Page 1]


Internet-Draft                    RDBD                    September 2019


Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
     1.1.  Use-Cases . . . . . . . . . . . . . . . . . . . . . . . .   3
     1.2.  Terminology . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  New Resource Record Types . . . . . . . . . . . . . . . . . .   4
     2.1.  RDBDKEY Resource Record Definition  . . . . . . . . . . .   4
     2.2.  RDBD Resource Record Definition . . . . . . . . . . . . .   5
   3.  RDBD processing . . . . . . . . . . . . . . . . . . . . . . .   7
   4.  Use-cases for Signatures  . . . . . . . . . . . . . . . . . .   8
     4.1.  Many-to-one Use-Case  . . . . . . . . . . . . . . . . . .   8
     4.2.  Extending DNSSEC  . . . . . . . . . . . . . . . . . . . .   8
   5.  Security Considerations . . . . . . . . . . . . . . . . . . .   9
     5.1.  Efficiacy of signatures . . . . . . . . . . . . . . . . .   9
     5.2.  DNSSEC  . . . . . . . . . . . . . . . . . . . . . . . . .   9
     5.3.  Lookup Loops  . . . . . . . . . . . . . . . . . . . . . .   9
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  10
   7.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  10
   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  10
     8.1.  Normative References  . . . . . . . . . . . . . . . . . .  10
     8.2.  Informative References  . . . . . . . . . . . . . . . . .  11
   Appendix A.  Implementation (and Toy Deployment:-) Status . . . .  11
   Appendix B.  Examples . . . . . . . . . . . . . . . . . . . . . .  11
   Appendix C.  Possible dig output... . . . . . . . . . . . . . . .  14
   Appendix D.  Changes and Open Issues  . . . . . . . . . . . . . .  15
     D.1.  Changes from -02 to -03 . . . . . . . . . . . . . . . . .  15
     D.2.  Changes from -01 to -02 . . . . . . . . . . . . . . . . .  16
     D.3.  Changes from -00 to -01 . . . . . . . . . . . . . . . . .  16
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  16

1.  Introduction

   Determining relationships between DNS 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 if it is not clear that the two domains are in fact related.
   This specification provides a way for one domain to explicitly
   document, or disavow, relationships with other domains, utilizing DNS
   records.

   It is not a goal of this specification to provide a high-level of
   assurance as to whether or not two domains are definitely related,
   nor to provide fine-grained detail about the kinds of relationships



Brotman & Farrell        Expires March 21, 2020                 [Page 2]


Internet-Draft                    RDBD                    September 2019


   that may exist between domains.  However, the mechanism defined here
   is extensible in a way that should allow use-cases calling for such
   declarations to be handled later.

1.1.  Use-Cases

   The use cases for this include:

   o  where an organisation has names below different ccTLDs, and would
      like to allow others to correlate their ownership more easily,
      consider "example.de" and "example.ie" registered by regional
      offices of the same company;

   o  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;

   o  when doing Internet surveys, we should be able to provide more
      accurate results if we have information as to which domains are,
      or are not, related;

   o  a domain holder may wish to declare that no relationship exists
      with some other domain, for example "good.example" may want to
      declare that it is not associated with "g00d.example" if the
      latter is currently being used in some cousin-domain style attack
      in which case, it is more likely that there can be a larger list
      of names (compared to the "positive" use-cases) for which there is
      a desire to disavow a relationship.

   [[Discussion of this draft is taking place on the dnsop@ietf.org
   mailing list.  Previously, discussion was on the dbound@ietf.org
   list.  There's a github repo for this draft at
   <https://github.com/abrotman/related-domains-by-dns> - issues and PRs
   are welcome there.]]

1.2.  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:

   o  Relating-domain: this refers to the domain that is declarating a
      relationship exists.  (This was called the "parent/primary" in
      -00).




Brotman & Farrell        Expires March 21, 2020                 [Page 3]


Internet-Draft                    RDBD                    September 2019


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

2.  New Resource Record Types

   We define a resource record type (RDBD) that can declare, or disavow,
   a relationship.  RDBD also includes 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.,
   "club.example.com"), using an RDBDKEY resource record, and the RDBD
   record of the Related-domain (e.g., "member.example.com") can contain
   a signature (verifiable with the "club.example.com" public key) over
   the text representation ('A-label') of the two names (plus a couple
   of other inputs).

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.  [[In the meantime we're experimenting using 0xffa8, which is
   decimal 65448, from the experimental RR code range, for the RDBDKEY
   resource record.]]

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

   There can be multiple occurrences of the RDBDKEY resource record in
   the same zone.







Brotman & Farrell        Expires March 21, 2020                 [Page 4]


Internet-Draft                    RDBD                    September 2019


2.2.  RDBD Resource Record Definition

   To declare a relationship exists an RDBD resource record is published
   at the apex of the Related-domain zone.

   To disavow a relationship an RDBD resource record is published at the
   apex of the Relating-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.
   [[In the meantime we're experimenting using 0xffa3, which is decimal
   65443, from the experimental RR code range, for the RDBD resource
   record.]]

   The RDBD RR is class independent.

   The RDBD RR has no special Time to Live (TTL) requirements.

   There can be multiple occurrences of the RDBD resource record in the
   same zone.

   RDBD relationships are uni-directional.  If bi-directional
   relationships exist, then both domains can publish RDBD RRs and
   optionally sign those.

   The wire format for an RDBD RDATA consists of a two octet rdbd-tag, a
   domain name or URL, 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            |                               /
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               /
      /                        domain name or URL                     /
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+-+|
      |    key-tag                    | sig-alg     |                 /
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                 /
      /                            signature                          /
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   We define two possible values for the rdbd-tag in this specification,
   later specifications can define new rdbd-tag values:

   o  0: states that no relationship exists between the domains

   o  1: states that some relationship exists between the domains



Brotman & Farrell        Expires March 21, 2020                 [Page 5]


Internet-Draft                    RDBD                    September 2019


   The domain name field contains either a single domain name, or an
   HTTPS URL.  In the latter case, successfully de-referencing that URL
   is expected to result in a JSON object that contains a list of domain
   names, such as is shown in the figure below.


                              [
                                  "example.com",
                                  "example.net",
                                  "foo.example"
                              ]


   If an optional signature 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, and is calculated as defined in
   [RFC4034] appendix B.

   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 prsentation syntax for RRs?]]

   The input to signing ("to-be-signed" data) is the concatenation of
   the following linefeed-separated (where linefeed has the value
   '0x0a') lines:

                   relating=<Relating-domain name>
                   related=<Related-domain name or URL>
                   rdbd-tag=<rdbd-tag value>
                   key-tag=<key-tag>
                   sig-alg=<sig-alg>


   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.

   The rdbd-tag and key-tag and sig-alg fields MUST be in decimal with
   leading zeros omitted.

   A linefeed MUST be included after the "sig-alg" value in the last
   line.




Brotman & Farrell        Expires March 21, 2020                 [Page 6]


Internet-Draft                    RDBD                    September 2019


   [[Presentation syntax and to-be-signed details are very liable to
   change.]]

   See the examples in the Appendix for further details.

3.  RDBD processing

   o  If multiple RDBD records exist with conflicting "rdbd-tag" values,
      those RDBD records SHOULD be ignored.

   o  If an RDBD record has an invalid or undocumented "rdbd-tag", that
      RDBD record SHOULD be ignored.

   o  The document being referenced by a URL within an RDBD record MUST
      be a well-formed JSON [RFC8259] document.  If the document does
      not validate as a JSON document, the contents of the document
      SHOULD be ignored.  There is no defined maximum size for these
      documents, but a referring site ought be considerate of the
      retrieving entity's resources.

   o  When retrieving the document via HTTPS, the certificate presented
      MUST properly validate.  If the certificate fails to validate, the
      retreiving entity SHOULD ignore the contents of the file located
      at that resource.

   o  Normal HTTP processing rules apply when de-referencing a URL found
      in an RDBD record, for example, a site may employ HTTP
      redirection.

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

   o  Implementations producing RDBD RRs SHOULD support optional signing
      of those and production of RDBDKEY RRs.

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

   o  RSA keys MUST use a 2048 bit or longer modulus.

   o  Implementations of this specification that support signing or
      verifying signatures SHOULD support use of Ed25519 (sig-alg==15).
      [RFC8080][RFC8032]






Brotman & Farrell        Expires March 21, 2020                 [Page 7]


Internet-Draft                    RDBD                    September 2019


   o  A validated signature is solely meant to be additional evidence
      that the relevant domains are related, or that one disavows such a
      relationship.

4.  Use-cases for Signatures

   [[The signature mechanism is pretty complex, relative to anything
   else here, so it might be considered as an at-risk feature.]]

   We see two possibly interesting use-cases for the signature mechanism
   defined here.  They are not mutually exclusive.

4.1.  Many-to-one Use-Case

   If a bi-directional relationship exists between one Relating-domain
   and many Related-domains and the signature scheme is not used, then
   making the many required changes to the Relating-domain zone could be
   onerous.  Instead, the signature mechanism allows one to publish a
   stable value (the RDBDKEY) once in the Relating-domain.  Each
   Related-domain can then also publish a stable value (the RDBD RR with
   a signature) where the signature provides confirmation that both
   domains are involved in declaraing the relationship.

   This scenario also makes sense if the relationship (represented by
   the rdbd-tag) between the domains is inherently directional, for
   example, if the relationship between the Related-domains and
   Relating-domain is akin to a membership relationship.

4.2.  Extending DNSSEC

   If the Relating-domain and Related-domain zones are both DNSSEC-
   signed, then the signature mechanism defined here adds almost no
   value and so is unlikely to be worth deploying in that it provides no
   additional cryptorgraphic security (though the many-to-one advantage
   could still apply).  If neither zone is DNSSEC-signed, then again,
   there may be little value in deploying RDBD signatures.

   The minimal value that remains in either such case, is that if a
   client has acquired and cached RDBDKEY values in some secure manner,
   then the RDBD signatures do offer some benefit.  However, at this
   point it seems fairly unlikely that RDBDKEY values will be acquired
   and cached via some secure out-of-band mechanisms, so we do not
   expect much deployment of RDBD signatures in either the full-DNSSEC
   or no-DNSSEC cases.

   However, where the Relating-domain's zone is DNSSEC-signed, but the
   Related-domain's zone is not DNSSEC signed, then the RDBD signatures




Brotman & Farrell        Expires March 21, 2020                 [Page 8]


Internet-Draft                    RDBD                    September 2019


   do provide value, in essence by extending DNSSEC "sideways" to the
   Related-domain.  The figure below illustrates this situation.


            +-----------------+
            | Relating-domain |
            | (DNSSEC-signed) |         +---------------------+
            | RDBDKEY-1       |<----+   + Related-domain      |
            +-----------------+     |   | (NOT DNSSEC-signed) |
                                    +---+ RDBD RR with SIG    |
                                        +---------------------+

              Extending DNSSEC use-case for RDBD signatures


5.  Security Considerations

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

5.2.  DNSSEC

   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.

5.3.  Lookup Loops

   A bad actor could create a loop of relationships, such as
   a.example->b.example->c.example->a.example or similar.  Automated
   systems SHOULD protect against such loops.  For example, only
   performing a configured number of lookups from the first domain.
   Publishers of RDBD records 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.






Brotman & Farrell        Expires March 21, 2020                 [Page 9]


Internet-Draft                    RDBD                    September 2019


6.  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 will 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.  It will also
   likely be useful to define a string representation for each
   registered rdbd-tag value, e.g.  perhaps "UNRELATED" for rdbd-tag
   value 0, and "RELATED" for rdbd-tag value 1, so that tools displaying
   RDBD information can be consistent.]]

7.  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, Pete Resnick, Andrew
   Sullivan, Tim Wisinski, Suzanne Woolf, Joe St. Sauver, 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.

8.  References

8.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

   [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,
              <https://www.rfc-editor.org/info/rfc4034>.

   [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,
              <https://www.rfc-editor.org/info/rfc5702>.

   [RFC8032]  Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital
              Signature Algorithm (EdDSA)", RFC 8032,
              DOI 10.17487/RFC8032, January 2017,
              <https://www.rfc-editor.org/info/rfc8032>.



Brotman & Farrell        Expires March 21, 2020                [Page 10]


Internet-Draft                    RDBD                    September 2019


   [RFC8080]  Sury, O. and R. Edmonds, "Edwards-Curve Digital Security
              Algorithm (EdDSA) for DNSSEC", RFC 8080,
              DOI 10.17487/RFC8080, February 2017,
              <https://www.rfc-editor.org/info/rfc8080>.

   [RFC8259]  Bray, T., Ed., "The JavaScript Object Notation (JSON) Data
              Interchange Format", STD 90, RFC 8259,
              DOI 10.17487/RFC8259, December 2017,
              <https://www.rfc-editor.org/info/rfc8259>.

8.2.  Informative References

   [RFC6376]  Crocker, D., Ed., Hansen, T., Ed., and M. Kucherawy, Ed.,
              "DomainKeys Identified Mail (DKIM) Signatures", STD 76,
              RFC 6376, DOI 10.17487/RFC6376, September 2011,
              <https://www.rfc-editor.org/info/rfc6376>.

   [RFC7344]  Kumari, W., Gudmundsson, O., and G. Barwood, "Automating
              DNSSEC Delegation Trust Maintenance", RFC 7344,
              DOI 10.17487/RFC7344, September 2014,
              <https://www.rfc-editor.org/info/rfc7344>.

Appendix A.  Implementation (and Toy Deployment:-) Status

   [[Note to RFC-editor: according to RFC 7942, sections such as this
   one ought not be part of the final RFC.  We still dislike that idea,
   but whatever;-)]]

   We are not aware of any independent implementations so far.  One of
   the authors has a github repo at <https://github.com/sftcd/rdbd-
   deebeedeerrr> with scripts that allow one to produce zone file
   fragments and signatures for a set of domains.  There is also a
   wrapper script for the dig tool that provides a nicer view of RDBD
   and RDBDKEY records, and that verifies signatures.  See the README
   there for details.

   In terms of deployments, we used the above for a "toy" deployment in
   the tolerantnetworks.ie domain and other related domains that one can
   determine by following the relevant trail:-)

Appendix B.  Examples

   These examples have been generated using the proof-of-concept
   implementation mentioned above.  These are intended for interop, not
   for beauty:-) The dig wrapper script referred to above produces more
   readable output, shown further below..

   The following names and other values are used in these examples.



Brotman & Farrell        Expires March 21, 2020                [Page 11]


Internet-Draft                    RDBD                    September 2019


   o  Relating domain: my.example

   o  Related domain: my-way.example

   o  Unrelated domain: my-bad.example

   o  URL for other related domains: <https://my.example/related-names>

   o  URL for other unrelaed domains: <https://my.example/unrelateds>

   my.example zone file fragments:


        my.example.     3600 IN TYPE65448 \# 298 (
                     0000030830820122300d06092a864886f70d010101050
                     00382010f003082010a0282010100bb3b09979b3c4e61
                     0f231dafbd8295d5b6d9475eba8df1cff49b08b99a768
                     15e660c243b8ce7175cc9857be00847cff865ca81e56a
                     f0ec1813a43787902e8b2560b64016c4c8e64262b7b8e
                     ae2e6f735e1186237fff49110227b69fbcefa1cfddf7f
                     df052f250871bb03be114493a8e29a95d04b50b9e99b5
                     8e40e70381384c159d02d781e6837791c2ead0c547e7f
                     fb0aa198b2aef259c42273a69af4f22c7439972d3052d
                     4a581895e203115963689044b4cbbdb6cf90ff1866630
                     593aad625772e6f540bd93801c5781fdd74481fbb6399
                     f745b4525c767e3fb4a4d919e265d541f6bee95d0b9e1
                     15bd4749a3a9748e2d8745466629fa6682d36e83cbae8
                     30203010001
                     )
        my.example.     3600 IN TYPE65443 \# 85 (
                     0001066d792d776179076578616d706c650039820f039
                     b08e9d5a8e057a87c6e7ddb92a680b7a2e69baef46404
                     b3bc9fcd93f4fe261bda56c107dba2d672255a86a771f
                     cc3eca0f12cdd1b302f20b2234de8610e03
                     )
        my.example.     3600 IN TYPE65443 \# 18 (
                     0000066d792d626164076578616d706c6500
                     )
        my.example.     3600 IN TYPE65443 \# 39 (
                     00012368747470733a2f2f6d792d7761792e6578616d7
                     06c652f6d7973747566662e6a736f6e00
                     )
        my.example.     3600 IN TYPE65443 \# 42 (
                     00002668747470733a2f2f6d792d7761792e6578616d7
                     06c652f6e6f746d7973747566662e6a736f6e00
                     )





Brotman & Farrell        Expires March 21, 2020                [Page 12]


Internet-Draft                    RDBD                    September 2019


   my.example private key:


     -----BEGIN RSA PRIVATE KEY-----
     MIIEpAIBAAKCAQEAuzsJl5s8TmEPIx2vvYKV1bbZR166jfHP9JsIuZp2gV5mDCQ7
     jOcXXMmFe+AIR8/4ZcqB5Wrw7BgTpDeHkC6LJWC2QBbEyOZCYre46uLm9zXhGGI3
     //SRECJ7afvO+hz933/fBS8lCHG7A74RRJOo4pqV0EtQuembWOQOcDgThMFZ0C14
     Hmg3eRwurQxUfn/7CqGYsq7yWcQic6aa9PIsdDmXLTBS1KWBiV4gMRWWNokES0y7
     22z5D/GGZjBZOq1iV3Lm9UC9k4AcV4H910SB+7Y5n3RbRSXHZ+P7Sk2RniZdVB9r
     7pXQueEVvUdJo6l0ji2HRUZmKfpmgtNug8uugwIDAQABAoIBAF1sJuwkBGJjocb2
     4CLijtsVorMu/E0pdIdr+F2MSkdhD/BM//3drVWaJGXcMqWKizpXYptT0iUsGljd
     cGIsJzgeWrH96nEIG+XgIH/rei2uD8Q39hNcOCnh2szWXb+FSdQEnQacMJFXFmbW
     pw0d1K5FTi2h9wTdIKupF988y9h4OzVkW9qIDqOzKAKnxoyYZ0xiglaUq6NeHRs2
     Sv7ow5CErKm4ZDqvtcqxs+uWblm3i5LsPGKexDZfXDQqle7hjFbXKUw+ZREF8hzc
     bCfa3A5Xyo7nLdgGR2DOZlzOQA+iz5Cnpb35gdOV+giptlwndrn8Lc8U1Zf1f47T
     aOxh2YECgYEA4u/VQ2B4Ux4NNX8g3womc/rJZOMWVxkd8odRhBy4s0c+atGy3ztp
     SOprBQrkjcFE831b596MOE11y1GpmKK7q5nI2IcMuStnLoj27a95QVznswnbyA6a
     g3cIAz/lOHCexLzi8edjcwTxJv1XNE9518SbkU0EbW2OY5jZsHU4I0MCgYEA0zVt
     m3PrU5/JW1GqmRhDa7PyfB9ESq5mIXIaT6mPh0XLryMn2uUmFBMC3iuxNayjQgzI
     Gg3XVClcb4vvrVDrkxY5aTDmizvVvF0MletBiLYjCwWHsOGql4hxwhvENYcYvCjs
     T0WShG8FuuuHaH371+2hBkREeLHQRlyh0om2c8ECgYEA4JCb5PSNnRJb19hZWtzc
     eGBu8lqVPNMqA1lMnQMe8qlJZsLj0mskIHd4N6Ez0eKyrJAcZjKfZwefzPaecOB3
     /bNMQJhDSulcTXxTfZjq0HdzAIR87FcnJ3iegTi1R0iKk/ymRuLGUodNa1u+85DB
     7XYsy3f/LZoAESasJCWay6kCgYAyGpuc5BvwY5iF5FK/LMVZuH+OuHAf801hI8tg
     GI5m/cS7EHD0+aVV38ivYdgRLpowIg4aOCxb19AI2j6KdAbehsgpzyLx5sjmfYBt
     1DhgsSyRAcfVy0MH3aN289VRCXJxuJeOmqeOaTQHyrX9sN1ctQ+dB/biVvRcrL7q
     ziaNQQKBgQC9MECoVH/bYJVY6RoC5ZYAa6A4CYDhaXnw40lQ90ckSgWr3FenV7gw
     b2xg7zLOX2HZZ+6HejMNGC/efZKVN2Okkpe4KGOXcDH3pYrrkLsLCNRXzxBsyOIt
     e3e1kAriqiXcr3sPBbn7nakUa7G23O7Hb31C0KGMyf9znN+qWda+3g==
     -----END RSA PRIVATE KEY-----


   my-way.example zone file fragments:


















Brotman & Farrell        Expires March 21, 2020                [Page 13]


Internet-Draft                    RDBD                    September 2019


        my-way.example. 3600 IN TYPE65448 \# 36 (
                     0000030f6d5a2d3caf0d740e139d36a0e52325c4e078e
                     7623f19be3b872367dc8027ef42
                     )
        my-way.example. 3600 IN TYPE65443 \# 273 (
                     0001026d79076578616d706c65003e6c088d887950e26
                     305a59bbe63263b65d34e11656968497500cbef7af12b
                     e14d173d7368e24da54258c851456d3c2d94437692879
                     d1d2b5d3f0acf1e3de6ebb345f8c31f209af6fd7f2731
                     3804fc79db421231126e3e42115ce51a81d2619ed221a
                     fea2b64d1d9ffbef0bd4786fbe5f42c75951ae645078d
                     b7a5a88ed3173d4a209734f49a23a0920ce38ed44011d
                     784e47cf7658cc313cf01349c80b936b17fca3542f32a
                     ff956e808c2520736a917df648e4e5f2eea5de994ce90
                     dba6d5051a4e0934da4a9f6ff01ef5df98d3b4da52b12
                     ea3b8e7ebabcf6d7a0a170dc1284753e3e6b039f8a32c
                     e707312ea5b02180072b517a6056db6e47f8dd5240ab1
                     874646
                     )


   my-way.example private key:


              0000000 5f24 3132 daa0 4cc4 0a77 4cb6 e834 16db
              0000020 05b0 faf7 ca27 16b6 0ae7 e177 d3f9 db5f
              0000040


Appendix C.  Possible dig output...

   Below we show the output that a modified dig tool might display for
   the my.example assertions above.


















Brotman & Farrell        Expires March 21, 2020                [Page 14]


Internet-Draft                    RDBD                    September 2019


 $ dig RDBD my.example

 ; <<>> DiG 9.11.5-P1-1ubuntu2.5-Ubuntu <<>> RDBD my.example
 ;; global options: +cmd
 ;; Got answer:
 ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 4289
 ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 5, AUTHORITY: 0, ADDITIONAL: 1

 ;; OPT PSEUDOSECTION:
 ; EDNS: version: 0, flags:; udp: 4096
 ; COOKIE: e69085d4b9a18cca63ae96035d7bc0aa96580e0d6255c122 (good)
 ;; QUESTION SECTION:
 ;my.example. IN RDBD

 ;; ANSWER SECTION:
 my.example. 3600 IN RDBD RELATED may-way.example Sig: good
                            KeyId: 50885 Alg: 15 Sig: UIi04agb...
 my.example. 3600 IN RDBD UNRELATED my-bad.example
 my.example. 3600 IN RDBD RELATED https://my-way.example/mystuff.json
 my.example. 3600 IN RDBD UNRELATED https://my-way.example/notmine.json

 ;; Query time: 721 msec
 ;; SERVER: 127.0.0.1#53(127.0.0.1)
 ;; WHEN: Fri Sep 13 17:15:38 IST 2019
 ;; MSG SIZE rcvd: 600



Appendix D.  Changes and Open Issues

   [[RFC editor: please delete this appendix ]]

D.1.  Changes from -02 to -03

   o  Incorporated feedback/comments from IETF-105

   o  Suggest list dicussion move to dnsop@ietf.org

   o  Adopted some experimental RRCODE values

   o  Fixed normative vs. informative refs

   o  Changed the examples to use the PoC implementation.

   o  Restructured text a lot






Brotman & Farrell        Expires March 21, 2020                [Page 15]


Internet-Draft                    RDBD                    September 2019


D.2.  Changes from -01 to -02

   o  Added negative assertions based on IETF104 feedback

   o  Added URL option based on IETF104 feedback

   o  Made sample generation script

   o  Typo fixes etc.

D.3.  Changes from -00 to -01

   o  Changed from primary/secondary to relating/related (better
      suggestions are still welcome)

   o  Moved away from abuse of TXT RRs

   o  We 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)

   o  Added Ed25519 option

   o  Re-worked and extended examples

Authors' Addresses

   Alex Brotman
   Comcast, Inc

   Email: alex_brotman@comcast.com


   Stephen Farrell
   Trinity College Dublin

   Email: stephen.farrell@cs.tcd.ie














Brotman & Farrell        Expires March 21, 2020                [Page 16]


Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/