idnits 2.17.1 draft-yaoyuan-dnsext-idr-adr-00.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 : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. == There are 6 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 == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: o ADR is only used for authorization check and SHOULD not be included in answers when a resolver sends response packets to users. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: o For each node and leaf on the tree-style domain name space, there MUST be at most one IDR record for each in the corresponding database, the number of ADR MUST not be limited. -- The document date (April 17, 2020) is 1470 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'EDNS0' is mentioned on line 237, but not defined == Unused Reference: 'RFC2671' is defined on line 466, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2671 (Obsoleted by RFC 6891) ** Obsolete normative reference: RFC 2672 (Obsoleted by RFC 6672) Summary: 3 errors (**), 0 flaws (~~), 6 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Infrastructure System Engineering Group Y. Chen 3 Internet-Draft Baidu 4 Intended status: Informational April 17, 2020 5 Expires: October 17, 2020 7 Invisible Canonical Name Implementation 8 draft-yaoyuan-dnsext-idr-adr-00 10 Status of this Memo 12 This Internet-Draft is submitted to IETF in full conformance with the 13 provisions of BCP 78 and BCP 79. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as 18 Internet-Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt. 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 This Internet-Draft will expire on October 17, 2020. 33 Copyright Notice 35 Copyright (c) 2020 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents 40 (http://trustee.ietf.org/license-info) in effect on the date of 41 publication of this document. Please review these documents 42 carefully, as they describe your rights and restrictions with respect 43 to this document. Code Components extracted from this document must 44 include Simplified BSD License text as described in Section 4.e of 45 the Trust Legal Provisions and are provided without warranty as 46 described in the Simplified BSD License. 48 Abstract 50 To accomplish the goal that not exposing redundant and unuseful CNAME 51 chains in answers responded to clients, this document describes two 52 new DNS resource records called "IDR" and "ADR" for hiding CNAME 53 iterative process and better safety consideration. 55 1. Introduction 57 The CNAME record presented in [RFC1034] and [RFC1035] nowadays is 58 widely used to complete different functions. Simultaneously the 59 record begins to show signs of weakness when helping engineers solve 60 complex technical problems during increasingly complicated network 61 environment. There are three fundamental flaws about CNAME and a 62 scene which it cannot fit in: 64 o Unnecessary and massive consumption of network bandwidth in 65 traffic between clients and name resolvers if a chain with 66 multi-CNAMEs is contained in answer section. Actually these 67 CNAMEs are useless at all for clients. 69 o The abuse of canonical names without authentication. Today we 70 can easily configure a name redirected to a famous website 71 without getting permission of the owner. Although website users 72 with dns knowledge finally will know it is an alias after 73 looking through the resolving process (someone not) and resource 74 servers may take some security defence to deny illegal access, 75 it still cause a tort about private intellectual property of 76 real service providers. Maybe we can take some measures in dns 77 layer. 79 o CNAME chains in authoritative name servers MAY cause dns 80 hijacking. As a name server will continue to find answers in 81 internal cache, the upper servers could give answers those not 82 equal to the real authoritative servers without validation. 84 o In certain special circumstances or requirements, services 85 providers closest to users side are not willing to present the 86 intermediate process of the CNAMEs to customers. Certainly they 87 MUST ask for permission of the original content administrators 88 at first. 90 To solve the above problems, we define two new DNS Resource Records 91 with some extensions to current DNS rules.The changes are designed to 92 be compatible with existing software. The existing support for CNAME 93 and DNAME[RFC2672] is retained. 95 2. Terminology 97 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 98 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 99 document are to be interpreted as described in BCP 14, [RFC2119]. 101 3. The "IDR" and "ADR" Resource Record 103 IDR means "Invisible Direct Reference", it looks like a transparent 104 agent who borrows resource records from others. The users cannot feel 105 the agency process in detail. IDR means "Allow Direct Reference", 106 which supplies a mechanism for safe references with permission. IDR 107 and ADR have the following format: 109 IDR: IDR 110 ADR: ADR 112 Like a normal record, all fields are required. The DATA field 113 is a fully qualified [RFC1035] which MUST be 114 in uncompressed form transferred in dns message. Both of records 115 include a TTL value that represents the maximum time-to-live for a 116 cached response in a resolver. 118 IDR and ADR have the same behaviours as CNAME except the following 119 features: 121 o when a authoritative server deals with a query, return directly 122 back to the asker when an IDR record is found rather than fall 123 into deeply more queries process in its own name tree. 125 o ADR is only used for authorization check and SHOULD not be 126 included in answers when a resolver sends response packets to 127 users. 129 o When a resolver receives an IDR answer from a server, it MUST 130 substitute the QNAME with IDR's and restart an 131 additional query of QTYPE ADR. If the answer section includes 132 the original QNAME(authentication passed), then the query 133 process for original QTYPE can be continued. 135 o Such kind of node as present in of IDL in answers MUST 136 be removed if there is an IDR-ADR pair. 138 The co-existence relationships among IDR/ADR and CNAME/DNAME: 140 o IDR and ADR: YES 142 o IDR and CNAME/DNAME: NO 144 o ADR and CNAME/DNAME: YES 146 o For each node and leaf on the tree-style domain name space, 147 there MUST be at most one IDR record for each in the 148 corresponding database, the number of ADR MUST not be limited. 150 4. Query Processing 152 To complete the IDR/ADR mechanism the updating algorithms [RFC2136] 153 and the name running algorithms [RFC1034][RFC2672] must be modified 154 slightly for both servers and resolvers. 156 4.1. Processing By Primary Master Servers 158 The following comparison rule SHOULD be added in the end of chapter 159 1.1.5. in [RFC2136]. 161 IDL compare only NAME, CLASS, and TYPE -- it is not possible 162 to have more than one IDL RR, even if their data fields 163 differ. 165 Meanwhile, ADLs SHOULD be allowed to co-exist with CNAME, DNAME, NS. 167 4.2. Processing By Authoritative Servers 169 For a server performing non-recursive service steps 3.a and 5 of 170 section 4.3.2 [RFC1034][RFC2672] are changed to check for a IDL 171 record after checking for a CNAME type, and to make a pretreatment 172 before packaging response message. 174 DNS clients sending Extended DNS [EDNS0] queries with Version 0 or 175 non-extended queries are presumed not to understand the semantics of 176 the IDR/ADR record, so a server which implements this specification, 177 when answering a non-extended query, SHOULD give out a CNAME record 178 for each IDR record encountered during query processing to help the 179 client reach the correct DNS data. The behaviour of clients and 180 servers under Extended DNS versions greater than 0 will be specified 181 when those versions are defined. 183 The revised server algorithm is: 185 1. Set or clear the value of recursion available in the response 186 depending on whether the name server is willing to provide 187 recursive service. If recursive service is available and 188 requested via the RD bit in the query, go to step 5, otherwise 189 step 2. 191 2. Search the available zones for the zone which is the nearest 192 ancestor to QNAME. If such a zone is found, go to step 3, 193 otherwise step 4. 195 3. Start matching down, label by label, in the zone. The matching 196 process can terminate several ways: 198 a. If the whole of QNAME is matched, we have found the node. 200 If the data at the node is a CNAME, and QTYPE doesn't match 201 CNAME, copy the CNAME RR into the answer section of the 202 response, change QNAME to the canonical name in the CNAME RR, 203 and go back to step 1. 205 Else if the data at the node is a IDL, and QTYPE doesn't match 206 IDL, copy the IDL RR into the answer section of the 207 response. If the query was not 208 extended [EDNS0] with a Version indicating understanding of the 209 IDL record, the server SHOULD make a substitution of CNAME for 210 of RR already put in answer, then go back to step 6. The 211 reason of not going back to step 1 is 212 that it prevents the upper servers from hijacking dns data 213 which SHOULD be responded by others who are authorized to 214 answer. 216 Otherwise, copy all RRs which match QTYPE into the answer 217 section and go to step 6. 219 b. If a match would take us out of the authoritative data, we have 220 a referral. This happens when we encounter a node with NS RRs 221 marking cuts along the bottom of a zone. 223 Copy the NS RRs for the subzone into the authority section of 224 the reply. Put whatever addresses are available into the 225 additional section, using glue RRs if the addresses are not 226 available from authoritative data or the cache. Go to step 4. 228 c. If at some label, a match is impossible (i.e., the 229 corresponding label does not exist), look to see whether the 230 last label matched has a DNAME record. 232 If a DNAME record exists at that point, copy that record into 233 the answer section. If substitution of its for its 234 in QNAME would overflow the legal size for a , set RCODE to YXDOMAIN and exit; otherwise 236 perform the substitution and continue. If the query was not 237 extended [EDNS0] with a Version indicating understanding of the 238 DNAME record, the server SHOULD synthesize a CNAME record as 239 described above and include it in the answer section. Go back 240 to step 1. 242 If there was no DNAME record, look to see if the "*" label 243 exists. 245 If the "*" label does not exist, check whether the name we are 246 looking for is the original QNAME in the query or a name we 247 have followed due to a CNAME. If the name is original, set an 248 authoritative name error in the response and exit. Otherwise 249 just exit. 251 If the "*" label does exist, match RRs at that node against 252 QTYPE. If any match, copy them into the answer section, but 253 set the owner of the RR to be QNAME, and not the node with the 254 "*" label. Go to step 6. 256 4. Start matching down in the cache. If QNAME is found in the cache, 257 copy all RRs attached to it that match QTYPE into the answer 258 section. If QNAME is not found in the cache but a DNAME record is 259 present at an ancestor of QNAME, copy that DNAME record into the 260 answer section. If there was no delegation from authoritative 261 data, look for the best one from the cache, and put it in the 262 authority section. Go to step 6. 264 5. Use the local resolver or a copy of its algorithm (see resolver 265 section of this memo) to answer the query. Store the results, 266 including any intermediate CNAMEs, DNAMEs in the answer section of 267 the response, including two nodes which are connected 268 by an IDL/ADL pair(not added) pointing to each other. 270 6. Using local data only, attempt to add other RRs which may be 271 useful to the additional section of the query. Exit. 273 Note that the IDLs SHOULD be also sent to clients with status 274 "refused" if there are not corresponding ADLs found. 276 4.3. Processing By Resolvers 278 A resolver or a server providing recursive service MUST be modified 279 to treat a IDL as somewhat analogous to a CNAME with some 280 differences. 281 The resolver algorithm of [RFC1034][RFC2672] section 5.3.3 is 282 modified to renumber step 4.e as 4.f, 4.d as 4.e and insert a new 283 4.d. The complete algorithm becomes: 285 1. See if the answer is in local information, and if so return it to 286 the client. 288 2. Find the best servers to ask. 290 3. Send them queries until one returns a response. 292 4. Analyze the response, either: 294 a. if the response answers the question or contains a name error, 295 cache the data as well as returning it back to the client. 297 b. if the response contains a better delegation to other servers, 298 cache the delegation information, and go to step 2. 300 c. if the response shows a CNAME and that is not the answer 301 itself, cache the CNAME, change the SNAME to the canonical name 302 in the CNAME RR and go to step 1. 304 d. if the response shows a IDL and that is not the answer 305 itself, cache the IDL, preserve the original QNAME and QTYPE, 306 change the QNAME with the in the IDL RR and restart an 307 ADL query in local database or outside name servers. If 308 returned results do not contain a ADL, terminate the process 309 with RCODE refused. Else if one or more ADLs are found, cache 310 them and judge if the original QNAME is included. If YES, 311 change back to original QTYPE and go to step 1, else return 312 the answer to the client with RCODE refused. 314 e. if the response shows a DNAME and that is not the answer 315 itself, cache the DNAME. If substitution of the DNAME's 316 for its in the SNAME would overflow the legal 317 size for a , return an implementation-dependent 318 error to the application; otherwise perform the substitution 319 and go to step 1. 321 f. if the response shows a server failure or other bizarre 322 contents, delete the server from the SLIST and go back to step 323 3. 325 Before sending the records in answer section to the client, we MUST 326 eliminate such kind of nodes which own this feature: the node is the 327 in a IDL record, and it allows the to reference the 328 records inside the node. In other words, the node has a IDL 329 redirecting to another node which also has a ADL to authorize the 330 jumping behaviour. 332 5. Examples of Use 334 5.1. Simple Mapping 336 If the zone data for the FOO.EXAMPLE domain contains: 338 WWW.FOO.EXAMPLE IDL WWW.BAR.EXAMPLE 340 And the zone data for the BAR.EXAMPLE domain contains: 342 WWW.BAR.EXAMPLE ADL WWW.FOO.EXAMPLE 343 A 1.2.3.4 345 When a client send a query of type A for WWW.FOO.EXAMPLE, it will get 346 a response as: 348 WWW.FOO.EXAMPLE A 1.2.3.4 350 The client will not feel the existence of the intermediate node 351 WWW.BAR.EXAMPLE when receiving answer from a resolver. We suggest a 352 dns software which implements this specification could provide a 353 method to present the detailed query process since it is convenient 354 for operations staff to locate and solve problems related to dns. 356 5.2. Multilayer Mapping 358 If dns name space includes the chain structure below: 360 IDL IDL IDL IDL 361 ------> ------> ------> ------> matched calss 362 entrance node ---> N1 N2 N3 ... Nn ------> target 363 <------ <------ <------ <------ matched type 364 ADL ADL ADL ADL 366 According to the processing rules, clients will only see the target 367 in answer section with original QTYPE eventually. The nodes from N1 368 to Nn will be silently removed by resolvers when encoding the 369 response packets. 371 5.3. Interaction with CNAME 373 If the zone data for the FOO.EXAMPLE domain contains: 375 WWW.FOO.EXAMPLE CNAME WWW.BAR.EXAMPLE 377 The zone data for the BAR.EXAMPLE domain contains: 379 WWW.BAR.EXAMPLE IDL WWW.BAZ.EXAMPLE 381 The zone data for the BAR.EXAMPLE domain contains: 383 WWW.BAZ.EXAMPLE ADL WWW.BAR.EXAMPLE 384 CNAME WWW.QUX.EXAMPLE 386 And the zone data for the QUX.EXAMPLE domain contains: 388 WWW.QUX.EXAMPLE A 1.2.3.4 390 When a client send a query of type A for WWW.FOO.EXAMPLE, it will get 391 a response as: 393 WWW.FOO.EXAMPLE CNAME WWW.BAR.EXAMPLE 394 WWW.BAR.EXAMPLE CNAME WWW.QUX.EXAMPLE 395 WWW.QUX.EXAMPLE A 1.2.3.4 397 5.4. Interaction with DNAME 399 If the zone data for the FOO.EXAMPLE domain contains: 401 WWW.FOO.EXAMPLE IDL WWW.FROBOZZ.EXAMPLE 403 The zone data for the FROBOZZ.EXAMPLE domain contains: 405 WWW.FROBOZZ.EXAMPLE ADL WWW.FOO.EXAMPLE 406 FROBOZZ.EXAMPLE DNAME FROBOZZ-DIVISION.ACME.EXAMPLE 408 The zone data for the ACME.EXAMPLE domain contains: 410 WWW.FROBOZZ-DIVISION.ACME.EXAMPLE A 1.2.3.4 412 When a client send a query of type A for WWW.FOO.EXAMPLE, it will get 413 a response as: 415 WWW.FOO.EXAMPLE CNAME WWW.FROBOZZ-DIVISION.ACME.EXAMPLE 416 WWW.FROBOZZ-DIVISION.ACME.EXAMPLE A 1.2.3.4 418 The ADL record MUST be arranged in the zone file of domain 419 "FROBOZZ.EXAMPLE", otherwise it will meet a DNAME and terminate the 420 query process because of the non-existance of ADL. 422 The above examples are based on an extended recursive queries with 423 EDNS over Version 0 from clients. 425 5.5. Handling queries with non-extended EDNS or EDNS with Version 0 427 When authoritative Servers see such a kind of query, they MUST treat 428 IDL as a normal CNAME if exist. 429 ADLs MUST be ignored and RCODE MUST be set to NXDOMAIN if there are 430 not other kinds of records at all except ADLs inside the node. 432 6. Security Considerations 434 The IDL/ADL records are similar to the CNAME record with regard to 435 quoting resource records which have existed in other domains, 436 differing in that the usage is safer than CNAME and do good to 437 lighten pressure on network load. 439 7. IANA Considerations 441 IANA may agree the allocation of these two records in the dns type 442 registry if the specification is proved to be reasonable in the 443 future. 445 8. References 447 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 448 STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, 449 . 451 [RFC1035] Mockapetris, P., "Domain names - implementation and 452 specification", 453 STD 13, RFC 1035, DOI 10.17487/RFC1035, November 1987, 454 . 456 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 457 Requirement Levels", BCP 14, RFC 2119, 458 DOI 10.17487/RFC2119, March 1997, 459 . 461 [RFC2136] Vixie, P., Ed., Thomson, S., Rekhter, Y., and J. Bound, 462 "Dynamic Updates in the Domain Name System (DNS UPDATE)", 463 RFC 2136, DOI 10.17487/RFC2136, April 1997, 464 . 466 [RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", 467 RFC 2671, DOI 10.17487/RFC2671, August 1999, 468 . 470 [RFC2672] Crawford, M., "Non-Terminal DNS Name Redirection", 471 RFC 2672, DOI 10.17487/RFC2672, August 1999, 472 . 474 Authors' Addresses 476 Yaoyuan Chen 477 Beijing Baidu Netcom Science Technology Co., Ltd 478 No. 10 Shangdi 10th Street, Haidian District 479 Beijing of China 481 Phone: +86-18801393917 482 Email: chenyaoyuan@baidu.com