From: Vladimír Čunát Date: Thu, 1 Apr 2021 13:05:31 +0000 (+0200) Subject: policy.STUB docs: recommend NO_EDNS and mention NO_0X20 X-Git-Tag: v5.3.2~1^2 X-Git-Url: http://git.ipfire.org/cgi-bin/gitweb.cgi?a=commitdiff_plain;h=refs%2Fpipelines%2F80983;p=thirdparty%2Fknot-resolver.git policy.STUB docs: recommend NO_EDNS and mention NO_0X20 --- diff --git a/modules/policy/README.rst b/modules/policy/README.rst index 83ca7729d..9ba76ac38 100644 --- a/modules/policy/README.rst +++ b/modules/policy/README.rst @@ -332,9 +332,10 @@ Actions :func:`policy.FORWARD`, :func:`policy.TLS_FORWARD` and :func:`policy.STU policy.STUB('192.0.2.1@5353'), {todname('1.168.192.in-addr.arpa')})) -.. note:: Forwarding targets must support +.. note:: By default, forwarding targets must support `EDNS `_ and `0x20 randomization `_. + See example in `Replacing part of the DNS tree`_. .. _tls-forwarding: @@ -538,7 +539,11 @@ The easiest work-around is to disable reading from cache for grafted domains. '2.0.192.in-addr.arpa.' -- this applies to reverse DNS tree as well }) -- Beware: the rule order is important, as policy.STUB is not a chain action. - policy.add(policy.suffix(policy.FLAGS({'NO_CACHE'}), extraTrees)) + -- Flags: for "dumb" targets disabling EDNS can help (below) as DNSSEC isn't + -- validated anyway; in some of those cases adding 'NO_0X20' can also help, + -- though it also lowers defenses against off-path attacks on communication + -- between the two servers. + policy.add(policy.suffix(policy.FLAGS({'NO_CACHE', 'NO_EDNS'}), extraTrees)) policy.add(policy.suffix(policy.STUB({'2001:db8::1'}), extraTrees)) Response policy zones