<?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.io/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.io/tags/redis_cache/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>redis_cache</title>
      <link>https://coredns.io/explugins/redis_cache/</link>
      <pubDate>Mon, 11 May 2026 00:00:00 +0000</pubDate>
      
      <guid>https://coredns.io/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>
