idnits 2.17.1 draft-brotman-rdbd-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (September 18, 2019) is 1682 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Downref: Normative reference to an Informational RFC: RFC 8032 Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group A. Brotman 3 Internet-Draft Comcast, Inc 4 Intended status: Standards Track S. Farrell 5 Expires: March 21, 2020 Trinity College Dublin 6 September 18, 2019 8 Related Domains By DNS 9 draft-brotman-rdbd-03 11 Abstract 13 This document describes a mechanism by which a DNS domain can 14 publicly document the existence or absence of a relationship with a 15 different domain, called "Related Domains By DNS", or "RDBD." 17 Status of This Memo 19 This Internet-Draft is submitted in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF). Note that other groups may also distribute 24 working documents as Internet-Drafts. The list of current Internet- 25 Drafts is at https://datatracker.ietf.org/drafts/current/. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 This Internet-Draft will expire on March 21, 2020. 34 Copyright Notice 36 Copyright (c) 2019 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (https://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. Code Components extracted from this document must 45 include Simplified BSD License text as described in Section 4.e of 46 the Trust Legal Provisions and are provided without warranty as 47 described in the Simplified BSD License. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 52 1.1. Use-Cases . . . . . . . . . . . . . . . . . . . . . . . . 3 53 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 54 2. New Resource Record Types . . . . . . . . . . . . . . . . . . 4 55 2.1. RDBDKEY Resource Record Definition . . . . . . . . . . . 4 56 2.2. RDBD Resource Record Definition . . . . . . . . . . . . . 5 57 3. RDBD processing . . . . . . . . . . . . . . . . . . . . . . . 7 58 4. Use-cases for Signatures . . . . . . . . . . . . . . . . . . 8 59 4.1. Many-to-one Use-Case . . . . . . . . . . . . . . . . . . 8 60 4.2. Extending DNSSEC . . . . . . . . . . . . . . . . . . . . 8 61 5. Security Considerations . . . . . . . . . . . . . . . . . . . 9 62 5.1. Efficiacy of signatures . . . . . . . . . . . . . . . . . 9 63 5.2. DNSSEC . . . . . . . . . . . . . . . . . . . . . . . . . 9 64 5.3. Lookup Loops . . . . . . . . . . . . . . . . . . . . . . 9 65 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 66 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 67 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 68 8.1. Normative References . . . . . . . . . . . . . . . . . . 10 69 8.2. Informative References . . . . . . . . . . . . . . . . . 11 70 Appendix A. Implementation (and Toy Deployment:-) Status . . . . 11 71 Appendix B. Examples . . . . . . . . . . . . . . . . . . . . . . 11 72 Appendix C. Possible dig output... . . . . . . . . . . . . . . . 14 73 Appendix D. Changes and Open Issues . . . . . . . . . . . . . . 15 74 D.1. Changes from -02 to -03 . . . . . . . . . . . . . . . . . 15 75 D.2. Changes from -01 to -02 . . . . . . . . . . . . . . . . . 16 76 D.3. Changes from -00 to -01 . . . . . . . . . . . . . . . . . 16 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 79 1. Introduction 81 Determining relationships between DNS domains can be one of the more 82 difficult investigations on the Internet. It is typical to see 83 something such as "example.com" and "dept-example.com" and be unsure 84 if there is an actual relationship between those two domains, or if 85 one might be an attacker attempting to impersonate the other. In 86 some cases, anecdotal evidence from the DNS or WHOIS/RDAP may be 87 sufficient. However, service providers of various kinds may err on 88 the side of caution and treat one of the domains as untrustworthy or 89 abusive if it is not clear that the two domains are in fact related. 90 This specification provides a way for one domain to explicitly 91 document, or disavow, relationships with other domains, utilizing DNS 92 records. 94 It is not a goal of this specification to provide a high-level of 95 assurance as to whether or not two domains are definitely related, 96 nor to provide fine-grained detail about the kinds of relationships 97 that may exist between domains. However, the mechanism defined here 98 is extensible in a way that should allow use-cases calling for such 99 declarations to be handled later. 101 1.1. Use-Cases 103 The use cases for this include: 105 o where an organisation has names below different ccTLDs, and would 106 like to allow others to correlate their ownership more easily, 107 consider "example.de" and "example.ie" registered by regional 108 offices of the same company; 110 o following an acquisition, a domain holder might want to indicate 111 that example.net is now related to example.com in order to make a 112 later migration easier; 114 o when doing Internet surveys, we should be able to provide more 115 accurate results if we have information as to which domains are, 116 or are not, related; 118 o a domain holder may wish to declare that no relationship exists 119 with some other domain, for example "good.example" may want to 120 declare that it is not associated with "g00d.example" if the 121 latter is currently being used in some cousin-domain style attack 122 in which case, it is more likely that there can be a larger list 123 of names (compared to the "positive" use-cases) for which there is 124 a desire to disavow a relationship. 126 [[Discussion of this draft is taking place on the dnsop@ietf.org 127 mailing list. Previously, discussion was on the dbound@ietf.org 128 list. There's a github repo for this draft at 129 - issues and PRs 130 are welcome there.]] 132 1.2. Terminology 134 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 135 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 136 "OPTIONAL" in this document are to be interpreted as described in 137 [RFC2119]. 139 The following terms are used throughout this document: 141 o Relating-domain: this refers to the domain that is declarating a 142 relationship exists. (This was called the "parent/primary" in 143 -00). 145 o Related-domain: This refers to the domain that is referenced by 146 the Relating-domain, such as "dept-example.com". (This was called 147 the "secondary" in -00.) 149 2. New Resource Record Types 151 We define a resource record type (RDBD) that can declare, or disavow, 152 a relationship. RDBD also includes an optional digital signature 153 mechanism that can somewhat improve the level of assurance with which 154 an RDBD declaration can be handled. This mechanism is partly 155 modelled on how DKIM [RFC6376] handles public keys and signatures - a 156 public key is hosted at the Relating-domain (e.g., 157 "club.example.com"), using an RDBDKEY resource record, and the RDBD 158 record of the Related-domain (e.g., "member.example.com") can contain 159 a signature (verifiable with the "club.example.com" public key) over 160 the text representation ('A-label') of the two names (plus a couple 161 of other inputs). 163 2.1. RDBDKEY Resource Record Definition 165 The RDBDKEY record is published at the apex of the Relating-domain 166 zone. 168 The wire and presentation format of the RDBDKEY resource record is 169 identical to the DNSKEY record. [RFC4034] 171 [[All going well, at some point we'll be able to say...]] IANA has 172 allocated RR code TBD for the RDBDKEY resource record via Expert 173 Review. [[In the meantime we're experimenting using 0xffa8, which is 174 decimal 65448, from the experimental RR code range, for the RDBDKEY 175 resource record.]] 177 The RDBDKEY RR uses the same registries as DNSKEY for its fields. 178 (This follows the precedent set for CDNSKEY in [RFC7344].) 180 No special processing is performed by authoritative servers or by 181 resolvers, when serving or resolving. For all practical purposes, 182 RDBDKEY is a regular RR type. 184 The flags field of RDBDKEY records MUST be zero. [[Is that correct/ 185 ok?]] 187 There can be multiple occurrences of the RDBDKEY resource record in 188 the same zone. 190 2.2. RDBD Resource Record Definition 192 To declare a relationship exists an RDBD resource record is published 193 at the apex of the Related-domain zone. 195 To disavow a relationship an RDBD resource record is published at the 196 apex of the Relating-domain zone. 198 [[All going well, at some point we'll be able to say...]] IANA has 199 allocated RR code TBD for the RDBD resource record via Expert Review. 200 [[In the meantime we're experimenting using 0xffa3, which is decimal 201 65443, from the experimental RR code range, for the RDBD resource 202 record.]] 204 The RDBD RR is class independent. 206 The RDBD RR has no special Time to Live (TTL) requirements. 208 There can be multiple occurrences of the RDBD resource record in the 209 same zone. 211 RDBD relationships are uni-directional. If bi-directional 212 relationships exist, then both domains can publish RDBD RRs and 213 optionally sign those. 215 The wire format for an RDBD RDATA consists of a two octet rdbd-tag, a 216 domain name or URL, and the optional signature fields which are: a 217 two-octet key-tag, a one-octet signature algorithm, and the digital 218 signature bits. 220 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 221 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 222 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 223 | rdbd-tag | / 224 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / 225 / domain name or URL / 226 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+-+| 227 | key-tag | sig-alg | / 228 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / 229 / signature / 230 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 232 We define two possible values for the rdbd-tag in this specification, 233 later specifications can define new rdbd-tag values: 235 o 0: states that no relationship exists between the domains 237 o 1: states that some relationship exists between the domains 238 The domain name field contains either a single domain name, or an 239 HTTPS URL. In the latter case, successfully de-referencing that URL 240 is expected to result in a JSON object that contains a list of domain 241 names, such as is shown in the figure below. 243 [ 244 "example.com", 245 "example.net", 246 "foo.example" 247 ] 249 If an optional signature is included, the sig-alg field MUST contain 250 the signature algorithm used, with the same values used as would be 251 used in an RRSIG. The key-tag MUST match the RDBDKEY RR value for 252 the corresponding public key, and is calculated as defined in 253 [RFC4034] appendix B. 255 If the optional signature is omitted, then the presentation form of 256 the key-tag, sig-alg and signature fields MAY be omitted. If not 257 omitted then the sig-alg and key-tag fields MUST be zero and the 258 signature field MUST be a an empty string. [[Is that the right way 259 to have optional fields in prsentation syntax for RRs?]] 261 The input to signing ("to-be-signed" data) is the concatenation of 262 the following linefeed-separated (where linefeed has the value 263 '0x0a') lines: 265 relating= 266 related= 267 rdbd-tag= 268 key-tag= 269 sig-alg= 271 The Relating-domain and Related-domain values MUST be the 'A-label' 272 representation of these names. The trailing "." representing the DNS 273 root MUST NOT be included in the to-be-signed data, so a Relating- 274 domain value above might be "example.com" but "example.com." MUST 275 NOT be used as input to signing. 277 The rdbd-tag and key-tag and sig-alg fields MUST be in decimal with 278 leading zeros omitted. 280 A linefeed MUST be included after the "sig-alg" value in the last 281 line. 283 [[Presentation syntax and to-be-signed details are very liable to 284 change.]] 286 See the examples in the Appendix for further details. 288 3. RDBD processing 290 o If multiple RDBD records exist with conflicting "rdbd-tag" values, 291 those RDBD records SHOULD be ignored. 293 o If an RDBD record has an invalid or undocumented "rdbd-tag", that 294 RDBD record SHOULD be ignored. 296 o The document being referenced by a URL within an RDBD record MUST 297 be a well-formed JSON [RFC8259] document. If the document does 298 not validate as a JSON document, the contents of the document 299 SHOULD be ignored. There is no defined maximum size for these 300 documents, but a referring site ought be considerate of the 301 retrieving entity's resources. 303 o When retrieving the document via HTTPS, the certificate presented 304 MUST properly validate. If the certificate fails to validate, the 305 retreiving entity SHOULD ignore the contents of the file located 306 at that resource. 308 o Normal HTTP processing rules apply when de-referencing a URL found 309 in an RDBD record, for example, a site may employ HTTP 310 redirection. 312 o Consumers of RDBD RRs MAY support signature verification. They 313 MUST be able to parse/process unsigned or signed RDBD RRs even if 314 they cannot cryptographically verify signatures. 316 o Implementations producing RDBD RRs SHOULD support optional signing 317 of those and production of RDBDKEY RRs. 319 o Implementations of this specification that support signing or 320 verifying signatures MUST support use of RSA with SHA256 (sig- 321 alg==8) with at least 2048 bit RSA keys. [RFC5702] 323 o RSA keys MUST use a 2048 bit or longer modulus. 325 o Implementations of this specification that support signing or 326 verifying signatures SHOULD support use of Ed25519 (sig-alg==15). 327 [RFC8080][RFC8032] 329 o A validated signature is solely meant to be additional evidence 330 that the relevant domains are related, or that one disavows such a 331 relationship. 333 4. Use-cases for Signatures 335 [[The signature mechanism is pretty complex, relative to anything 336 else here, so it might be considered as an at-risk feature.]] 338 We see two possibly interesting use-cases for the signature mechanism 339 defined here. They are not mutually exclusive. 341 4.1. Many-to-one Use-Case 343 If a bi-directional relationship exists between one Relating-domain 344 and many Related-domains and the signature scheme is not used, then 345 making the many required changes to the Relating-domain zone could be 346 onerous. Instead, the signature mechanism allows one to publish a 347 stable value (the RDBDKEY) once in the Relating-domain. Each 348 Related-domain can then also publish a stable value (the RDBD RR with 349 a signature) where the signature provides confirmation that both 350 domains are involved in declaraing the relationship. 352 This scenario also makes sense if the relationship (represented by 353 the rdbd-tag) between the domains is inherently directional, for 354 example, if the relationship between the Related-domains and 355 Relating-domain is akin to a membership relationship. 357 4.2. Extending DNSSEC 359 If the Relating-domain and Related-domain zones are both DNSSEC- 360 signed, then the signature mechanism defined here adds almost no 361 value and so is unlikely to be worth deploying in that it provides no 362 additional cryptorgraphic security (though the many-to-one advantage 363 could still apply). If neither zone is DNSSEC-signed, then again, 364 there may be little value in deploying RDBD signatures. 366 The minimal value that remains in either such case, is that if a 367 client has acquired and cached RDBDKEY values in some secure manner, 368 then the RDBD signatures do offer some benefit. However, at this 369 point it seems fairly unlikely that RDBDKEY values will be acquired 370 and cached via some secure out-of-band mechanisms, so we do not 371 expect much deployment of RDBD signatures in either the full-DNSSEC 372 or no-DNSSEC cases. 374 However, where the Relating-domain's zone is DNSSEC-signed, but the 375 Related-domain's zone is not DNSSEC signed, then the RDBD signatures 376 do provide value, in essence by extending DNSSEC "sideways" to the 377 Related-domain. The figure below illustrates this situation. 379 +-----------------+ 380 | Relating-domain | 381 | (DNSSEC-signed) | +---------------------+ 382 | RDBDKEY-1 |<----+ + Related-domain | 383 +-----------------+ | | (NOT DNSSEC-signed) | 384 +---+ RDBD RR with SIG | 385 +---------------------+ 387 Extending DNSSEC use-case for RDBD signatures 389 5. Security Considerations 391 5.1. Efficiacy of signatures 393 The optional signature mechanism defined here offers no protection 394 against an active attack if both the RDBD and RDBDKEY values are 395 accessed via an untrusted path. 397 5.2. DNSSEC 399 RDBD does not require DNSSEC. Without DNSSEC it is possible for an 400 attacker to falsify DNS query responses for someone investigating a 401 relationship. Conversely, an attacker could delete the response that 402 would normally demonstrate the relationship, causing the 403 investigating party to believe there is no link between the two 404 domains. An attacker could also replay an old RDBD value that is 405 actually no longer published in the DNS by the Related-domain. 407 Deploying signed records with DNSSEC should allow for detection of 408 these kinds of attack. 410 5.3. Lookup Loops 412 A bad actor could create a loop of relationships, such as 413 a.example->b.example->c.example->a.example or similar. Automated 414 systems SHOULD protect against such loops. For example, only 415 performing a configured number of lookups from the first domain. 416 Publishers of RDBD records SHOULD attempt to keep links direct and so 417 that only the fewest number of lookups are needed, but it is 418 understood this may not always be possible. 420 6. IANA Considerations 422 This document introduces two new DNS RR types, RDBD and RDBDKEY. 423 [[Codepoints for those are not yet allocated by IANA, nor have 424 codepoints been requested so far.]] 426 [[New rdbd-tag value handling will need to be defined if we keep that 427 field. Maybe something like: 0-255: RFC required; 256-1023: 428 reserved; 1024-2047: Private use; 2048-65535: FCFS. It will also 429 likely be useful to define a string representation for each 430 registered rdbd-tag value, e.g. perhaps "UNRELATED" for rdbd-tag 431 value 0, and "RELATED" for rdbd-tag value 1, so that tools displaying 432 RDBD information can be consistent.]] 434 7. Acknowledgements 436 Thanks to all who commented on this on the dbound and other lists, in 437 particular to the following who provided comments that caused us to 438 change the draft: Bob Harold, John Levine, Pete Resnick, Andrew 439 Sullivan, Tim Wisinski, Suzanne Woolf, Joe St. Sauver, and Paul 440 Wouters. (We're not implying any of these fine folks actually like 441 this draft btw, but we did change it because of their comments:-) 442 Apologies to anyone we missed, just let us know and we'll add your 443 name here. 445 8. References 447 8.1. Normative References 449 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 450 Requirement Levels", BCP 14, RFC 2119, 451 DOI 10.17487/RFC2119, March 1997, 452 . 454 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. 455 Rose, "Resource Records for the DNS Security Extensions", 456 RFC 4034, DOI 10.17487/RFC4034, March 2005, 457 . 459 [RFC5702] Jansen, J., "Use of SHA-2 Algorithms with RSA in DNSKEY 460 and RRSIG Resource Records for DNSSEC", RFC 5702, 461 DOI 10.17487/RFC5702, October 2009, 462 . 464 [RFC8032] Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital 465 Signature Algorithm (EdDSA)", RFC 8032, 466 DOI 10.17487/RFC8032, January 2017, 467 . 469 [RFC8080] Sury, O. and R. Edmonds, "Edwards-Curve Digital Security 470 Algorithm (EdDSA) for DNSSEC", RFC 8080, 471 DOI 10.17487/RFC8080, February 2017, 472 . 474 [RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data 475 Interchange Format", STD 90, RFC 8259, 476 DOI 10.17487/RFC8259, December 2017, 477 . 479 8.2. Informative References 481 [RFC6376] Crocker, D., Ed., Hansen, T., Ed., and M. Kucherawy, Ed., 482 "DomainKeys Identified Mail (DKIM) Signatures", STD 76, 483 RFC 6376, DOI 10.17487/RFC6376, September 2011, 484 . 486 [RFC7344] Kumari, W., Gudmundsson, O., and G. Barwood, "Automating 487 DNSSEC Delegation Trust Maintenance", RFC 7344, 488 DOI 10.17487/RFC7344, September 2014, 489 . 491 Appendix A. Implementation (and Toy Deployment:-) Status 493 [[Note to RFC-editor: according to RFC 7942, sections such as this 494 one ought not be part of the final RFC. We still dislike that idea, 495 but whatever;-)]] 497 We are not aware of any independent implementations so far. One of 498 the authors has a github repo at with scripts that allow one to produce zone file 500 fragments and signatures for a set of domains. There is also a 501 wrapper script for the dig tool that provides a nicer view of RDBD 502 and RDBDKEY records, and that verifies signatures. See the README 503 there for details. 505 In terms of deployments, we used the above for a "toy" deployment in 506 the tolerantnetworks.ie domain and other related domains that one can 507 determine by following the relevant trail:-) 509 Appendix B. Examples 511 These examples have been generated using the proof-of-concept 512 implementation mentioned above. These are intended for interop, not 513 for beauty:-) The dig wrapper script referred to above produces more 514 readable output, shown further below.. 516 The following names and other values are used in these examples. 518 o Relating domain: my.example 520 o Related domain: my-way.example 522 o Unrelated domain: my-bad.example 524 o URL for other related domains: 526 o URL for other unrelaed domains: 528 my.example zone file fragments: 530 my.example. 3600 IN TYPE65448 \# 298 ( 531 0000030830820122300d06092a864886f70d010101050 532 00382010f003082010a0282010100bb3b09979b3c4e61 533 0f231dafbd8295d5b6d9475eba8df1cff49b08b99a768 534 15e660c243b8ce7175cc9857be00847cff865ca81e56a 535 f0ec1813a43787902e8b2560b64016c4c8e64262b7b8e 536 ae2e6f735e1186237fff49110227b69fbcefa1cfddf7f 537 df052f250871bb03be114493a8e29a95d04b50b9e99b5 538 8e40e70381384c159d02d781e6837791c2ead0c547e7f 539 fb0aa198b2aef259c42273a69af4f22c7439972d3052d 540 4a581895e203115963689044b4cbbdb6cf90ff1866630 541 593aad625772e6f540bd93801c5781fdd74481fbb6399 542 f745b4525c767e3fb4a4d919e265d541f6bee95d0b9e1 543 15bd4749a3a9748e2d8745466629fa6682d36e83cbae8 544 30203010001 545 ) 546 my.example. 3600 IN TYPE65443 \# 85 ( 547 0001066d792d776179076578616d706c650039820f039 548 b08e9d5a8e057a87c6e7ddb92a680b7a2e69baef46404 549 b3bc9fcd93f4fe261bda56c107dba2d672255a86a771f 550 cc3eca0f12cdd1b302f20b2234de8610e03 551 ) 552 my.example. 3600 IN TYPE65443 \# 18 ( 553 0000066d792d626164076578616d706c6500 554 ) 555 my.example. 3600 IN TYPE65443 \# 39 ( 556 00012368747470733a2f2f6d792d7761792e6578616d7 557 06c652f6d7973747566662e6a736f6e00 558 ) 559 my.example. 3600 IN TYPE65443 \# 42 ( 560 00002668747470733a2f2f6d792d7761792e6578616d7 561 06c652f6e6f746d7973747566662e6a736f6e00 562 ) 564 my.example private key: 566 -----BEGIN RSA PRIVATE KEY----- 567 MIIEpAIBAAKCAQEAuzsJl5s8TmEPIx2vvYKV1bbZR166jfHP9JsIuZp2gV5mDCQ7 568 jOcXXMmFe+AIR8/4ZcqB5Wrw7BgTpDeHkC6LJWC2QBbEyOZCYre46uLm9zXhGGI3 569 //SRECJ7afvO+hz933/fBS8lCHG7A74RRJOo4pqV0EtQuembWOQOcDgThMFZ0C14 570 Hmg3eRwurQxUfn/7CqGYsq7yWcQic6aa9PIsdDmXLTBS1KWBiV4gMRWWNokES0y7 571 22z5D/GGZjBZOq1iV3Lm9UC9k4AcV4H910SB+7Y5n3RbRSXHZ+P7Sk2RniZdVB9r 572 7pXQueEVvUdJo6l0ji2HRUZmKfpmgtNug8uugwIDAQABAoIBAF1sJuwkBGJjocb2 573 4CLijtsVorMu/E0pdIdr+F2MSkdhD/BM//3drVWaJGXcMqWKizpXYptT0iUsGljd 574 cGIsJzgeWrH96nEIG+XgIH/rei2uD8Q39hNcOCnh2szWXb+FSdQEnQacMJFXFmbW 575 pw0d1K5FTi2h9wTdIKupF988y9h4OzVkW9qIDqOzKAKnxoyYZ0xiglaUq6NeHRs2 576 Sv7ow5CErKm4ZDqvtcqxs+uWblm3i5LsPGKexDZfXDQqle7hjFbXKUw+ZREF8hzc 577 bCfa3A5Xyo7nLdgGR2DOZlzOQA+iz5Cnpb35gdOV+giptlwndrn8Lc8U1Zf1f47T 578 aOxh2YECgYEA4u/VQ2B4Ux4NNX8g3womc/rJZOMWVxkd8odRhBy4s0c+atGy3ztp 579 SOprBQrkjcFE831b596MOE11y1GpmKK7q5nI2IcMuStnLoj27a95QVznswnbyA6a 580 g3cIAz/lOHCexLzi8edjcwTxJv1XNE9518SbkU0EbW2OY5jZsHU4I0MCgYEA0zVt 581 m3PrU5/JW1GqmRhDa7PyfB9ESq5mIXIaT6mPh0XLryMn2uUmFBMC3iuxNayjQgzI 582 Gg3XVClcb4vvrVDrkxY5aTDmizvVvF0MletBiLYjCwWHsOGql4hxwhvENYcYvCjs 583 T0WShG8FuuuHaH371+2hBkREeLHQRlyh0om2c8ECgYEA4JCb5PSNnRJb19hZWtzc 584 eGBu8lqVPNMqA1lMnQMe8qlJZsLj0mskIHd4N6Ez0eKyrJAcZjKfZwefzPaecOB3 585 /bNMQJhDSulcTXxTfZjq0HdzAIR87FcnJ3iegTi1R0iKk/ymRuLGUodNa1u+85DB 586 7XYsy3f/LZoAESasJCWay6kCgYAyGpuc5BvwY5iF5FK/LMVZuH+OuHAf801hI8tg 587 GI5m/cS7EHD0+aVV38ivYdgRLpowIg4aOCxb19AI2j6KdAbehsgpzyLx5sjmfYBt 588 1DhgsSyRAcfVy0MH3aN289VRCXJxuJeOmqeOaTQHyrX9sN1ctQ+dB/biVvRcrL7q 589 ziaNQQKBgQC9MECoVH/bYJVY6RoC5ZYAa6A4CYDhaXnw40lQ90ckSgWr3FenV7gw 590 b2xg7zLOX2HZZ+6HejMNGC/efZKVN2Okkpe4KGOXcDH3pYrrkLsLCNRXzxBsyOIt 591 e3e1kAriqiXcr3sPBbn7nakUa7G23O7Hb31C0KGMyf9znN+qWda+3g== 592 -----END RSA PRIVATE KEY----- 594 my-way.example zone file fragments: 596 my-way.example. 3600 IN TYPE65448 \# 36 ( 597 0000030f6d5a2d3caf0d740e139d36a0e52325c4e078e 598 7623f19be3b872367dc8027ef42 599 ) 600 my-way.example. 3600 IN TYPE65443 \# 273 ( 601 0001026d79076578616d706c65003e6c088d887950e26 602 305a59bbe63263b65d34e11656968497500cbef7af12b 603 e14d173d7368e24da54258c851456d3c2d94437692879 604 d1d2b5d3f0acf1e3de6ebb345f8c31f209af6fd7f2731 605 3804fc79db421231126e3e42115ce51a81d2619ed221a 606 fea2b64d1d9ffbef0bd4786fbe5f42c75951ae645078d 607 b7a5a88ed3173d4a209734f49a23a0920ce38ed44011d 608 784e47cf7658cc313cf01349c80b936b17fca3542f32a 609 ff956e808c2520736a917df648e4e5f2eea5de994ce90 610 dba6d5051a4e0934da4a9f6ff01ef5df98d3b4da52b12 611 ea3b8e7ebabcf6d7a0a170dc1284753e3e6b039f8a32c 612 e707312ea5b02180072b517a6056db6e47f8dd5240ab1 613 874646 614 ) 616 my-way.example private key: 618 0000000 5f24 3132 daa0 4cc4 0a77 4cb6 e834 16db 619 0000020 05b0 faf7 ca27 16b6 0ae7 e177 d3f9 db5f 620 0000040 622 Appendix C. Possible dig output... 624 Below we show the output that a modified dig tool might display for 625 the my.example assertions above. 627 $ dig RDBD my.example 629 ; <<>> DiG 9.11.5-P1-1ubuntu2.5-Ubuntu <<>> RDBD my.example 630 ;; global options: +cmd 631 ;; Got answer: 632 ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 4289 633 ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 5, AUTHORITY: 0, ADDITIONAL: 1 635 ;; OPT PSEUDOSECTION: 636 ; EDNS: version: 0, flags:; udp: 4096 637 ; COOKIE: e69085d4b9a18cca63ae96035d7bc0aa96580e0d6255c122 (good) 638 ;; QUESTION SECTION: 639 ;my.example. IN RDBD 641 ;; ANSWER SECTION: 642 my.example. 3600 IN RDBD RELATED may-way.example Sig: good 643 KeyId: 50885 Alg: 15 Sig: UIi04agb... 644 my.example. 3600 IN RDBD UNRELATED my-bad.example 645 my.example. 3600 IN RDBD RELATED https://my-way.example/mystuff.json 646 my.example. 3600 IN RDBD UNRELATED https://my-way.example/notmine.json 648 ;; Query time: 721 msec 649 ;; SERVER: 127.0.0.1#53(127.0.0.1) 650 ;; WHEN: Fri Sep 13 17:15:38 IST 2019 651 ;; MSG SIZE rcvd: 600 653 Appendix D. Changes and Open Issues 655 [[RFC editor: please delete this appendix ]] 657 D.1. Changes from -02 to -03 659 o Incorporated feedback/comments from IETF-105 661 o Suggest list dicussion move to dnsop@ietf.org 663 o Adopted some experimental RRCODE values 665 o Fixed normative vs. informative refs 667 o Changed the examples to use the PoC implementation. 669 o Restructured text a lot 671 D.2. Changes from -01 to -02 673 o Added negative assertions based on IETF104 feedback 675 o Added URL option based on IETF104 feedback 677 o Made sample generation script 679 o Typo fixes etc. 681 D.3. Changes from -00 to -01 683 o Changed from primary/secondary to relating/related (better 684 suggestions are still welcome) 686 o Moved away from abuse of TXT RRs 688 o We now specify optional DNSSEC-like signatures (we'd be fine with 689 moving back to a more DKIM-like mechanism, but wanted to see how 690 this looked) 692 o Added Ed25519 option 694 o Re-worked and extended examples 696 Authors' Addresses 698 Alex Brotman 699 Comcast, Inc 701 Email: alex_brotman@comcast.com 703 Stephen Farrell 704 Trinity College Dublin 706 Email: stephen.farrell@cs.tcd.ie