From: Josh Soref <2119212+jsoref@users.noreply.github.com> Date: Mon, 21 Oct 2024 18:47:17 +0000 (-0400) Subject: spelling: greater X-Git-Tag: rec-5.2.0-alpha1~6^2~8 X-Git-Url: http://git.ipfire.org/?a=commitdiff_plain;h=b13bc3fd0128a876225ff21ef822a5e4eaaf92cb;p=thirdparty%2Fpdns.git spelling: greater Signed-off-by: Josh Soref <2119212+jsoref@users.noreply.github.com> --- diff --git a/docs/appendices/backend-writers-guide.rst b/docs/appendices/backend-writers-guide.rst index 5b535071f2..f668bb7c0e 100644 --- a/docs/appendices/backend-writers-guide.rst +++ b/docs/appendices/backend-writers-guide.rst @@ -531,7 +531,7 @@ A secondary zone is pulled from a primary, after which it is 'fresh', but this is only temporary. In the SOA record of a zone there is a field which specifies the 'refresh' interval. After that interval has elapsed, the secondary nameserver needs to check at the primary if the serial number -there is higher than what is stored in the backend locally. +there is greater than what is stored in the backend locally. If this is the case, PowerDNS dubs the domain 'stale', and schedules a transfer of data from the remote. This transfer remains scheduled until diff --git a/docs/changelog/pre-4.0.rst b/docs/changelog/pre-4.0.rst index e14a3f5f7e..7535ff9510 100644 --- a/docs/changelog/pre-4.0.rst +++ b/docs/changelog/pre-4.0.rst @@ -1561,7 +1561,7 @@ Changes between 3.2-RC2 and 3.2-RC3 3003 `__. - Mark Zealey found that an earlier performance improvement could cause crashes under high load, with lots of IPs configured in local-address - and receiver-threads higher than 1. Fixed in `commit + and receiver-threads greater than 1. Fixed in `commit 3005 `__. Changes between 3.2-RC1 and 3.2-RC2 diff --git a/docs/common/secpoll.rst b/docs/common/secpoll.rst index d181f1ffaf..a9eee744af 100644 --- a/docs/common/secpoll.rst +++ b/docs/common/secpoll.rst @@ -44,7 +44,7 @@ If at a later date, resolution fails, the security-status is not reset to 1. It could be lowered however if we discover the security status is less urgent than we thought. If resolution fails, and the previous security-status was 1, the new security-status becomes 0 ('no data'). -If the security-status was higher than 1, it will remain that way, and not get set to 0. +If the security-status was greater than 1, it will remain that way, and not get set to 0. In this way, security-status of 0 really means 'no data', and cannot mask a known problem. diff --git a/pdns/dnsdistdist/docs/advanced/tuning.rst b/pdns/dnsdistdist/docs/advanced/tuning.rst index 85a5692e5e..96a3829467 100644 --- a/pdns/dnsdistdist/docs/advanced/tuning.rst +++ b/pdns/dnsdistdist/docs/advanced/tuning.rst @@ -54,7 +54,7 @@ Large installations running dnsdist before 1.4.0 are advised to increase the def Looking at ``udp-in-errors`` in :func:`dumpStats` will reveal whether the system is dropping UDP datagrams because dnsdist does not pick them up fast enough. In that case it might be good to add more :func:`addLocal` directives. In the same way, if the number of ``Drops`` in :func:`showServers` increase fast enough, it might mean that the backend is overloaded but also that the UDP received thread is. In that case adding more :func:`newServer` -Using a single connected UDP socket to contact a backend, and thus a single (source address, source port, destination address, destination port) tuple, might not play well with some load-balancing mechanisms present in front of the backend. Linux's ``reuseport``, for example, does not balance the incoming datagrams to several threads in that case. That can be worked around by using the ``sockets`` option of the :func:`newServer` directive to open several sockets instead of one. You may want to set that number to a value somewhat higher than the number of worker threads configured in the backend. dnsdist will then select a socket using round-robin to forward a query to the backend, and use event multiplexing on the receiving side. +Using a single connected UDP socket to contact a backend, and thus a single (source address, source port, destination address, destination port) tuple, might not play well with some load-balancing mechanisms present in front of the backend. Linux's ``reuseport``, for example, does not balance the incoming datagrams to several threads in that case. That can be worked around by using the ``sockets`` option of the :func:`newServer` directive to open several sockets instead of one. You may want to set that number to a value somewhat greater than the number of worker threads configured in the backend. dnsdist will then select a socket using round-robin to forward a query to the backend, and use event multiplexing on the receiving side. Note that, since 1.7, dnsdist supports marking a backend as "TCP only", as well as enabling DNS over TLS communication between dnsdist and that backend. That leads to a different model where UDP queries are instead passed to a TCP worker: diff --git a/pdns/dnsdistdist/docs/reference/config.rst b/pdns/dnsdistdist/docs/reference/config.rst index 09eca5b66c..cd2b4d3fc4 100644 --- a/pdns/dnsdistdist/docs/reference/config.rst +++ b/pdns/dnsdistdist/docs/reference/config.rst @@ -711,7 +711,7 @@ Servers - address, e.g. ``""192.0.2.2""`` - interface name, e.g. ``""eth0""`` - address@interface, e.g. ``""192.0.2.2@eth0""`` " - ``sockets`` ``number`` "Number of UDP sockets (and thus source ports) used toward the backend server, defaults to a single one. Note that for backends which are multithreaded, this setting will have an effect on the number of cores that will be used to process traffic from dnsdist. For example you may want to set 'sockets' to a number somewhat higher than the number of worker threads configured in the backend, particularly if the Linux kernel is being used to distribute traffic to multiple threads listening on the same socket (via `reuseport`). See also :func:`setRandomizedOutgoingSockets`." + ``sockets`` ``number`` "Number of UDP sockets (and thus source ports) used toward the backend server, defaults to a single one. Note that for backends which are multithreaded, this setting will have an effect on the number of cores that will be used to process traffic from dnsdist. For example you may want to set 'sockets' to a number somewhat greater than the number of worker threads configured in the backend, particularly if the Linux kernel is being used to distribute traffic to multiple threads listening on the same socket (via `reuseport`). See also :func:`setRandomizedOutgoingSockets`." ``disableZeroScope`` ``bool`` "Disable the EDNS Client Subnet :doc:`../advanced/zero-scope` feature, which does a cache lookup for an answer valid for all subnets (ECS scope of 0) before adding ECS information to the query and doing the regular lookup. Default is false. This requires the ``parseECS`` option of the corresponding cache to be set to true" ``rise`` ``number`` "Require ``number`` consecutive successful checks before declaring the backend up, default: 1" ``useProxyProtocol`` ``bool`` "Add a proxy protocol header to the query, passing along the client's IP address and port along with the original destination address and port. Default is disabled."