: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.
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.
-- 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
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.
.. _`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
--------------
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
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
^^^^^^^
------------------------------------------
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
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.
projects / thirdparty / knot-resolver.git / commitdiff
