https://coredns.website.cncfstack.com/categories/external/Recent content in external on CoreDNS: DNS and Service DiscoveryHugo -- gohugo.ioen-usCoreDNS - All Rights ReservedMon, 11 May 2026 00:00:00 +0000https://coredns.website.cncfstack.com/explugins/redis_cache/Mon, 11 May 2026 00:00:00 +0000https://coredns.website.cncfstack.com/explugins/redis_cache/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.https://coredns.website.cncfstack.com/explugins/docker/Thu, 18 Dec 2025 18:39:00 +0400https://coredns.website.cncfstack.com/explugins/docker/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.https://coredns.website.cncfstack.com/explugins/kubeforward/Fri, 04 Apr 2025 17:15:00 +0000https://coredns.website.cncfstack.com/explugins/kubeforward/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 <namespace> service_name <service_name> port_name <port_name> expire <duration> health_check <duration> force_tcp prefer_udp } Configuration Parameters namespace (required): Specifies the Kubernetes namespace where the target Service resides.https://coredns.website.cncfstack.com/explugins/json/Wed, 05 Mar 2025 15:51:45 -0800https://coredns.website.cncfstack.com/explugins/json/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 <URI> 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 TXThttps://coredns.website.cncfstack.com/explugins/gslb/Sun, 09 Feb 2025 17:00:00 +0200https://coredns.website.cncfstack.com/explugins/gslb/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.https://coredns.website.cncfstack.com/explugins/fanout/Tue, 03 Sep 2024 22:00:00 +0800https://coredns.website.cncfstack.com/explugins/fanout/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’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 belowhttps://coredns.website.cncfstack.com/explugins/k8s_cache/Wed, 24 Apr 2024 15:20:00 +0200https://coredns.website.cncfstack.com/explugins/k8s_cache/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 “late cache”, which is shifted a number of seconds.https://coredns.website.cncfstack.com/explugins/gathersrv/Sun, 02 Jul 2023 12:00:00 +0000https://coredns.website.cncfstack.com/explugins/gathersrv/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.https://coredns.website.cncfstack.com/explugins/meship/Mon, 15 May 2023 12:00:00 +0000https://coredns.website.cncfstack.com/explugins/meship/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.https://coredns.website.cncfstack.com/explugins/meshname/Mon, 15 May 2023 12:00:00 +0000https://coredns.website.cncfstack.com/explugins/meshname/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.https://coredns.website.cncfstack.com/explugins/multicluster/Fri, 03 Mar 2023 03:51:43 +0000https://coredns.website.cncfstack.com/explugins/multicluster/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.https://coredns.website.cncfstack.com/explugins/recursor/Mon, 30 Jan 2023 16:15:00 +0200https://coredns.website.cncfstack.com/explugins/recursor/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.https://coredns.website.cncfstack.com/explugins/k8s_event/Tue, 23 Aug 2022 10:57:00 +0800https://coredns.website.cncfstack.com/explugins/k8s_event/Description k8s_event listens for log printings, and reports them as Events to Kubernetes APIServer. This plugin requires … 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.https://coredns.website.cncfstack.com/explugins/redis/Mon, 27 Jun 2022 18:00:00 -0400https://coredns.website.cncfstack.com/explugins/redis/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 .https://coredns.website.cncfstack.com/explugins/finalize/Thu, 23 Dec 2021 09:00:00 +0100https://coredns.website.cncfstack.com/explugins/finalize/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 > 0 can be specified.https://coredns.website.cncfstack.com/explugins/kubenodes/Fri, 17 Dec 2021 00:00:00 +0000https://coredns.website.cncfstack.com/explugins/kubenodes/Description kubenodes watches the Kubernetes API and synthesizes A, AAAA, and PTR records for Node addresses. This plugin requires … 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’ external addresses. If omitted, kubenodes will build records using Nodes’ internal addresses.https://coredns.website.cncfstack.com/explugins/ebpf/Thu, 14 Oct 2021 00:00:00 +0000https://coredns.website.cncfstack.com/explugins/ebpf/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.https://coredns.website.cncfstack.com/explugins/rrl/Thu, 07 Oct 2021 00:00:00 +0000https://coredns.website.cncfstack.com/explugins/rrl/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.https://coredns.website.cncfstack.com/explugins/mysql/Mon, 07 Jun 2021 01:01:00 +0000https://coredns.website.cncfstack.com/explugins/mysql/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.https://coredns.website.cncfstack.com/explugins/warnlist/Thu, 03 Jun 2021 16:00:00 +0100https://coredns.website.cncfstack.com/explugins/warnlist/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.https://coredns.website.cncfstack.com/explugins/git/Thu, 07 Jan 2021 00:12:00 +0800https://coredns.website.cncfstack.com/explugins/git/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.https://coredns.website.cncfstack.com/explugins/alternate/Mon, 28 Sep 2020 00:00:00 -0500https://coredns.website.cncfstack.com/explugins/alternate/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:https://coredns.website.cncfstack.com/explugins/k8s_dns_chaos/Tue, 22 Sep 2020 21:57:00 +0800https://coredns.website.cncfstack.com/explugins/k8s_dns_chaos/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.https://coredns.website.cncfstack.com/explugins/records/Tue, 22 Sep 2020 07:53:19 +0100https://coredns.website.cncfstack.com/explugins/records/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.https://coredns.website.cncfstack.com/explugins/k8s_gateway/Sat, 19 Sep 2020 12:00:00 -0800https://coredns.website.cncfstack.com/explugins/k8s_gateway/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’s own connection to the k8s API server and doesn’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).https://coredns.website.cncfstack.com/explugins/netbox/Sun, 28 Jun 2020 15:01:20 +0100https://coredns.website.cncfstack.com/explugins/netbox/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’t found. If a record is found a record is sent and the query processing is stopped.https://coredns.website.cncfstack.com/explugins/mdns/Wed, 17 Jun 2020 11:07:00 +1200https://coredns.website.cncfstack.com/explugins/mdns/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.https://coredns.website.cncfstack.com/explugins/wgsd/Wed, 27 May 2020 17:05:00 -0800https://coredns.website.cncfstack.com/explugins/wgsd/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.<zone>. The target for the PTR records is <base32PubKey>._wireguard._udp.<zone> which corresponds to SRV records. SRV targets are of the format <base32PubKey>.https://coredns.website.cncfstack.com/explugins/alias/Sat, 25 Apr 2020 19:12:00 +0800https://coredns.website.cncfstack.com/explugins/alias/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’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.https://coredns.website.cncfstack.com/explugins/lighthouse/Thu, 21 Nov 2019 10:00:00 +0800https://coredns.website.cncfstack.com/explugins/lighthouse/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.https://coredns.website.cncfstack.com/explugins/idetcd/Mon, 13 Aug 2018 18:54:20 +0100https://coredns.website.cncfstack.com/explugins/idetcd/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 “http://localhost:2379”. 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.https://coredns.website.cncfstack.com/explugins/gravwell/Wed, 04 Jul 2018 20:25:00 +0000https://coredns.website.cncfstack.com/explugins/gravwell/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.https://coredns.website.cncfstack.com/explugins/amazondns/Tue, 06 Mar 2018 20:32:00 +0900https://coredns.website.cncfstack.com/explugins/amazondns/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’t be Authoritative name server. In my case, Authoritative name server is required to handle delegated responsibility for the subdomain.https://coredns.website.cncfstack.com/explugins/kubernetai/Mon, 05 Mar 2018 21:57:00 +0800https://coredns.website.cncfstack.com/explugins/kubernetai/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.https://coredns.website.cncfstack.com/explugins/unbound/Thu, 25 Jan 2018 11:25:00 +0000https://coredns.website.cncfstack.com/explugins/unbound/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’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:https://coredns.website.cncfstack.com/explugins/on/Mon, 22 Jan 2018 07:53:19 +0100https://coredns.website.cncfstack.com/explugins/on/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 &, 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.https://coredns.website.cncfstack.com/explugins/dump/Wed, 17 Jan 2018 21:57:00 +0800https://coredns.website.cncfstack.com/explugins/dump/Description dump uses the synax from the log plugin, and defaults to this format: {remote} - [{when}] {>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.https://coredns.website.cncfstack.com/explugins/pdsql/Sat, 09 Dec 2017 10:26:00 +0800https://coredns.website.cncfstack.com/explugins/pdsql/Description pdsql uses PowerDNS generic sql as backend. Use jinzhu/gorm database drivers, supports as many databases as Gorm does. Syntax pdsql <dialect> <arg> { // 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.https://coredns.website.cncfstack.com/explugins/ipin/Sat, 09 Dec 2017 02:00:00 +0800https://coredns.website.cncfstack.com/explugins/ipin/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 <port> . Syntax ipin Examples Start a server on the default port and load the ipin plugin. . { ipin } When queried for “192-168-1-1.https://coredns.website.cncfstack.com/explugins/demo/Tue, 25 Jul 2017 21:57:00 +0800https://coredns.website.cncfstack.com/explugins/demo/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:https://coredns.website.cncfstack.com/explugins/example/Tue, 25 Jul 2017 21:57:00 +0800https://coredns.website.cncfstack.com/explugins/example/Description The example plugin prints “example” 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.https://coredns.website.cncfstack.com/explugins/ens/Fri, 13 Sep 2019 09:00:00 +0100https://coredns.website.cncfstack.com/explugins/ens/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.https://coredns.website.cncfstack.com/explugins/ipecho/Fri, 29 Sep 2017 16:18:35 +0100https://coredns.website.cncfstack.com/explugins/ipecho/Description ipecho parses the IP out of a subdomain and echos it back as an record. Example A IN 127.0.0.1.example.com. -> A: 127.0.0.1 AAAA IN ::1.example.com. -> AAAA: ::1 Syntax ipecho { domain example1.com domain example2.com ttl 2629800 } domain adds the domain that should be handled ttl defines the ttl that should be used in the response debug enables debug logging