惯性聚合 高效追踪和阅读你感兴趣的博客、新闻、科技资讯
阅读原文 在惯性聚合中打开

推荐订阅源

CTFtime.org: upcoming CTF events
CTFtime.org: upcoming CTF events
Project Zero
Project Zero
N
Netflix TechBlog - Medium
P
Privacy International News Feed
Cisco Talos Blog
Cisco Talos Blog
Recorded Future
Recorded Future
C
Cybersecurity and Infrastructure Security Agency CISA
The Register - Security
The Register - Security
P
Palo Alto Networks Blog
GbyAI
GbyAI
量子位
Simon Willison's Weblog
Simon Willison's Weblog
Cyberwarzone
Cyberwarzone
M
MIT News - Artificial intelligence
T
Threatpost
腾讯CDC
MyScale Blog
MyScale Blog
P
Privacy & Cybersecurity Law Blog
罗磊的独立博客
博客园 - 叶小钗
V
V2EX
美团技术团队
NISL@THU
NISL@THU
Y
Y Combinator Blog
Google DeepMind News
Google DeepMind News
C
Cisco Blogs
C
CXSECURITY Database RSS Feed - CXSecurity.com
Google Online Security Blog
Google Online Security Blog
PCI Perspectives
PCI Perspectives
K
KPMG report finds enterprise disconnect between AI and its ROI | CIO
爱范儿
爱范儿
G
Google Developers Blog
博客园 - Franky
P
Proofpoint News Feed
T
The Blog of Author Tim Ferriss
B
Blog
Spread Privacy
Spread Privacy
钛媒体:引领未来商业与生活新知
钛媒体:引领未来商业与生活新知
Latest news
Latest news
The GitHub Blog
The GitHub Blog
T
Threat Research - Cisco Blogs
D
DataBreaches.Net
F
Full Disclosure
L
LINUX DO - 热门话题
Stack Overflow Blog
Stack Overflow Blog
Scott Helme
Scott Helme
C
CERT Recently Published Vulnerability Notes
Jina AI
Jina AI
cs.AI updates on arXiv.org
cs.AI updates on arXiv.org
F
Fortinet All Blogs

Plugin on CoreDNS: DNS and Service Discovery

kubernetes log proxyproto rewrite forward clouddns errors grpc_server https https3 docker auto geoip multisocket nomad dnstap import ready etcd header loadbalance bind grpc file prometheus quic kubeforward JSON gslb autopath dnssec root k8s_cache bufsize k8s_external reload gathersrv meship meshname multicluster acl cache recursor health trace k8s_event redis route53 dns64 finalize kubenodes ebpf rrl secondary mysql warnlist loop minimal sign azure git local any cancel debug erratic metadata nsid pprof alternate k8s_dns_chaos records k8s_gateway hosts netbox mdns wgsd alias chaos whoami lighthouse ens idetcd gravwell amazondns kubernetai redisc unbound on dump pdsql ipin Logging with dnstap demo example When Should Plugins be External? Add External Plugins How Queries Are Processed in CoreDNS How to Add Plugins to CoreDNS Writing Plugins for CoreDNS
fanout
2024-09-03 · via Plugin on CoreDNS: DNS and Service Discovery

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 below

    • tls - no client authentication is used, and the system CAs are used to verify the server certificate
    • tls CA - no client authentication is used, and the file CA is used to verify the server certificate
    • tls CERT KEY - client authentication is used with the specified cert/key pair. The server certificate is verified with the system CAs
    • tls CERT KEY CA - client authentication is used with the specified cert/key pair. The server certificate is verified using the specified CA file
  • tls_servername NAME allows you to set a server name in the TLS configuration; for instance 9.9.9.9 needs this to be set to dns.quad9.net. Multiple upstreams are still allowed in this scenario, but they have to use the same tls_servername. E.g. mixing 9.9.9.9 (QuadDNS) with 1.1.1.1 (Cloudflare) will not work.

  • worker-count is the number of parallel queries per request. By default equals to count of IP list. Use this only for reducing parallel queries per request.

  • policy - specifies the policy of DNS server selection mechanism. The default is sequential.

    • sequential - select DNS servers one-by-one based on its order
    • weighted-random - select DNS servers randomly based on weighted-random-server-count and weighted-random-load-factor params.
  • weighted-random-server-count is the number of DNS servers to be requested. Equals to the number of specified IPs by default. Used only with the weighted-random policy.

  • weighted-random-load-factor - the probability of selecting a server. This is specified in the order of the list of IP addresses and takes values between 1 and 100. By default, all servers have an equal probability of 100. Used only with the weighted-random policy.

  • network is a specific network protocol. Could be tcp, udp, tcp-tls.

  • except is a list is a space-separated list of domains to exclude from proxying.

  • except-file is the path to file with line-separated list of domains to exclude from proxying.

  • attempt-count is the number of attempts to connect to upstream servers that are needed before considering an upstream to be down. If 0, the upstream will never be marked as down and request will be finished by timeout. Default is 3.

  • timeout is the timeout of request. After this period, attempts to receive a response from the upstream servers will be stopped. Default is 30s.

  • race gives priority to the first result, whether it is negative or not, as long as it is a standard DNS result.

