| Internet-Draft | Active Update of DNS Cache | July 2022 |
| Zhang, et al. | Expires 8 January 2023 | [Page] |
Under the caching mechanism in [RFC1035], the local DNS server cannot obtain the update status of the authoritative server in time, this makes the data inconsistent. Shortening TTL increases server load. In the passive query of the authoritative server, an active notification method is added to update the DNS mapping cache of the local DNS server in order to improve the efficiency of DNS resolution. Authoritative servers actively send DNS update packets after updating resource records. This document designs the API for receiving DNS update packets on the local DNS server.¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 8 January 2023.¶
Copyright (c) 2022 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
The user invokes the resolver through the browser to initiate a domain name query, sends a DNS request to the local DNS server, first checks whether there is a cache record, and then iteratively queries the DNS servers at all levels. But the cached mapping between hosts and hostnames and IP addresses is not permanent, and the DNS server will discard the cached information after a time-to-live.[RFC1035]The local DNS server cannot obtain the update status of the authoritative server in time. If the cached record is within the lifetime, the record has been updated in the authoritative server, which will inevitably cause the data to be out of sync. If the time-to-live is set too small in order to improve the synchronization rate of data, the cache area will not have the effect of caching, and the name server will be frequently queried, resulting in high load on the name server and low resolution efficiency.¶
The mapping cache is updated in a way that combines passive queries from local DNS servers with active notifications from authoritative servers. This method improves the problem of inconsistency between authoritative server records and local DNS server records caused by record updates in authoritative servers. This method not only improves the parsing efficiency, but also reduces the query load of the authoritative server.¶
Compared to using NOTIFY message[RFC1996] to notify remote triggering of cache refresh, the active update cache mechanism provides a new API to receive and update specific data, and relieves the recursive server's receiving and updating pressure.¶
This document designs the API on the local DNS server to receive DNS update packets. If the resource record in the authoritative server is updated, the authoritative server will push the record in the form of an update package to all local servers that have the original record in the cache. The sending mechanism of the update package is resolved by other drafts.¶
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119] .¶
The DNS message format is defined by [RFC1035], refer to the domain name dynamic update message format [RFC2136], and make some necessary changes. Define new DNS opcodes CACHED UPDATE and new DNS request.¶
The overall format of an CACHED UPDATE message is, following:¶
+---------------------+ | Header | +---------------------+ | Zone | specifies the zone to be updated +---------------------+ | Original | Original RRs +---------------------+ | Update | RRs to be updated +---------------------+ | Additional Data | +---------------------+¶
The Header section specifies that this message is a CACHED UPDATE, and describes the size of the other sections. The Original section contains the original resource record of the resource record to be updated. The Update section contains the resource records to update. The Additional Data section contains data that may be required to complete this update but is not part of this update. Using the DNSSEC mechanism for security verification, the additional data packet contains the digital signature RRSIG. CACHED UPDATE satisfies the prerequisites that the original RR must exist.¶
An update transaction may be carried in a UDP datagram or in a TCP connection.¶
The advantage of using UDP datagram is that the channel utilization rate is high, and there is no need to establish a long-term connection between the client and the server. But the disadvantage is low reliability. If the transmission fails, the synchronization of the record will be greatly reduced. If the recursive server is missing, the database space in the authoritative server will be wasted.¶
The advantage of using TCP connection is high reliability, but it has the disadvantages of low channel utilization and high sending pressure on authoritative servers.¶
Since update messages from authoritative servers are delivered through insecure channels, anyone can change the cached RRs in the local DNS server. To keep records safe, updating the DNS cache must be authenticated.¶
TSIG is a mechanism for securing DNS messages [RFC2845]. Because TSIG RRs are only associated with a DNS request/response, once used to validate DNS messages are discarded and cannot be cached. Moreover, TSIG belongs to symmetric encryption, which requires both parties to the transaction to be trusted. Therefore, TSIG is not suitable for a mechanism where an authoritative server may send update messages multiple times within a certain period of time.¶
The private signature key and public key system in the blockchain is used to ensure the credibility of the source of the update record. Moreover, each update record is formed into a chain data structure by calculating the Hash value of each block to ensure the traceability of the update.¶
The DNSSEC mechanism provides data integrity and authentication to security-aware resolvers and applications through the use of cryptographic digital signatures [RFC2535]. An authoritative DNS server signs a resource record with a private key, and the local DNS server verifies it with the corresponding public key. If validation fails, the update message may not be issued by an authoritative DNS server in this zone.¶
The local DNS server requests a query from the authoritative server, and the authoritative server replies with a response record carrying the digital signature RRSIG. The local DNS server obtains the public key DNSKEY resource record by sending a query message for the public key, and stores the record in the database corresponding to the area to which it belongs. When the authoritative DNS server sends an update message carrying a digital signature to the local DNS server, the local DNS server searches the DNSKEY record according to the zone.¶
After the recursive server receives cache updates, it updates specific data at the right time.¶
To confirm that the recursive server has received the updated data, the recursive server replies to the source with a NOTIFY response message. [RFC1996] describes the characteristics of the NOTIFY response.¶
After the authoritative server receives a response from a set of recursive servers corresponding to specific data, it deletes the record from the update queue. An active update of the recursive server cache by the authoritative server completes.¶
DNS_cached_update - Receive update packets sent by authoritative servers, resolve update packets, and update cache.¶
DNS_cached_update(int sockfd, void *buff, size_t nbytes, struct sockaddr *from, socklen_t *addrlen)¶
The DNS_cached_update() function receives the message from the connectionless mode socket, parses the update information from the message, and updates the cache. It is often used with connectionless mode sockets because it allows applications to retrieve the source address from which data is received.¶
sockfd - a descriptor that identifies a connected socket buff - Receive data buffer nbytes - Receive data buffer size from - A socket address structure pointing to the protocol address of the datagram sender addrlen - The length of the socket address structure of the protocol address of the datagram sender¶
Upon successful completion, DNS_cached_update() returns the length of the message in bytes. Otherwise the function returns -1 and sets errno to indicate the error.¶
Inside the name server, the data structure is mainly divided into directory data structure, separate data structure for each zone, and data structure for cached data. All data structures implement the same tree structure format [RFC1035]. In cache data structures, data is stored in RR. Query processing will need to traverse the tree using case-insensitive label comparisons. During cache updates, the directory structure is used to store parameters used to control update activity.¶
The RR format is defined by [RFC1035]. Use the node name NAME in RR to query, if the query is successful, update the value of RDATA according to TYPE and CLASS.¶
If the destination recursive server with a large number of update records in the update queue of the authoritative server is the same, then the authoritative server directly sends a cache refresh message to the destination recursive server.¶
After receiving the message, the destination recursive server sends a refresh request to the authoritative server, advances the refresh time, and sends a response message to the authoritative server.¶
After the authoritative server receives the response, it deletes all update records destined for this recursive server in the queue, so as to improve the active update efficiency of the authoritative server.¶
This document clarifies correct DNS server behavior and does not introduce any changes or new security considerations.¶
There are no actions for IANA.¶
The authors wish to thank Shuangli Wu, YiFang Qin for their input.¶