<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>redis_cache on CoreDNS: DNS and Service Discovery</title><link>https://coredns.website.cncfstack.com/tags/redis_cache/</link><description>Recent content in redis_cache on CoreDNS: DNS and Service Discovery</description><generator>Hugo -- gohugo.io</generator><language>en-us</language><copyright>CoreDNS - All Rights Reserved</copyright><lastBuildDate>Mon, 11 May 2026 00:00:00 +0000</lastBuildDate><atom:link href="https://coredns.website.cncfstack.com/tags/redis_cache/index.xml" rel="self" type="application/rss+xml"/><item><title>redis_cache</title><link>https://coredns.website.cncfstack.com/explugins/redis_cache/</link><pubDate>Mon, 11 May 2026 00:00:00 +0000</pubDate><guid>https://coredns.website.cncfstack.com/explugins/redis_cache/</guid><description>Description redis_cache stores DNS responses in a shared Redis-compatible backend (Redis, Valkey, or any RESP-protocol server) so that multiple CoreDNS instances can amortize upstream lookups across the fleet — for example several pods in a Kubernetes cluster, or a fleet of node-local-dns daemons. It is intended to sit behind the built-in cache plugin, which stays as the L1 (in-process) cache; redis_cache is the L2 (networked) cache.
If the Redis backend is unreachable the plugin becomes a noop and lookups continue to flow through the rest of the chain.</description></item></channel></rss>