<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>plugin on CoreDNS: DNS and Service Discovery</title><link>https://coredns.website.cncfstack.com/categories/plugin/</link><description>Recent content in plugin on CoreDNS: DNS and Service Discovery</description><generator>Hugo -- gohugo.io</generator><language>en-us</language><copyright>CoreDNS - All Rights Reserved</copyright><lastBuildDate>Mon, 13 Jul 2026 15:51:55 +0000</lastBuildDate><atom:link href="https://coredns.website.cncfstack.com/categories/plugin/index.xml" rel="self" type="application/rss+xml"/><item><title>acl</title><link>https://coredns.website.cncfstack.com/plugins/acl/</link><pubDate>Tue, 07 Feb 2023 20:00:01 +0000</pubDate><guid>https://coredns.website.cncfstack.com/plugins/acl/</guid><description>Description With acl enabled, users are able to block or filter suspicious DNS queries by configuring IP filter rule sets, i.e. allowing authorized queries or blocking unauthorized queries.
When evaluating the rule sets, acl uses the source IP of the TCP/UDP headers of the DNS query received by CoreDNS. This source IP will be different than the IP of the client originating the request in cases where the source IP of the request is changed in transit.</description></item><item><title>any</title><link>https://coredns.website.cncfstack.com/plugins/any/</link><pubDate>Wed, 28 Oct 2020 18:26:48 +0000</pubDate><guid>https://coredns.website.cncfstack.com/plugins/any/</guid><description>Description any basically blocks ANY queries by responding to them with a short HINFO reply. See RFC 8482 for details.
Syntax any Examples example.org { whoami any } A dig +nocmd ANY example.org +noall +answer now returns:
example.org. 8482 IN HINFO &amp;#34;ANY obsoleted&amp;#34; &amp;#34;See RFC 8482&amp;#34; See Also RFC 8482.</description></item><item><title>auto</title><link>https://coredns.website.cncfstack.com/plugins/auto/</link><pubDate>Mon, 13 Jul 2026 15:51:55 +0000</pubDate><guid>https://coredns.website.cncfstack.com/plugins/auto/</guid><description>Description The auto plugin is used for an &amp;ldquo;old-style&amp;rdquo; DNS server. It serves from a preloaded file that exists on disk. If the zone file contains signatures (i.e. is signed, i.e. using DNSSEC) correct DNSSEC answers are returned. Only NSEC is supported! If you use this setup you are responsible for re-signing the zonefile. New or changed zones are automatically picked up from disk only when SOA&amp;rsquo;s serial changes. If the zones are not updated via a zone transfer, the serial must be manually changed.</description></item><item><title>autopath</title><link>https://coredns.website.cncfstack.com/plugins/autopath/</link><pubDate>Fri, 22 Nov 2024 08:09:54 +0000</pubDate><guid>https://coredns.website.cncfstack.com/plugins/autopath/</guid><description>Description If the autopath plugin sees a query that matches the first element of the configured search path, it will follow the chain of search path elements and return the first reply that is not NXDOMAIN. On any failures, the original reply is returned. Because autopath returns a reply for a name that wasn&amp;rsquo;t the original question, it will add a CNAME that points from the original name (with the search path element in it) to the name of this answer.</description></item><item><title>azure</title><link>https://coredns.website.cncfstack.com/plugins/azure/</link><pubDate>Mon, 11 Jan 2021 23:17:55 +0000</pubDate><guid>https://coredns.website.cncfstack.com/plugins/azure/</guid><description>Description The azure plugin is useful for serving zones from Microsoft Azure DNS. The azure plugin supports all the DNS records supported by Azure, viz. A, AAAA, CNAME, MX, NS, PTR, SOA, SRV, and TXT record types. NS record type is not supported by azure private DNS.
Syntax azure RESOURCE_GROUP:ZONE... { tenant TENANT_ID client CLIENT_ID secret CLIENT_SECRET subscription SUBSCRIPTION_ID environment ENVIRONMENT fallthrough [ZONES...] access private } RESOURCE_GROUP:ZONE is the resource group to which the hosted zones belongs on Azure, and ZONE the zone that contains data.</description></item><item><title>bind</title><link>https://coredns.website.cncfstack.com/plugins/bind/</link><pubDate>Fri, 08 Aug 2025 17:41:04 +0000</pubDate><guid>https://coredns.website.cncfstack.com/plugins/bind/</guid><description>Description Normally, the listener binds to the wildcard host. However, you may want the listener to bind to another IP instead.
If several addresses are provided, a listener will be open on each of the IP provided.
Each address has to be an IP or name of one of the interfaces of the host. Bind by interface name, binds to the IPs on that interface at the time of startup or reload (reload will happen with a SIGHUP or if the config file changes).</description></item><item><title>bufsize</title><link>https://coredns.website.cncfstack.com/plugins/bufsize/</link><pubDate>Tue, 15 Aug 2023 20:06:20 +0000</pubDate><guid>https://coredns.website.cncfstack.com/plugins/bufsize/</guid><description>Description bufsize limits a requester&amp;rsquo;s UDP payload size to within a maximum value. If a request with an OPT RR has a bufsize greater than the limit, the bufsize of the request will be reduced. Otherwise the request is unaffected. It prevents IP fragmentation, mitigating certain DNS vulnerabilities. It cannot increase UDP size requested by the client, it can be reduced only. This will only affect queries that have an OPT RR (EDNS(0)).</description></item><item><title>cache</title><link>https://coredns.website.cncfstack.com/plugins/cache/</link><pubDate>Wed, 01 Jul 2026 06:01:46 +0000</pubDate><guid>https://coredns.website.cncfstack.com/plugins/cache/</guid><description>Description With cache enabled, all records except zone transfers and metadata records will be cached for up to 3600s. Caching is mostly useful in a scenario when fetching data from the backend (upstream, database, etc.) is expensive.
Cache will pass DNSSEC (DNSSEC OK; DO) options through the plugin for upstream queries.
This plugin can only be used once per Server Block.
Syntax cache [TTL] [ZONES...] TTL max TTL in seconds. If not specified, the maximum TTL will be used, which is 3600 for NOERROR responses and 1800 for denial of existence ones.</description></item><item><title>cancel</title><link>https://coredns.website.cncfstack.com/plugins/cancel/</link><pubDate>Wed, 28 Oct 2020 18:26:48 +0000</pubDate><guid>https://coredns.website.cncfstack.com/plugins/cancel/</guid><description>Description The cancel plugin creates a canceling context for each request. It adds a timeout that gets triggered after 5001 milliseconds.
The 5001 number was chosen because the default timeout for DNS clients is 5 seconds, after that they give up.
A plugin interested in the cancellation status should call plugin.Done() on the context. If the context was canceled due to a timeout the plugin should not write anything back to the client and return a value indicating CoreDNS should not either; a zero return value should suffice for that.</description></item><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><item><title>docker</title><link>https://coredns.website.cncfstack.com/explugins/docker/</link><pubDate>Thu, 18 Dec 2025 18:39:00 +0400</pubDate><guid>https://coredns.website.cncfstack.com/explugins/docker/</guid><description>Description The docker plugin provides a DNS interface to Docker containers. It connects to the local Docker daemon, subscribes to the container event stream, and maintains a live view of container names, network aliases, Docker DNS names, Docker Compose project.service pairs, and custom names attached via Docker labels. The plugin answers A, AAAA, SRV, TXT, CNAME, and PTR queries for the containers it observes, along with a synthetic SOA and NS record at each configured zone apex.</description></item><item><title>kubeforward</title><link>https://coredns.website.cncfstack.com/explugins/kubeforward/</link><pubDate>Fri, 04 Apr 2025 17:15:00 +0000</pubDate><guid>https://coredns.website.cncfstack.com/explugins/kubeforward/</guid><description>Description The kubeforward plugin enables CoreDNS to dynamically update its list of DNS forwarders by monitoring changes to a specified Kubernetes Service. It observes EndpointSlices associated with the Service and adjusts the DNS forwarding configuration in real-time as endpoints are added, removed, or updated. This functionality enhances the reliability and resilience of DNS services within Kubernetes clusters.
Syntax kubeforward { namespace &amp;lt;namespace&amp;gt; service_name &amp;lt;service_name&amp;gt; port_name &amp;lt;port_name&amp;gt; expire &amp;lt;duration&amp;gt; health_check &amp;lt;duration&amp;gt; force_tcp prefer_udp } Configuration Parameters namespace (required): Specifies the Kubernetes namespace where the target Service resides.</description></item><item><title>JSON</title><link>https://coredns.website.cncfstack.com/explugins/json/</link><pubDate>Wed, 05 Mar 2025 15:51:45 -0800</pubDate><guid>https://coredns.website.cncfstack.com/explugins/json/</guid><description>Name json - query a JSON-formatted DNS server
Description The json plugin queries a JSON-formatted DNS server and returns the result as a DNS response.
Syntax json &amp;lt;URI&amp;gt; URI (required): The URI of the JSON-formatted DNS server. Example . { json https://your-json-dns-server.com/api/v1/dns } Supported record types The json plugin supports the following DNS record types:
A AAAA CNAME MX TXT</description></item><item><title>gslb</title><link>https://coredns.website.cncfstack.com/explugins/gslb/</link><pubDate>Sun, 09 Feb 2025 17:00:00 +0200</pubDate><guid>https://coredns.website.cncfstack.com/explugins/gslb/</guid><description>Description This plugin provides support for GSLB, enabling advanced load balancing and failover mechanisms based on backend health checks and policies. It is particularly useful for managing geographically distributed services or for ensuring high availability and resilience.
Features: IPv4 and IPv6 support Health Checks: HTTPS TCP ICMP Selection Modes: Failover: Routes traffic to the highest-priority available backend. Random: Distributes traffic randomly across backends. Round Robin: Cycles through backends in sequence. Syntax gslb DB_YAML_FILE [ZONES.</description></item><item><title>fanout</title><link>https://coredns.website.cncfstack.com/explugins/fanout/</link><pubDate>Tue, 03 Sep 2024 22:00:00 +0800</pubDate><guid>https://coredns.website.cncfstack.com/explugins/fanout/</guid><description>Description Each incoming DNS query that hits the CoreDNS fanout plugin will be replicated in parallel to each listed IP (i.e. the DNS servers). The first non-negative response from any of the queried DNS Servers will be forwarded as a response to the application&amp;rsquo;s DNS request.
Syntax tls CERT KEY CA define the TLS properties for TLS connection. From 0 to 3 arguments can be provided with the meaning as described below</description></item><item><title>k8s_cache</title><link>https://coredns.website.cncfstack.com/explugins/k8s_cache/</link><pubDate>Wed, 24 Apr 2024 15:20:00 +0200</pubDate><guid>https://coredns.website.cncfstack.com/explugins/k8s_cache/</guid><description>Description This is a fork of cache. It adds an option to send a refreshed positive cache item first to pods with the label k8s-cache.coredns.io/early-refresh=true. Other pods get it only after a specified duration. This makes it possible to implement stable NetworkPolicy whitelists on the basis of domain names that are resolved with DNS, using Stable FQDNNetworkPolicies.
The implementation uses an additional cache store called the &amp;ldquo;late cache&amp;rdquo;, which is shifted a number of seconds.</description></item><item><title>gathersrv</title><link>https://coredns.website.cncfstack.com/explugins/gathersrv/</link><pubDate>Sun, 02 Jul 2023 12:00:00 +0000</pubDate><guid>https://coredns.website.cncfstack.com/explugins/gathersrv/</guid><description>Description This plugin could be helpful for services that are logically distributed over several k8s clusters and use headless service to expose themselves. The aim of this plugin is to provide a method to discover all service instances through a single service domain. The result of querying distributed service domain contains masqueraded results gathered from multiple clusters. In contrast to multicluster plugin it does not require that k8s clusters have to share the same cluster zone.</description></item><item><title>meship</title><link>https://coredns.website.cncfstack.com/explugins/meship/</link><pubDate>Mon, 15 May 2023 12:00:00 +0000</pubDate><guid>https://coredns.website.cncfstack.com/explugins/meship/</guid><description>Background Currently, a strict hierarchy is followed when resolving DNS names. It is centrally designed. To address the problem of centrality, there are several approaches. One of these approaches is Meshname. With a meship domain, the address to which the domain is to be resolved is encoded in the domain name. Thus, when a meship domain is to be resolved, the domain name is decoded first and then returned as a AAAA record.</description></item><item><title>meshname</title><link>https://coredns.website.cncfstack.com/explugins/meshname/</link><pubDate>Mon, 15 May 2023 12:00:00 +0000</pubDate><guid>https://coredns.website.cncfstack.com/explugins/meshname/</guid><description>Background Currently, a strict hierarchy is followed when resolving DNS names. It is centrally designed. To address the problem of centrality, there are several approaches. One of these approaches is Meshname. With meshname, the IPv6 address of the authoritative name server responsible for the meshname domain is already encoded in the domain name. Thus, when a meshname domain is to be resolved, the first thing that is done is to decode the encoded authoritative DNS server from the domain.</description></item><item><title>multicluster</title><link>https://coredns.website.cncfstack.com/explugins/multicluster/</link><pubDate>Fri, 03 Mar 2023 03:51:43 +0000</pubDate><guid>https://coredns.website.cncfstack.com/explugins/multicluster/</guid><description>Description The multicluster plugin implements the Kubernetes DNS-Based Multicluster Service Discovery Specification.
Syntax multicluster [ZONES...] { kubeconfig KUBECONFIG [CONTEXT] noendpoints fallthrough [ZONES...] } kubeconfig KUBECONFIG [CONTEXT] authenticates the connection to a remote k8s cluster using a kubeconfig file. [CONTEXT] is optional, if not set, then the current context specified in kubeconfig will be used. It supports TLS, username and password, or token-based authentication. This option is ignored if connecting in-cluster (i.</description></item><item><title>recursor</title><link>https://coredns.website.cncfstack.com/explugins/recursor/</link><pubDate>Mon, 30 Jan 2023 16:15:00 +0200</pubDate><guid>https://coredns.website.cncfstack.com/explugins/recursor/</guid><description>Description The recursor resolves domains using defined IP addresses or resolving other mapped domains using defined resolvers.
Syntax recursor { [external-yaml config-file-path] [external-json config-file-path] [verbose 0..2] zone: zone.name [resolver non-default { urls udp://ip-1:port udp://ip-n:port [timeout_ms 500] }] [alias alias-name | * { [hosts domain-1 domain-n] [ips ip-1 ip-n] [resolver_name non-default] [ttl custom-ttl] }] } The recursor definition:
zone - DNS zone for the recursor verbose - stdout logs level: 0 - minimal 1 - middle 2 - talkative resolvers - other DNS servers: map-key/id: name of resolver, default overrides system default resolver urls: list of URL addresses, example: udp://127.</description></item><item><title>k8s_event</title><link>https://coredns.website.cncfstack.com/explugins/k8s_event/</link><pubDate>Tue, 23 Aug 2022 10:57:00 +0800</pubDate><guid>https://coredns.website.cncfstack.com/explugins/k8s_event/</guid><description>Description k8s_event listens for log printings, and reports them as Events to Kubernetes APIServer.
This plugin requires &amp;hellip;
the kubeapi plugin to create a connection to the Kubernetes API. create/patch/update permission to the Events API. Enabling this plugin is process-wide: enabling k8s_event in at least one server block enables it globally.
Syntax k8s_event { level LEVELS... rate [QPS] [Burst] [CacheSize] } levels selects what level of logs should be reported as Kubernetes events.</description></item><item><title>redis</title><link>https://coredns.website.cncfstack.com/explugins/redis/</link><pubDate>Mon, 27 Jun 2022 18:00:00 -0400</pubDate><guid>https://coredns.website.cncfstack.com/explugins/redis/</guid><description>Description redis enables reading zone data from redis database. this plugin should be located right next to etcd in plugins.cfg
Syntax redis redis loads authoritative zones from redis server
address will default to local redis server (localhost:6379)
redis { address ADDR password PWD prefix PREFIX suffix SUFFIX connect_timeout TIMEOUT read_timeout TIMEOUT ttl TTL } address is redis server address to connect in the form of host:port or ip:port. password is redis server auth key connect_timeout time in ms to wait for redis server to connect read_timeout time in ms to wait for redis server to respond ttl default ttl for dns records, 300 if not provided prefix add PREFIX to all redis keys suffix add SUFFIX to all redis keys Examples .</description></item><item><title>finalize</title><link>https://coredns.website.cncfstack.com/explugins/finalize/</link><pubDate>Thu, 23 Dec 2021 09:00:00 +0100</pubDate><guid>https://coredns.website.cncfstack.com/explugins/finalize/</guid><description>Description The plugin will try to resolve CNAMEs and only return the resulting A or AAAA address. If no A or AAAA record can be resolved the original (first) answer will be returned to the client.
Circular dependencies are detected and an error will be logged accordingly. In that case the original (first) answer will be returned to the client as well.
Syntax finalize [max_depth MAX] max_depth MAX to limit the maximum calls to resolve a CNAME chain to the final A or AAAA record, a value &amp;gt; 0 can be specified.</description></item><item><title>kubenodes</title><link>https://coredns.website.cncfstack.com/explugins/kubenodes/</link><pubDate>Fri, 17 Dec 2021 00:00:00 +0000</pubDate><guid>https://coredns.website.cncfstack.com/explugins/kubenodes/</guid><description>Description kubenodes watches the Kubernetes API and synthesizes A, AAAA, and PTR records for Node addresses.
This plugin requires &amp;hellip;
the kubeapi plugin to create a connection to the Kubernetes API. (http://github.com/coredns/kubeapi) list/watch permission to the Nodes API. This plugin can only be used once per Server Block.
Syntax kubenodes [ZONES...] { external ttl TTL fallthrough [ZONES...] } external will build records using Nodes&amp;rsquo; external addresses. If omitted, kubenodes will build records using Nodes&amp;rsquo; internal addresses.</description></item><item><title>ebpf</title><link>https://coredns.website.cncfstack.com/explugins/ebpf/</link><pubDate>Thu, 14 Oct 2021 00:00:00 +0000</pubDate><guid>https://coredns.website.cncfstack.com/explugins/ebpf/</guid><description>Description This experimental plugin allows you to use an eBPF XDP program to analyze and filter traffic before it reaches CoreDNS, and report very basic Prometheus metrics. When CoreDNS exits, the program will be detached from the interface.
This generic solution serves in part as an example of how you can integrate an eBPF XDP program with CoreDNS with a custom plugin. But due to the generic nature, map entry is somewhat cryptic and metrics must be defined in the Corefile, limiting their scope.</description></item><item><title>rrl</title><link>https://coredns.website.cncfstack.com/explugins/rrl/</link><pubDate>Thu, 07 Oct 2021 00:00:00 +0000</pubDate><guid>https://coredns.website.cncfstack.com/explugins/rrl/</guid><description>Description The rrl plugin tracks response rates per category of response. The category of a given response consists of the following:
Prefix of the client IP (per the ipv4/6-prefix-length) Requested name (qname) excluding response type of error (see response type below) Requested type (qtype) excluding response type of error (see response type below) Response type (each corresponding to the configurable per-second allowances) response - for positive responses that contain answers nodata - for NODATA responses nxdomain - for NXDOMAIN responses referrals - for referrals or delegations error - for all DNS errors (except NXDOMAIN) To better protect against attacks using invalid requests, requested name and type are not categorized separately for error type requests.</description></item><item><title>mysql</title><link>https://coredns.website.cncfstack.com/explugins/mysql/</link><pubDate>Mon, 07 Jun 2021 01:01:00 +0000</pubDate><guid>https://coredns.website.cncfstack.com/explugins/mysql/</guid><description>Description This plugin uses MySQL as a backend to store DNS records. These will then can served by CoreDNS. The backend uses a simple, single table data structure that can be shared by other systems to add and remove records from the DNS server. As there is no state stored in the plugin, the service can be scaled out by spinning multiple instances of CoreDNS backed by the same database.</description></item><item><title>warnlist</title><link>https://coredns.website.cncfstack.com/explugins/warnlist/</link><pubDate>Thu, 03 Jun 2021 16:00:00 +0100</pubDate><guid>https://coredns.website.cncfstack.com/explugins/warnlist/</guid><description>Description The warnlist plugin accepts a list of malicious or otherwise undesirable domains and emits a log entry and Prometheus metrics when a domain (or subdomain) is requested.
Prohibited domains can be loaded from a local file or a URL and can be automatically reloaded after a specified period.
warnlist can be thought of as a non-blocking blacklist/blocklist/denylist/badlist. When used with a curated data source, the plugin can surface simplistic low-noise alerts without the need to ship and inspect DNS logs.</description></item><item><title>git</title><link>https://coredns.website.cncfstack.com/explugins/git/</link><pubDate>Thu, 07 Jan 2021 00:12:00 +0800</pubDate><guid>https://coredns.website.cncfstack.com/explugins/git/</guid><description>Description git clones a git repository into the site. This makes it possible to deploy your zones with a simple git push.
The git plugin starts a service routine that runs during the lifetime of the server. When the service starts, it clones the repository. While the server is still up, it pulls the latest every so often. You can also set up a webhook to pull immediately after a push.</description></item><item><title>alternate</title><link>https://coredns.website.cncfstack.com/explugins/alternate/</link><pubDate>Mon, 28 Sep 2020 00:00:00 -0500</pubDate><guid>https://coredns.website.cncfstack.com/explugins/alternate/</guid><description>Description The alternate plugin is able to selectively forward queries to another upstream server, depending the error result provided by the initial resolver. It allows an alternate set of upstreams be specified which will be used if the plugin chain returns specific error messages. The alternate plugin utilizes the forward plugin (https://coredns.io/plugins/forward) to query the specified upstreams.
The alternate plugin supports only DNS protocol and random policy w/o additional forward parameters, so following directives will fail:</description></item><item><title>k8s_dns_chaos</title><link>https://coredns.website.cncfstack.com/explugins/k8s_dns_chaos/</link><pubDate>Tue, 22 Sep 2020 21:57:00 +0800</pubDate><guid>https://coredns.website.cncfstack.com/explugins/k8s_dns_chaos/</guid><description>Description This plugin implements the Kubernetes DNS-Based Service Discovery Specification.
CoreDNS running with the k8s_dns_chaos plugin can be used to do chaos tests on DNS.
This plugin can only be used once per Server Block.
Syntax k8s_dns_chaos [ZONES...] The k8s_dns_chaos supports all options in plugin kubernetes, besides, it also supports other configuration items for chaos.
kubernetes [ZONES...] { endpoint URL tls CERT KEY CACERT kubeconfig KUBECONFIG CONTEXT namespaces NAMESPACE... labels EXPRESSION pods POD-MODE endpoint_pod_names ttl TTL noendpoints transfer to ADDRESS.</description></item><item><title>records</title><link>https://coredns.website.cncfstack.com/explugins/records/</link><pubDate>Tue, 22 Sep 2020 07:53:19 +0100</pubDate><guid>https://coredns.website.cncfstack.com/explugins/records/</guid><description>Description The records plugin is useful for serving zone data that is specified inline in the configuration file. As opposed to the hosts plugin, this plugin supports all record types. Records need to be specified in text representation as specified in RFC 1035. If no TTL is specified in the records, a default TTL of 3600s is assumed.
For negative responses a SOA record should be included in the response, this will only be done when a SOA record is included in the data.</description></item><item><title>k8s_gateway</title><link>https://coredns.website.cncfstack.com/explugins/k8s_gateway/</link><pubDate>Sat, 19 Sep 2020 12:00:00 -0800</pubDate><guid>https://coredns.website.cncfstack.com/explugins/k8s_gateway/</guid><description>Description This plugin is very similar to k8s_external but supporting all types of Kubernetes external resources - Ingress, Service of type LoadBalancer and networking.x-k8s.io/Gateway (when it becomes available).
This plugin relies on it&amp;rsquo;s own connection to the k8s API server and doesn&amp;rsquo;t share any code with the existing kubernetes plugin. The assumption is that this plugin can now be deployed as a separate instance (alongside the internal kube-dns) and act as a single external DNS interface into your Kubernetes cluster(s).</description></item><item><title>netbox</title><link>https://coredns.website.cncfstack.com/explugins/netbox/</link><pubDate>Sun, 28 Jun 2020 15:01:20 +0100</pubDate><guid>https://coredns.website.cncfstack.com/explugins/netbox/</guid><description>Description netbox enables reading zone data from a netbox instance.
Syntax netbox { url http://10.0.0.2:9000/api/ipam/ip-addresses token youSekretAPITokenForNetbox } The plugin will delegate search to the next plugin if a record isn&amp;rsquo;t found. If a record is found a record is sent and the query processing is stopped.</description></item><item><title>mdns</title><link>https://coredns.website.cncfstack.com/explugins/mdns/</link><pubDate>Wed, 17 Jun 2020 11:07:00 +1200</pubDate><guid>https://coredns.website.cncfstack.com/explugins/mdns/</guid><description>Description This plugin reads mDNS records from the local network and responds to queries based on those records.
Useful for providing mDNS records to non-mDNS-aware applications by making them accessible through a standard DNS server.
Syntax mdns example.com [minimum SRV records] [filter text] [bind address] Examples As a prerequisite to using this plugin, there must be systems on the local network broadcasting mDNS records. Note that the .local domain will be replaced with the configured domain.</description></item><item><title>wgsd</title><link>https://coredns.website.cncfstack.com/explugins/wgsd/</link><pubDate>Wed, 27 May 2020 17:05:00 -0800</pubDate><guid>https://coredns.website.cncfstack.com/explugins/wgsd/</guid><description>Description wgsd serves WireGuard peer information via DNS-SD (RFC6763) semantics. This enables dynamic discovery of WireGuard endpoint addressing (both IP address and port number) with the added benefit of NAT-to-NAT WireGuard connectivity where UDP hole punching is supported.
Following RFC6763 this plugin provides a listing of peers via PTR records at the namespace _wireguard._udp.&amp;lt;zone&amp;gt;. The target for the PTR records is &amp;lt;base32PubKey&amp;gt;._wireguard._udp.&amp;lt;zone&amp;gt; which corresponds to SRV records. SRV targets are of the format &amp;lt;base32PubKey&amp;gt;.</description></item><item><title>alias</title><link>https://coredns.website.cncfstack.com/explugins/alias/</link><pubDate>Sat, 25 Apr 2020 19:12:00 +0800</pubDate><guid>https://coredns.website.cncfstack.com/explugins/alias/</guid><description>Description The alias plugin eliminates CNAME records from zone apex by making the subsequent resolved records look like they belong to the zone apex. This behaves similarily to CloudFlare&amp;rsquo;s Zone Flattening.
This plugin works only with plugins that produce A or AAAA records alongside the CNAME record. Examples include auto and file. However, you might need to adjust the order of this plugin to use it with other plugins.
Preferrably, this should not be used in favour of the RFC drafts for the new ANAME records, but the DNS library used by CoreDNS does not support ANAME records yet.</description></item><item><title>chaos</title><link>https://coredns.website.cncfstack.com/plugins/chaos/</link><pubDate>Thu, 06 Feb 2020 12:07:03 +0000</pubDate><guid>https://coredns.website.cncfstack.com/plugins/chaos/</guid><description>Description This is useful for retrieving version or author information from the server by querying a TXT record for a special domain name in the CH class.
Syntax chaos [VERSION] [AUTHORS...] VERSION is the version to return. Defaults to CoreDNS-&amp;lt;version&amp;gt;, if not set. AUTHORS is what authors to return. This defaults to all GitHub handles in the OWNERS files. Note that you have to make sure that this plugin will get actual queries for the following zones: version.</description></item><item><title>lighthouse</title><link>https://coredns.website.cncfstack.com/explugins/lighthouse/</link><pubDate>Thu, 21 Nov 2019 10:00:00 +0800</pubDate><guid>https://coredns.website.cncfstack.com/explugins/lighthouse/</guid><description>Description Lighthouse plugin allows Cross Cluster Service Discovery between Kubernetes clusters connected by Submariner.
If the default Kubernetes plugin fails to resolve a DNS request, the lighthouse plugin will try to resolve it using the information it gathered from other clusters that have joined the submariner control plane. On a successful resolution, lighthouse plugin returns the cluster IP of the service in the remote cluster. Submariner ensures that this IP is reachable.</description></item><item><title>idetcd</title><link>https://coredns.website.cncfstack.com/explugins/idetcd/</link><pubDate>Mon, 13 Aug 2018 18:54:20 +0100</pubDate><guid>https://coredns.website.cncfstack.com/explugins/idetcd/</guid><description>Description idetcd is used for identifying nodes in a cluster without domain name collision.The basic idea is quite simple: Set up CoreDNS server on every node when you going to start a cluster, and node exposes itself by taking the free domain name in etcd.
Syntax idetcd { endpoint ENDPOINT... limit LIMIT pattern PATTERN } endpoint defines the etcd endpoints. Defaults to &amp;ldquo;http://localhost:2379&amp;rdquo;. limit defines the maximum limit of the node number in the cluster, if some nodes is going to expose itself after the node number in the cluster hits this limit, it will fail.</description></item><item><title>gravwell</title><link>https://coredns.website.cncfstack.com/explugins/gravwell/</link><pubDate>Wed, 04 Jul 2018 20:25:00 +0000</pubDate><guid>https://coredns.website.cncfstack.com/explugins/gravwell/</guid><description>Description This plugin allows for directly integrating DNS auditing into Gravwell. The plugin acts as an integrated ingester and ships DNS requests and responses directly to a Gravwell instance.
DNS Requests and responses can be encoded as text, JSON, or as a packed binary format.
Syntax gravwell { Ingest-Secret IngestSecretToken Cleartext-Target 192.168.1.1:4023 Tag dns Encoding json Log-Level INFO #Cleartext-Target 192.168.1.2:4023 #second indexer #Ciphertext-Target 192.168.1.1:4024 #Insecure-Novalidate-TLS true #disable TLS certificate validation #Ingest-Cache-Path /tmp/coredns_ingest.</description></item><item><title>amazondns</title><link>https://coredns.website.cncfstack.com/explugins/amazondns/</link><pubDate>Tue, 06 Mar 2018 20:32:00 +0900</pubDate><guid>https://coredns.website.cncfstack.com/explugins/amazondns/</guid><description>Description The amazondns plugin behaves Authoritative name server using Amazon DNS Server as the backend.
The Amazon DNS server is used to resolve the DNS domain names that you specify in a private hosted zone in Route 53. However, the server acts as Caching name server. Although CoreDNS has proxy plugin and we can configure Amazon DNS server as the backend, it can&amp;rsquo;t be Authoritative name server. In my case, Authoritative name server is required to handle delegated responsibility for the subdomain.</description></item><item><title>kubernetai</title><link>https://coredns.website.cncfstack.com/explugins/kubernetai/</link><pubDate>Mon, 05 Mar 2018 21:57:00 +0800</pubDate><guid>https://coredns.website.cncfstack.com/explugins/kubernetai/</guid><description>Description Kubernetai (koo-ber-NET-eye) is the plural form of Kubernetes. In a nutshell, Kubernetai is an external plugin for CoreDNS that holds multiple kubernetes plugin configurations. It allows one CoreDNS server to connect to more than one Kubernetes server at a time.
With kubernetai, you can define multiple kubernetes blocks in your Corefile. All options are exactly the same as the built in kubernetes plugin, you just name them kubernetai instead of kubernetes.</description></item><item><title>unbound</title><link>https://coredns.website.cncfstack.com/explugins/unbound/</link><pubDate>Thu, 25 Jan 2018 11:25:00 +0000</pubDate><guid>https://coredns.website.cncfstack.com/explugins/unbound/</guid><description>Description Via unbound you can perform recursive queries. Unbound uses DNSSEC by default when resolving and it returns those records (DNSKEY, RRSIG, NSEC and NSEC3) back to the clients. The unbound plugin will remove those records when a client didn&amp;rsquo;t ask for it. The internal (RR) answer cache of Unbound is disabled, so you may want to use the cache plugin.
Libunbound can be configured via (a subset of) options, currently the following are set, by default:</description></item><item><title>on</title><link>https://coredns.website.cncfstack.com/explugins/on/</link><pubDate>Mon, 22 Jan 2018 07:53:19 +0100</pubDate><guid>https://coredns.website.cncfstack.com/explugins/on/</guid><description>Description on executes a command when a specified event is triggered. This can be useful for preparing to serve a site by running a script or starting a background process when the server starts, or for stopping it when the server exits.
Each command that is executed is blocking, unless you suffix the command with a space and &amp;amp;, which will cause the command to be run in the background. (Do not do this when the server is exiting, or the command may not finish before its parent process exits.</description></item><item><title>dump</title><link>https://coredns.website.cncfstack.com/explugins/dump/</link><pubDate>Wed, 17 Jan 2018 21:57:00 +0800</pubDate><guid>https://coredns.website.cncfstack.com/explugins/dump/</guid><description>Description dump uses the synax from the log plugin, and defaults to this format:
{remote} - [{when}] {&amp;gt;id} {type} {class} {name} {proto} {port} So a query will show up as:
:1 - [17/Jan/2018:20:02:19 +0000] 3644 MX IN example.net. udp 46481 Note that this is shorter than the default for log so you can distinguish between the two outputs. log only logs queries that have seen a response, so this plugin can be used as a debugging aid to just dump all incoming queries.</description></item><item><title>pdsql</title><link>https://coredns.website.cncfstack.com/explugins/pdsql/</link><pubDate>Sat, 09 Dec 2017 10:26:00 +0800</pubDate><guid>https://coredns.website.cncfstack.com/explugins/pdsql/</guid><description>Description pdsql uses PowerDNS generic sql as backend.
Use jinzhu/gorm database drivers, supports as many databases as Gorm does.
Syntax pdsql &amp;lt;dialect&amp;gt; &amp;lt;arg&amp;gt; { // enable debug mode debug [db] // create table for test auto-migrate } Install Driver pdsql needs db drivers for dialect, to install a driver you need to add an import in plugin.cfg, like
pdsql_mysql:github.com/jinzhu/gorm/dialects/mysql pdsql_sqlite:github.com/jinzhu/gorm/dialects/sqlite pdsql_mysql and pdsql_sqlite are meaningless, specified to prevent duplicates.
Examples Start a server on port 1053, use test.</description></item><item><title>ipin</title><link>https://coredns.website.cncfstack.com/explugins/ipin/</link><pubDate>Sat, 09 Dec 2017 02:00:00 +0800</pubDate><guid>https://coredns.website.cncfstack.com/explugins/ipin/</guid><description>Description ipin returns IP address and port based on you domain name. Your IP address is returned in the answer section, currently only support ipv4, so A record only.
The optional port are included in the additional section as a SRV record.
._port.qname. 0 IN SRV 0 0 &amp;lt;port&amp;gt; . Syntax ipin Examples Start a server on the default port and load the ipin plugin.
. { ipin } When queried for &amp;ldquo;192-168-1-1.</description></item><item><title>demo</title><link>https://coredns.website.cncfstack.com/explugins/demo/</link><pubDate>Tue, 25 Jul 2017 21:57:00 +0800</pubDate><guid>https://coredns.website.cncfstack.com/explugins/demo/</guid><description>Description This demo plugin showcases the implementation of source IP based service discovery. It is intended as a boilerplate code, so that anyone that is interested in coredns implementation could build their plugin on top of this demo plugin.
This demo plugin and its full code has been walked through in past KubeCon talks
Note: In order to add a new plugin, an additional step of make gen is needed. Therefore, to build the coredns with demo plugin the following should be used:</description></item><item><title>example</title><link>https://coredns.website.cncfstack.com/explugins/example/</link><pubDate>Tue, 25 Jul 2017 21:57:00 +0800</pubDate><guid>https://coredns.website.cncfstack.com/explugins/example/</guid><description>Description The example plugin prints &amp;ldquo;example&amp;rdquo; on every query received. It serves as documentation for writing CoreDNS plugins.
Syntax example Metrics If monitoring is enabled (via the prometheus directive) the following metric is exported:
coredns_example_request_count_total{server} - query count to the example plugin. The server label indicated which server handled the request, see the metrics plugin for details.
Health This plugin implements dynamic health checking. It will always return healthy though.</description></item><item><title>clouddns</title><link>https://coredns.website.cncfstack.com/plugins/clouddns/</link><pubDate>Thu, 08 Jan 2026 11:42:04 +0000</pubDate><guid>https://coredns.website.cncfstack.com/plugins/clouddns/</guid><description>Description The clouddns plugin is useful for serving zones from resource record sets in GCP Cloud DNS. This plugin supports all Google Cloud DNS records. This plugin can be used when CoreDNS is deployed on GCP or elsewhere. Note that this plugin accesses the resource records through the Google Cloud API. For records in a privately hosted zone, it is not necessary to place CoreDNS and this plugin in the associated VPC network.</description></item><item><title>ens</title><link>https://coredns.website.cncfstack.com/explugins/ens/</link><pubDate>Fri, 13 Sep 2019 09:00:00 +0100</pubDate><guid>https://coredns.website.cncfstack.com/explugins/ens/</guid><description>Description The ens plugin serves DNS records from the Ethereum Name Service. Ethereum provides an authoritative source of DNS records for relevant domains, allowing authoritative data to be served by any nameserver without it having write-access to the DNS records themselves.
It is recommended that this comes after rewrite in the plugins.cfg file.
Syntax ens { # connection is the connection to an Ethereum node. It is *highly* # recommended that a local node is used, as remote connections can # cause DNS requests to time out.</description></item><item><title>debug</title><link>https://coredns.website.cncfstack.com/plugins/debug/</link><pubDate>Wed, 28 Oct 2020 18:26:48 +0000</pubDate><guid>https://coredns.website.cncfstack.com/plugins/debug/</guid><description>Description Normally CoreDNS will recover from panics; using debug inhibits this. The main use of debug is to help in testing. A side effect of using debug is that log.Debug and log.Debugf messages will be printed to standard output.
Note that the errors plugin (if loaded) will also set a recover, negating this setting.
Enabling this plugin is process-wide: enabling debug in at least one server block enables debug mode globally.</description></item><item><title>dns64</title><link>https://coredns.website.cncfstack.com/plugins/dns64/</link><pubDate>Mon, 24 Jan 2022 14:51:48 +0000</pubDate><guid>https://coredns.website.cncfstack.com/plugins/dns64/</guid><description>Description The dns64 plugin will when asked for a domain&amp;rsquo;s AAAA records, but only finds A records, synthesizes the AAAA records from the A records.
The synthesis is only performed if the query came in via IPv6.
This translation is for IPv6-only networks that have NAT64.
Syntax dns64 [PREFIX] PREFIX defines a custom prefix instead of the default 64:ff9b::/96. Or use this slightly longer form with more options:
dns64 [PREFIX] { [translate_all] prefix PREFIX [allow_ipv4] } prefix specifies any local IPv6 prefix to use, instead of the well known prefix (64:ff9b::/96) translate_all translates all queries, including responses that have AAAA results.</description></item><item><title>dnssec</title><link>https://coredns.website.cncfstack.com/plugins/dnssec/</link><pubDate>Wed, 01 Jul 2026 06:01:46 +0000</pubDate><guid>https://coredns.website.cncfstack.com/plugins/dnssec/</guid><description>Description With dnssec, any reply that doesn&amp;rsquo;t (or can&amp;rsquo;t) do DNSSEC will get signed on the fly. Authenticated denial of existence is implemented with NSEC black lies. Using ECDSA as an algorithm is preferred as this leads to smaller signatures (compared to RSA). NSEC3 is not supported.
This plugin can only be used once per Server Block.
Syntax dnssec [ZONES... ] { key file|aws_secretsmanager KEY... cache_capacity CAPACITY } The signing behavior depends on the keys specified.</description></item><item><title>dnstap</title><link>https://coredns.website.cncfstack.com/plugins/dnstap/</link><pubDate>Wed, 01 Jul 2026 06:01:46 +0000</pubDate><guid>https://coredns.website.cncfstack.com/plugins/dnstap/</guid><description>Description dnstap is a flexible, structured binary log format for DNS software; see https://dnstap.info. With this plugin you make CoreDNS output dnstap logging.
Every message is sent to the socket as soon as it comes in, the dnstap plugin has a buffer of 10000 messages, above that number dnstap messages will be dropped (this is logged).
Syntax Outgoing Connections (Connect to Sink) dnstap SOCKET [full] [writebuffer] [queue] { [identity IDENTITY] [version VERSION] [extra EXTRA] [skipverify] } SOCKET is the socket (path) supplied to the dnstap command line tool.</description></item><item><title>erratic</title><link>https://coredns.website.cncfstack.com/plugins/erratic/</link><pubDate>Wed, 28 Oct 2020 18:26:48 +0000</pubDate><guid>https://coredns.website.cncfstack.com/plugins/erratic/</guid><description>Description erratic returns a static response to all queries, but the responses can be delayed, dropped or truncated. The erratic plugin will respond to every A or AAAA query. For any other type it will return a SERVFAIL response (except AXFR). The reply for A will return 192.0.2.53 (RFC 5737), for AAAA it returns 2001:DB8::53 (RFC 3849). For an AXFR request it will respond with a small zone transfer.
Syntax erratic { drop [AMOUNT] truncate [AMOUNT] delay [AMOUNT [DURATION]] } drop: drop 1 per AMOUNT of queries, the default is 2.</description></item><item><title>errors</title><link>https://coredns.website.cncfstack.com/plugins/errors/</link><pubDate>Thu, 08 Jan 2026 11:42:04 +0000</pubDate><guid>https://coredns.website.cncfstack.com/plugins/errors/</guid><description>Description Any errors encountered during the query processing will be printed to standard output. The errors of particular type can be consolidated and printed once per some period of time.
This plugin can only be used once per Server Block.
Syntax The basic syntax is:
errors Extra knobs are available with an expanded syntax:
errors { stacktrace consolidate DURATION REGEXP [LEVEL] [show_first] } Option stacktrace will log a stacktrace during panic recovery.</description></item><item><title>etcd</title><link>https://coredns.website.cncfstack.com/plugins/etcd/</link><pubDate>Mon, 13 Jul 2026 15:51:55 +0000</pubDate><guid>https://coredns.website.cncfstack.com/plugins/etcd/</guid><description>Description The etcd plugin implements the (older) SkyDNS service discovery service. It is not suitable as a generic DNS zone data plugin. Only a subset of DNS record types are implemented, and subdomains and delegations are not handled at all. The plugin will also recursively descend the tree and return all records found, see &amp;ldquo;Special Behavior&amp;rdquo; below for details.
The data in the etcd instance has to be encoded as a message like SkyDNS.</description></item><item><title>file</title><link>https://coredns.website.cncfstack.com/plugins/file/</link><pubDate>Wed, 01 Jul 2026 06:01:46 +0000</pubDate><guid>https://coredns.website.cncfstack.com/plugins/file/</guid><description>Description The file plugin is used for an &amp;ldquo;old-style&amp;rdquo; DNS server. It serves from a preloaded file that exists on disk contained RFC 1035 styled data. If the zone file contains signatures (i.e., is signed using DNSSEC), correct DNSSEC answers are returned. Only NSEC is supported! If you use this setup you are responsible for re-signing the zonefile.
Syntax file DBFILE [ZONES...] DBFILE the database file to read and parse. If the path is relative, the path from the root plugin will be prepended to it.</description></item><item><title>forward</title><link>https://coredns.website.cncfstack.com/plugins/forward/</link><pubDate>Mon, 13 Jul 2026 15:51:55 +0000</pubDate><guid>https://coredns.website.cncfstack.com/plugins/forward/</guid><description>Description The forward plugin re-uses already opened sockets to the upstreams. It supports UDP, TCP, DNS-over-TLS, DNS-over-HTTPS and uses in band health checking.
When it detects an error a health check is performed. This checks runs in a loop, performing each check at a 0.5s interval for as long as the upstream reports unhealthy. Once healthy we stop health checking (until the next error). The health checks use a recursive DNS query (.</description></item><item><title>geoip</title><link>https://coredns.website.cncfstack.com/plugins/geoip/</link><pubDate>Thu, 11 Dec 2025 04:36:33 +0000</pubDate><guid>https://coredns.website.cncfstack.com/plugins/geoip/</guid><description>Description The geoip plugin allows you to enrich the data associated with Client IP addresses, e.g. geoip information like City, Country, and Network ASN. GeoIP data is commonly available in the .mmdb format, a database format that maps IPv4 and IPv6 addresses to data records using a binary search tree.
The data is added leveraging the metadata plugin, values can then be retrieved using it as well.
Longitude example:
import ( &amp;#34;strconv&amp;#34; &amp;#34;github.</description></item><item><title>grpc</title><link>https://coredns.website.cncfstack.com/plugins/grpc/</link><pubDate>Mon, 13 Jul 2026 15:51:55 +0000</pubDate><guid>https://coredns.website.cncfstack.com/plugins/grpc/</guid><description>Description The grpc plugin supports gRPC and TLS.
This plugin can only be used once per Server Block.
Syntax In its most basic form:
grpc FROM TO... FROM is the base domain to match for the request to be proxied. TO&amp;hellip; are the destination endpoints to proxy to. The number of upstreams is limited to 15. Multiple upstreams are randomized (see policy) on first use. When a proxy returns an error the next upstream in the list is tried.</description></item><item><title>grpc_server</title><link>https://coredns.website.cncfstack.com/plugins/grpc_server/</link><pubDate>Thu, 08 Jan 2026 11:42:04 +0000</pubDate><guid>https://coredns.website.cncfstack.com/plugins/grpc_server/</guid><description>Description The grpc_server plugin allows you to configure parameters for the DNS-over-gRPC server to fine-tune the security posture and performance of the server.
This plugin can only be used once per gRPC listener block.
Syntax grpc_server { max_streams POSITIVE_INTEGER max_connections POSITIVE_INTEGER } max_streams limits the number of concurrent gRPC streams per connection. This helps prevent unbounded streams on a single connection, exhausting server resources. The default value is 256 if not specified.</description></item><item><title>header</title><link>https://coredns.website.cncfstack.com/plugins/header/</link><pubDate>Tue, 09 Sep 2025 18:54:52 +0000</pubDate><guid>https://coredns.website.cncfstack.com/plugins/header/</guid><description>Description header ensures that the flags are in the desired state for queries and responses. The modifications are made transparently for the client and subsequent plugins.
Syntax header { SELECTOR ACTION FLAGS... SELECTOR ACTION FLAGS... } SELECTOR defines if the action should be applied on query or response.
ACTION defines the state for DNS message header flags. Actions are evaluated in the order they are defined so last one has the most precedence.</description></item><item><title>health</title><link>https://coredns.website.cncfstack.com/plugins/health/</link><pubDate>Thu, 08 Sep 2022 18:42:54 +0000</pubDate><guid>https://coredns.website.cncfstack.com/plugins/health/</guid><description>Description Enabled process wide health endpoint. When CoreDNS is up and running this returns a 200 OK HTTP status code. The health is exported, by default, on port 8080/health.
Syntax health [ADDRESS] Optionally takes an address; the default is :8080. The health path is fixed to /health. The health endpoint returns a 200 response code and the word &amp;ldquo;OK&amp;rdquo; when this server is healthy.
An extra option can be set with this extended syntax:</description></item><item><title>hosts</title><link>https://coredns.website.cncfstack.com/plugins/hosts/</link><pubDate>Mon, 13 Jul 2026 15:51:55 +0000</pubDate><guid>https://coredns.website.cncfstack.com/plugins/hosts/</guid><description>Description The hosts plugin is useful for serving zones from a /etc/hosts file. It serves from a preloaded file that exists on disk. It checks the file for changes and updates the zones accordingly. This plugin only supports A, AAAA, and PTR records. The hosts plugin can be used with readily available hosts files that block access to advertising servers.
The plugin reloads the content of the hosts file every 5 seconds.</description></item><item><title>import</title><link>https://coredns.website.cncfstack.com/plugins/import/</link><pubDate>Mon, 13 Oct 2025 05:58:44 +0000</pubDate><guid>https://coredns.website.cncfstack.com/plugins/import/</guid><description>Description The import plugin can be used to include files into the main configuration. Another use is to reference predefined snippets. Both can help to avoid some duplication.
This is a unique plugin in that import can appear outside of a server block. In other words, it can appear at the top of a Corefile where an address would normally be.
Syntax import PATTERN PATTERN is the file, glob pattern (*) or snippet to include.</description></item><item><title>https</title><link>https://coredns.website.cncfstack.com/plugins/https/</link><pubDate>Thu, 08 Jan 2026 11:42:04 +0000</pubDate><guid>https://coredns.website.cncfstack.com/plugins/https/</guid><description>Description The https plugin allows you to configure parameters for the DNS-over-HTTPS (DoH) server to fine-tune the security posture and performance of the server.
This plugin can only be used once per HTTPS listener block.
Syntax https { max_connections POSITIVE_INTEGER } max_connections limits the number of concurrent TCP connections to the HTTPS server. The default value is 200 if not specified. Set to 0 for unbounded. Examples Set custom limits for maximum connections:</description></item><item><title>k8s_external</title><link>https://coredns.website.cncfstack.com/plugins/k8s_external/</link><pubDate>Tue, 15 Aug 2023 20:06:20 +0000</pubDate><guid>https://coredns.website.cncfstack.com/plugins/k8s_external/</guid><description>Description This plugin allows an additional zone to resolve the external IP address(es) of a Kubernetes service and headless services. This plugin is only useful if the kubernetes plugin is also loaded.
The plugin uses an external zone to resolve in-cluster IP addresses. It only handles queries for A, AAAA, SRV, and PTR records; To make it a proper DNS zone, it handles SOA and NS queries for the apex of the zone.</description></item><item><title>https3</title><link>https://coredns.website.cncfstack.com/plugins/https3/</link><pubDate>Thu, 08 Jan 2026 11:42:04 +0000</pubDate><guid>https://coredns.website.cncfstack.com/plugins/https3/</guid><description>Description The https3 plugin allows you to configure parameters for the DNS-over-HTTPS/3 (DoH3) server to fine-tune the security posture and performance of the server. HTTPS/3 uses QUIC as the underlying transport.
This plugin can only be used once per HTTPS3 listener block.
Syntax https3 { max_streams POSITIVE_INTEGER } max_streams limits the number of concurrent QUIC streams per connection. This helps prevent unbounded streams on a single connection, exhausting server resources. The default value is 256 if not specified.</description></item><item><title>loadbalance</title><link>https://coredns.website.cncfstack.com/plugins/loadbalance/</link><pubDate>Tue, 09 Sep 2025 18:54:52 +0000</pubDate><guid>https://coredns.website.cncfstack.com/plugins/loadbalance/</guid><description>Description The loadbalance will act as a round-robin DNS load balancer by randomizing the order of A, AAAA, and MX records in the answer.
See Wikipedia about the pros and cons of this setup. It will take care to sort any CNAMEs before any address records, because some stub resolver implementations (like glibc) are particular about that.
Syntax loadbalance [round_robin | weighted WEIGHTFILE] { reload DURATION prefer CIDR [CIDR...] } round_robin policy randomizes the order of A, AAAA, and MX records applying a uniform probability distribution.</description></item><item><title>loop</title><link>https://coredns.website.cncfstack.com/plugins/loop/</link><pubDate>Mon, 17 May 2021 20:28:52 +0000</pubDate><guid>https://coredns.website.cncfstack.com/plugins/loop/</guid><description>Description The loop plugin will send a random probe query to ourselves and will then keep track of how many times we see it. If we see it more than twice, we assume CoreDNS has seen a forwarding loop and we halt the process.
The plugin will try to send the query for up to 30 seconds. This is done to give CoreDNS enough time to start up. Once a query has been successfully sent, loop disables itself to prevent a query of death.</description></item><item><title>metadata</title><link>https://coredns.website.cncfstack.com/plugins/metadata/</link><pubDate>Wed, 28 Oct 2020 18:26:48 +0000</pubDate><guid>https://coredns.website.cncfstack.com/plugins/metadata/</guid><description>Description By enabling metadata any plugin that implements metadata.Provider interface will be called for each DNS query, at the beginning of the process for that query, in order to add its own metadata to context.
The metadata collected will be available for all plugins, via the Context parameter provided in the ServeDNS function. The package (code) documentation has examples on how to inspect and retrieve metadata a plugin might be interested in.</description></item><item><title>kubernetes</title><link>https://coredns.website.cncfstack.com/plugins/kubernetes/</link><pubDate>Wed, 01 Jul 2026 06:01:46 +0000</pubDate><guid>https://coredns.website.cncfstack.com/plugins/kubernetes/</guid><description>Description This plugin implements the Kubernetes DNS-Based Service Discovery Specification.
CoreDNS running the kubernetes plugin can be used as a replacement for kube-dns in a kubernetes cluster. See the deployment repository for details on how to deploy CoreDNS in Kubernetes.
stubDomains and upstreamNameservers are implemented via the forward plugin. See the examples below.
This plugin can only be used once per Server Block.
Syntax kubernetes [ZONES...] With only the plugin specified, the kubernetes plugin will default to the zone specified in the server&amp;rsquo;s block.</description></item><item><title>nsid</title><link>https://coredns.website.cncfstack.com/plugins/nsid/</link><pubDate>Wed, 28 Oct 2020 18:26:48 +0000</pubDate><guid>https://coredns.website.cncfstack.com/plugins/nsid/</guid><description>Description This plugin implements RFC 5001 and adds an EDNS0 OPT resource record to replies that uniquely identify the server. This is useful in anycast setups to see which server was responsible for generating the reply and for debugging.
This plugin can only be used once per Server Block.
Syntax nsid [DATA] DATA is the string to use in the nsid record.
If DATA is not given, the host&amp;rsquo;s name is used.</description></item><item><title>local</title><link>https://coredns.website.cncfstack.com/plugins/local/</link><pubDate>Mon, 13 Jul 2026 15:51:55 +0000</pubDate><guid>https://coredns.website.cncfstack.com/plugins/local/</guid><description>Description local will respond with a basic reply to a &amp;ldquo;local request&amp;rdquo;. Local requests are defined to be names in the following zones: localhost, 0.in-addr.arpa, 127.in-addr.arpa and 255.in-addr.arpa, any query under .localhost., and, by default for backward compatibility, any query prefixed by localhost.. When seeing one of the non-apex localhost forms a metric counter is increased and if debug is enabled a debug log is emitted.
With local enabled any query falling under these zones will get a reply.</description></item><item><title>minimal</title><link>https://coredns.website.cncfstack.com/plugins/minimal/</link><pubDate>Mon, 15 Mar 2021 14:42:29 +0000</pubDate><guid>https://coredns.website.cncfstack.com/plugins/minimal/</guid><description>Description The minimal plugin tries to minimize the size of the response. Depending on the response type it removes resource records from the AUTHORITY and ADDITIONAL sections.
Specifically this plugin looks at successful responses (this excludes negative responses, i.e. nodata or name error). If the successful response isn&amp;rsquo;t a delegation only the RRs in the answer section are written to the client.
Syntax minimal Examples Enable minimal responses:
example.org { whoami forward .</description></item><item><title>pprof</title><link>https://coredns.website.cncfstack.com/plugins/pprof/</link><pubDate>Wed, 28 Oct 2020 18:26:48 +0000</pubDate><guid>https://coredns.website.cncfstack.com/plugins/pprof/</guid><description>Description You can visit /debug/pprof on your site for an index of the available endpoints. By default it will listen on localhost:6053.
This is a debugging tool. Certain requests (such as collecting execution traces) can be slow. If you use pprof on a live server, consider restricting access or enabling it only temporarily.
This plugin can only be used once per Server Block.
Syntax pprof [ADDRESS] Optionally pprof takes an address; the default is localhost:6053.</description></item><item><title>log</title><link>https://coredns.website.cncfstack.com/plugins/log/</link><pubDate>Fri, 06 Mar 2026 16:27:00 +0000</pubDate><guid>https://coredns.website.cncfstack.com/plugins/log/</guid><description>Description By just using log you dump all queries (and parts for the reply) on standard output. Options exist to tweak the output a little. Note that for busy servers logging will incur a performance hit.
Enabling or disabling the log plugin only affects the query logging, any other logging from CoreDNS will show up regardless.
Syntax log With no arguments, a query log entry is written to stdout in the common log format for all requests.</description></item><item><title>multisocket</title><link>https://coredns.website.cncfstack.com/plugins/multisocket/</link><pubDate>Thu, 11 Dec 2025 04:36:33 +0000</pubDate><guid>https://coredns.website.cncfstack.com/plugins/multisocket/</guid><description>Description With multisocket, you can define the number of servers that will listen on the same port. The SO_REUSEPORT socket option allows to open multiple listening sockets at the same address and port. In this case, kernel distributes incoming connections between sockets.
Enabling this option allows to start multiple servers, which increases the throughput of CoreDNS in environments with a large number of CPU cores.
Syntax multisocket [NUM_SOCKETS] NUM_SOCKETS - the number of servers that will listen on one port.</description></item><item><title>prometheus</title><link>https://coredns.website.cncfstack.com/plugins/metrics/</link><pubDate>Wed, 01 Jul 2026 06:01:46 +0000</pubDate><guid>https://coredns.website.cncfstack.com/plugins/metrics/</guid><description>Description With prometheus you export metrics from CoreDNS and any plugin that has them. The default location for the metrics is localhost:9153. The metrics path is fixed to /metrics.
In addition to the default Go metrics exported by the Prometheus Go client, the following metrics are exported:
coredns_build_info{version, revision, goversion} - info about CoreDNS itself. coredns_panics_total{} - total number of panics. coredns_dns_requests_total{server, zone, view, proto, family, type} - total query count.</description></item><item><title>nomad</title><link>https://coredns.website.cncfstack.com/plugins/nomad/</link><pubDate>Thu, 11 Dec 2025 04:36:33 +0000</pubDate><guid>https://coredns.website.cncfstack.com/plugins/nomad/</guid><description>Description This plugin serves DNS records for services registered with Nomad. Nomad 1.3+ comes with support for discovering services with an in-built service catalogue that is available via the HTTP API. This plugin extends the HTTP API and provides a DNS interface for querying the service catalogue.
The query can be looked up with the format [service].[namespace].service.nomad. The plugin currently handles A, AAAA and SRV records. Refer to #Usage Example for more details.</description></item><item><title>quic</title><link>https://coredns.website.cncfstack.com/plugins/quic/</link><pubDate>Fri, 13 Jun 2025 10:26:16 +0000</pubDate><guid>https://coredns.website.cncfstack.com/plugins/quic/</guid><description>Description The quic plugin allows you to configure parameters for the DNS-over-QUIC (DoQ) server to fine-tune the security posture and performance of the server.
This plugin can only be used once per quic Server Block.
Syntax quic { max_streams POSITIVE_INTEGER worker_pool_size POSITIVE_INTEGER } max_streams limits the number of concurrent QUIC streams per connection. This helps prevent DoS attacks where an attacker could open many streams on a single connection, exhausting server resources.</description></item><item><title>reload</title><link>https://coredns.website.cncfstack.com/plugins/reload/</link><pubDate>Tue, 15 Aug 2023 20:06:20 +0000</pubDate><guid>https://coredns.website.cncfstack.com/plugins/reload/</guid><description>Description This plugin allows automatic reload of a changed Corefile. To enable automatic reloading of zone file changes, use the auto plugin.
This plugin periodically checks if the Corefile has changed by reading it and calculating its SHA512 checksum. If the file has changed, it reloads CoreDNS with the new Corefile. This eliminates the need to send a SIGHUP or SIGUSR1 after changing the Corefile.
The reloads are graceful - you should not see any loss of service when the reload happens.</description></item><item><title>ready</title><link>https://coredns.website.cncfstack.com/plugins/ready/</link><pubDate>Tue, 09 Sep 2025 19:01:00 +0000</pubDate><guid>https://coredns.website.cncfstack.com/plugins/ready/</guid><description>Description By enabling ready an HTTP endpoint on port 8181 will return 200 OK, when all plugins that are able to signal readiness have done so. If some are not ready yet the endpoint will return a 503 with the body containing the list of plugins that are not ready.
Each Server Block that enables the ready plugin will have the plugins in that server block report readiness into the /ready endpoint that runs on the same port.</description></item><item><title>root</title><link>https://coredns.website.cncfstack.com/plugins/root/</link><pubDate>Fri, 22 Nov 2024 08:09:54 +0000</pubDate><guid>https://coredns.website.cncfstack.com/plugins/root/</guid><description>Description The default root is the current working directory of CoreDNS. The root plugin allows you to change this. A relative root path is relative to the current working directory. NOTE: The root directory is NOT currently supported by all plugins. Currently the following plugins respect the root plugin configuration:
file tls dnssec This plugin can only be used once per Server Block.
Syntax root PATH PATH is the directory to set as CoreDNS&amp;rsquo; root.</description></item><item><title>route53</title><link>https://coredns.website.cncfstack.com/plugins/route53/</link><pubDate>Tue, 10 May 2022 17:23:57 +0000</pubDate><guid>https://coredns.website.cncfstack.com/plugins/route53/</guid><description>Description The route53 plugin is useful for serving zones from resource record sets in AWS route53. This plugin supports all Amazon Route 53 records (https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/ResourceRecordTypes.html). The route53 plugin can be used when CoreDNS is deployed on AWS or elsewhere.
Syntax route53 [ZONE:HOSTED_ZONE_ID...] { aws_access_key [AWS_ACCESS_KEY_ID AWS_SECRET_ACCESS_KEY] # Deprecated, uses other authentication methods instead. aws_endpoint ENDPOINT credentials PROFILE [FILENAME] fallthrough [ZONES...] refresh DURATION } ZONE the name of the domain to be accessed.</description></item><item><title>sign</title><link>https://coredns.website.cncfstack.com/plugins/sign/</link><pubDate>Mon, 15 Mar 2021 14:42:29 +0000</pubDate><guid>https://coredns.website.cncfstack.com/plugins/sign/</guid><description>Description The sign plugin is used to sign (see RFC 6781) zones. In this process DNSSEC resource records are added. The signatures that sign the resource records sets have an expiration date, this means the signing process must be repeated before this expiration data is reached. Otherwise the zone&amp;rsquo;s data will go BAD (RFC 4035, Section 5.5). The sign plugin takes care of this.
Only NSEC is supported, sign does not support NSEC3.</description></item><item><title>proxyproto</title><link>https://coredns.website.cncfstack.com/plugins/proxyproto/</link><pubDate>Wed, 01 Jul 2026 06:01:46 +0000</pubDate><guid>https://coredns.website.cncfstack.com/plugins/proxyproto/</guid><description>Description This plugin adds support for the PROXY protocol version 1 and 2. It allows CoreDNS to receive connections from a load balancer or proxy that uses the PROXY protocol to forward the original client&amp;rsquo;s IP address and port information.
Syntax proxyproto { allow &amp;lt;CIDR...&amp;gt; default &amp;lt;use|ignore|reject|skip&amp;gt; udp_session_tracking &amp;lt;duration&amp;gt; [max_sessions] } If allow is unspecified, PROXY protocol headers are accepted from all IP addresses. The default option controls how connections from sources not listed in allow are handled.</description></item><item><title>whoami</title><link>https://coredns.website.cncfstack.com/plugins/whoami/</link><pubDate>Thu, 06 Feb 2020 12:07:03 +0000</pubDate><guid>https://coredns.website.cncfstack.com/plugins/whoami/</guid><description>Description The whoami plugin is not really that useful, but can be used for having a simple (fast) endpoint to test clients against. When whoami returns a response it will have your client&amp;rsquo;s IP address in the additional section as either an A or AAAA record.
The reply always has an empty answer section. The port and transport are included in the additional section as a SRV record, transport can be &amp;ldquo;tcp&amp;rdquo; or &amp;ldquo;udp&amp;rdquo;.</description></item><item><title>rewrite</title><link>https://coredns.website.cncfstack.com/plugins/rewrite/</link><pubDate>Fri, 06 Mar 2026 16:27:00 +0000</pubDate><guid>https://coredns.website.cncfstack.com/plugins/rewrite/</guid><description>Description Rewrites are invisible to the client. There are simple rewrites (fast) and complex rewrites (slower), but they&amp;rsquo;re powerful enough to accommodate most dynamic back-end applications.
Syntax A simplified/easy-to-digest syntax for rewrite is&amp;hellip;
rewrite [continue|stop] FIELD [TYPE] [(FROM TO)|TTL] [OPTIONS] FIELD indicates what part of the request/response is being re-written.
type - the type field of the request will be rewritten. FROM/TO must be a DNS record type (A, MX, etc.</description></item><item><title>secondary</title><link>https://coredns.website.cncfstack.com/plugins/secondary/</link><pubDate>Mon, 13 Jul 2026 15:51:55 +0000</pubDate><guid>https://coredns.website.cncfstack.com/plugins/secondary/</guid><description>Description With secondary you can transfer (via AXFR) a zone from another server. The retrieved zone is not committed to disk (a violation of the RFC). This means restarting CoreDNS will cause it to retrieve all secondary zones.
If the primary server(s) don&amp;rsquo;t respond when CoreDNS is starting up, the AXFR will be retried indefinitely every 10s.
Syntax secondary [ZONES...] ZONES zones it should be authoritative for. If empty, the zones from the configuration block are used.</description></item><item><title>template</title><link>https://coredns.website.cncfstack.com/plugins/template/</link><pubDate>Thu, 08 Jan 2026 11:42:04 +0000</pubDate><guid>https://coredns.website.cncfstack.com/plugins/template/</guid><description>Description The template plugin allows you to dynamically respond to queries by just writing a (Go) template.
Syntax template CLASS TYPE [ZONE...] { match REGEX... answer RR additional RR authority RR rcode CODE ederror EXTENDED_ERROR_CODE [EXTRA_REASON] fallthrough [FALLTHROUGH-ZONE...] } CLASS the query class (usually IN or ANY). TYPE the query type (A, PTR, &amp;hellip; can be ANY to match all types). ZONE the zone scope(s) for this template. Defaults to the server zones.</description></item><item><title>timeouts</title><link>https://coredns.website.cncfstack.com/plugins/timeouts/</link><pubDate>Mon, 13 Jul 2026 15:51:55 +0000</pubDate><guid>https://coredns.website.cncfstack.com/plugins/timeouts/</guid><description>Description CoreDNS is configured with sensible timeouts for server connections by default. However in some cases for example where CoreDNS is serving over a slow mobile data connection the default timeouts are not optimal.
Additionally some routers hold open connections when using DNS over TLS or DNS over HTTPS. Allowing a longer idle timeout helps performance and reduces issues with such routers.
The timeouts &amp;ldquo;plugin&amp;rdquo; allows you to configure CoreDNS server read, write and idle timeouts.</description></item><item><title>tls</title><link>https://coredns.website.cncfstack.com/plugins/tls/</link><pubDate>Mon, 13 Jul 2026 15:51:55 +0000</pubDate><guid>https://coredns.website.cncfstack.com/plugins/tls/</guid><description>Description CoreDNS supports queries that are encrypted using TLS (DNS over Transport Layer Security, RFC 7858) or are using gRPC (https://grpc.io/ , not an IETF standard). Normally DNS traffic isn&amp;rsquo;t encrypted at all (DNSSEC only signs resource records).
The tls &amp;ldquo;plugin&amp;rdquo; allows you to configure the cryptographic keys that are needed for both DNS-over-TLS and DNS-over-gRPC. If the tls plugin is omitted, then no encryption takes place.
The gRPC protobuffer is defined in pb/dns.</description></item><item><title>trace</title><link>https://coredns.website.cncfstack.com/plugins/trace/</link><pubDate>Mon, 13 Jul 2026 15:51:55 +0000</pubDate><guid>https://coredns.website.cncfstack.com/plugins/trace/</guid><description>Description With trace you enable OpenTracing of how a request flows through CoreDNS. Enable the debug plugin to get logs from the trace plugin.
Syntax The simplest form is just:
trace [ENDPOINT-TYPE] [ENDPOINT] ENDPOINT-TYPE is the type of tracing destination. Currently only zipkin and datadog are supported. Defaults to zipkin. ENDPOINT is the tracing destination, and defaults to localhost:9411. For Zipkin, if ENDPOINT does not begin with http, then it will be transformed to http://ENDPOINT/api/v2/spans.</description></item><item><title>transfer</title><link>https://coredns.website.cncfstack.com/plugins/transfer/</link><pubDate>Mon, 13 Jul 2026 15:51:55 +0000</pubDate><guid>https://coredns.website.cncfstack.com/plugins/transfer/</guid><description>Description This plugin answers zone transfers for authoritative plugins that implement transfer.Transferer.
transfer answers full zone transfer (AXFR) requests and incremental zone transfer (IXFR) requests with AXFR fallback if the zone has changed.
When a plugin wants to notify it&amp;rsquo;s secondaries it will call back into the transfer plugin.
The following plugins implement zone transfers using this plugin: file, auto, secondary, and kubernetes. See transfer.go for implementation details if you are a plugin author that wants to use this plugin.</description></item><item><title>tsig</title><link>https://coredns.website.cncfstack.com/plugins/tsig/</link><pubDate>Wed, 01 Jul 2026 06:01:46 +0000</pubDate><guid>https://coredns.website.cncfstack.com/plugins/tsig/</guid><description>Description With tsig, you can define CoreDNS&amp;rsquo;s TSIG secret keys. Using those keys, tsig validates incoming TSIG requests and signs responses to those requests. It does not itself sign requests outgoing from CoreDNS; it is up to the respective plugins sending those requests to sign them using the keys defined by tsig.
The tsig plugin can also require that incoming requests be signed for certain query types, refusing requests that do not comply.</description></item><item><title>view</title><link>https://coredns.website.cncfstack.com/plugins/view/</link><pubDate>Wed, 01 Jul 2026 06:01:46 +0000</pubDate><guid>https://coredns.website.cncfstack.com/plugins/view/</guid><description>Description view defines an expression that must evaluate to true for a DNS request to be routed to the server block. This enables advanced server block routing functions such as split dns.
Syntax view NAME { expr EXPRESSION } view NAME - The name of the view used by metrics and exported as metadata for requests that match the view&amp;rsquo;s expression expr EXPRESSION - CoreDNS will only route incoming queries to the enclosing server block if the EXPRESSION evaluates to true.</description></item></channel></rss>