idnits 2.17.1 draft-yao-dbound-dns-solution-02.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (January 26, 2016) is 3012 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: 'RFC4033' is defined on line 362, but no explicit reference was found in the text == Unused Reference: 'RFC5585' is defined on line 367, but no explicit reference was found in the text == Unused Reference: 'RFC6125' is defined on line 372, but no explicit reference was found in the text == Unused Reference: 'RFC6265' is defined on line 379, but no explicit reference was found in the text == Unused Reference: 'RFC7208' is defined on line 383, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 5585 ** Obsolete normative reference: RFC 6125 (Obsoleted by RFC 9525) Summary: 2 errors (**), 0 flaws (~~), 7 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Domain Boundaries J. Yao 3 Internet-Draft N. Kong 4 Intended status: Standards Track X. Li 5 Expires: July 29, 2016 CNNIC 6 January 26, 2016 8 Resource Record for DNS Administrative Boundaries 9 draft-yao-dbound-dns-solution-02 11 Abstract 13 Two or more DNS names may have the same DNS administrative 14 boundaries. This document adds the function of lookup of domain name 15 administrative boundary to domain name system, which describes a new 16 method for using dbound resource record for judging domain name 17 administrative boundaries. 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at http://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on July 29, 2016. 36 Copyright Notice 38 Copyright (c) 2016 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 This document may contain material from IETF Documents or IETF 52 Contributions published or made publicly available before November 53 10, 2008. The person(s) controlling the copyright in some of this 54 material may not have granted the IETF Trust the right to allow 55 modifications of such material outside the IETF Standards Process. 56 Without obtaining an adequate license from the person(s) controlling 57 the copyright in such materials, this document may not be modified 58 outside the IETF Standards Process, and derivative works of it may 59 not be created outside the IETF Standards Process, except to format 60 it for publication as an RFC or to translate it into languages other 61 than English. 63 Table of Contents 65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 66 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 67 3. Framework . . . . . . . . . . . . . . . . . . . . . . . . . . 3 68 4. Application Algorithm for Dbound Query . . . . . . . . . . . 4 69 5. Wildcard issue . . . . . . . . . . . . . . . . . . . . . . . 6 70 6. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . 7 71 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 72 8. Security Considerations . . . . . . . . . . . . . . . . . . . 7 73 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 74 10. Change History . . . . . . . . . . . . . . . . . . . . . . . 8 75 10.1. draft-yao-dbound-dns-solution: Version 00 . . . . . . . 8 76 10.2. draft-yao-dbound-dns-solution: Version 01 . . . . . . . 8 77 10.3. draft-yao-dbound-dns-solution: Version 02 . . . . . . . 8 78 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 79 11.1. Normative References . . . . . . . . . . . . . . . . . . 8 80 11.2. Informative References . . . . . . . . . . . . . . . . . 9 81 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 83 1. Introduction 85 Two or more DNS [RFC1034] [RFC1035] names may have the same 86 administrative boundaries. If they share the same DNS administrative 87 boundaries, we regard that they have a relationship. Otherwise they 88 have not a relationship. This document describes an method for using 89 dbound resource record for judging domain name administrative 90 boundaries. 92 The drafts [Boundaries-Problem] [Boundaries-Concepts] list many use 93 cases where some applications may use domain name administrative 94 boundaries. With the growth of Internet, there should have more 95 Internet applications which will use domain name administrative 96 boundaries technology. 98 With the growth of new gTLD program, it is very common for a company 99 to have many domain names for the same aim. So we should design a 100 method for judging the two or more domain names which share the 101 administrative boundaries. 103 2. Terminology 105 The basic key words such as "MUST", "MUST NOT", "SHALL", "SHALL NOT", 106 "SHOULD", "SHOULD NOT", "MAY", and "MAYNOT" are to be interpreted as 107 described in [RFC2119]. 109 The basic DNS terms used in this specification are defined in the 110 documents [RFC1034] and [RFC1035]. 112 3. Framework 114 This section presents a mechanism to lookup of the administrative 115 boundary between two domains. The mechanism defines a new resource 116 record type (RRTYPE) to satisfy the requirements specified in the 117 previous section. The RDATA for an Dbound RR consists of a 1 octet 118 Flag field, a 1 octet Reserved 1 field, a 1 octet Reserved 2 field, 119 and a Anchor Name / Name Collection field. 121 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 122 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 123 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 124 | Flag | Reserved 1 | Reserved 2 | / 125 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / 126 / Anchor Name / Name Collection / 127 / / 128 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 130 Figure 2. The structure of RDATA of Dbound resource record 132 Flag: 133 The Flag field identifies the usage of Anchor Name / Name Collection 134 field. If flag=0, the Anchor Name / Name Collection is the anchor 135 name, the anchor name will be the string of PSL. Through it, the DNS 136 administrators can configure the relationship between the owner name 137 and PSL. Those which point to the PSL will share the same DNS 138 administrative boundaries; 139 If flag=1, the Anchor Name / Name Collection is the anchor name, it 140 means that dbound record is to try to build a connection between the 141 owner name and the anchor name which is a FQDN. Through it, the DNS 142 administrators can configure the relationship between the owner name 143 and the anchor name. Those which share the same anchor name will 144 share the same DNS administrative boundaries; 146 If flag=2, the Anchor Name / Name Collection is the name collection, 147 the Name Collection will be a collection of names which are supposed 148 to share the same DNS boundaries under the same anchor name and will 149 be separated by comma(,). The owner name is some names' anchor name 150 in other dbound RR. Through it, the application can learn how many 151 names share the same DNS boundaries under the owner name (some names' 152 anchor name in other dbound RRs) 154 Reserved 1 field and Reserved 2 field: 155 These two fields will be kept for the future use. 157 Anchor Name / Name Collection: 158 There are two kinds of relationship mechanism, one is controlled by 159 PSL; the other is specified by building the connection among names. 160 If Flag is 0, the Anchor Name / Name Collection field will have the 161 value of PSL; If Flag is 1, the Anchor Name / Name Collection field 162 will have the value of the anchor name. The anchor name acts like a 163 middleman. All names sharing the same administrative boundaries will 164 point to the same anchor name; If Flag is 2, the Anchor Name / Name 165 Collection field will have the value of name collection with names 166 separated by comma (,). 168 4. Application Algorithm for Dbound Query 170 Given two domain names A and B 171 There are two cases where application can determin whether domain 172 names A and B share the same administrative boundaries. 174 Case 1: If A and B's flag value in the dbound record are 0, 175 application should confirm that the Anchor Name / Name Collection 176 fields of both names have the value of PSL. 178 Case 2: If A and B's flag value in the dbound record are 1, 179 application should check whether the names point to the same anchor. 181 Algorithm 1: 182 1)When the application needs to know whether two names A and B share 183 the same administrative boundary, it needs to do the following steps 184 to confirm it. 186 Step 1, the application sends the query of A for dbound record to the 187 DNS servers, and analyzes the response. If the application gets the 188 dbound RR for A, it checks whether there is a dbound record with the 189 flag value of 0 or 1. If the value of flag of A's dbound records is 190 0, go to step 2; If the value of flag of A's dbound records is 1, go 191 to step 3; Otherwise, go to step 4; 193 Step 2, the application sends the query of B for dbound record to the 194 DNS servers, and analyzes the response. If the application gets the 195 dbound RR, it checks this RR. If the value of flag of B's dbound 196 records is 0, check whether the value of anchor name of A and B's 197 dbound records are PSL. If yes, it means that A and B enjoys the 198 same administrative boundaries under the PSL and exit. Otherwise go 199 to step 4 201 Step 3, the application sends the query of B for dbound record to the 202 DNS servers, and analyzes the response. If the application gets the 203 dbound RR, it checks this RR. If the value of flag of B's dbound 204 records is 1, check whether the value of anchor name of A and B's 205 dbound records are same. If yes, it means that A and B enjoys the 206 same administrative boundaries under the same anchor name and exit. 207 Otherwise go to step 4 209 Step 4, Exit and display some error information 211 2)Given name A, check who shares the same administrative boundaries 212 with A. 213 The application sends the query of A for dbound record to the DNS 214 servers, and analyzes the response. If the application gets the 215 dbound RR for A, it checks whether there is a dbound record with the 216 flag value of 2. If yes, check the value of name collection of A's 217 dbound record, find name list, check every name on the name list with 218 A to confirm whether they enjoy the same administrative boundaries 219 via the method 1) above. 221 3)Given more names than two, check whether they shares the same 222 administrative boundaries. 223 The application selects one of the names as A and check whether every 224 other name share the same administrative boundaries with A via the 225 the method 1) above. 227 For examples: 229 EXAMPLE 1, if a.example and b.exmaple want to share the same DNS 230 administrative boundaries, it can configure the following RRs: 231 a.example dbound 1 c.example 232 b.example dbound 1 c.example 233 c.example dbound 2 a.example,b.example 234 or the anchor name can also be one of the names who share the same 235 DNS administrative boundaries: 236 a.example dbound 1 b.exmaple 237 b.example dbound 1 b.example 238 b.example dbound 2 a.example,b.example 240 USAGE: if the application wants to check whether a.example and 241 b.example share the same DNS boundaries, it find a.example and 242 b.example share the same anchor under the flag's value of 1 under the 243 RRs above, and verify that a.example and b.example share the same DNS 244 boundaries. 245 if the application wants to check which domain names share the same 246 DNS boundaries with a.example, it find a.example and b.example are 247 supposed to have the same DNS boundaries under the flag's value of 2, 248 and verify that a.example and b.example share the same DNS boundaries 249 through checking a.example and b.example sharing the same anchor 250 under the flag's value of 1 . 252 EXAMPLE 2, if a.example and b.exmaple want to share the same DNS 253 administrative boundaries under PSL, it can configure the following 254 RRs: 255 a.example dbound 0 http://mxr.mozilla.org/mozilla- 256 central/source/netwerk/dns/ effective_tld_names.dat?raw=1 257 b.example dbound 0 http://mxr.mozilla.org/mozilla- 258 central/source/netwerk/dns/ effective_tld_names.dat?raw=1 260 USAGE: if the application wants to check whether a.example and 261 b.example share the same dns boundaries, it find a.example and 262 b.example share the same anchor under the flag's value of 0, and 263 verify that a.example and b.example share the same dns boundaries via 264 the PSL link. 266 ADVANTAGES: This new mechanism builds a relationship through the 267 anchor name (middleman) to avoid to construct too many pairwise 268 relationship. It will help to reduce the RRs configuration and 269 checking when there are many domain names which are supposed to share 270 the same DNS boundaries. 272 5. Wildcard issue 274 The parent name may announce that all names under it to share the 275 same administrative boundaries with itself, but it needs two-way 276 assertion here. Parents can say all its children are under its 277 control and share the same boundaries. In the other hand, the 278 children should confirm that they share the same boundary with its 279 parents too. 281 For example: 283 example.com dbound 1 example.com 284 *.example.com dbound 1 example.com 285 example.com dbound 2 example.com, *.example.com 287 It means that example.com and its children share the same 288 administrative boundaries. 290 In some cases, the children may lose its parent's control by 291 configure some DNS records for themselves. The debound record has 292 similar same limitation with the wildcard. Wildcards work for the 293 non-configured sub-domain names only. Those names which can not 294 queried through wildcard will not work for dbound too. Those names 295 should configure their own dbound record separately instead of 296 wildcard dbound configuration. 298 For example: 299 If there is an A record at a.b.example.com, the wildcard will not 300 match a.b.example.com or b.example.com. In this exmaple, quering 301 c.example.com will work if c.example.com is not configured in some 302 ways. If there is a A record for a.b.example.com, it indicates that 303 the a.b.exmaple.com or b.exmaple.com might exist. so under this 304 situation, a.b.exmaple.com or b.exmaple.com should configure their 305 own dbound record since a.b.exmaple.com or b.exmaple.com may be out 306 of control of the parents. 308 6. Discussion 310 This section will be removed if it is published. 312 It is an initial design. It is open to change and will follow the 313 WG's decision 315 7. IANA Considerations 317 The IANA should allocate the new DNS type for DBOUND. 319 8. Security Considerations 321 To be decided. 323 9. Acknowledgements 325 Thanks a lot for WG discussion in dbound WG. Especially thanks for 326 Andrew Sullivan and John R Levine's kind comments and helpful debate. 328 10. Change History 330 RFC Editor: Please remove this section. 332 10.1. draft-yao-dbound-dns-solution: Version 00 334 o One solution for DBOUND problem. 336 10.2. draft-yao-dbound-dns-solution: Version 01 338 o add the new method in section of discussion 340 10.3. draft-yao-dbound-dns-solution: Version 02 342 o update the draft based on the new method discussed in Japan IETF 343 meeting 2015. 345 11. References 347 11.1. Normative References 349 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 350 STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, 351 . 353 [RFC1035] Mockapetris, P., "Domain names - implementation and 354 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 355 November 1987, . 357 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 358 Requirement Levels", BCP 14, RFC 2119, 359 DOI 10.17487/RFC2119, March 1997, 360 . 362 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 363 Rose, "DNS Security Introduction and Requirements", 364 RFC 4033, DOI 10.17487/RFC4033, March 2005, 365 . 367 [RFC5585] Hansen, T., Crocker, D., and P. Hallam-Baker, "DomainKeys 368 Identified Mail (DKIM) Service Overview", RFC 5585, 369 DOI 10.17487/RFC5585, July 2009, 370 . 372 [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and 373 Verification of Domain-Based Application Service Identity 374 within Internet Public Key Infrastructure Using X.509 375 (PKIX) Certificates in the Context of Transport Layer 376 Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March 377 2011, . 379 [RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265, 380 DOI 10.17487/RFC6265, April 2011, 381 . 383 [RFC7208] Kitterman, S., "Sender Policy Framework (SPF) for 384 Authorizing Use of Domains in Email, Version 1", RFC 7208, 385 DOI 10.17487/RFC7208, April 2014, 386 . 388 11.2. Informative References 390 [Boundaries-Concepts] 391 Deccio, C. and J. Levine, "Concepts for Domain Name 392 Relationships", draft: dbound concepts, July 2015. 394 https://tools.ietf.org/html/draft-deccio-dbound-name- 395 relationships-00 397 [Boundaries-Problem] 398 Sullivan, A., Hodges, J., and J. Levine, "DBOUND: DNS 399 Administrative Boundaries Problem Statement", 400 draft: dbound problem, July 2015. 402 https://tools.ietf.org/html/draft-sullivan-dbound-problem- 403 statement-01 405 [publicsuffix.org] 406 Mozilla Foundation, "Public Suffix List", also known 407 as: Effective TLD (eTLD) List. 409 https://publicsuffix.org/ 411 Authors' Addresses 412 Jiankang Yao 413 CNNIC 414 4 South 4th Street,Zhongguancun,Haidian District 415 Beijing, Beijing 100190 416 China 418 Phone: +86 10 5881 3007 419 Email: yaojk@cnnic.cn 421 Ning Kong 422 CNNIC 423 4 South 4th Street,Zhongguancun,Haidian District 424 Beijing, Beijing 100190 425 China 427 Phone: +86 10 5881 3147 428 Email: nkong@cnnic.cn 430 Xiaodong Li 431 CNNIC 432 4 South 4th Street,Zhongguancun,Haidian District 433 Beijing, Beijing 100190 434 China 436 Phone: +86 10 5881 3020 437 Email: xl@cnnic.cn