diff --git a/daemon/README.rst b/daemon/README.rst
index 545e0fa18c063e0c6e1e9ef2f88cfc846811aca1..2880143c14b6184b97bafe3624637b1edd0753cd 100644
--- a/daemon/README.rst
+++ b/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.
diff --git a/modules/dns64/README.rst b/modules/dns64/README.rst
index 79096dc16c908d45ca56f79307290126c8431870..6ee33d8167e9dc82a7387040841b2ced6daf4e1f 100644
--- a/modules/dns64/README.rst
+++ b/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.
diff --git a/modules/hints/README.rst b/modules/hints/README.rst
index e37b1580f5fca43cd040c87319122ef8b289440c..fef40715749d565772ef289c37968a7fb24eee7f 100644
--- a/modules/hints/README.rst
+++ b/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
diff --git a/modules/policy/README.rst b/modules/policy/README.rst
index 722819dbedc62ea2b918189bcf184cb8fcdee3be..c2ceb153761faa71582bb1bc0b6ca987236a2024 100644
--- a/modules/policy/README.rst
+++ b/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
diff --git a/modules/priming/README.rst b/modules/priming/README.rst
index 826c78c134f53419c8b729e32bc0dd256151c7c0..29136849d235a9bf0dad551f4986ddd15f94e4ea 100644
--- a/modules/priming/README.rst
+++ b/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
diff --git a/modules/serve_stale/README.rst b/modules/serve_stale/README.rst
index 74ee09be594f5149bfa1041b005fe80b0efbf8f0..5c681facfe2a3c42cbae6f1905fc60a763b20e3e 100644
--- a/modules/serve_stale/README.rst
+++ b/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
^^^^^^^
diff --git a/modules/ta_signal_query/README.rst b/modules/ta_signal_query/README.rst
index 00bdd48f5aaef65942cfb19f48e460a336c1af1d..04ee1edcefe8dafffaffb158d5897275f54f7c72 100644
--- a/modules/ta_signal_query/README.rst
+++ b/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.