Internet-Draft Active Update of DNS Cache April 2022
Zhang, et al. Expires 13 October 2022 [Page]
Workgroup:
DNSOP
Internet-Draft:
draft-shuangli-dnsop-update-of-dns-cache-01
Updates:
1034 (if approved)
Published:
Intended Status:
Standards Track
Expires:
Authors:
X. Zhang
Computer Network Information Center, Chinese Academy of Sciences
S. Wu
Computer Network Information Center, Chinese Academy of Sciences
Y. Qin
Computer Network Information Center, Chinese Academy of Sciences
W. Wang
Computer Network Information Center, Chinese Academy of Sciences
X. Zhou
Computer Network Information Center, Chinese Academy of Sciences

Active Update of DNS Cache

Abstract

Under the caching mechanism in [RFC1035], the local DNS server cannot obtain the update status of the authoritative server in time, making 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.

Status of This Memo

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 13 October 2022.

Table of Contents

1. 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.[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.

1.1. 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 [RFC2119] .

2. Cache Update Message

2.1. Cache Update Message Format

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.

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

2.3. 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 [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 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.

2.4. 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. [RFC1996] describes the characteristics of the NOTIFY response.

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

3. DNS Update Cache API

3.1. Name

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

3.2. Synopsis

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

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

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

4. 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 [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.

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

6. Security Considerations

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

7. IANA Considerations

There are no actions for IANA.

8. Acknowledgements

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

9. References

[RFC1035]
Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, , <https://www.rfc-editor.org/info/rfc1035>.
[RFC1996]
Vixie, P., "A Mechanism for Prompt Notification of Zone Changes (DNS NOTIFY)", RFC 1996, DOI 10.17487/RFC1996, , <https://www.rfc-editor.org/info/rfc1996>.
[RFC2119]
Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, , <https://www.rfc-editor.org/info/rfc2119>.
[RFC2136]
Vixie, P., Ed., Thomson, S., Rekhter, Y., and J. Bound, "Dynamic Updates in the Domain Name System (DNS UPDATE)", RFC 2136, DOI 10.17487/RFC2136, , <https://www.rfc-editor.org/info/rfc2136>.
[RFC2535]
Eastlake 3rd, D., "Domain Name System Security Extensions", RFC 2535, DOI 10.17487/RFC2535, , <https://www.rfc-editor.org/info/rfc2535>.
[RFC2845]
Vixie, P., Gudmundsson, O., Eastlake 3rd, D., and B. Wellington, "Secret Key Transaction Authentication for DNS (TSIG)", RFC 2845, DOI 10.17487/RFC2845, , <https://www.rfc-editor.org/info/rfc2845>.

Authors' Addresses

Xinqing Zhang
Computer Network Information Center, Chinese Academy of Sciences
Shuangli Wu
Computer Network Information Center, Chinese Academy of Sciences
Yifang Qin
Computer Network Information Center, Chinese Academy of Sciences
Wei Wang
Computer Network Information Center, Chinese Academy of Sciences
Xu Zhou
Computer Network Information Center, Chinese Academy of Sciences

mirror server hosted at Truenetwork, Russian Federation.