Metrics

If monitoring is enabled (via the prometheus plugin) then the following metric are exported:

  • coredns_fanout_request_duration_seconds{to} - duration per upstream interaction.
  • coredns_fanout_request_count_total{to} - query count per upstream.
  • coredns_fanout_response_rcode_count_total{to, rcode} - count of RCODEs per upstream.

Where to is one of the upstream servers (TO from the config), rcode is the returned RCODE from the upstream.

Examples

Proxy all requests within example.org. to a nameservers running on a different ports. The first positive response from a proxy will be provided as the result.

example.org {
    fanout . 127.0.0.1:9005 127.0.0.1:9006 127.0.0.1:9007 127.0.0.1:9008
}

Sends parallel requests between three resolvers, one of which has a IPv6 address via TCP. The first response from proxy will be provided as the result.

. {
    fanout . 10.0.0.10:53 10.0.0.11:1053 [2003::1]:53 {
        network TCP
    }
}

Proxying everything except requests to example.org

. {
    fanout . 10.0.0.10:1234 {
        except example.org
    }
}

Proxy everything except example.org using the host’s resolv.conf’s nameservers:

. {
    fanout . /etc/resolv.conf {
        except example.org
    }
}

Proxy all requests to 9.9.9.9 using the DNS-over-TLS protocol. Note the tls-server is mandatory if you want a working setup, as 9.9.9.9 can’t be used in the TLS negotiation.

. {
    fanout . tls://9.9.9.9 {
       tls-server dns.quad9.net
    }
}

Sends parallel requests between five resolvers via UDP uses two workers and without attempting to reconnect. The first positive response from a proxy will be provided as the result.

. {
    fanout . 10.0.0.10:53 10.0.0.11:53 10.0.0.12:53 10.0.0.13:1053 10.0.0.14:1053 {
        worker-count 2
    }
}

Multiple upstream servers are configured but one of them is down, query a non-existent domain. If race is enable, we will get NXDOMAIN result quickly, otherwise we will get "connection timed out" result in a few seconds.

. {
    fanout . 10.0.0.10:53 10.0.0.11:53 10.0.0.12:53 10.0.0.13:1053 10.0.0.14:1053 {
        race
    }
}

Sends parallel requests between two randomly selected resolvers. Note, that 127.0.0.1:9007 would be selected more frequently as it has the highest weighted-random-load-factor.

example.org {
    fanout . 127.0.0.1:9005 127.0.0.1:9006 127.0.0.1:9007 {
      policy weighted-random
      weighted-random-server-count 2
      weighted-random-load-factor 50 70 100
    }
}

Sends parallel requests between three resolver sequentially (default mode).

example.org {
    fanout . 127.0.0.1:9005 127.0.0.1:9006 127.0.0.1:9007 {
        policy sequential
    }
}

Also See

See the fanout.