Active Update of DNS Cache

Introduction 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.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 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.

Reserved Words 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 .

Cache Update Message

Cache Update Message Format The DNS message format is defined by , refer to the domain name dynamic update message format , 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.

Transport Issues 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.

Authentication 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 . 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 . 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 have been 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.

The Recursive Server receives the Message from The Authoritative Server 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. describes the characteristics of the NOTIFY response.

Tne Authoritative Server receives the Response from The Recursive Server 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 Update Cache API

Name DNS_cached_update - Receive update packets sent by authoritative servers, resolve update packets, and update cache.

Synopsis DNS_cached_update(int sockfd, void *buff, size_t nbytes, struct sockaddr *from, socklen_t *addrlen)

Description 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

Return Value 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.

Cache Update 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 . 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 . Use the node name NAME in RR to query, if the query is successful, update the value of RDATA according to TYPE and CLASS.

Aggregation of Many Update Records for The Same Destination 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.

Security Considerations This document clarifies correct DNS server behavior and does not introduce any changes or new security considerations.

IANA Considerations There are no actions for IANA.

Acknowledgements The authors wish to thank Shuangli Wu, YiFang Qin for their input.