idnits 2.17.1 draft-shuangli-dnsop-update-of-dns-cache-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. ** The abstract seems to contain references ([RFC1035]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. -- The draft header indicates that this document updates RFC1034, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. (Using the creation date from RFC1034, updated by this document, for RFC5378 checks: 1987-11-01) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (11 April 2022) is 739 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) ** Obsolete normative reference: RFC 2535 (Obsoleted by RFC 4033, RFC 4034, RFC 4035) ** Obsolete normative reference: RFC 2845 (Obsoleted by RFC 8945) Summary: 4 errors (**), 0 flaws (~~), 2 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DNSOP X. Zhang 3 Internet-Draft S. Wu 4 Updates: 1034 (if approved) Y. Qin 5 Intended status: Standards Track W. Wang 6 Expires: 13 October 2022 X. Zhou 7 Computer Network Information Center, Chinese Academy of Sciences 8 11 April 2022 10 Active Update of DNS Cache 11 draft-shuangli-dnsop-update-of-dns-cache-00 13 Abstract 15 Under the caching mechanism in [RFC1035], the local DNS server cannot 16 obtain the update status of the authoritative server in time, making 17 the data inconsistent. Shortening TTL increases server load. In the 18 passive query of the authoritative server, an active notification 19 method is added to update the DNS mapping cache of the local DNS 20 server in order to improve the efficiency of DNS resolution. 21 Authoritative servers actively send DNS update packets after updating 22 resource records. This document designs the API for receiving DNS 23 update packets on the local DNS server. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at https://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on 13 October 2022. 42 Copyright Notice 44 Copyright (c) 2022 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 49 license-info) in effect on the date of publication of this document. 50 Please review these documents carefully, as they describe your rights 51 and restrictions with respect to this document. Code Components 52 extracted from this document must include Revised BSD License text as 53 described in Section 4.e of the Trust Legal Provisions and are 54 provided without warranty as described in the Revised BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 59 1.1. Reserved Words . . . . . . . . . . . . . . . . . . . . . 3 60 2. Cache Update Message . . . . . . . . . . . . . . . . . . . . 3 61 2.1. Cache Update Message Format . . . . . . . . . . . . . . . 3 62 2.2. Transport Issues . . . . . . . . . . . . . . . . . . . . 4 63 2.3. Authentication . . . . . . . . . . . . . . . . . . . . . 4 64 2.4. The Recursive Server receives the Message from The 65 Authoritative Server . . . . . . . . . . . . . . . . . . 5 66 2.5. Tne Authoritative Server receives the Response from The 67 Recursive Server . . . . . . . . . . . . . . . . . . . . 6 68 3. DNS Update Cache API . . . . . . . . . . . . . . . . . . . . 6 69 3.1. Name . . . . . . . . . . . . . . . . . . . . . . . . . . 6 70 3.2. Synopsis . . . . . . . . . . . . . . . . . . . . . . . . 6 71 3.3. Description . . . . . . . . . . . . . . . . . . . . . . . 6 72 3.4. Return Value . . . . . . . . . . . . . . . . . . . . . . 6 73 4. Cache Update . . . . . . . . . . . . . . . . . . . . . . . . 7 74 5. Aggregation of Many Update Records for The Same 75 Destination . . . . . . . . . . . . . . . . . . . . . . . 7 76 6. Security Considerations . . . . . . . . . . . . . . . . . . . 7 77 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 78 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 79 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 82 1. Introduction 84 The user invokes the resolver through the browser to initiate a 85 domain name query, sends a DNS request to the local DNS server, first 86 checks whether there is a cache record, and then iteratively queries 87 the DNS servers at all levels. But the cached mapping between hosts 88 and hostnames and IP addresses is not permanent, and the DNS server 89 will discard the cached information after a time-to-live.[RFC1035]The 90 local DNS server cannot obtain the update status of the authoritative 91 server in time. If the cached record is within the lifetime, the 92 record has been updated in the authoritative server, which will 93 inevitably cause the data to be out of sync. If the time-to-live is 94 set too small in order to improve the synchronization rate of data, 95 the cache area will not have the effect of caching, and the name 96 server will be frequently queried, resulting in high load on the name 97 server and low resolution efficiency. 99 The mapping cache is updated in a way that combines passive queries 100 from local DNS servers with active notifications from authoritative 101 servers. This method improves the problem of inconsistency between 102 authoritative server records and local DNS server records caused by 103 record updates in authoritative servers. This method not only 104 improves the parsing efficiency, but also reduces the query load of 105 the authoritative server. 107 Compared to using NOTIFY message[RFC1996] to notify remote triggering 108 of cache refresh, the active update cache mechanism provides a new 109 API to receive and update specific data, and relieves the recursive 110 server's receiving and updating pressure. 112 This document designs the API on the local DNS server to receive DNS 113 update packets. If the resource record in the authoritative server 114 is updated, the authoritative server will push the record in the form 115 of an update package to all local servers that have the original 116 record in the cache. The sending mechanism of the update package is 117 resolved by other drafts. 119 1.1. Reserved Words 121 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 122 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 123 document are to be interpreted as described in [RFC2119] . 125 2. Cache Update Message 127 2.1. Cache Update Message Format 129 The DNS message format is defined by [RFC1035], refer to the domain 130 name dynamic update message format [RFC2136], and make some necessary 131 changes. Define new DNS opcodes CACHED UPDATE and new DNS request. 133 The overall format of an CACHED UPDATE message is, following: 135 +---------------------+ 136 | Header | 137 +---------------------+ 138 | Zone | specifies the zone to be updated 139 +---------------------+ 140 | Original | Original RRs 141 +---------------------+ 142 | Update | RRs to be updated 143 +---------------------+ 144 | Additional Data | 145 +---------------------+ 147 The Header section specifies that this message is a CACHED UPDATE, 148 and describes the size of the other sections. The Original section 149 contains the original resource record of the resource record to be 150 updated. The Update section contains the resource records to update. 151 The Additional Data section contains data that may be required to 152 complete this update but is not part of this update. Using the 153 DNSSEC mechanism for security verification, the additional data 154 packet contains the digital signature RRSIG. CACHED UPDATE satisfies 155 the prerequisites that the original RR must exist. 157 2.2. Transport Issues 159 An update transaction may be carried in a UDP datagram or in a TCP 160 connection. 162 The advantage of using UDP datagram is that the channel utilization 163 rate is high, and there is no need to establish a long-term 164 connection between the client and the server. But the disadvantage 165 is low reliability. If the transmission fails, the synchronization 166 of the record will be greatly reduced. If the recursive server is 167 missing, the database space in the authoritative server will be 168 wasted. 170 The advantage of using TCP connection is high reliability, but it has 171 the disadvantages of low channel utilization and high sending 172 pressure on authoritative servers. 174 2.3. Authentication 176 Since update messages from authoritative servers are delivered 177 through insecure channels, anyone can change the cached RRs in the 178 local DNS server. To keep records safe, updating the DNS cache must 179 be authenticated. 181 TSIG is a mechanism for securing DNS messages [RFC2845]. Because 182 TSIG RRs are only associated with a DNS request/response, once used 183 to validate DNS messages are discarded and cannot be cached. 184 Moreover, TSIG belongs to symmetric encryption, which requires both 185 parties to the transaction to be trusted. Therefore, TSIG is not 186 suitable for a mechanism where an authoritative server may send 187 update messages multiple times within a certain period of time. 189 The private signature key and public key system in the blockchain is 190 used to ensure the credibility of the source of the update record. 191 Moreover, each update record is formed into a chain data structure by 192 calculating the Hash value of each block to ensure the traceability 193 of the update. 195 The DNSSEC mechanism provides data integrity and authentication to 196 security-aware resolvers and applications through the use of 197 cryptographic digital signatures [RFC2535]. An authoritative DNS 198 server signs a resource record with a private key, and the local DNS 199 server verifies it with the corresponding public key. If validation 200 fails, the update message may not have been issued by an 201 authoritative DNS server in this zone. 203 The local DNS server requests a query from the authoritative server, 204 and the authoritative server replies with a response record carrying 205 the digital signature RRSIG. The local DNS server obtains the public 206 key DNSKEY resource record by sending a query message for the public 207 key, and stores the record in the database corresponding to the area 208 to which it belongs. When the authoritative DNS server sends an 209 update message carrying a digital signature to the local DNS server, 210 the local DNS server searches the DNSKEY record according to the 211 zone. 213 2.4. The Recursive Server receives the Message from The Authoritative 214 Server 216 After the recursive server receives cache updates, it updates 217 specific data at the right time. 219 To confirm that the recursive server has received the updated data, 220 the recursive server replies to the source with a NOTIFY response 221 message. [RFC1996] describes the characteristics of the NOTIFY 222 response. 224 2.5. Tne Authoritative Server receives the Response from The Recursive 225 Server 227 After the authoritative server receives a response from a set of 228 recursive servers corresponding to specific data, it deletes the 229 record from the update queue. An active update of the recursive 230 server cache by the authoritative server completes. 232 3. DNS Update Cache API 234 3.1. Name 236 DNS_cached_update - Receive update packets sent by authoritative 237 servers, resolve update packets, and update cache. 239 3.2. Synopsis 241 DNS_cached_update(int sockfd, void *buff, size_t nbytes, struct 242 sockaddr *from, socklen_t *addrlen) 244 3.3. Description 246 The DNS_cached_update() function receives the message from the 247 connectionless mode socket, parses the update information from the 248 message, and updates the cache. It is often used with connectionless 249 mode sockets because it allows applications to retrieve the source 250 address from which data is received. 252 sockfd - a descriptor that identifies a connected socket 253 buff - Receive data buffer 254 nbytes - Receive data buffer size 255 from - A socket address structure pointing to the protocol address 256 of the datagram sender 257 addrlen - The length of the socket address structure of the protocol 258 address of the datagram sender 260 3.4. Return Value 262 Upon successful completion, DNS_cached_update() returns the length of 263 the message in bytes. Otherwise the function returns -1 and sets 264 errno to indicate the error. 266 4. Cache Update 268 Inside the name server, the data structure is mainly divided into 269 directory data structure, separate data structure for each zone, and 270 data structure for cached data. All data structures implement the 271 same tree structure format [RFC1035]. In cache data structures, data 272 is stored in RR. Query processing will need to traverse the tree 273 using case-insensitive label comparisons. During cache updates, the 274 directory structure is used to store parameters used to control 275 update activity. 277 The RR format is defined by [RFC1035]. Use the node name NAME in RR 278 to query, if the query is successful, update the value of RDATA 279 according to TYPE and CLASS. 281 5. Aggregation of Many Update Records for The Same Destination 283 If the destination recursive server with a large number of update 284 records in the update queue of the authoritative server is the same, 285 then the authoritative server directly sends a cache refresh message 286 to the destination recursive server. 288 After receiving the message, the destination recursive server sends a 289 refresh request to the authoritative server, advances the refresh 290 time, and sends a response message to the authoritative server. 292 After the authoritative server receives the response, it deletes all 293 update records destined for this recursive server in the queue, so as 294 to improve the active update efficiency of the authoritative server. 296 6. Security Considerations 298 This document clarifies correct DNS server behavior and does not 299 introduce any changes or new security considerations. 301 7. IANA Considerations 303 There are no actions for IANA. 305 8. Acknowledgements 307 The authors wish to thank Shuangli Wu, YiFang Qin for their input. 309 9. References 311 [RFC1035] Mockapetris, P., "Domain names - implementation and 312 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 313 November 1987, . 315 [RFC1996] Vixie, P., "A Mechanism for Prompt Notification of Zone 316 Changes (DNS NOTIFY)", RFC 1996, DOI 10.17487/RFC1996, 317 August 1996, . 319 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 320 Requirement Levels", BCP 14, RFC 2119, 321 DOI 10.17487/RFC2119, March 1997, 322 . 324 [RFC2136] Vixie, P., Ed., Thomson, S., Rekhter, Y., and J. Bound, 325 "Dynamic Updates in the Domain Name System (DNS UPDATE)", 326 RFC 2136, DOI 10.17487/RFC2136, April 1997, 327 . 329 [RFC2535] Eastlake 3rd, D., "Domain Name System Security 330 Extensions", RFC 2535, DOI 10.17487/RFC2535, March 1999, 331 . 333 [RFC2845] Vixie, P., Gudmundsson, O., Eastlake 3rd, D., and B. 334 Wellington, "Secret Key Transaction Authentication for DNS 335 (TSIG)", RFC 2845, DOI 10.17487/RFC2845, May 2000, 336 . 338 Authors' Addresses 340 Xinqing Zhang 341 Computer Network Information Center, Chinese Academy of Sciences 342 Email: zhangxinqing21@mails.ucas.ac.cn 344 Shuangli Wu 345 Computer Network Information Center, Chinese Academy of Sciences 346 Email: wushuangli@cnic.cn 348 Yifang Qin 349 Computer Network Information Center, Chinese Academy of Sciences 350 Email: qinyf@cnic.cn 352 Wei Wang 353 Computer Network Information Center, Chinese Academy of Sciences 354 Email: wangwei@cnic.cn 356 Xu Zhou 357 Computer Network Information Center, Chinese Academy of Sciences 358 Email: zhouxu@cnic.cn