docs: cross-linking nitpicks

- clickable module references
- clickable RFC references via :rfc:`NNN#anchor`

daemon/README.rst

@@ -762,7 +762,7 @@ daemons or manipulated from other processes, making for example synchronised loa
   :return: current timeout
 
   Get or set time interval for which a nameserver address will be ignored after determining that it doesn't return (useful) answers.
-  The intention is to avoid waiting if there's little hope; instead, kresd can immediately SERVFAIL or immediately use stale records (with ``serve_stale`` module).
+  The intention is to avoid waiting if there's little hope; instead, kresd can immediately SERVFAIL or immediately use stale records (with :ref:`serve_stale <mod-serve_stale>` module).
 
   .. warning:: This settings applies only to the current kresd process.
 

modules/dns64/README.rst

@@ -5,7 +5,7 @@ DNS64
 
 The module for :rfc:`6147` DNS64 AAAA-from-A record synthesis, it is used to enable client-server communication between an IPv6-only client and an IPv4-only server. See the well written `introduction`_ in the PowerDNS documentation.
 
-.. warning:: The module currently won't work well with policy.STUB.
+.. warning:: The module currently won't work well with :ref:`policy.STUB <mod-policy>`.
 
 .. tip:: The A record sub-requests will be DNSSEC secured, but the synthetic AAAA records can't be. Make sure the last mile between stub and resolver is secure to avoid spoofing.
 

modules/hints/README.rst

@@ -25,7 +25,7 @@ Examples
     -- Add a custom hint
     hints['foo.bar'] = '127.0.0.1'
 
-.. note:: The ``policy`` module applies before ``hints``, meaning e.g. that hints for special names (:rfc:`6761#section-6`) like ``localhost`` or ``test`` will get shadowed by ``policy`` rules by default.
+.. note:: The :ref:`policy <mod-policy>` module applies before hints, meaning e.g. that hints for special names (:rfc:`6761#section-6`) like ``localhost`` or ``test`` will get shadowed by policy rules by default.
     That can be worked around e.g. by explicit ``policy.PASS`` action.
 
 Properties

modules/policy/README.rst

@@ -55,7 +55,7 @@ Also, it is possible to write your own action (i.e. Lua function). It is possibl
 
 Forwarding over TLS protocol (DNS-over-TLS)
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-Policy `TLS_FORWARD` allows you to forward queries using `Transport Layer Security`_ protocol, which hides the content of your queries from an attacker observing the network traffic. Further details about this protocol can be found in `RFC 7858`_ and `IETF draft dprive-dtls-and-tls-profiles`_.
+Policy `TLS_FORWARD` allows you to forward queries using `Transport Layer Security`_ protocol, which hides the content of your queries from an attacker observing the network traffic. Further details about this protocol can be found in :rfc:`7858` and `IETF draft dprive-dtls-and-tls-profiles`_.
 
 Queries affected by `TLS_FORWARD` policy will always be resolved over TLS connection. Knot Resolver does not implement fallback to non-TLS connection, so if TLS connection cannot be established or authenticated according to the configuration, the resolution will fail.
 
@@ -211,5 +211,4 @@ This module is enabled by default because it implements mandatory :rfc:`6761` lo
 .. _`Jan-Piet Mens's post`: http://jpmens.net/2011/04/26/how-to-configure-your-bind-resolvers-to-lie-using-response-policy-zones-rpz/
 .. _`Transport Layer Security`: https://en.wikipedia.org/wiki/Transport_Layer_Security
 .. _`DNS Privacy Project`: https://dnsprivacy.org/
-.. _`RFC 7858`: https://tools.ietf.org/html/rfc7858
 .. _`IETF draft dprive-dtls-and-tls-profiles`: https://tools.ietf.org/html/draft-ietf-dprive-dtls-and-tls-profiles

modules/priming/README.rst

@@ -4,7 +4,7 @@ Priming module
 --------------
 
 The module for Initializing a DNS Resolver with Priming Queries implemented
-according to RFC 8109. Purpose of the module is to keep up-to-date list of
+according to :rfc:`8109`. Purpose of the module is to keep up-to-date list of
 root DNS servers and associated IP addresses.
 
 Result of successful priming query replaces root hints distributed with

modules/serve_stale/README.rst

@@ -9,7 +9,7 @@ unable to contact upstream servers.
 By default it allows stale-ness by up to one day,
 after roughly four seconds trying to contact the servers.
 It's quite configurable/flexible; see the beginning of the module source for details.
-See also the RFC draft_ (not fully followed).
+See also the RFC draft_ (not fully followed) and :any:`cache.ns_tout`.
 
 Running
 ^^^^^^^

modules/ta_signal_query/README.rst

@@ -4,7 +4,7 @@ Signaling Trust Anchor Knowledge in DNSSEC
 ------------------------------------------
 
 The module for Signaling Trust Anchor Knowledge in DNSSEC Using Key Tag Query,
-implemented according to RFC 8145 section 5.
+implemented according to :rfc:`8145#section-5`.
 
 This feature allows validating resolvers to signal to authoritative servers
 which keys are referenced in their chain of trust. The data from such
@@ -15,8 +15,8 @@ This mechanism serve to measure the acceptance and use of new DNSSEC
 trust anchors and key signing keys (KSKs). This signaling data can be
 used by zone administrators as a gauge to measure the successful deployment
 of new keys. This is of particular interest for the DNS root zone in the event
-of key and/or algorithm rollovers that rely on RFC 5011 to automatically
+of key and/or algorithm rollovers that rely on :rfc:`5011` to automatically
 update a validating DNS resolver’s trust anchor.
 
-This module is enabled by default. You may use modules.unload('ta_signal_query')
+This module is enabled by default. You may use ``modules.unload('ta_signal_query')``
 in your configuration.