Internet DRAFT - draft-shuangli-dnsop-update-of-dns-cache
draft-shuangli-dnsop-update-of-dns-cache
DNSOP X. Zhang
Internet-Draft S. Wu
Updates: 1034 (if approved) Y. Qin
Intended status: Experimental W. Wang
Expires: 8 January 2023 X. Zhou
Computer Network Information Center, Chinese Academy of Sciences
7 July 2022
Active Update of DNS Cache
draft-shuangli-dnsop-update-of-dns-cache-01
Abstract
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.
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 8 January 2023.
Copyright Notice
Copyright (c) 2022 IETF Trust and the persons identified as the
document authors. All rights reserved.
Zhang, et al. Expires 8 January 2023 [Page 1]
Internet-Draft Active Update of DNS Cache July 2022
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.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Reserved Words . . . . . . . . . . . . . . . . . . . . . 3
2. Cache Update Message . . . . . . . . . . . . . . . . . . . . 3
2.1. Cache Update Message Format . . . . . . . . . . . . . . . 3
2.2. Transport Issues . . . . . . . . . . . . . . . . . . . . 4
2.3. Authentication . . . . . . . . . . . . . . . . . . . . . 4
2.4. The Recursive Server receives the Message from The
Authoritative Server . . . . . . . . . . . . . . . . . . 5
2.5. Tne Authoritative Server receives the Response from The
Recursive Server . . . . . . . . . . . . . . . . . . . . 6
3. DNS Update Cache API . . . . . . . . . . . . . . . . . . . . 6
3.1. Name . . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.2. Synopsis . . . . . . . . . . . . . . . . . . . . . . . . 6
3.3. Description . . . . . . . . . . . . . . . . . . . . . . . 6
3.4. Return Value . . . . . . . . . . . . . . . . . . . . . . 6
4. Cache Update . . . . . . . . . . . . . . . . . . . . . . . . 7
5. Aggregation of Many Update Records for The Same
Destination . . . . . . . . . . . . . . . . . . . . . . . 7
6. Security Considerations . . . . . . . . . . . . . . . . . . . 7
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 7
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8
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,
Zhang, et al. Expires 8 January 2023 [Page 2]
Internet-Draft Active Update of DNS Cache July 2022
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:
Zhang, et al. Expires 8 January 2023 [Page 3]
Internet-Draft Active Update of DNS Cache July 2022
+---------------------+
| 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.
Zhang, et al. Expires 8 January 2023 [Page 4]
Internet-Draft Active Update of DNS Cache July 2022
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.
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.
Zhang, et al. Expires 8 January 2023 [Page 5]
Internet-Draft Active Update of DNS Cache July 2022
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.
Zhang, et al. Expires 8 January 2023 [Page 6]
Internet-Draft Active Update of DNS Cache July 2022
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,
November 1987, <https://www.rfc-editor.org/info/rfc1035>.
Zhang, et al. Expires 8 January 2023 [Page 7]
Internet-Draft Active Update of DNS Cache July 2022
[RFC1996] Vixie, P., "A Mechanism for Prompt Notification of Zone
Changes (DNS NOTIFY)", RFC 1996, DOI 10.17487/RFC1996,
August 1996, <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, March 1997,
<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, April 1997,
<https://www.rfc-editor.org/info/rfc2136>.
[RFC2535] Eastlake 3rd, D., "Domain Name System Security
Extensions", RFC 2535, DOI 10.17487/RFC2535, March 1999,
<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, May 2000,
<https://www.rfc-editor.org/info/rfc2845>.
Authors' Addresses
Xinqing Zhang
Computer Network Information Center, Chinese Academy of Sciences
Email: zhangxinqing21@mails.ucas.ac.cn
Shuangli Wu
Computer Network Information Center, Chinese Academy of Sciences
Email: wushuangli@cnic.cn
Yifang Qin
Computer Network Information Center, Chinese Academy of Sciences
Email: qinyf@cnic.cn
Wei Wang
Computer Network Information Center, Chinese Academy of Sciences
Email: wangwei@cnic.cn
Xu Zhou
Computer Network Information Center, Chinese Academy of Sciences
Email: zhouxu@cnic.cn
Zhang, et al. Expires 8 January 2023 [Page 8]
