Error in documentation: `discovery_max_stale` is not in `dns_config`

Moved the entry at the top level instead of DNS

website/source/docs/agent/options.html.md

@@ -695,6 +695,16 @@ Consul will not enable TLS for the HTTP API unless the `https` port has been ass
   to the Consul raft log in environments where health checks have volatile output like
   timestamps, process ids, ...
 
+  * <a name="discovery_max_stale"></a><a href="#discovery_max_stale">`discovery_max_stale`</a> - Enables
+  stale requests for all service discovery HTTP endpoints. This is equivalent to the
+  [`max_stale`](#max_stale) configuration for DNS requests. If this value is zero (default), all service
+  discovery HTTP endpoints are forwarded to the leader. If this value is greater than zero, any Consul server
+  can handle the service discovery request.  If a Consul server is behind the leader by more than `discovery_max_stale`,
+  the query will be re-evaluated on the leader to get more up-to-date results. Consul agents also add a new
+  `X-Consul-Effective-Consistency` response header which indicates if the agent did a stale read. `discover-max-stale`
+  was introduced in Consul 1.0.7 as a way for Consul operators to force stale requests from clients at the agent level,
+  and defaults to zero which matches default consistency behavior in earlier Consul versions.
+
 *   <a name="dns_config"></a><a href="#dns_config">`dns_config`</a> This object allows a number
     of sub-keys to be set which can tune how DNS queries are serviced. See this guide on
     [DNS caching](/docs/guides/dns-cache.html) for more detail.
@@ -717,17 +727,6 @@ Consul will not enable TLS for the HTTP API unless the `https` port has been ass
       leader, so this lets Consul continue serving requests in long outage scenarios where no leader can
       be elected.
 
-    * <a name="discovery_max_stale"></a><a href="#discovery_max_stale">`discovery_max_stale`</a> - Enables
-      stale requests for all service discovery HTTP endpoints. This is equivalent to the
-      [`max_stale`](#max_stale) configuration for DNS requests. If this value is zero (default), all service
-      discovery HTTP endpoints are forwarded to the leader. If this value is greater than zero, any Consul server
-      can handle the service discovery request.  If a Consul server is behind the leader by more than `discovery_max_stale`,
-      the query will be re-evaluated on the leader to get more up-to-date results. Consul agents also add a new
-      `X-Consul-Effective-Consistency` response header which indicates if the agent did a stale read. `discover-max-stale`
-      was introduced in Consul 1.0.7 as a way for Consul operators to force stale requests from clients at the agent level,
-      and defaults to zero which matches default consistency behavior in earlier Consul versions.
-
-
     * <a name="node_ttl"></a><a href="#node_ttl">`node_ttl`</a> - By default, this is "0s", so all
       node lookups are served with a 0 TTL value. DNS caching for node lookups can be enabled by
       setting this value. This should be specified with the "s" suffix for second or "m" for minute.
@@ -768,7 +767,7 @@ Consul will not enable TLS for the HTTP API unless the `https` port has been ass
       When answering a question, Consul will use the complete list of
       matching hosts, shuffle the list randomly, and then limit the number of
       answers to `a_record_limit` (default: no limit). This limit does not apply to SRV records.
-      
+
       In environments where [RFC 3484 Section 6](https://tools.ietf.org/html/rfc3484#section-6) Rule 9
       is implemented and enforced (i.e. DNS answers are always sorted and
       therefore never random), clients may need to set this value to `1` to