COREDNS-LOOP(7)

💅 COREDNS-LOOP(7) — the loop plugin, explained by your bestie

okay so real talk, this is a CoreDNS Plugins manpage, section 7 of the manual, and it's about the loop plugin. it's short, it's dramatic, and it will literally kill your server on purpose. let's get into it 🫶

---

✨ NAME ✨

loop — it detects simple forwarding loops and halts the server. yes bestie, halts. like, stops the whole process. it's giving bodyguard energy 💀

---

🌸 DESCRIPTION 🌸

so here's the vibe: the loop plugin sends a random probe query to ourselves, and then it keeps track of how many times it sees that query come back around. if it sees it more than twice, it assumes CoreDNS has seen a forwarding loop, and it halts the process. periodt. 🔥

the plugin will try to send that query for up to 30 seconds. why? because it's giving CoreDNS enough time to start up, bestie, it's not trying to rush anybody. once a query has been successfully sent, loop disables itself — this is so we never get a "query of death". iconic self-preservation behavior tbh 👑

note (and this is important, no cap): loop will only send "looping queries" for the first zone given in the Server Block.

the query it sends is <random number>.<random number>.zone with type set to HINFO. literally that's the whole thing. 🦋

---

✨ SYNTAX ✨

loop

that's it. that's the syntax. one word. she's lowkey minimal. 💅

---

🎀 EXAMPLES 🎀

start a server on the default port and load the loop and forward plugins. and yes, the forward plugin is forwarding to itself. chaotic of you, but go off 🍓

. {
    loop
    forward . 127.0.0.1
}

after CoreDNS has started, it stops the process while logging this:

plugin/loop: Loop (127.0.0.1:55953 -> :1053) detected for zone ".", see https://coredns.io/plugins/loop#troubleshooting. Query: "HINFO 4547991504243258144.3688648895315093531."

not me reading that and going "well yeah bestie, it caught you" 😭

---

💜 LIMITATIONS 💜

okay so this plugin is not omniscient, she's just doing her best. she only attempts to find simple static forwarding loops at start up time.

for a loop to actually get detected, the following must be true:

• the loop must be present at start up time.
• the loop must occur for the HINFO query type.

that's it. if your loop happens later or in some other fancy way, she's asleep on the job (by design, because she disabled herself). 🙈

---

🌈 TROUBLESHOOTING 🌈

when your CoreDNS logs contain the message Loop ... detected ..., that means the loop detection plugin has detected an infinite forwarding loop in one of the upstream DNS servers. and this is a fatal error — like, genuinely, because operating with an infinite loop will consume memory and CPU until eventual out of memory death by the host. not the cute kind of death. 💀

a forwarding loop is usually caused by:

• Most commonly, CoreDNS forwarding requests directly to itself. e.g. via a loopback address such as 127.0.0.1, ::1 or 127.0.0.53
• Less commonly, CoreDNS forwarding to an upstream server that in turn, forwards requests back to CoreDNS.

to troubleshoot this, look in your Corefile for any forwards to the zone in which the loop was detected. make sure they're not forwarding to a local address or to another DNS server that's forwarding requests back to CoreDNS. and if forward is using a file (e.g. /etc/resolv.conf), make sure that file does not contain local addresses. 🔍

---

🧚 TROUBLESHOOTING LOOPS IN KUBERNETES CLUSTERS 🧚

when a CoreDNS Pod deployed in Kubernetes detects a loop, that Pod will start to "CrashLoopBackOff". why? because Kubernetes will try to restart the Pod every time CoreDNS detects the loop and exits. it's a whole cycle and it's exhausting honestly 😭

a common cause of forwarding loops in Kubernetes clusters is an interaction with a local DNS cache on the host node (e.g. systemd-resolved). for example, in certain configurations systemd-resolved will put the loopback address 127.0.0.53 as a nameserver into /etc/resolv.conf. Kubernetes (via kubelet) by default will pass this /etc/resolv.conf file to all Pods using the default dnsPolicy, rendering them unable to make DNS lookups (this includes CoreDNS Pods). CoreDNS uses this /etc/resolv.conf as a list of upstreams to forward requests to. and since it contains a loopback address, CoreDNS ends up forwarding requests to itself. peak "you did this to yourself" behavior 🫠

there are many ways to work around this issue, some are listed here:

• Add the following to your kubelet config yaml: resolvConf: <path-to-your-real-resolv-conf-file> (or via command line flag --resolv-conf deprecated in 1.10). Your "real" resolv.conf is the one that contains the actual IPs of your upstream servers, and no local/loopback address. This flag tells kubelet to pass an alternate resolv.conf to Pods. For systems using systemd-resolved, /run/systemd/resolve/resolv.conf is typically the location of the "real" resolv.conf, although this can be different depending on your distribution.
• Disable the local DNS cache on host nodes, and restore /etc/resolv.conf to the original.
• A quick and dirty fix is to edit your Corefile, replacing forward . /etc/resolv.conf with the IP address of your upstream DNS, for example forward . 8.8.8.8. But this only fixes the issue for CoreDNS — kubelet will continue to forward the invalid resolv.conf to all default dnsPolicy Pods, leaving them unable to resolve DNS.

bestie, the quick and dirty fix is right there in the name. it's quick. it's dirty. it does not fix everything. don't @ me. 💅

---

okay that's the whole page, you made it, I'm so proud of you 🎀 this was CoreDNS, dated March 2026, from the COREDNS-LOOP(7) manual — now go fix that Corefile, you gorgeous icon, and remember: she halts the server because she loves you. ✨👑🦋