doc: move mode() function to DNSSEC & data verification section

diff --git a/daemon/README.rst b/daemon/README.rst
index 8de957bfd2e7c6feb18eecefb70f1d2bf03334dd..6194e06921fde139050b51d1655dbce376242627 100644 (file)
--- a/daemon/README.rst
+++ b/daemon/README.rst
@@ -34,29 +34,6 @@ TODO: Basics
       Operation not permitted
 
 
-.. function:: mode('strict' | 'normal' | 'permissive')
-
-   :return: Change resolver strictness checking level.
-
-   By default, resolver runs in *normal* mode. There are possibly many small adjustments
-   hidden behind the mode settings, but the main idea is that in *permissive* mode, the resolver
-   tries to resolve a name with as few lookups as possible, while in *strict* mode it spends much
-   more effort resolving and checking referral path. However, if majority of the traffic is covered
-   by DNSSEC, some of the strict checking actions are counter-productive.
-
-   .. csv-table::
-    :header: "Glue type", "Modes when it is accepted",   "Example glue [#example_glue]_"
-
-    "mandatory glue",     "strict, normal, permissive",  "ns1.example.org"
-    "in-bailiwick glue",  "normal, permissive",          "ns1.example2.org"
-    "any glue records",   "permissive",                  "ns1.example3.net"
-
-   .. [#example_glue] The examples show glue records acceptable from servers
-        authoritative for `org` zone when delegating to `example.org` zone.
-        Unacceptable or missing glue records trigger resolution of names listed
-        in NS records before following respective delegation.
-
-
 .. function:: reorder_RR([true | false])
 
    :param boolean value: New value for the option *(optional)*

diff --git a/daemon/lua/trust_anchors.rst b/daemon/lua/trust_anchors.rst
index b35385d6a296e15ed56b4feac39e713c06a173c2..b57583ad7cb38793248b37b80a7d819807951dfe 100644 (file)
--- a/daemon/lua/trust_anchors.rst
+++ b/daemon/lua/trust_anchors.rst
@@ -1,7 +1,7 @@
 .. _dnssec-config:
 
-DNSSEC
-======
+DNSSEC, data verification
+=========================
 
 Since version 4.0, **DNSSEC validation is enabled by default**.
 This is secure default and should not be changed unless absolutely necessary.
@@ -124,3 +124,8 @@ Following functions allow to modify DNSSEC configuration *if you really have to*
 .. function:: trust_anchors.summary()
 
    Return string with summary of configured DNSSEC trust anchors, including negative TAs.
+
+DNSSEC is main technology to protect data, but it is also possible to change how strictly
+resolver checks data from insecure DNS zones:
+
+.. include:: ../lib/layer/mode.rst

diff --git a/doc/config.rst b/doc/config.rst
index db98f88929f91d827f58ccd136dc8e2cd1977fe7..2bb771e3bec83c5a6961d2b1b83cee5b9b076bcd 100644 (file)
--- a/doc/config.rst
+++ b/doc/config.rst
@@ -70,6 +70,7 @@ Now you know what configuration file to modify, how to read examples and what mo
 .. include:: ../daemon/bindings/cache.rst
 .. include:: ../daemon/lua/trust_anchors.rst
 
+
 Multiple instances
 ==================
 

diff --git a/lib/layer/mode.rst b/lib/layer/mode.rst
new file mode 100644 (file)
index 0000000..ea5a03d
--- /dev/null
+++ b/lib/layer/mode.rst
@@ -0,0 +1,24 @@
+.. function:: mode(['strict' | 'normal' | 'permissive'])
+
+   :param: New checking level specified as string (*optional*).
+   :return: Current checking level.
+
+   Get or change resolver strictness checking level.
+
+   By default, resolver runs in *normal* mode. There are possibly many small adjustments
+   hidden behind the mode settings, but the main idea is that in *permissive* mode, the resolver
+   tries to resolve a name with as few lookups as possible, while in *strict* mode it spends much
+   more effort resolving and checking referral path. However, if majority of the traffic is covered
+   by DNSSEC, some of the strict checking actions are counter-productive.
+
+   .. csv-table::
+    :header: "Glue type", "Modes when it is accepted",   "Example glue [#example_glue]_"
+
+    "mandatory glue",     "strict, normal, permissive",  "ns1.example.org"
+    "in-bailiwick glue",  "normal, permissive",          "ns1.example2.org"
+    "any glue records",   "permissive",                  "ns1.example3.net"
+
+   .. [#example_glue] The examples show glue records acceptable from servers
+        authoritative for `org` zone when delegating to `example.org` zone.
+        Unacceptable or missing glue records trigger resolution of names listed
+        in NS records before following respective delegation.