idnits 2.17.00 (12 Aug 2021) /tmp/idnits6507/draft-dickson-dnsext-ds2-01.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 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 15 instances 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 == Line 907 has weird spacing: '...ne file for "...' == Line 1137 has weird spacing: '...ple.com en.b...' == Line 1141 has weird spacing: '...ple.com fr.b...' -- The document date (November 8, 2010) is 4212 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) == Unused Reference: 'RFC1033' is defined on line 546, but no explicit reference was found in the text == Unused Reference: 'RFC5155' is defined on line 577, but no explicit reference was found in the text ** Downref: Normative reference to an Unknown state RFC: RFC 1033 Summary: 1 error (**), 0 flaws (~~), 8 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 dnsext B. Dickson 3 Internet-Draft Brian Dickson 4 Expires: May 12, 2011 November 8, 2010 6 DNSSEC Delegation Signature with Canonical Signer Name 7 draft-dickson-dnsext-ds2-01 9 Abstract 11 The Domain Name System Security (DNSSEC) Extensions introduced the DS 12 resource record (RR) for authentication of zone delegations. This 13 document introduces an alternative resource record, DS2, which 14 similarly provides authentication of zone delegations. However, DS2 15 provides a canonical signer name, for zones whose content may be 16 duplicated with multiple owner names. The zone is signed by the 17 canonical signer, and the DS2 record allows for validation using this 18 signer name. 20 Author's Note 22 Intended Status: Proposed Standard. 24 Status of this Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on May 12, 2011. 41 Copyright Notice 43 Copyright (c) 2010 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 59 1.1. Rationale . . . . . . . . . . . . . . . . . . . . . . . . 4 60 1.2. Requirements . . . . . . . . . . . . . . . . . . . . . . . 4 61 1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 62 2. Backward Compatibility . . . . . . . . . . . . . . . . . . . . 5 63 3. The DS2 Resource Record . . . . . . . . . . . . . . . . . . . 5 64 3.1. RDATA Fields . . . . . . . . . . . . . . . . . . . . . . . 6 65 3.1.1. The Canonical Signer Name Field . . . . . . . . . . . 6 66 3.1.2. The Key Tag Field . . . . . . . . . . . . . . . . . . 6 67 3.1.3. The Algorithm Field . . . . . . . . . . . . . . . . . 6 68 3.1.4. The Digest Type Field . . . . . . . . . . . . . . . . 6 69 3.1.5. The Digest Field . . . . . . . . . . . . . . . . . . . 7 70 3.2. DS2 RDATA Wire Format . . . . . . . . . . . . . . . . . . 7 71 3.3. Presentation Format . . . . . . . . . . . . . . . . . . . 7 72 3.4. DS2 RR Example . . . . . . . . . . . . . . . . . . . . . . 8 73 4. Authoritative Server Considerations . . . . . . . . . . . . . 8 74 4.1. Delegated (Child) Zones Beneath DS2-signed Zone Cuts . . . 8 75 4.1.1. Zone Signing . . . . . . . . . . . . . . . . . . . . . 9 76 4.1.2. Dynamic Update . . . . . . . . . . . . . . . . . . . . 9 77 4.2. Parent Zone at Zone Cut . . . . . . . . . . . . . . . . . 10 78 4.2.1. Zone Serving . . . . . . . . . . . . . . . . . . . . . 10 79 4.2.2. Referrals to Signed Zones . . . . . . . . . . . . . . 10 80 4.2.3. Responding to Queries for DS2 RRs . . . . . . . . . . 10 81 5. Validator Considerations . . . . . . . . . . . . . . . . . . . 10 82 5.1. DS responses without NSEC/NSEC3 . . . . . . . . . . . . . 11 83 5.2. NSEC/NSEC3 RRs with DS2 type bit set . . . . . . . . . . . 11 84 5.3. DS2 Signed Delegated Zones . . . . . . . . . . . . . . . . 11 85 5.3.1. RRSIG Validation Using Canonical Signer Name . . . . . 11 86 6. Security Considerations . . . . . . . . . . . . . . . . . . . 12 87 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 88 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 89 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 90 9.1. Normative References . . . . . . . . . . . . . . . . . . . 12 91 9.2. Informative References . . . . . . . . . . . . . . . . . . 13 92 Appendix A. Constructs . . . . . . . . . . . . . . . . . . . . . 13 93 A.1. Elements . . . . . . . . . . . . . . . . . . . . . . . . . 13 94 A.1.1. Zone Master File . . . . . . . . . . . . . . . . . . . 13 95 A.1.2. Zone Delegation (Zone Cut) . . . . . . . . . . . . . . 13 96 A.1.3. $ORIGIN . . . . . . . . . . . . . . . . . . . . . . . 14 97 A.1.4. $INCLUDE . . . . . . . . . . . . . . . . . . . . . . . 14 98 A.2. Basic Constructs . . . . . . . . . . . . . . . . . . . . . 14 99 A.2.1. Zone Cut as a Replacement for a CNAME . . . . . . . . 14 100 A.2.2. Zone Cut as a Replacement for a DNAME . . . . . . . . 16 101 A.2.3. Identical Zones with Non-Identical Child Zones . . . . 18 102 Appendix B. Construction Examples, Unsigned . . . . . . . . . . . 20 103 B.1. Objective, In Lay Terms . . . . . . . . . . . . . . . . . 20 104 B.2. Building a Set of 'same' Zones . . . . . . . . . . . . . . 20 105 B.3. Building a Two-Deep Example . . . . . . . . . . . . . . . 22 106 B.3.1. First Level Zone File . . . . . . . . . . . . . . . . 22 107 B.3.2. Server Conf for First Level Zones . . . . . . . . . . 22 108 B.3.3. Server Conf for Second Level Zones . . . . . . . . . . 23 109 Appendix C. Construction Examples, Signed . . . . . . . . . . . . 23 110 C.1. Signed Single Level Zones . . . . . . . . . . . . . . . . 23 111 C.1.1. Create the Single Level Zone . . . . . . . . . . . . . 23 112 C.1.2. Sign the zone . . . . . . . . . . . . . . . . . . . . 24 113 C.1.3. De-canonicalize the zone . . . . . . . . . . . . . . . 24 114 C.1.4. Add DS2 Records to Parent Zones . . . . . . . . . . . 24 115 C.2. Signed Two Level Zones . . . . . . . . . . . . . . . . . . 24 116 C.2.1. Create the Child Zone . . . . . . . . . . . . . . . . 24 117 C.2.2. Sign the child zone . . . . . . . . . . . . . . . . . 25 118 C.2.3. De-canonicalize the child zone . . . . . . . . . . . . 25 119 C.2.4. Create the Canonical First-Level Zone And Add DS2 120 Records . . . . . . . . . . . . . . . . . . . . . . . 25 121 C.2.5. Sign the first-level zone . . . . . . . . . . . . . . 25 122 C.2.6. De-canonicalize the first-level zone . . . . . . . . . 25 123 C.2.7. Add DS2 Records to Parent Zones . . . . . . . . . . . 25 124 Appendix D. Use Cases . . . . . . . . . . . . . . . . . . . . . . 25 125 D.1. All the same . . . . . . . . . . . . . . . . . . . . . . . 25 126 D.2. Two (ore more) levels of sameness . . . . . . . . . . . . 26 127 D.3. Groupings of sameness with additional singletons, 128 beneath identical zones . . . . . . . . . . . . . . . . . 26 129 D.4. All different below one or more levels of all the same . . 27 130 Appendix E. Signed Zone Examples . . . . . . . . . . . . . . . . 28 131 Appendix F. Example Responses . . . . . . . . . . . . . . . . . . 28 132 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 28 134 1. Introduction 136 1.1. Rationale 138 The DNS Security Extensions included the DS RR to provide 139 authenticated zone delegations. Though the DS RR meets the 140 requirements for authentication of delegations, it introduces a side- 141 effect in that otherwise identical zones with different owner names 142 produce non-identical cryptographic signatures. Such zones must be 143 signed repeatedly, using each unique owner name. This property 144 introduces undesired scaling effects. 146 The existence of Internationalized Domain Names (IDNs) creates the 147 need for "equivalent" zones, whose content is identical, but whose 148 owner name differs. Among the sources of this need, are the 149 existence of many-to-one mappings of symbol to canonical meaning, 150 analogous to the two-to-one mapping of upper/lower to lowercase in 151 ASCII. 153 When the many-to-one mapping occurs once per label, the inflated 154 number of zones is not unreasonable. However, there is no such 155 limitation on per-label instances, nor on the number of labels having 156 this characteristic, in IDNs. The desire or need for multiple names 157 for identical zones is not limited to IDNs; in particular, identical 158 names under multiple TLDs is another use case. 160 The cost to cryptographically secure multiple identical zones is 161 high, relative to the perceived security benefit, in certain cases: 162 identical zones known by very many names, large zones, and zones 163 where zone data will be updated rapidly, and any combination thereof. 164 In these cases, the costs of maintaining the multitude of RRSIGs may 165 be extremely high and use of the "re-usable" RRSIGs for duplicated 166 zone content may be more appropriate. 168 This document presents the DS2 Resource Record which can be used as 169 an alternative, or even adjunct, to the DS RR to mitigate these 170 issues. 172 1.2. Requirements 174 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 175 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 176 document are to be interpreted as described in [RFC2119]. 178 1.3. Terminology 180 The reader is assumed to be familiar with the basic DNS and DNSSEC 181 concepts described in [RFC1034], [RFC1035], [RFC4033], [RFC4034], 183 [RFC4035], and subsequent RFCs that update them: [RFC2136], 184 [RFC2181], and [RFC2308]. 186 The following terminology is used throughout this document: 188 Delegation: an NS RRSet with a name different from the current zone 189 apex, signifying a delegation to a child zone. 191 Secure delegation: a name containing a delegation (NS RRSet) and a 192 signed DS RRSet, signifying a delegation to a signed child zone. 194 Insecure delegation: a name containing a delegation (NS RRSet), but 195 lacking a DS RRSet, signifying a delegation to an unsigned child 196 zone. 198 2. Backward Compatibility 200 This specification describes a protocol change that is partially 201 backwards compatible with RFC 4033 [RFC4033] [RFC4033] , RFC 4034 202 [RFC4034] [RFC4034] , and RFC 4035 [RFC4035] [RFC4035] . In 203 particular, security-aware resolvers that are unaware of this 204 specification (DS2-unaware resolvers) may not validate the responses 205 introduced by this document. Zones delegations signed with DS2 only, 206 will be interpreted as "Insecure" by DS2-unaware resolvers. 208 Security-unaware resolvers are unaffected by this specification. 210 3. The DS2 Resource Record 212 The DS2 Resource Record (RR) is very similar to the DS RR RFC 4034 213 [RFC4034] [RFC4034] . The main distinction is that the DS2 RR 214 includes an explicit Canonical Signer Name, as opposed to the 215 implicit signer name of the DS RR. 217 The Canonical Signer Name is used in the validation process, for both 218 the corresponding DNSKEY RR, and for validation of RRSIG RRs in the 219 delegated zone. 221 The delegated zone is the product of signing a version of the zone, 222 where the owner and signer of the zone, and parent of all RRs in the 223 zone, is the Canonical Signer Name. 225 The remainder of the DS2 RR is the same as that of the DS RR, where 226 the DS RR was produced using the Canonical Signer Name as the owner 227 name (and signer name) of the DNSKEY RR . 229 Note that the DS RR with an owner of the Canonical Signer Name MAY 230 exist, but does not need to exist. 232 Note also that DS and DS2 records may coexist. This is likely to 233 occur in a zone which was itself delegated via a DS2, i.e. for which 234 multiple, differently-named copies of the zone exist. 236 The type number for the DS2 record is {TBD}. 238 The DS2 resource record is class independent. 240 The DS2 RR has no special TTL requirements. 242 3.1. RDATA Fields 244 3.1.1. The Canonical Signer Name Field 246 The Canonical Signer Name field identifies the name to be used as the 247 Signer when performing validation on the delegated zone. 249 The Canonical Signer Name is also used in validating the DNSKEY which 250 corresponds to the DS2 record in the zone apex of the delegated zone. 252 This is detailed below. 254 3.1.2. The Key Tag Field 256 The Key Tag field lists the key tag of the DNSKEY RR referred to by 257 the DS record, in network byte order. 259 The Key Tag used by the DS RR is identical to the Key Tag used by 260 RRSIG RRs. Appendix B describes how to compute a Key Tag. 262 3.1.3. The Algorithm Field 264 The Algorithm field lists the algorithm number of the DNSKEY RR 265 referred to by the DS record. 267 The algorithm number used by the DS RR is identical to the algorithm 268 number used by RRSIG and DNSKEY RRs. Appendix A.1 lists the 269 algorithm number types. 271 3.1.4. The Digest Type Field 273 The DS RR refers to a DNSKEY RR by including a digest of that DNSKEY 274 RR. The Digest Type field identifies the algorithm used to construct 275 the digest. Appendix A.2 lists the possible digest algorithm types. 277 3.1.5. The Digest Field 279 The DS record refers to a DNSKEY RR by including a digest of that 280 DNSKEY RR. 282 The digest is calculated by concatenating the canonical form of the 283 fully qualified owner name of the DNSKEY RR with the DNSKEY RDATA, 284 and then applying the digest algorithm. 286 digest = digest_algorithm( DNSKEY owner name | DNSKEY RDATA); 288 "|" denotes concatenation 290 DNSKEY RDATA = Flags | Protocol | Algorithm | Public Key. 292 The size of the digest may vary depending on the digest algorithm and 293 DNSKEY RR size. As of the time of this writing, the only defined 294 digest algorithm is SHA-1, which produces a 20 octet digest. 296 3.2. DS2 RDATA Wire Format 298 The RDATA for a DS RR consists of a Canonical Signer Name (domain 299 name), a 2 octet Key Tag field, a 1 octet Algorithm field, a 1 octet 300 Digest Type field, and a Digest field. 302 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 303 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 304 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 305 / / 306 / Canonical Signer Name / 307 / / 308 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 309 | Key Tag | Algorithm | Digest Type | 310 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 311 / / 312 / Digest / 313 / / 314 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 316 3.3. Presentation Format 318 The presentation format of the RDATA portion is as follows: 320 The Canonical Signer Name field is represented as a domain name. 322 The Key Tag field MUST be represented as an unsigned decimal integer. 324 The Algorithm field MUST be represented either as an unsigned decimal 325 integer or as an algorithm mnemonic specified in Appendix A.1. 327 The Digest Type field MUST be represented as an unsigned decimal 328 integer. 330 The Digest MUST be represented as a sequence of case-insensitive 331 hexadecimal digits. Whitespace is allowed within the hexadecimal 332 text. 334 3.4. DS2 RR Example 336 The following example shows a DNSKEY RR and its corresponding DS2 RR. 338 dskey.example.com. 86400 IN DNSKEY 256 3 5 ( AQOeiiR0GOMYkDshWoSKz 339 9XzfwJr1AYtsmx3TGkJaNXVb 340 fi/2pHm822aJ5iI9BMzNXxeY 341 CmZDRD99WYwYqUSdjMmmAphX 342 dvxegXd/M5+X7OrzKBaMbCVd 343 FLUUh6DhweJBjEVv5f2wwjM9 344 XzcnOf+EPbtG9DMBmADjFDc2 345 w/rljwvFw== 346 ) ; key id = 60485 348 dskey.example.com. 86400 IN DS2 dskey.example.com. 60485 5 1 ( 2BB183 349 AF5F22588179A53B0A98631FAD 350 1A292118 ) 352 The first four text fields specify the name, TTL, Class, and RR type 353 (DS2). The name "dskey.example.com." is the Canonical Signer Name, 354 which in this case is the same as the owner name. Value 60485 is the 355 key tag for the corresponding "dskey.example.com." DNSKEY RR, and 356 value 5 denotes the algorithm used by this "dskey.example.com." 357 DNSKEY RR. The value 1 is the algorithm used to construct the 358 digest, and the rest of the RDATA text is the digest in hexadecimal. 360 4. Authoritative Server Considerations 362 4.1. Delegated (Child) Zones Beneath DS2-signed Zone Cuts 364 The DS2 signature is designed to permit zones signed by another 365 Signer Name, to be authenticated. 367 While the motivation for this is enabling duplicated zone content 368 under different owner names, this is not a requirement. 370 Child zones are always unique from the perspective of resolvers. All 371 delegations are normal delegations. It is only the delegation 372 signatures (DS or DS2) that get special treatment. 374 The Canonical Signer Name (CSN) is ONLY to be used for signature 375 validation. No relationship between zones sharing CSNs is implied or 376 should be inferred. 378 In particular, the "strong linking" of child zones (on the authority 379 server(s)) is not required. Even if two child zones started off 380 identical, they would be permitted to subsequently diverge, 381 regardless of SOA Serial Numbers. 383 4.1.1. Zone Signing 385 The Child zone below a DS2-signed zone cut, are signed as follows: 386 The rightmost portion of the owner name matching the zone name, is 387 replaced with the Canonical Signer Name. 388 The Signer Name used is the Canonical Signer Name. 389 The RRsets are signed with the above changes, but otherwise as 390 usual. 392 The normal usage of DS2, is that a "canonical" version of a zone, 393 with owner name of the Canonical Signer Name, is signed normally per 394 RFC 4035. Then, the entire zone, including signatures, is used 395 verbatim, except for changing the rightmost portion of the owner 396 names. 398 This "copy" of the zone exists for the purpose of having the same 399 zone known by multiple names, e.g. aliasing, such as for IDN usage. 400 The DS2 ensures that the delegation is secure, and that the existing 401 signatures validate properly. 403 Copying the zone is not the only means by which such a zone may be 404 created or used. 406 4.1.2. Dynamic Update 408 In addition to the existing issues for Dynamic Updates for DNSSEC- 409 signed zones, a new problem is introduced by this specification. 411 When a dynamic update needs to be applied to a DS2-signed delegated 412 zone, might incorrectly be presumed that it needs to be applied to 413 all "copies" of the zone. 415 The correct behaviour is specified by the Dynamic Update 416 specification, RFC 2181. Only the Primary Master Server is able to 417 know, and respond appropriately, if zones are in fact "copies". 419 The specific mechanism by which this occurs is beyond the scope of 420 this document. 422 However, implementors intending to enable "copies", are encouraged to 423 consider methods which do not duplicate data, but rather maintain a 424 single instance of the zone data. This methodology implies that 425 dynamic updates to the zone, by any of its names, result in the zone 426 being updated for all names by which the zone is known. 428 4.2. Parent Zone at Zone Cut 430 4.2.1. Zone Serving 432 This specification modifies DNSSEC-enabled DNS responses generated by 433 authoritative servers. In particular, when a signed delegation is 434 returned, whether it includes a DS, DS2, or both, it is also 435 necessary to return the corresponding NSEC/NSEC3 record showing the 436 covered RR types. 438 4.2.2. Referrals to Signed Zones 440 At a zone cut, it is possible for both DS and DS2 RRs to exist for 441 the same owner name. The new rule applies in all circumstances, 442 whether only DS, only DS2, or both, exist to sign the delegation. 444 The rule is: always return the corresponding NSEC/NSEC3 record 445 matching the owner (or owner hash). 447 The reason for this is, that receiving validator will need to know 448 which RR types are expected, in the answer. 450 A DS2-unaware receiving validator will need the NSEC/NSEC3 in 451 particular, if a DS2 RR exists but no DS RR exists. In that case, 452 the zone will validate as "Insecure", since no DS exists and has been 453 proven by the NSEC/NSEC RR (and its RRSIG). 455 4.2.3. Responding to Queries for DS2 RRs 457 This is the same circumstance as section 3.1.4.1 of RFC 4034, 458 "Responding to Queries for DS RRs". The same rules as DS RRs, apply 459 to DS2 RRs. 461 5. Validator Considerations 463 In RFC 5155, the Validator Considerations referencing DS, must be 464 presumed to now read "DS or DS2" (or in the negative sense, "neither 465 DS nor DS2"). 467 Validators MUST use the original Owner Name for any necessary queries 468 for DS, DS2, DNSKEY, and RRSIG resource records. This is because 469 there is no explicit or implicit relationship between the Canonical 470 Signer Name, and a zone whose name corresponds to the Canonical 471 Signer Name (which might not even exist). 473 5.1. DS responses without NSEC/NSEC3 475 If a response is received which includes a DS RR, but does not 476 include the corresponding NSEC/NSEC3 RR, the validator MUST attempt 477 to retrieve the NSEC/NSEC RR, and subsequently attempt to retrieve 478 the corresponding DS2 record if the DS2 type bit is set in the NSEC/ 479 NSEC3 type bit map. 481 Intermediate caches or middleboxes may not be DS2-aware, and may not 482 include DS2 records when QTYPE is not DS2. If the middlebox is DS2- 483 unaware, the middleboxes SHOULD still allow responses for exact 484 matches to unknown types, such as DS2. 486 5.2. NSEC/NSEC3 RRs with DS2 type bit set 488 If a DS2-aware validator receives a response with an NSEC/NSEC3 RR 489 with the DS2 type bit set, but had not also received the DS2 RR, the 490 validator MUST attempt to retrieve the DS2 RRset. 492 An intermediate cache or middlebox may have filtered out, or not 493 cached, the DS2 RR. Explicit querying for the DS2 RR may return the 494 missing DS2 RR. 496 5.3. DS2 Signed Delegated Zones 498 Zones whose delegation is signed by a DS2 RR, and which DS2 RR 499 successfully validates, MUST be validated using the Canonical Signer 500 Name (or Names, if multiple DS/DS2 RRs are present). 502 More specifically, RRSIG RRs in the delegated zone, MUST be validated 503 with Canonical Signer Names (CSN) whose DS2 RR is itself validated. 504 For purposes of this process, every DS RR can be treated as a DS2 RR 505 with the Canonical Signer Name of the DS2 RR's owner name, and MUST 506 be included in the set of CSNs. 508 5.3.1. RRSIG Validation Using Canonical Signer Name 510 The procedure for validating an RRSIG is modified as follows: 511 The RRSIG Signer Name MUST match the Canonical Signer Name. No 512 comparison is made between the Owner Name and either the Canonical 513 Signer Name or the Signer Name of the RRSIG. 515 The number of labels in the RRset Owner name, minus the numer of 516 labels in the Zone Name, plus the number of labels in the 517 Canonical Signer Name, MUST be greater than or equal to the value 518 in the RRSIG RR's Labels field. 519 The RRSIG RR's Algorithm, and Key Tag fields MUST match the 520 algorithm, and key tag for some DNSKEY RR in the zone's apex 521 DNSKEY RRset. 523 6. Security Considerations 525 Further work on DS/DS2 security issues may be necessary. In 526 particular, it is unclear whether the implicit signalling of use of 527 NSEC/NSEC3 may be vulnerable to downgrade attacks. 529 7. IANA Considerations 531 This document updates the IANA registry "DOMAIN NAME SYSTEM 532 PARAMETERS" (http://www.iana.org/assignments/dns-parameters) in sub- 533 registry "TYPES", by defining one new type. Section 3 defines the 534 DS2 RR type {TBD}. 536 8. Acknowledgements 538 The problems related to aliasing, as discussed on the DNSEXT WG 539 mailing list, provided helpful direction in limiting what changes 540 could or should be made to DNS, and DNSSEC in particular. 542 9. References 544 9.1. Normative References 546 [RFC1033] Lottor, M., "Domain administrators operations guide", 547 RFC 1033, November 1987. 549 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 550 STD 13, RFC 1034, November 1987. 552 [RFC1035] Mockapetris, P., "Domain names - implementation and 553 specification", STD 13, RFC 1035, November 1987. 555 [RFC2136] Vixie, P., Thomson, S., Rekhter, Y., and J. Bound, 556 "Dynamic Updates in the Domain Name System (DNS UPDATE)", 557 RFC 2136, April 1997. 559 [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS 560 Specification", RFC 2181, July 1997. 562 [RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS 563 NCACHE)", RFC 2308, March 1998. 565 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 566 Rose, "DNS Security Introduction and Requirements", 567 RFC 4033, March 2005. 569 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. 570 Rose, "Resource Records for the DNS Security Extensions", 571 RFC 4034, March 2005. 573 [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. 574 Rose, "Protocol Modifications for the DNS Security 575 Extensions", RFC 4035, March 2005. 577 [RFC5155] Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS 578 Security (DNSSEC) Hashed Authenticated Denial of 579 Existence", RFC 5155, March 2008. 581 9.2. Informative References 583 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 584 Requirement Levels", BCP 14, RFC 2119, March 1997. 586 Appendix A. Constructs 588 A.1. Elements 590 The following DNS elements are used in the constructs discussed here. 592 A.1.1. Zone Master File 594 The term "zone master file" has the meaning established in RFC 1035. 595 It is the file containing all the resource records and directives for 596 the zone. 598 A.1.2. Zone Delegation (Zone Cut) 600 The terms "zone delegation" and "zone cut" may generally be used 601 interchangeably. 603 A zone delegation is the act of putting in NS records in a zone at a 604 place other than the apex. 606 The zone delegation is the parent side of a zone cut. 608 A zone cut creates a new zone. The apex of the new zone has the same 609 owner name as the zone delegation. 611 A.1.3. $ORIGIN 613 Most DNS authority servers include the ability to directly refer to a 614 zone master file, with an implied $ORIGIN. For those, no $ORIGIN 615 needs to be used. 617 For completeness, zone master files with explicit $ORIGIN are also 618 used in examples. This is in keeping with RFC 1035. 620 A.1.4. $INCLUDE 622 In the instances where $ORIGIN use is needed, it is also necessary to 623 include common content via the $INCLUDE directive. This is also RFC 624 1035 compliant. 626 A.2. Basic Constructs 628 The following examples show ways to replace CNAME/DNAME usage with 629 other existing DNS items. Rationale for usage, and differences from 630 CNAME/DNAME are explained for each. 632 A.2.1. Zone Cut as a Replacement for a CNAME 634 The following example shows a simple CNAME, where the CNAME target 635 (for convenience) is a sibling of the CNAME itself. 637 zone file for example.com: 639 $ORIGIN example.com. 640 @ SOA ns1.example.com. postmaster ( 641 42 7200 600 3600000 60 ) 642 NS ns1.example.com 643 alias CNAME real.example.com 644 real TXT "This is real data, maintained in a single location." 646 Querying for type TXT at alias.example.com, will return the CNAME RR 647 plus the TXT RR for real.example.com (the CNAME target). 649 The following example shows the use of a zone cut, and the inclusion 650 of data from a single location, as an alternative. 652 zone file for example.com: 654 $ORIGIN example.com. 655 @ SOA ns1.example.com. postmaster ( 656 42 7200 600 3600000 60 ) 657 NS ns1.example.com 658 alias NS ns1.example.com ; all zones are served by ns1 659 real NS ns1.example.com ; normally there are multiple NS's 661 server configuration (with implicit $ORIGIN of zone.name): 662 zone alias.example.com { master; file="czone-data.example.com";}; 663 zone real.example.com { master; file="czone-data.example.com";}; 665 Or, server configuration (without implicit $ORIGIN): 666 zone alias.example.com { master; file="alias.example.com";}; 667 zone real.example.com { master; file="real.example.com";}; 669 zone file for alias.example.com: 671 $ORIGIN alias.example.com. 672 $INCLUDE "czone-data.example.com" 674 zone file for real.example.com: 676 $ORIGIN real.example.com. 677 $INCLUDE "czone-data.example.com" 679 file czone-data.example.com: 681 @ SOA ns1.example.com. postmaster ( 42 7200 600 3600000 60 ) 682 NS ns1.example.com 683 TXT "This is real data, maintained in a single location." 685 Querying for the TXT record for either alias.example.com, or 686 real.example.com, requires first following the delegation, and then 687 gets a response which does not include any CNAME. 689 The main difference here is, that the DNS node "alias.example.com" is 690 a real, first-class entry, which can be used interchangeably with 691 "real.example.com". E.g., it can be used as an MX target. 693 The other important difference is, as the data is all authoritative 694 and self-contained, it is not possible to have a broken CNAME. If 695 the necessary linkage is incorrect, the zone file will not load. 697 This means that maintaining aliased data in this way, returns values 698 in a consistent manner, in a deterministic path and timeframe. Data 699 kept this way can be validated, via zone loading and zone checking 700 functions included with most modern DNS authority servers. 702 A.2.2. Zone Cut as a Replacement for a DNAME 704 The following example shows a simple DNAME, where the DNAME target 705 (for convenience) is a sibling of the DNAME itself. 707 zone file for example.com: 709 $ORIGIN example.com. 710 @ SOA ns1.example.com. postmaster ( 711 42 7200 600 3600000 60 ) 712 NS ns1.example.com 713 alias DNAME real.example.com 714 content.real TXT "This is real data, kept only here." 716 Querying for type TXT at alias.example.com, will return the CNAME RR 717 plus the TXT RR for real.example.com (the CNAME target). 719 The following example shows the use of a zone cut, and the inclusion 720 of data from a single location, as an alternative. 722 zone file for example.com: 724 $ORIGIN example.com. 725 @ SOA ns1.example.com. postmaster ( 726 42 7200 600 3600000 60 ) 727 NS ns1.example.com 728 alias NS ns1.example.com ; all zones are served by ns1 729 real NS ns1.example.com ; normally there are multiple NS's 731 server configuration (with implicit $ORIGIN of zone.name): 732 zone alias.example.com { master; file="dzone.example.com";}; 733 zone real.example.com { master; file="dzone.example.com";}; 735 Or, server configuration (without implicit $ORIGIN): 736 zone alias.example.com { master; file="alias.example.com";}; 737 zone real.example.com { master; file="real.example.com";}; 739 zone file for alias.example.com: 741 $ORIGIN alias.example.com. 742 $INCLUDE "dzone.example.com" 744 zone file for real.example.com: 746 $ORIGIN real.example.com. 747 $INCLUDE "dzone.example.com" 749 file dzone.example.com: 751 @ SOA ns1.example.com. postmaster ( 42 7200 600 3600000 60 ) 752 NS ns1.example.com 753 content TXT "This is real data, maintained in a single location." 755 Querying for the TXT record for either content.alias.example.com, or 756 content.real.example.com, requires first following the delegation, 757 and then gets a response which does not include any DNAME or 758 synthesized CNAME. 760 The main difference here is, that the DNS node 761 "content.alias.example.com" is a real, first-class entry, which can 762 be used interchangeably with "content.real.example.com". E.g., it 763 can be used as an MX target. 765 The other important difference is, as the data is all authoritative 766 and self-contained, it is not possible to have a broken DNAME. If 767 the necessary linkage is incorrect, the zone file will not load. 769 This means that maintaining aliased data in this way, returns values 770 in a consistent manner, in a deterministic path and timeframe. Data 771 kept this way can be validated, via zone loading and zone checking 772 functions included with most modern DNS authority servers. 774 A.2.3. Identical Zones with Non-Identical Child Zones 776 This example demonstrates identical zones, where there are child 777 zones (of all identical parents) whose content differ. The owner 778 name of the child zones, relative to the parent apex name, is 779 identical. 781 Note Well: The following example is not possible with CNAME or DNAME 782 usage. 784 The query re-writing that occurs in CNAME/DNAME obscures zone cuts as 785 a distinction for any portion of the DNS tree below the CNAME/DNAME. 787 zone file for example.com: 789 $ORIGIN example.com. 790 @ SOA ns1.example.com. postmaster ( 791 42 7200 600 3600000 60 ) 792 NS ns1.example.com 793 alias NS ns1.example.com ; all zones are served by NS1 794 real NS ns1.example.com ; normally there are multiple NS's 796 server configuration (with implicit $ORIGIN of zone.name): 797 zone alias.example.com { 798 master; file="has-a-child.example.com";}; 799 zone real.example.com { 800 master; file="has-a-child.example.com";}; 801 zone child.alias.example.com { 802 master; file="child.alias.example.com";}; 803 zone child.real.example.com { 804 master; file="child.real.example.com";}; 806 (Non-implicit $ORIGIN may be used, similar to previous examples.) 808 file has-a-child.example.com: 810 @ SOA ns1.example.com. postmaster ( 811 42 7200 600 3600000 60 ) 812 NS ns1.example.com 813 content TXT "identical" 814 ; this zone cut exists in all aliased zones 815 child NS ns1.example.com 817 file child.alias.example.com: 819 @ SOA ns1.example.com. postmaster ( 820 42 7200 600 3600000 60 ) 821 NS ns1.example.com 822 TXT "divergent" 824 file child.real.example.com: 826 @ SOA ns1.example.com. postmaster ( 827 42 7200 600 3600000 60 ) 828 NS ns1.example.com 829 TXT "unique" 831 TXT Queries for content.alias.example.com and 832 content.real.example.com, both return "identical" results. 834 TXT Queries for child.alias.example.com, and child.real.example.com, 835 return "divergent" and "unique" results respectively, which come from 836 their respective zones. 838 If real.example.com were a very large zone, with very few members 839 whose values needed to differ from alias.example.com, this mechanism 840 would be quite useful for maintaining the data. 842 Appendix B. Construction Examples, Unsigned 844 The following examples show how to construct a hierarchy of zones, 845 with all zones at a given depth being identical. 847 The zones are unsigned, and can be implemented using existing DNS 848 elements. No DS2 is required. 850 B.1. Objective, In Lay Terms 852 In these example, we are using the constructs available, to build DNS 853 zones with specific characteristics. 855 What we want, is for all the zones (under consideration) to be "the 856 same". 858 What we mean by "the same" is that: 859 Every node in any zone, is in every zone; 860 Every combination of class and type, at each node, exists at that 861 node in all the zones; 862 The value of each tuple (name,class,type) in each zone is 863 identical. 865 In addition, whenever we use zone names (or placeholders for names), 866 like Ai.Bj, we mean all combinations of the members of set {A} and 867 the set {B}, combined, as {A}.{B}. The members of set {A} are A1, 868 A2, A3, etc., and the members of set {B} are B1, B2, B3., etc. The 869 letters "i" and "j" simply indicate that there is no relationship 870 between the number of members in sets {A} and {B}. 872 Additionally, A1, A2, etc., are placeholder names for what might be 873 actual names. For instance, A1 could be "foo.example.com.", and A2 874 could be "bar.example.net." 876 B.2. Building a Set of 'same' Zones 878 First, we need the zone content that will be used to populate the 879 zones. Let's say we have a single existing zone, that we want to 880 turn into a set of 'same' zones. 882 Zone file for "myzone.example.com.", the file myzone.zone: 884 myzone.example.com. SOA ns1.example.com postmaster ( 885 42 7200 600 3600000 60 ) 886 NS ns1.example.com 887 mytext.myzone.example.com. TXT "Example Text" 888 mymailer.myzone.example.com. A 127.0.0.1 889 www.myzone.example.com. A 127.0.0.2 890 radius.myzone.example.com. A 127.0.0.3 892 First we de-canonicalize the labels within the zone: 894 Zone file for "myzone.example.com.", the file myzone.zone: 896 myzone.example.com. SOA ns1.example.com postmaster ( 897 42 7200 600 3600000 60 ) 898 NS ns1.example.com 899 mytext TXT "Example Text" 900 mymailer A 127.0.0.1 901 www A 127.0.0.2 902 radius A 127.0.0.3 904 Then we turn the zone name itself into a reference to the $ORIGIN, 905 which itself will be supplied when the zone is loaded: 907 Zone file for "myzone.example.com.", the file myzone.zone: 909 @ SOA ns1.example.com postmaster ( 910 42 7200 600 3600000 60 ) 911 NS ns1.example.com 912 mytext TXT "Example Text" 913 mymailer A 127.0.0.1 914 www A 127.0.0.2 915 radius A 127.0.0.3 917 Finally, we modify the configuation file to use this file for both 918 myzone.example.com., and any other zones we want to have be the same: 920 Configuration file (named.conf, for BIND) elements needed 921 for myzone.example.com and additional zones: 923 zone "myzone.example.com."{master; file="myzone.zone";}; 924 zone "myzone.example.net."{master; file="myzone.zone";}; 925 zone "other.example.org."{master; file="myzone.zone";}; 927 Each time a zone file is loaded, it does so with an implicit $ORIGIN 928 of the zone name. This causes all the zones that have @ as the zone 929 name (SOA owner) to be identical, if they are read from the same 930 file. 932 B.3. Building a Two-Deep Example 934 For this example, we will build several zones with the same content, 935 by re-using the same file. For this example, we will save some steps 936 by using the same zone file as before, 'mysone.zone'. 938 Since the zones will be two deep, we need another set of zones above 939 those, i.e. one deep, who exist only to contain the two-deep zones. 941 In DNS parlance, these would, if inside a single zone, be considered 942 "empty non-terminals". However, they are not inside a single zone, 943 but rather are delegation-only zones. The "real" data is in their 944 children, and the parent zones contain no other data besides that 945 needed for the delegations (i.e. NS records and possibly glue 946 records). 948 B.3.1. First Level Zone File 950 This is a "thin" zone file, containing only the labels by which the 951 second level zones are to be known. 953 Zone file for first level zones, "first-level.zone": 955 @ SOA ns1.example.com postmaster ( 956 42 7200 600 3600000 60 ) 957 NS ns1.example.com 958 red NS ns1.example.com 959 green NS ns1.example.com 960 blue NS ns1.example.com 962 B.3.2. Server Conf for First Level Zones 964 This establishes the parent names for the first level zones, from 965 which the delegations to the second level occur: 967 Zone conf file elements for the first level zones: 969 zone "myzone.example.com."{master; file="first-level.zone";}; 970 zone "myzone.example.net."{master; file="first-level.zone";}; 971 zone "other.example.org."{master; file="first-level.zone";}; 973 B.3.3. Server Conf for Second Level Zones 975 This establishes the fully qualified zone names for the second level 976 zones, in all permutations and combinations: 978 Zone conf file elements for the first level zones: 980 zone "red.myzone.example.com."{master; file="myzone.zone";}; 981 zone "red.myzone.example.net."{master; file="myzone.zone";}; 982 zone "red.other.example.org."{master; file="myzone.zone";}; 983 zone "green.myzone.example.com."{master; file="myzone.zone";}; 984 zone "green.myzone.example.net."{master; file="myzone.zone";}; 985 zone "green.other.example.org."{master; file="myzone.zone";}; 986 zone "blue.myzone.example.com."{master; file="myzone.zone";}; 987 zone "blue.myzone.example.net."{master; file="myzone.zone";}; 988 zone "blue.other.example.org."{master; file="myzone.zone";}; 990 While this requires setting up all the zones, there is only one zone 991 file to maintain, and all the zones inherit the common contents. 993 Appendix C. Construction Examples, Signed 995 The following examples are exactly the same as the examples above, 996 except that they are signed. 998 The zone files are identical, and require the use of DS2 signatures. 1000 C.1. Signed Single Level Zones 1002 The procedure here is: 1003 Create the first-instance zone, fully qualified. 1004 Sign the zone, and capture the DS record. 1005 De-canonicalize the zone file, and use the DS as a basis for the 1006 DS2 records. 1007 The DS2 records will need to be signed by their respective parent 1008 zones. The signatures are omitted for clarity. 1010 C.1.1. Create the Single Level Zone 1012 We need to use the Canonical Signer Name for the zone name. 1014 Zone file for "myzone.example.com.", the file myzone.zone: 1016 myzone.example.com. SOA ns1.example.com postmaster ( 1017 42 7200 600 3600000 60 ) 1018 NS ns1.example.com 1019 mytext.myzone.example.com. TXT "Example Text" 1020 mymailer.myzone.example.com. A 127.0.0.1 1021 www.myzone.example.com. A 127.0.0.2 1022 radius.myzone.example.com. A 127.0.0.3 1024 C.1.2. Sign the zone 1026 C.1.3. De-canonicalize the zone 1028 C.1.4. Add DS2 Records to Parent Zones 1030 C.2. Signed Two Level Zones 1032 The procedure here is: 1033 Create the first-instance child zone, fully qualified. 1034 Sign the child zone, and capture the DS record. 1035 De-canonicalize the child zone file, and use the DS as a basis for 1036 the DS2 records on the child delegations. 1037 Create the first-instance parent zone, fully qualified, and 1038 include the DS2 records. 1039 Sign the parent zone, and capture the DS record. 1040 De-canonicalize the parent zone file, and use the DS as a basis 1041 for the DS2 records in the parent zones. 1042 The parents' DS2 records will need to be signed by their respective 1043 parent zones. Those signatures are omitted for clarity. 1045 C.2.1. Create the Child Zone 1047 We need to use the Canonical Signer Name for the zone name. 1049 Zone file for "red.myzone.example.com.", the file myzone.zone: 1051 red.myzone.example.com. SOA ns1.example.com postmaster ( 1052 42 7200 600 3600000 60 ) 1053 NS ns1.example.com 1054 mytext.red.myzone.example.com. TXT "Example Text" 1055 mymailer.red.myzone.example.com. A 127.0.0.1 1056 www.red.myzone.example.com. A 127.0.0.2 1057 radius.red.myzone.example.com. A 127.0.0.3 1059 C.2.2. Sign the child zone 1061 C.2.3. De-canonicalize the child zone 1063 C.2.4. Create the Canonical First-Level Zone And Add DS2 Records 1065 Zone file for "myzone.example.com.", "first-level.zone": 1067 myzone.example.com. SOA ns1.example.com postmaster ( 1068 42 7200 600 3600000 60 ) 1069 NS ns1.example.com 1070 red.myzone.example.com. NS ns1.example.com 1071 DS2 red.myzone.example.com. ( 1072 ; rest of DS record contents go here 1073 ) 1074 green.myzone.example.com. NS ns1.example.com 1075 DS2 red.myzone.example.com. ( 1076 ; rest of DS record contents go here 1077 ) 1078 blue.myzone.example.com. NS ns1.example.com 1079 DS2 red.myzone.example.com. ( 1080 ; rest of DS record contents go here 1081 ) 1083 C.2.5. Sign the first-level zone 1085 C.2.6. De-canonicalize the first-level zone 1087 C.2.7. Add DS2 Records to Parent Zones 1089 Appendix D. Use Cases 1091 D.1. All the same 1093 Use Case: identical zone content, where zones have more than one 1094 name. 1096 Example: 1098 colors.example.com 1099 colours.example.com 1101 D.2. Two (ore more) levels of sameness 1103 Use Case: identical zone content, where the zones owner names contain 1104 two or more labels with equivalent labels (synonyms/homonyms/IDNs). 1106 Example: 1108 colours.iso-with-accents.example.com 1109 colors.iso-with-accents.example.com 1110 colours.iso-without-accents.example.com 1111 colors.iso-without-accents.example.com 1112 colours.ascii.example.com 1113 colors.ascii.example.com 1115 D.3. Groupings of sameness with additional singletons, beneath 1116 identical zones 1118 Use Case: Clusters of content where the content of each cluster is 1119 identical, beneath zones which are identical. 1121 Example: Language-specific content, grouped by country, underneath 1122 aliases for some company's zones. 1124 [NB - Better examples of sameness and singletons are needed - same 1125 name, different content] 1126 Zone Name CSN 1127 --------- --- 1128 (Parents) 1129 big-company.example.com big-company.example.com 1130 trade-mark.example.com big-company.example.com 1131 product-name.example.com big-company.example.com 1133 (Children) 1134 en.big-company.example.com en.big-company.example.com 1135 en.trade-mark.example.com... ..en.big-company.example.com 1136 en.product-name.example.com. .en.big-company.example.com 1137 canada-en.big-company.example.com en.big-company.example.com 1138 usa.big-company.example.com en.big-company.example.com 1139 uk.big-company.example.com en.big-company.example.com 1140 fr.big-company.example.com fr.big-company.example.com 1141 canada-fr.big-company.example.com fr.big-company.example.com 1142 france.big-company.example.com fr.big-company.example.com 1143 sw.big-company.example.com sw.big-company.example.com 1144 (etc) 1146 (Grandchildren) 1147 secure-server.en.big-company.example.com 1148 secure-server.en.trade-mark.example.com 1149 (etc...) 1150 [Delegations are made to unique zones when unique values for 1151 arbitrary-depth labels are required.] 1152 [E.g. for SSL certificates, unique IP addresses, and such.] 1154 In the above table, each of the delegations to the children is signed 1155 by the CSN. 1157 Each zone uses a master zone file corresponding to the CSN on a 1:1 1158 basis. 1160 If two zones have the same CSN, they are loaded from the same master 1161 zone file. 1163 D.4. All different below one or more levels of all the same 1165 Use Case: Two large zones, whose content is identical except for one 1166 node in the zone. 1168 Use Case detail: The "exception" node is isolated via a zone cut, and 1169 all the grandchildren zones are unique. 1171 The children zones are identical, and signed once with delegations 1172 signed by DS2 RRs. The grandchildren zones are unique, signed by 1173 their respective owner names. The delegations from the (identical) 1174 parents of the grandchildren, require multiple DS RRs, one for each 1175 grandchild's signature. 1177 Note Well: The grandchildren in this case, MUST be served by the same 1178 set of nameservers, since the NS records at the zone cut are 1179 identical. 1181 bigzone.iso-with-accents.example.com 1182 bigzone.ascii.example.com 1183 unique-node.bigzone.iso-with-accents.example.com 1184 unique-node.bigzone.ascii.example.com 1186 Appendix E. Signed Zone Examples 1188 Appendix F. Example Responses 1190 Author's Address 1192 Brian Dickson 1193 Brian Dickson 1194 6261 Lawrence St, 1195 Halifax, NS B3L 1J8 1196 Canada 1198 Email: brian.peter.dickson@gmail.com