From 60c0998e1a589f8ef2acdcbdda522717d8596f2a Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Vladim=C3=ADr=20=C4=8Cun=C3=A1t?= <vladimir.cunat@nic.cz>
Date: Thu, 29 Mar 2018 14:06:01 +0200
Subject: [PATCH] docs: cross-linking nitpicks
- clickable module references
- clickable RFC references via :rfc:`NNN#anchor`
---
daemon/README.rst | 2 +-
modules/dns64/README.rst | 2 +-
modules/hints/README.rst | 2 +-
modules/policy/README.rst | 3 +--
modules/priming/README.rst | 2 +-
modules/serve_stale/README.rst | 2 +-
modules/ta_signal_query/README.rst | 6 +++---
7 files changed, 9 insertions(+), 10 deletions(-)
diff --git a/daemon/README.rst b/daemon/README.rst
index 545e0fa18..2880143c1 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 79096dc16..6ee33d816 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 e37b1580f..fef407157 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 722819dbe..c2ceb1537 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 826c78c13..29136849d 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 74ee09be5..5c681facf 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 00bdd48f5..04ee1edce 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.
--
GitLab