Directive -> plugin (#3363)

Caught my eye, we name things directive still, esp when talking about
the prometheus *plugin*. Rename everything that needs to be plugin to
'plugin'. Also make sure Metrics is a H2 section (not H1).

Signed-off-by: Miek Gieben <miek@miek.nl>

plugin/autopath/README.md

@@ -27,7 +27,7 @@ If a plugin implements the `AutoPather` interface then it can be used.
 
 ## Metrics
 
-If monitoring is enabled (via the *prometheus* directive) then the following metric is exported:
+If monitoring is enabled (via the *prometheus* plugin) then the following metric is exported:
 
 * `coredns_autopath_success_count_total{server}` - counter of successfully autopath-ed queries.
 

plugin/bind/README.md

@@ -40,7 +40,7 @@ To allow processing DNS requests only local host on both IPv4 and IPv6 stacks, u
 }
 ~~~
 
-If the configuration comes up with several *bind* directives, all addresses are consolidated together:
+If the configuration comes up with several *bind* plugins, all addresses are consolidated together:
 The following sample is equivalent to the preceding:
 
 ~~~ corefile

plugin/cache/README.md

@@ -61,9 +61,9 @@ Since shards don't fill up perfectly evenly, evictions will occur before the ent
 Each shard capacity is equal to the total cache size / number of shards (256). Eviction is random, not TTL based.
 Entries with 0 TTL will remain in the cache until randomly evicted when the shard reaches capacity.
 
-# Metrics
+## Metrics
 
-If monitoring is enabled (via the *prometheus* directive) then the following metrics are exported:
+If monitoring is enabled (via the *prometheus* plugin) then the following metrics are exported:
 
 * `coredns_cache_size{server, type}` - Total elements in the cache by cache type.
 * `coredns_cache_hits_total{server, type}` - Counter of cache hits by cache type.

plugin/dnssec/README.md

