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
3003 <http://wiki.powerdns.com/projects/trac/changeset/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 <http://wiki.powerdns.com/projects/trac/changeset/3005>`__.
Changes between 3.2-RC1 and 3.2-RC2
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.
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:
- 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."
projects / thirdparty / pdns.git / commitdiff