@@ -51,7 +51,7 @@ used (See [bugs](#bugs)).
 
 ## Metrics
 
-If monitoring is enabled (via the *prometheus* directive) then the following metrics are exported:
+If monitoring is enabled (via the *prometheus* plugin) then the following metrics are exported:
 
 * `coredns_dnssec_cache_size{server, type}` - total elements in the cache, type is "signature".
 * `coredns_dnssec_cache_hits_total{server}` - Counter of cache hits.

plugin/file/README.md

@@ -18,7 +18,7 @@ file DBFILE [ZONES...]
 ~~~
 
 * **DBFILE** the database file to read and parse. If the path is relative, the path from the *root*
-  directive will be prepended to it.
+  plugin will be prepended to it.
 * **ZONES** zones it should be authoritative for. If empty, the zones from the configuration block
   are used.
 

plugin/forward/README.md

@@ -94,7 +94,7 @@ On each endpoint, the timeouts of the communication are set by default and autom
 
 ## Metrics
 
-If monitoring is enabled (via the *prometheus* directive) then the following metric are exported:
+If monitoring is enabled (via the *prometheus* plugin) then the following metric are exported:
 
 * `coredns_forward_request_duration_seconds{to}` - duration per upstream interaction.
 * `coredns_forward_request_count_total{to}` - query count per upstream.

plugin/grpc/README.md

@@ -60,7 +60,7 @@ Also note the TLS config is "global" for the whole grpc proxy if you need a diff
 
 ## Metrics
 
-If monitoring is enabled (via the *prometheus* directive) then the following metric are exported:
+If monitoring is enabled (via the *prometheus* plugin) then the following metric are exported:
 
 * `coredns_grpc_request_duration_seconds{to}` - duration per upstream interaction.
 * `coredns_grpc_request_count_total{to}` - query count per upstream.

plugin/health/README.md

@@ -48,7 +48,7 @@ Doing this is supported but both endpoints ":8080" and ":8081" will export the e
 
 ## Metrics
 
-If monitoring is enabled (via the *prometheus* directive) then the following metric is exported:
+If monitoring is enabled (via the *prometheus* plugin) then the following metric is exported:
 
  *  `coredns_health_request_duration_seconds{}` - duration to process a HTTP query to the local
     `/health` endpoint. As this a local operation it should be fast. A (large) increase in this

plugin/hosts/README.md

@@ -55,7 +55,7 @@ hosts [FILE [ZONES...]] {
 ~~~
 
 * **FILE** the hosts file to read and parse. If the path is relative the path from the *root*
-  directive will be prepended to it. Defaults to /etc/hosts if omitted. We scan the file for changes
+  plugin will be prepended to it. Defaults to /etc/hosts if omitted. We scan the file for changes
   every 5 seconds.
 * **ZONES** zones it should be authoritative for. If empty, the zones from the configuration block
    are used.
@@ -74,7 +74,7 @@ hosts [FILE [ZONES...]] {
 
 ## Metrics
 
-If monitoring is enabled (via the *prometheus* directive) then the following metrics are exported:
+If monitoring is enabled (via the *prometheus* plugin) then the following metrics are exported:
 
 - `coredns_hosts_entries_count{}` - The combined number of entries in hosts and Corefile.
 - `coredns_hosts_reload_timestamp_seconds{}` - The timestamp of the last reload of hosts file.

plugin/import/README.md

@@ -9,7 +9,7 @@
 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 directive in that *import* can appear outside of a server block. In other words, it
+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

plugin/kubernetes/README.md

@@ -24,7 +24,7 @@ This plugin can only be used once per Server Block.
 kubernetes [ZONES...]
 ~~~
 
-With only the directive specified, the *kubernetes* plugin will default to the zone specified in
+With only the plugin specified, the *kubernetes* plugin will default to the zone specified in
 the server's block. It will handle all queries in that zone and connect to Kubernetes in-cluster. It
 will not provide PTR records for services or A records for pods. If **ZONES** is used it specifies
 all the zones the plugin should be authoritative for.
@@ -231,7 +231,7 @@ plugin is also enabled:
 
 ## Metrics
 
-If monitoring is enabled (via the *prometheus* directive) then the following metrics are exported:
+If monitoring is enabled (via the *prometheus* plugin) then the following metrics are exported:
 
 * `coredns_kubernetes_dns_programming_duration_seconds{service_kind}` - Exports the
   [DNS programming latency SLI](https://github.com/kubernetes/community/blob/master/sig-scalability/slos/dns_programming_latency.md).

plugin/reload/README.md

@@ -96,7 +96,7 @@ CoreDNS v1.7.0 and later does parse the Corefile and supports detecting changes
 
 ## Metrics
 
- If monitoring is enabled (via the *prometheus* directive) then the following metric is exported:
+ If monitoring is enabled (via the *prometheus* plugin) then the following metric is exported:
 
 * `coredns_reload_failed_count_total{}` - counts the number of failed reload attempts.
 

plugin/sign/README.md

@@ -62,7 +62,7 @@ sign DBFILE [ZONES...] {
 ~~~
 
 *  **DBFILE** the zone database file to read and parse. If the path is relative, the path from the
-   *root* directive will be prepended to it.
+   *root* plugin will be prepended to it.
 *  **ZONES** zones it should be sign for. If empty, the zones from the configuration block are
    used.
 * `key` specifies the key(s) (there can be multiple) to sign the zone. If `file` is
@@ -71,7 +71,7 @@ sign DBFILE [ZONES...] {
    *ignored*. These keys must also be Key Signing Keys (KSK).
 *  `directory` specifies the **DIR** where CoreDNS should save zones that have been signed.
    If not given this defaults to `/var/lib/coredns`. The zones are saved under the name
-   `db.<name>.signed`. If the path is relative the path from the *root* directive will be prepended
+   `db.<name>.signed`. If the path is relative the path from the *root* plugin will be prepended
    to it.
 
 Keys can be generated with `coredns-keygen`, to create one for use in the *sign* plugin, use:

plugin/template/README.md

@@ -59,7 +59,7 @@ The output of the template must be a [RFC 1035](https://tools.ietf.org/html/rfc1
 
 ## Metrics
 
-If monitoring is enabled (via the *prometheus* directive) then the following metrics are exported:
+If monitoring is enabled (via the *prometheus* plugin) then the following metrics are exported:
 
 * `coredns_template_matches_total{server, regex}` the total number of matched requests by regex.
 * `coredns_template_template_failures_total{server, regex,section,template}` the number of times the Go templating failed. Regex, section and template label values can be used to map the error back to the config file.

plugin/tls/README.md

@@ -11,7 +11,7 @@ or are using gRPC (https://grpc.io/, not an IETF standard). Normally DNS traffic
 all (DNSSEC only signs resource records).
 
 The *tls* "plugin" allows you to configure the cryptographic keys that are needed for both
-DNS-over-TLS and DNS-over-gRPC. If the `tls` directive is omitted, then no encryption takes place.
+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.proto`. It defines the proto as a simple wrapper for the
 wire data of a DNS message.