[Pdns-users] PowerDNS DNSdist 1.9.3 released

[Remi Gacogne via Pdns-users]

Hello!

Less than an hour after the release of PowerDNS DNSdist 1.9.2 today, we 
received reports of DNSdist crashing in some setups. This 1.9.3 release 
fixes the issue that was introduced in 1.9.2, for now by reverting the 
related change.


Please see the DNSdist website [1] for the changelog [2] and the current 
documentation. The upgrade guide is also available there [3].


Please send us all feedback and issues you might have via the mailing 
list, or in case of a bug, via GitHub [4].


The release tarball [5] and its signature [6] are available on the 
downloads website, and packages for several distributions are available 
from our repository [7].


[1]: https://dnsdist.org
[2]: https://dnsdist.org/changelog.html#change-1.9.3
[3]: https://dnsdist.org/upgrade_guide.html
[4]: https://github.com/PowerDNS/pdns/issues/new/choose
[5]:
https://downloads.powerdns.com/releases/dnsdist-1.9.3.tar.bz2
[6]:
https://downloads.powerdns.com/releases/dnsdist-1.9.3.tar.bz2.sig
[7]: https://repo.powerdns.com

Best regards,
--
Remi Gacogne
PowerDNS.COM BV - https://www.powerdns.com/


OpenPGP_signature.asc
Description: OpenPGP digital signature
___
Pdns-users mailing list
Pdns-users@mailman.powerdns.com
https://mailman.powerdns.com/mailman/listinfo/pdns-users

[Pdns-users] PowerDNS DNSdist 1.9.2 released

[Remi Gacogne via Pdns-users]

Hello!

We released PowerDNS DNSdist 1.9.2 today. This release fixes several issues:
- HTTP/1.1 was wrongly selected over HTTP/2 when a DNS over HTTPS client 
advertised both HTTP versions in ALPN and listed HTTP/1.1 first, and the 
nghttp2 provider was used

- The first connection to the DNSdist console done over IPv6 was rejected
- A failure of the first lazy health-check was not properly handled
- A crash might have occurred if an incoming DNS over HTTPS connection 
timed out right before the corresponding outgoing query to a backend 
did, and the nghttp2 provider was used
- DNS over HTTPS connections and queries counters were not working 
properly with the nghttp2 provider
- Incoming TCP connections from a client were not always closed right 
away after an error
- Outgoing TCP connections to a backend were not always closed right 
away after a timeout
- The Docker image was printing the DNSdist configuration to the 
terminal by default, including secrets, which might not have been expected
- It was not possible to return a "no server available" result from a 
custom Lua FFI load-balancing policy

- Several compilation warnings have been fixed

Please see the DNSdist website [1] for the more complete changelog [2] 
and the current documentation. The upgrade guide is also available there 
[3].


Please send us all feedback and issues you might have via the mailing 
list, or in case of a bug, via GitHub [4].


The release tarball [5] and its signature [6] are available on the 
downloads website, and packages for several distributions are available 
from our repository [7].


[1]: https://dnsdist.org
[2]: https://dnsdist.org/changelog.html#change-1.9.2
[3]: https://dnsdist.org/upgrade_guide.html
[4]: https://github.com/PowerDNS/pdns/issues/new/choose
[5]:
https://downloads.powerdns.com/releases/dnsdist-1.9.2.tar.bz2
[6]:
https://downloads.powerdns.com/releases/dnsdist-1.9.2.tar.bz2.sig
[7]: https://repo.powerdns.com

Best regards,
--
Remi Gacogne
PowerDNS.COM BV - https://www.powerdns.com/


OpenPGP_signature.asc
Description: OpenPGP digital signature
___
Pdns-users mailing list
Pdns-users@mailman.powerdns.com
https://mailman.powerdns.com/mailman/listinfo/pdns-users

[Pdns-users] PowerDNS DNSdist 1.9.1 released

[Remi Gacogne via Pdns-users]

Hello!

We released PowerDNS DNSdist 1.9.1 today. This version brings no 
functional changes, and only bumps the version of the Quiche library we 
use, to incorporate a recent security update [1], fixing CVE-2024-1410 
[2] and CVE-2024-1765 [3]. This applies only if you configured incoming 
DoQ or DoH3 using the addDOQLocal() or addDOH3Local() functions. If you 
are not using our packages but are building DNSdist from the source code 
with DoQ or DoH3 support enabled, you will have to make sure your 
version of Quiche has been upgraded to 0.20.1.


Please see the DNSdist website [4] for the more complete changelog [5] 
and the current documentation. The upgrade guide is also available there 
[6].


Please send us all feedback and issues you might have via the mailing 
list, or in case of a bug, via GitHub [7].


The release tarball [8] and its signature [9] are available on the 
downloads website, and packages for several distributions are available 
from our repository [10].


[1]: https://github.com/cloudflare/quiche/releases/tag/0.20.1
[2]: https://www.cve.org/CVERecord?id=CVE-2024-1410
[3]: https://www.cve.org/CVERecord?id=CVE-2024-1765
[4]: https://dnsdist.org
[5]: https://dnsdist.org/changelog.html#change-1.9.1
[6]: https://dnsdist.org/upgrade_guide.html
[7]: https://github.com/PowerDNS/pdns/issues/new/choose
[8]:
https://downloads.powerdns.com/releases/dnsdist-1.9.1.tar.bz2
[9]:
https://downloads.powerdns.com/releases/dnsdist-1.9.1.tar.bz2.sig
[10]: https://repo.powerdns.com

Best regards,
--
Remi Gacogne
PowerDNS.COM BV - https://www.powerdns.com/


OpenPGP_signature.asc
Description: OpenPGP digital signature
___
Pdns-users mailing list
Pdns-users@mailman.powerdns.com
https://mailman.powerdns.com/mailman/listinfo/pdns-users

[Pdns-users] PowerDNS DNSdist 1.9.0

[Remi Gacogne via Pdns-users]

Hello!

We are very happy to release PowerDNS DNSdist 1.9.0 today! This new 
version brings a fair number of new features since 1.8.3:


- DNS over QUIC [1]
- DNS over HTTP3
- AF_XDP [2] support
- the ability to set Extended DNS Error [3] statuses
- a cache-miss ratio dynamic block rule
- getAddressInfo for asynchronous DNS resolution
- Proxy Protocol support for TeeAction
- Proxy Protocol support can now be enabled on a per-bind basis
- many new selectors and actions

We would like to express our gratitude to Y7n05h [4] who contributed 
AF_XDP support during Google Summef Code! It took us far too long to 
integrate their contribution into a release, but it's finally there with 
impressive results.


We also replaced the default library handling DNS over HTTPS, switching 
from h2o to nghttp2 [5]. This change should be transparent for most 
users, since we made sure to preserve the existing features and 
configuration directives. Switching to nghttp2 allows us to support 
hardware acceleration for TLS exchanges, using for example Linux's kTLS 
[6] or Intel Quick-Assist Technology [7]. It also reduces our footprint 
on low-end devices by not requiring an additional library, since nghttp2 
was already used for outgoing DNS over HTTPS requests. Finally, while it 
was a long time coming, h2o is officially [8] no longer maintained in a 
way that makes it possible to use it as a stable library. Technically it 
will still be possible to revert to the use of h2o for incoming DNS over 
HTTPS in DNSdist 1.9.x, but we will remove that support after that.


Packagers need to be aware that SNMP support is no longer enabled by 
default, as it had been causing integration issues in some environments 
for a while, but it's still enabled in our packages. Two new features, 
DNS over QUIC and DNS over HTTP3, require the Cloudflare's Quiche [9] 
library, which is written in Rust [10] and might not be already present 
in some distributions.


We also made changes to our Open Source End of Life policy. Older 
release trains are now supported for one year after the following major 
release. Consult the EOL policy [11] for more details.


Please see the DNSdist website [12] for the more complete changelog [13] 
and the current documentation. The upgrade guide is also available there 
[14].


Please send us all feedback and issues you might have via the mailing 
list, or in case of a bug, via GitHub [15].


We are grateful to the PowerDNS community for the reporting of bugs, 
issues, feature requests, and especially to the submitters of fixes and 
implementations of features. We are particularly thankful to Denis 
Machard for testing and reporting issues with dnstap and protobuf 
exports, Håkan Lindqvist for tirelessly tracking issues in our DNS over 
HTTP3 feature, Oto Šťáva from the Knot Resolver team for testing DNSdist 
against his DNS over QUIC implementation in DNS Shotgun and reporting 
several discrepancies!


The release tarball [16] and its signature [17] are available on the 
downloads website, and packages for several distributions are available 
from our repository [18].


[1]: https://www.rfc-editor.org/rfc/rfc9250.html
[2]: https://www.kernel.org/doc/html/next/networking/af_xdp.html
[3]: https://www.rfc-editor.org/rfc/rfc8914.html
[4]: https://github.com/Y7n05h
[5]: https://nghttp2.org/
[6]: https://docs.kernel.org/networking/tls-offload.html
[7]: 
https://www.intel.com/content/www/us/en/architecture-and-technology/intel-quick-assist-technology-overview.html

[8]: https://github.com/h2o/h2o/issues/3230
[9]: https://github.com/cloudflare/quiche
[10]: https://www.rust-lang.org/
[11]: https://dnsdist.org/eol.html
[12]: https://dnsdist.org
[13]: https://dnsdist.org/changelog.html#change-1.9.0
[14]: https://dnsdist.org/upgrade_guide.html
[15]: https://github.com/PowerDNS/pdns/issues/new/choose
[16]:
https://downloads.powerdns.com/releases/dnsdist-1.9.0.tar.bz2
[17]:
https://downloads.powerdns.com/releases/dnsdist-1.9.0.tar.bz2.sig
[18]: https://repo.powerdns.com

Best regards,
--
Remi Gacogne
PowerDNS.COM BV - https://www.powerdns.com/


OpenPGP_signature.asc
Description: OpenPGP digital signature
___
Pdns-users mailing list
Pdns-users@mailman.powerdns.com
https://mailman.powerdns.com/mailman/listinfo/pdns-users

[Pdns-users] PowerDNS DNSdist 1.9.0-rc1 released

[Remi Gacogne via Pdns-users]

Hello!

We are excited to release the first release candidate of what will 
become PowerDNS DNSdist 1.9.0!


The latest addition to DNSdist is AF_XDP[1] support. AF_XDP is a Linux 
feature optimized for high performance packet processing, allowing 
DNSdist to process UDP datagrams even faster than it already was. To 
give you a concrete example, on an Intel E3-1270 with 4 cores (8 
threads) running at 3.8 Ghz, with a 10 Gbps Intel 82599 network card, 
DNSdist can reply with a static answer at 1 million UDP queries per 
second without AF_XDP, and around 2.5 millions with AF_XDP. Of course 
this comes with some limitations, requires a recent Linux kernel and 
support in the network device driver. Please refer to our documentation 
[2] to know more.


In addition to this new feature, our DNS over QUIC and DNS over HTTP3 
implementations have been significantly improved and several bugs fixed. 
We are particularly thankful to Denis Machard for testing and reporting 
issues with dnstap and protobuf exports, Håkan Lindqvist for tirelessly 
tracking issues in our DNS over HTTP3 feature, Oto Šťáva from the Knot 
Resolver team for testing DNSdist against his DNS over QUIC 
implementation in DNS Shotgun and reporting several discrepancies!


Please see the DNSdist website [3] for the more complete changelog [4] 
and the current documentation. The upgrade guide is also available there 
[5].


Please send us all feedback and issues you might have via the mailing 
list, or in case of a bug, via GitHub [6].


We are immensely grateful to the PowerDNS community for the reporting of 
bugs, issues, feature requests, and especially to the submitters of 
fixes and implementations of features.


The release tarball [7] and its signature [8] are available on the 
downloads website, and packages for several distributions are available 
from our repository [9].


[1]: https://www.kernel.org/doc/html/next/networking/af_xdp.html
[2]: https://dnsdist.org/advanced/xsk.html
[3]: https://dnsdist.org
[4]: https://dnsdist.org/changelog.html#change-1.9.0-rc1
[5]: https://dnsdist.org/upgrade_guide.html#x-to-1-9-0-rc1
[6]: https://github.com/PowerDNS/pdns/issues/new/choose
[7]:
https://downloads.powerdns.com/releases/dnsdist-1.9.0-rc1.tar.bz2
[8]:
https://downloads.powerdns.com/releases/dnsdist-1.9.0-rc1.tar.bz2.sig
[9]: https://repo.powerdns.com

Best regards,
--
Remi Gacogne
PowerDNS.COM BV - https://www.powerdns.com/


OpenPGP_signature.asc
Description: OpenPGP digital signature
___
Pdns-users mailing list
Pdns-users@mailman.powerdns.com
https://mailman.powerdns.com/mailman/listinfo/pdns-users

[Pdns-users] PowerDNS DNSdist 1.8.3 released

[Remi Gacogne via Pdns-users]

Hello!

We are very happy to release PowerDNS DNSdist 1.8.3 today, a maintenance 
release fixing a few bugs reported since 1.8.2:


- The exponential back-off timer used when a carbon server is 
unreachable had a bug that could lead to a busy-loop, consuming CPU time 
until the carbon server became reachable again
- In some cases, truncated UDP responses from a backend were not 
properly discarded

- Removing the last rule of a rules chain by its name or UUID was broken
- Several cosmetic issues related to eBPF dynamic blocks were fixed
- The JSON produced by the REST API might have been invalid when some 
special characters were present


In addition to these fixes, two new Lua bindings were added: 
DynBlockRulesGroup:removeRange and DNSHeader:getTC.


Please see the DNSdist website [1] for the more complete changelog [2] 
and the current documentation. The upgrade guide is also available there 
[3].


Please send us all feedback and issues you might have via the mailing 
list, or in case of a bug, via GitHub [4].


We are immensely grateful to the PowerDNS community for the reporting of 
bugs, issues, feature requests, and especially to the submitters of 
fixes and implementations of features.


The release tarball [5] and its signature [6] are available on the 
downloads website, and packages for several distributions are available 
from our repository [7].


[1]: https://dnsdist.org
[2]: https://dnsdist.org/changelog.html#change-1.8.3
[3]: https://dnsdist.org/upgrade_guide.html#x-to-1-8-3
[4]: https://github.com/PowerDNS/pdns/issues/new/choose
[5]:
https://downloads.powerdns.com/releases/dnsdist-1.8.3.tar.bz2
[6]:
https://downloads.powerdns.com/releases/dnsdist-1.8.3.tar.bz2.sig
[7]: https://repo.powerdns.com

Best regards,
--
Remi Gacogne
PowerDNS.COM BV - https://www.powerdns.com/


OpenPGP_signature.asc
Description: OpenPGP digital signature
___
Pdns-users mailing list
Pdns-users@mailman.powerdns.com
https://mailman.powerdns.com/mailman/listinfo/pdns-users

[Pdns-users] PowerDNS DNSdist 1.9.0-alpha4 released

[Remi Gacogne via Pdns-users]

Hello!

We are thrilled to release the fourth alpha release of what will become 
PowerDNS DNSdist 1.9.0!


The most exciting new feature in this latest alpha is support for DNS 
over HTTP/3! Like DNS over QUIC for which we announced support in the 
previous alpha, DNS over HTTP/3 uses QUIC to provide excellent 
performance in challenging environments. We are again leveraging 
Cloudflare's Quiche [1] for this new feature, keeping the number of 
DNSdist dependencies small.


We also added a few smaller features since alpha 3:

- support for setting Extended DNS Error statuses
- a cache-miss ratio dynamic block rule
- getAddressInfo for asynchronous DNS resolution
- a rings endpoint to the REST API
- NetmaskGroup:addNMG to merge Netmask groups
- an option to set the SSL proxy protocol TLV
- Proxy Protocol v2 support to TeeAction
- enabling incoming PROXY protocol on a per-bind basis
- the maximum size of entries in the packet cache is now configurable
- raw response spoofing for ANY queries
- QNameSuffixRule, PayloadSizeRule and TCResponseAction
- DynBlockRulesGroup:removeRange
- setting the action from setSuffixMatchRule's visitor is now supported
- we now send a HTTP 400 response to legacy HTTP/1.1 clients with nghttp2

And fixed a few issues:

- Kees Monshouwer removed legacy terms from the codebase
- building without DoH but with nghttp2 was broken
- Quiche detection did not properly check the version
- DNS over QUIC latency metrics were missing
- removing the last rule by its name or UUID was broken
- building with DNS over QUIC but without DNS over HTTPS or DNS over TLS 
was broken


Please see the DNSdist website [2] for the more complete changelog [3] 
and the current documentation. The upgrade guide is also available there 
[4].


Please send us all feedback and issues you might have via the mailing 
list, or in case of a bug, via GitHub [5].


We are immensely grateful to the PowerDNS community for the reporting of 
bugs, issues, feature requests, and especially to the submitters of 
fixes and implementations of features.


The release tarball [6] and its signature [7] are available on the 
downloads website, and packages for several distributions are available 
from our repository [8].


[1]: https://github.com/cloudflare/quiche
[2]: https://dnsdist.org
[3]: https://dnsdist.org/changelog.html#change-1.9.0-alpha4
[4]: https://dnsdist.org/upgrade_guide.html#x-to-1-9-0-alpha4
[5]: https://github.com/PowerDNS/pdns/issues/new/choose
[6]:
https://downloads.powerdns.com/releases/dnsdist-1.9.0-alpha4.tar.bz2
[7]:
https://downloads.powerdns.com/releases/dnsdist-1.9.0-alpha4.tar.bz2.sig
[8]: https://repo.powerdns.com

Best regards,
--
Remi Gacogne
PowerDNS.COM BV - https://www.powerdns.com/


OpenPGP_signature.asc
Description: OpenPGP digital signature
___
Pdns-users mailing list
Pdns-users@mailman.powerdns.com
https://mailman.powerdns.com/mailman/listinfo/pdns-users

Re: [Pdns-users] [EXT] Re: remote backend

[Remi Gacogne via Pdns-users]

On 29/11/2023 01:07, Alexis Fidalgo wrote:
Problem is (and i’ve testing with golang and python) after the answer 
the “initialize” message, the socket is closed, so, getAllDomains 
message is being sent using a closed socket and that’s why i don’t see 
it on the responder side and pdns does not receive and answer, polls 2 
times and reaches timeout.


Why do you think the socket is closed? It doesn't show up in your 
previous strace log, and poll() wouldn't not time out but immediately 
return an error if the socket had been closed.



i can see there’s no test for unixsocket in the source tree.


There is such a test in test-remotebackend-unix.cc

--
Remi Gacogne
PowerDNS.COM BV - https://www.powerdns.com/



OpenPGP_signature.asc
Description: OpenPGP digital signature
___
Pdns-users mailing list
Pdns-users@mailman.powerdns.com
https://mailman.powerdns.com/mailman/listinfo/pdns-users

Re: [Pdns-users] correct answer for lookup in backend

[Remi Gacogne via Pdns-users]

Hi,

On 29/11/2023 21:23, Alexis Fidalgo via Pdns-users wrote:

Quick question, when using JSON/RPC in remote backend with http connector.

{"method":"lookup", "parameters":{"qtype":"ANY", "qname":"www.example.com.", "remote":"192.0.2.24", 
"local":"192.0.2.1", "real-remote":"192.0.2.24", "zone-id":-1}}

must be answered with

{"result":[{"qtype":"A", "qname":"www.example.com", "content":"203.0.113.2", 
"ttl": 60}]}

If theres no records to answer, which is the correct answer?

1. {“result”:[]}
2. {“result”:false}


The expected answer is an empty array. The current code treats a 
non-array value as an empty array but I wouldn't rely on this behaviour.


Best regards,
--
Remi Gacogne
PowerDNS.COM BV - https://www.powerdns.com/



OpenPGP_signature.asc
Description: OpenPGP digital signature
___
Pdns-users mailing list
Pdns-users@mailman.powerdns.com
https://mailman.powerdns.com/mailman/listinfo/pdns-users

Re: [Pdns-users] remote backend

[Remi Gacogne via Pdns-users]

Hi!

On 28/11/2023 19:59, Alexis Fidalgo via Pdns-users wrote:
Sorry about that, yes, this will work locally, meaning the remote 
responder (my script) will run on the same VM than pdns-auth, so 
pdns-auth will connect using a unix socket with the responder using 
remote backend.


That actually occurs, this is what is shown from the pdns

---
alz@nuc  /opt/pdns-auth-4.8.3/sbin  ./pdns_server
Nov 28 14:52:54 This is a standalone pdns
Nov 28 14:52:54 Listening on controlsocket in 
'/var/run/pdns/pdns.controlsocket'

Nov 28 14:52:54 UDP server bound to 0.0.0.0:5300
Nov 28 14:52:54 UDP server bound to 0.0.0.0:5300
Nov 28 14:52:54 UDP server bound to 0.0.0.0:5300
Nov 28 14:52:54 UDP server bound to 0.0.0.0:5300
Nov 28 14:52:54 UDP server bound to 0.0.0.0:5300
Nov 28 14:52:54 UDP server bound to 0.0.0.0:5300
Nov 28 14:52:54 TCP server bound to 0.0.0.0:5300
Nov 28 14:52:54 PowerDNS Authoritative Server 4.8.3 (C) 2001-2022 
PowerDNS.COM BV
Nov 28 14:52:54 Using 64-bits mode. Built using gcc 10.2.1 20210110 on 
Nov 28 2023 11:42:16 by a...@nuc.lesi.com.
Nov 28 14:52:54 PowerDNS comes with ABSOLUTELY NO WARRANTY. This is free 
software, and you are welcome to redistribute it according to the terms 
of the GPL version 2.
Nov 28 14:52:54 [stub-resolver] Doing stub resolving for 
'auth-4.8.3.security-status.secpoll.powerdns.com.|TXT', using resolvers: 
192.168.86.1
Nov 28 14:52:54 [stub-resolver] Question for 
'auth-4.8.3.security-status.secpoll.powerdns.com.|TXT' got answered by 
192.168.86.1
Nov 28 14:52:54 Polled security status of version 4.8.3 at startup, no 
known issues reported: OK

Nov 28 14:52:54 Reconnecting to backend
Nov 28 14:52:54 PDNSException while filling the zone cache: Exception 
caught when sending: Could not send a message to remote process

—

this is what is showed on the responder when the

---
2023-11-28T14:52:54.907-0300 DEBUG handlers/handlers.go:65 pdns request 
received: {"method": "initialize", "parameters": {"path": "/tmp/pra.sock"}}
2023-11-28T14:52:54.907-0300 DEBUG handlers/handlers.go:50 Response 
{"result":true}

—


This same responder script, if using http returns exactly the same json, 
getAllDomains comes after the initialize, then the lookups, so the 
responder works ok.



Problem is, when i switch to unix socket, throws the error on the red 
line after the initialize and dies


That's very weird indeed, and unfortunately the unix connector is 
lacking a bit of logging in this area. Any chance you would be able to 
strace the authoritative server process?


Cheers,f
--
Remi Gacogne
PowerDNS.COM BV - https://www.powerdns.com/
___
Pdns-users mailing list
Pdns-users@mailman.powerdns.com
https://mailman.powerdns.com/mailman/listinfo/pdns-users

Re: [Pdns-users] Blacklist domains

[Remi Gacogne via Pdns-users]

Hi Andrea,

On 24/10/2023 15:39, Andrea Biancalani via Pdns-users wrote:
yes, it is. Postal Police (or Post Police, don't know how that could be 
translated in english) it's a branch of the Italian state police which 
has the task of monitoring crimes on the internet, stemming scams, 
mitigating risky behavior linked to the improper use of communication 
methods, combating pedophilia and exploitation, etc...


We're a local ISP and sometimes we receive direct communications about 
blocking specific DNS traffic to avoid helping scams and frauds. I 
suppose any country has its IT crime police, or at least they should be.


I would suggest looking into Response Policy Zones (RPZ) which was 
pretty much designed for this use-case: 
https://docs.powerdns.com/recursor/lua-config/rpz.html


Best regards,
--
Remi Gacogne
PowerDNS.COM BV - https://www.powerdns.com/



OpenPGP_signature.asc
Description: OpenPGP digital signature
___
Pdns-users mailing list
Pdns-users@mailman.powerdns.com
https://mailman.powerdns.com/mailman/listinfo/pdns-users

[Pdns-users] PowerDNS DNSdist 1.9.0-alpha3 released

[Remi Gacogne via Pdns-users]

Hello!

We are thrilled to release the third alpha release of what will become 
PowerDNS DNSdist 1.9.0!


Let's first address the elephant in the room: the second alpha was never 
released due to a last-minute issue discovered in RPM packaging after 
the tag was pushed, so we went to alpha3 right away.


The most exciting new feature in this third alpha is support for DNS 
over QUIC [1], which combines the confidentiality and integrity 
capabilities of DNS over TLS and DNS over HTTPS without the overhead of 
TCP connections.
Our implementation is based on Cloudflare's Quiche [2], which has 
already been battle-tested by being used on their edge network and in 
Android's DNS resolver. We first selected Quiche as the building block 
for QUIC because the API is both simple and powerful, but also because 
it is written in Rust. Rust is a memory-safe language and significantly 
reduces the risk of security issues.
One annoying drawback is that Quiche has not yet been packaged in most 
Linux distributions. This is not an issue if you are using our packages, 
because we ship the latest release of Quiche along DNSdist, but it might 
make building DNSdist with DNS over QUIC support a bit harder if you are 
doing it on your own, as you will need to first compile Quiche. We hope 
that distributions will adopt Quiche in the near future.


In addition to DNS over QUIC, we also added a few new features:
- the ability to parse Extended DNS Errors present in responses and 
export them via protobuf
- Denis Machard added Lua bindings to look at the selected backend from 
Lua rules and actions


We also fixed a few issues:
- phonedph1 fixed a typo on the metric name for TCP client timeouts
- contrary to what we announced, h2o support was not available anymore 
in our packages in the first alpha
- incoming DoH connections were not using the proper timeout value when 
handled by nghttp2

- cosmetic issues in eBPF dynamic block reporting
- invalid subnet masks coming from a string were not properly normalized
- DNS header might have been misaligned in some cases, causing issues on 
some architectures

- some log messages were not recorded at the proper level

Please also note that, as we did for stable releases, we switched to our 
own fork of libh2o [3] in order to mitigate CVE-2023-44487 [4], also 
known as HTTP/2 rapid reset [5].


We still have a few surprises left for 1.9.0 final, but more on that later!

Please see the DNSdist website [6] for the more complete changelog [7] 
and the current documentation. The upgrade guide is also available there 
[8].


Please send us all feedback and issues you might have via the mailing 
list, or in case of a bug, via GitHub [9].


We are immensely grateful to the PowerDNS community for the reporting of 
bugs, issues, feature requests, and especially to the submitters of 
fixes and implementations of features.


The release tarball [10] and its signature [11] are available on the 
downloads website, and packages for several distributions are available 
from our repository [12].


[1]: https://www.rfc-editor.org/rfc/rfc9250.html
[2]: https://github.com/cloudflare/quiche
[3]: https://github.com/PowerDNS/h2o/tree/v2.2.6%2Bpdns
[4]: https://www.cve.org/CVERecord?id=CVE-2023-44487
[5]: 
https://blog.cloudflare.com/technical-breakdown-http2-rapid-reset-ddos-attack/

[6]: https://dnsdist.org
[7]: https://dnsdist.org/changelog.html#change-1.9.0-alpha3
[8]: https://dnsdist.org/upgrade_guide.html#x-to-1-9-0-alpha3
[9]: https://github.com/PowerDNS/pdns/issues/new/choose
[10]:
https://downloads.powerdns.com/releases/dnsdist-1.9.0-alpha3.tar.bz2
[11]:
https://downloads.powerdns.com/releases/dnsdist-1.9.0-alpha3.tar.bz2.sig
[12]: https://repo.powerdns.com

Best regards,
--
Remi Gacogne
PowerDNS.COM BV - https://www.powerdns.com/


OpenPGP_signature.asc
Description: OpenPGP digital signature
___
Pdns-users mailing list
Pdns-users@mailman.powerdns.com
https://mailman.powerdns.com/mailman/listinfo/pdns-users

[Pdns-users] PowerDNS DNSdist 1.7.5 and 1.8.2 released

[Remi Gacogne via Pdns-users]

Hi,

Today we have released DNSdist 1.7.5 and 1.8.2, with absolutely no 
changes with, respectively, 1.7.4 and 1.8.1, apart from the fact that 
our DNSdist packages have been rebuilt against our own fork [1] of 
libh2o in order to mitigate CVE-2023-44487 [2], also known as HTTP/2 
rapid reset [3].


This attack exploits a vulnerability in most implementations of the 
HTTP/2 protocol, making it easier to cause a denial of service of HTTP/2 
servers by sending them crafted queries. While the vulnerability does 
not come from DNSdist's code, all versions of DNSdist supporting DNS 
over HTTPS are impacted by this issue if incoming DNS over HTTPS is 
enabled, which is not the case by default.


As we warned earlier, libh2o is no longer supported as a stable library, 
and there will be no official release fixing this issue. For this reason 
we have forked the official h2o repository and backported the fix to the 
2.2.x branch, making it available to the public. If you are not using 
our packages but are compiling DNSdist yourself, or relying on your 
distribution's packages, please ensure that you are using a patched 
version of libh2o in order to be protected.


In the very near future we will be releasing DNSdist 1.9.0 where DNS 
over HTTPS is provided by the nghttp2 library, so we do not have to rely 
on h2o any longer.


Please see the DNSdist website [4] for the current documentation.

Please send us all feedback and issues you might have via the mailing 
list, or in case of a bug, via GitHub [5].


The tarballs (1.7.5 [6], 1.8.2 [7]) and theirs signatures (1.7.5 [8], 
1.8.2 [9]) are available on the downloads website, and packages for 
several distributions are available from our repository [10].


Docker images have not been updated yet but will be soon.

[1]: https://github.com/PowerDNS/h2o/tree/v2.2.6%2Bpdns
[2]: https://www.cve.org/CVERecord?id=CVE-2023-44487
[3]: 
https://blog.cloudflare.com/technical-breakdown-http2-rapid-reset-ddos-attack/

[4]: https://dnsdist.org
[5]: https://github.com/PowerDNS/pdns/issues/new/choose
[6]:
https://downloads.powerdns.com/releases/dnsdist-1.7.5.tar.bz2
[7]:
https://downloads.powerdns.com/releases/dnsdist-1.8.2.tar.bz2
[8]:
https://downloads.powerdns.com/releases/dnsdist-1.7.5.tar.bz2.sig
[9]:
https://downloads.powerdns.com/releases/dnsdist-1.8.2.tar.bz2.sig
[10]: https://repo.powerdns.com

Best regards,
--
Remi Gacogne
PowerDNS.COM BV - https://www.powerdns.com/


OpenPGP_signature.asc
Description: OpenPGP digital signature
___
Pdns-users mailing list
Pdns-users@mailman.powerdns.com
https://mailman.powerdns.com/mailman/listinfo/pdns-users

Re: [Pdns-users] package build instructions

[Remi Gacogne via Pdns-users]

Hi Alex,

On 09/10/2023 16:21, Alex Pavlov via Pdns-users wrote:

Meanwhile have one question about DoH & DoT implementation in DNSDIST 1.5 and 
higher.
Is written in documentation "...like CertBot, set permissions assuming that services 
are started as root, which is no longer true for dnsdist as of 1.5.0. For that particular 
case, making a copy of the necessary files in the /etc/dnsdist directory is advised, 
using for example CertBot’s --deploy-hook feature to copy the files with the right 
permissions after a renewal."

So I set my CertBot with --deploy-hook which copy certs in to /etc/dnsdist and than do 
proper chmod and chown for files so dnsdist be able to read it. That is done and works 
fine... however rising one more question: When certs expired (after each 90 days period) 
and my CertBot do "certbot renew" it replaces the certs files in /etc/dnsdist 
and changes permissions.
Does DNSDIST process detects that files changed and serves DoH|DoT from new 
cert files ?
Or need to add one more command in  --deploy-hook  to restart DNSDIST if certs changed 
(like: "systemctl restart dnsdist") ?


No, dnsdist doesn't monitor whether the certificate file changes on 
disk. You can either use the console to issue a 
'reloadAllCertificates()' command which will reload all certificates and 
keys without interruption, or restart dnsdist.


Best regards,
--
Remi Gacogne
PowerDNS.COM BV - https://www.powerdns.com/



OpenPGP_signature.asc
Description: OpenPGP digital signature
___
Pdns-users mailing list
Pdns-users@mailman.powerdns.com
https://mailman.powerdns.com/mailman/listinfo/pdns-users

Re: [Pdns-users] DNSdist 1.9.0-alpha1 released dnsdist_server_healthcheckfailurestimeout

[Remi Gacogne via Pdns-users]

Hi Christoph,


On 19/09/2023 01:04, Christoph via Pdns-users wrote:
We have made a lot of small improvements since 1.8.x as well, like 
adding Lua bindings to access selectors and actions, more fields of a 
DNS header in Lua actions, and adding metrics for health-check events.


thanks a lot! We are already running it on one server to get the new
healthcheck metrics!


Great, thanks!

# HELP dnsdist_server_healthcheckfailurestimeout Number of health 
check attempts where the response did not arrive in time

# TYPE dnsdist_server_healthcheckfailurestimeout counter
Does this mean, that if the checkInterval is at 1sec and the server is 
down for 7seconds this counter will be at 7 or just at 1 if the downtime 
had no interruption?


It should be at 7, since a health-check attempt will be done every 
second and the counter will be incremented for every failure.


Best regards,
--
Remi Gacogne
PowerDNS.COM BV - https://www.powerdns.com/



OpenPGP_signature.asc
Description: OpenPGP digital signature
___
Pdns-users mailing list
Pdns-users@mailman.powerdns.com
https://mailman.powerdns.com/mailman/listinfo/pdns-users

[Pdns-users] PowerDNS DNSdist 1.9.0-alpha1 released

[Remi Gacogne via Pdns-users]

Hello!

We are very happy to be releasing the first alpha release of what will 
become DNSdist 1.9.0!


The most important change since 1.8.1 is that incoming DNS over HTTPS 
requests are now handled by the nghttp2 library, instead of the h2o one. 
This change should be transparent for most users, since we made sure to 
preserve the existing features and configuration directives. Switching 
to nghttp2 allows us to support hardware acceleration for TLS exchanges, 
using for example Linux's kTLS or Intel Quick-Assist Technology. It also 
reduces our footprint on low-end devices by not requiring an additional 
library, since nghttp2 was already used for outgoing DNS over HTTPS 
requests. Finally, while it was a long time coming, h2o is officially 
[1] no longer maintained in a way that makes it possible to use it as a 
stable library. Technically it will still be possible to revert to the 
use of h2o for incoming DNS over HTTPS in DNSdist 1.9.x, but we will 
remove that support after that.


We have made a lot of small improvements since 1.8.x as well, like 
adding Lua bindings to access selectors and actions, more fields of a 
DNS header in Lua actions, and adding metrics for health-check events.


We still have several wonderful features planned for 1.9.0 that have not 
been merged yet, but rest assured that the final release will not be boring!


Packagers need to be aware that SNMP support is no longer enabled by 
default, as it had been causing integration issues in some environments 
for a while, but it's still enabled in our packages.


Speaking of packages, we are now publishing SLSA attestations along with 
our packages, making it possible to verify how exactly they were built 
and reproduce our workflow, providing strong guarantees against 
supply-chain attacks. Please get in touch if you want to know more!


Please see the DNSdist website [2] for the more complete changelog [3] 
and the current documentation. The upgrade guide is also available there 
[4].


Please send us all feedback and issues you might have via the mailing 
list, or in case of a bug, via GitHub [5].


We are immensely grateful to the PowerDNS community for the reporting of 
bugs, issues, feature requests, and especially to the submitters of 
fixes and implementations of features.


The release tarball [6] and its signature [7] are available on the 
downloads website, and packages for several distributions are available 
from our repository [8].


[1]: https://github.com/h2o/h2o/issues/3230
[2]: https://dnsdist.org
[3]: https://dnsdist.org/changelog.html#change-1.9.0-alpha1
[4]: https://dnsdist.org/upgrade_guide.html#x-to-1-9-0-alpha1
[5]: https://github.com/PowerDNS/pdns/issues/new/choose
[6]:
https://downloads.powerdns.com/releases/dnsdist-1.9.0-alpha1.tar.bz2
[7]:
https://downloads.powerdns.com/releases/dnsdist-1.9.0-alpha1.tar.bz2.sig
[8]: https://repo.powerdns.com

Best regards,
--
Remi Gacogne
PowerDNS.COM BV - https://www.powerdns.com/



OpenPGP_signature.asc
Description: OpenPGP digital signature
___
Pdns-users mailing list
Pdns-users@mailman.powerdns.com
https://mailman.powerdns.com/mailman/listinfo/pdns-users

[Pdns-users] PowerDNS DNSdist 1.8.1 released

[Remi Gacogne via Pdns-users]

Hello!

We are very happy to release DNSdist 1.8.1 today, a maintenance release 
fixing a few bugs reported since 1.8.0:


- Several bugs have been fixed in the health-check code, including one 
issue that could have resulted in some health-check responses to be lost
- A crash has been fixed when dealing with DNS over HTTPS queries for 
which a X-Forwarded-For header overrides the initial source IP, which is 
not enabled by default
- Re-connection failures are now more carefully handled for backend UDP 
sockets, avoiding high CPU usage in some network topology changes

- Self-answered UDP responses with recvmmsg are not properly accounted for
- A memory leak when processing TLS tickets with OpenSSL 3.x has been fixed
- Cache hit and miss metrics with DoH queries are now properly accounted for
- Christof Chen fixed an issue with SpoofAction, by copying the QClass 
from the request
- A race has been fixed when creating the first TLS connections to a 
backend, which could have led to sub-optimal TLS session reuse

- Short reads are now properly handled when doing backend upgrade discovery
- Winfried Angele fixed an accidental change of disableZeroScope to 
disableZeroScoping
- The group ownership of the dnsdist.conf file is now properly set when 
installed via RPM
- Houtworm fixed the webserver configuration template for our docker 
container

- phonedph1 fixed the console description of PoolAction and QPSPoolAction

In addition to these fixes, Jacob Bunk made the TSIG query type 
available from Lua, and we improved the accounting of eBPF dynamic blocks.


Finally it is now possible to declare custom metrics at runtime for use 
from Lua, and Lua FFI inspection functions are automatically loaded at 
runtime.


Please see the DNSdist website [1] for the more complete changelog [2] 
and the current documentation. The upgrade guide is also available there 
[3].


Please send us all feedback and issues you might have via the mailing 
list, or in case of a bug, via GitHub [4].


We are immensely grateful to the PowerDNS community for the reporting of 
bugs, issues, feature requests, and especially to the submitters of 
fixes and implementations of features.


The release tarball [5] and its signature [6] are available on the 
downloads website, and packages for several distributions are available 
from our repository [7].


[1]: https://dnsdist.org
[2]: https://dnsdist.org/changelog.html#change-1.8.1
|3]: https://dnsdist.org/upgrade_guide.html#x-to-1-8-0
[4]: https://github.com/PowerDNS/pdns/issues/new/choose
[5]:
https://downloads.powerdns.com/releases/dnsdist-1.8.1.tar.bz2
[6]:
https://downloads.powerdns.com/releases/dnsdist-1.8.1.tar.bz2.sig
[7]: https://repo.powerdns.com

--
Remi Gacogne
PowerDNS.COM BV - https://www.powerdns.com/


OpenPGP_signature.asc
Description: OpenPGP digital signature
___
Pdns-users mailing list
Pdns-users@mailman.powerdns.com
https://mailman.powerdns.com/mailman/listinfo/pdns-users

[Pdns-users] Third Release Candidate of PowerDNS DNSdist 1.8.0

[Remi Gacogne via Pdns-users]

Hello!

We are very happy to release the third candidate of what will become 
dnsdist 1.8.0!


This release contains fixes for several issues that were found in the 
second release candidate.


- #12641: Use the correct source address when harvesting failed
- #12639: Fix a race when a cross-protocol query triggers an IO error
- #12638: Report the TCP latency for TCP-only Do53, DoT and DoH backends
- #12648: Report per-incoming transport latencies in the web interface

The first one is actually a follow-up to the "dnsdist is responding from 
the wrong source IP address in some setups" which was incompletely 
corrected in rc2. The second one is a race condition that might have 
been occurring in very specific cases of network errors during 
asynchronous processing of cross-protocol queries. The last issue is a 
bit more complicated: in 1.8.0 we decided to break down the latency 
metrics to provide a more accurate view of what was actually going on:


- global latency metrics are now per incoming protocol (Do53 UDP, Do53 
TCP, DoT, DoH)
- backend latency metrics are split between UDP (Do53) and TCP (Do53 
TCP, DoT, DoH)


This change brought some adjustment in the interfaces consuming these 
metrics, and it was reported that this was not quite right. The web 
interface, for example, was only reporting the UDP-based metrics and not 
the other ones.


Please see the dnsdist website [1] for the more complete changelog [2] 
and the current documentation. The upgrade guide is also available there 
[3].


Please send us all feedback and issues you might have via the mailing 
list, or in case of a bug, via GitHub [4].


We are immensely grateful to the PowerDNS community for the reporting of 
bugs, issues, feature requests, and especially to the submitters of 
fixes and implementations of features.


The release tarball [5] and its signature [6] are available on the 
downloads website, and packages for several distributions are available 
from our repository [7].


[1]: https://dnsdist.org
[2]: https://dnsdist.org/changelog.html#change-1.8.0-rc3
|3]: https://dnsdist.org/upgrade_guide.html#x-to-1-8-0
[4]: https://github.com/PowerDNS/pdns/issues/new/choose
[5]:
https://downloads.powerdns.com/releases/dnsdist-1.8.0-rc3.tar.bz2
[6]:
https://downloads.powerdns.com/releases/dnsdist-1.8.0-rc3.tar.bz2.sig
[7]: https://repo.powerdns.com


OpenPGP_signature
Description: OpenPGP digital signature
___
Pdns-users mailing list
Pdns-users@mailman.powerdns.com
https://mailman.powerdns.com/mailman/listinfo/pdns-users

[Pdns-users] Second Release Candidate of PowerDNS DNSdist 1.8.0

[Remi Gacogne via Pdns-users]

Hi!

We are very happy to release the second candidate of what will become 
dnsdist 1.8.0!


This release contains fixes for a few issues that were found in the 
first release candidate, the most important one being that dnsdist was 
responding from the wrong source IP address in some setups, which was 
reported by multiple users. Many thanks to them!


- #12586: Fix the harvesting of destination addresses, so we reply from 
the correct source IP in all cases

- #12587: Skip signal-unsafe logging when we are about to exit, with TSAN
- #12588: Fix compilation with DoH disabled (Adam Majer)
- #12589: YaHTTP: Better detection of whether C++11 features are available
- #12592: Only increment the ‘servfail-responses’ metric on backend 
responses (phonedph1)

- #12593: Clean up the fortify and LTO m4 by not directly editing flags
- #12615: Add Lua bindings for PB requestorID, deviceName and deviceID

Please see the dnsdist website [1] for the more complete changelog [2] 
and the current documentation. The upgrade guide is also available there 
[3].


Please send us all feedback and issues you might have via the mailing 
list, or in case of a bug, via GitHub [4].


We are immensely grateful to the PowerDNS community for the reporting of 
bugs, issues, feature requests, and especially to the submitters of 
fixes and implementations of features.


The release tarball [5] and its signature [6] are available on the 
downloads website, and packages for several distributions are available 
from our repository [7].


[1]: https://dnsdist.org
[2]: https://dnsdist.org/changelog.html#change-1.8.0-rc2
|3]: https://dnsdist.org/upgrade_guide.html#x-to-1-8-0
[4]: https://github.com/PowerDNS/pdns/issues/new/choose
[5]:
https://downloads.powerdns.com/releases/dnsdist-8.0-rc2.tar.bz2
[6]:
https://downloads.powerdns.com/releases/dnsdist-1.8.0-rc2.tar.bz2.sig
[7]: https://repo.powerdns.com

Best regards,
--
Remi Gacogne
PowerDNS.COM BV - https://www.powerdns.com/


OpenPGP_signature
Description: OpenPGP digital signature
___
Pdns-users mailing list
Pdns-users@mailman.powerdns.com
https://mailman.powerdns.com/mailman/listinfo/pdns-users

[Pdns-users] First release candidate of dnsdist 1.8.0

[Remi Gacogne via Pdns-users]

 of a bug, via GitHub [8].


We are immensely grateful to the PowerDNS community for the reporting of 
bugs, issues, feature requests, and especially to the submitters of 
fixes and implementations of features.


The release tarball [9] and its signature [10] are available on the 
downloads website, and packages for several distributions are available 
from our repository [11].



Best regards,

[1]: https://datatracker.ietf.org/doc/draft-ietf-add-ddr/
[2]: 
https://www.intel.com/content/www/us/en/architecture-and-technology/intel-quick-assist-technology-overview.html

[3]: https://docs.kernel.org/networking/tls-offload.html
[4]: https://dnsdist.org/rules-actions.html?#MaxQPSIPRule
[5]: https://dnsdist.org
[6]: https://dnsdist.org/changelog.html#change-1.7.2
|7]: https://dnsdist.org/upgrade_guide.html#x-to-1-8-0
[8]: https://github.com/PowerDNS/pdns/issues/new/choose
[9]:
https://downloads.powerdns.com/releases/dnsdist-1.7.2.tar.bz2
[10]:
https://downloads.powerdns.com/releases/dnsdist-1.7.2.tar.bz2.sig
[11]: https://repo.powerdns.com

--
Remi Gacogne
PowerDNS.COM BV - https://www.powerdns.com/



OpenPGP_signature
Description: OpenPGP digital signature
___
Pdns-users mailing list
Pdns-users@mailman.powerdns.com
https://mailman.powerdns.com/mailman/listinfo/pdns-users

Re: [Pdns-users] troubleshooting dnsdist -> recursor instability

[Remi Gacogne via Pdns-users]

Hi Christoph,

On 24/10/2022 01:46, Christoph via Pdns-users wrote:

Is this unexpected or not unusual?
If unusual: what would be the usual ways to further track this issue down?


Clearly unexpected. You might be able to get more information about what 
is going by setting setVerboseHealthChecks [1] in dnsdist. Otherwise you 
might have to look at the metrics reported by the recursor, or capture 
the traffic (look for UDP queries for a.root-servers.net type A).


One unrelated thing I noticed in your configuration is that you are 
setting maxInFlight to 1000 on newServer, telling dnsdist to send up to 
1000 concurrent queries on an outgoing TCP connection to the backend, 
but on the recursor's side it looks like 
max-concurrent-requests-per-tcp-connection [2] is set to the default of 
10. This might lead to terrible latency numbers over TCP, so I would 
suggest increasing that setting, or decreasing the maxInFlight value in 
the dnsdist configuration.



[1]: https://dnsdist.org/reference/config.html#setVerboseHealthChecks
[2]: 
https://docs.powerdns.com/recursor/settings.html#max-concurrent-requests-per-tcp-connection


Best regards,
--
Remi Gacogne
PowerDNS.COM BV - https://www.powerdns.com/



OpenPGP_signature
Description: OpenPGP digital signature
___
Pdns-users mailing list
Pdns-users@mailman.powerdns.com
https://mailman.powerdns.com/mailman/listinfo/pdns-users

Re: [Pdns-users] [dnsdist] Dnsdist not reading from the cache

[Remi Gacogne via Pdns-users]

Hi Sami,

On 12/09/2022 17:16, SAMI RAHAL via Pdns-users wrote:
Thank you very much, i tried with connecting with dnsdist -c and it 
gives the result of the cache:


Entries: 196858/200
Hits: 2255893765
Misses: 363296636
Deferred inserts: 91558
Deferred lookups: 174058
Lookup Collisions: 24882
Insert Collisions: 24759
TTL Too Shorts: 0


Great!


before i connect with dnsdist -l 127.0.0.1:5300


Right, that would have started a new dnsdist instance instead of 
connecting to the existing one, which explains why the counters were empty.


Best regards,
--
Remi Gacogne
PowerDNS.COM BV - https://www.powerdns.com/



OpenPGP_signature
Description: OpenPGP digital signature
___
Pdns-users mailing list
Pdns-users@mailman.powerdns.com
https://mailman.powerdns.com/mailman/listinfo/pdns-users

Re: [Pdns-users] [dnsdist] Dnsdist not reading from the cache

[Remi Gacogne via Pdns-users]

Hi Sami,

On 12/09/2022 14:25, SAMI RAHAL via Pdns-users wrote:

yes it's weird, because in the web interface it says that the cache is 
working, here is my configuration


Thanks. And how do you collect the output that shows 0 hits and 0 misses?
I'm guessing you are connecting to the console via

dnsdist -c

and then issuing

getPool("resolverTopnet"):getCache():printStats()

is that correct?

If so, would you mind sharing the output of

dumpStats()

as well?


Best regards,
--
Remi Gacogne
PowerDNS.COM BV - https://www.powerdns.com/



OpenPGP_signature
Description: OpenPGP digital signature
___
Pdns-users mailing list
Pdns-users@mailman.powerdns.com
https://mailman.powerdns.com/mailman/listinfo/pdns-users

Re: [Pdns-users] [dnsdist] Dnsdist not reading from the cache

[Remi Gacogne via Pdns-users]

On 09/09/2022 17:38, SAMI RAHAL via Pdns-users wrote:

The server is in production it receives requests as shown in this summary


Uptime: 17 days, Number of queries: 2326402346 (2385.00 qps), ACL drops: 
0, Dynamic drops: 27076173, Rule drops: 6451838
Average response time: 9.40 ms, CPU Usage: 26.50%, Cache hitrate: 
85.37%, Server selection policy: leastOutstanding

Listening on: 0.0.0.0:53, ACL: 0.0.0.0/0


The cache hitrate information from that output indicates that the cache 
is working.
If you still think this is not the case, please share an unedited 
configuration that we can use to reproduce the issue, and what you do 
exactly to test whether the cache is working.


--
Remi Gacogne
PowerDNS.COM BV - https://www.powerdns.com/



OpenPGP_signature
Description: OpenPGP digital signature
___
Pdns-users mailing list
Pdns-users@mailman.powerdns.com
https://mailman.powerdns.com/mailman/listinfo/pdns-users

Re: [Pdns-users] [EXT] RE: [EXTERNE]Re: [dnsdist] Dnsdist not reading from the cache

[Remi Gacogne via Pdns-users]

On 09/09/2022 11:34, SAMI RAHAL wrote:


Thank you for your answer I test the cache as follows:
getPool("resolverTopnet"):getCache():printStats()

I get empty values:

Entries: 0/200
Hits: 0
Misses: 0
Deferred inserts: 0
Deferred lookups: 0
Lookup Collisions: 0
Insert Collisions: 0
TTL Too Shorts: 0

before updating dnsdist from 1.5 to 1.7 i can see the values


But how are you testing exactly? How are you sending the DNS queries 
during your test?


--
Remi Gacogne
PowerDNS.COM BV - https://www.powerdns.com/



OpenPGP_signature
Description: OpenPGP digital signature
___
Pdns-users mailing list
Pdns-users@mailman.powerdns.com
https://mailman.powerdns.com/mailman/listinfo/pdns-users

Re: [Pdns-users] [dnsdist] Dnsdist not reading from the cache

[Remi Gacogne via Pdns-users]

Hi,

On 07/09/2022 14:02, SAMI RAHAL via Pdns-users wrote:

for those running dnsdist I'm wondering is anyone has set up cache.

If you have, I'd appreciate pointers in your strategies (and/or some
examples?).


A lot of installations are using caching in dnsdist, yes. I don't see 
anything immediately wrong after looking at your configuration. What 
makes you think caching is not working?


--
Remi Gacogne
PowerDNS.COM BV - https://www.powerdns.com/



OpenPGP_signature
Description: OpenPGP digital signature
___
Pdns-users mailing list
Pdns-users@mailman.powerdns.com
https://mailman.powerdns.com/mailman/listinfo/pdns-users

[Pdns-users] dnsdist 1.7.2 released

[Remi Gacogne via Pdns-users]

Hello!

We are very happy to release dnsdist 1.7.2 today, a maintenance release 
fixing a few bugs reported since 1.7.1:


- An unhandled exception could happen when an invalid protocol was used 
in an incoming DNS over HTTPS forwarded-for header and passed to the 
backend via the proxy protocol, leading to a use-after-free and a crash. 
Forwarded-for headers are not used by default and should only be used if 
the client can be trusted (#11667)
- An invalid proxy-protocol was sent to the backend, over TCP, if a 
query received via DNS over HTTPS resulted in a truncated UDP response 
from the backend (#11665)
- Some metrics lacked a proper description in our Prometheus endpoint 
(#11664)
- A side-effect of fixing the health-check timeout in 1.7.1 was leading 
to a CPU usage increase on devices that are mostly idle. We improved 
that situation, reducing the CPU usage even below what it was in 1.7.0 
(#11579, #11580)


We also added a couple Lua bindings to make it easier to look into the 
DNS payload from custom Lua rules and actions (#11666).


Please see the dnsdist website [1] for the more complete changelog [2] 
and the current documentation.


Please send us all feedback and issues you might have via the mailing 
list, or in case of a bug, via GitHub [3].


The release tarball [4] and its signature [5] are available on the 
downloads website, and packages for several distributions are available 
from our repository [6].


Finally, we would like to thank the PowerDNS community and all external 
contributors for their great work in this release!


[1]: https://dnsdist.org
[2]: https://dnsdist.org/changelog.html#change-1.7.2
[3]: https://github.com/PowerDNS/pdns/issues/new/choose
[4]:
https://downloads.powerdns.com/releases/dnsdist-1.7.2.tar.bz2
[5]:
https://downloads.powerdns.com/releases/dnsdist-1.7.2.tar.bz2.sig
[6]: https://repo.powerdns.com

--
Remi Gacogne
PowerDNS.COM BV - https://www.powerdns.com/



OpenPGP_signature
Description: OpenPGP digital signature
___
Pdns-users mailing list
Pdns-users@mailman.powerdns.com
https://mailman.powerdns.com/mailman/listinfo/pdns-users

[Pdns-users] dnsdist 1.7.1 released

[Remi Gacogne via Pdns-users]

Hello!

We are very happy to release dnsdist 1.7.1 today, a maintenance release 
fixing a few bugs reported since 1.7.0:


- A use-after-free error could happen if a network error occurred in the 
middle of a XFR query, for a proxy-protocol-enabled backend, leading to 
a crash
- The TLS Server Name Indication was not properly set on outgoing DNS 
over HTTPS or DNS over TLS connections to a backend
- The health-check timeout was not properly set for outgoing DNS over 
HTTPS connections, leading to a very long timeout
- The outgoing protocol was not always properly set in our in-memory 
ring buffers
- Outgoing UDP timeouts were sometimes processed a bit too late when the 
health-check interval was set to more than one second

- Filtering qnames via eBPF was broken
- The dynamic block mechanism was not properly switching to eBPF 
filtering, when available, if the block action was not explicitly set

- The latency histogram was broken in our prometheus metrics
- Trying to create a 0-sized packet cache would lead to a crash

In addition to these fixes, our Docker images no longer have capability 
requirements. More information on that topic is available in our upgrade 
guide [1].


We also improved our compatibility with OpenSSL 3.0.0's API.

As usual there were also other smaller enhancements and fixes, please 
see the dnsdist website [2] for the more complete changelog [3] and the 
current documentation.


Please send us all feedback and issues you might have via the mailing 
list, or in case of a bug, via GitHub [4].


The release tarball [5] and its signature [6] are available on the 
downloads website, and packages for several distributions are available 
from our repository [7].


Finally, we would like to thank the PowerDNS community and all external 
contributors for their great work in this release!


[1]: https://dnsdist.org/upgrade_guide.html#to-1-7-1
[2]: https://dnsdist.org
[3]: https://dnsdist.org/changelog.html#change-1.7.1
[4]: https://github.com/PowerDNS/pdns/issues/new/choose
[5]:
https://downloads.powerdns.com/releases/dnsdist-1.7.1.tar.bz2
[6]:
https://downloads.powerdns.com/releases/dnsdist-1.7.1.tar.bz2.sig
[7]: https://repo.powerdns.com

--
Remi Gacogne
PowerDNS.COM BV - https://www.powerdns.com/


OpenPGP_signature
Description: OpenPGP digital signature
___
Pdns-users mailing list
Pdns-users@mailman.powerdns.com
https://mailman.powerdns.com/mailman/listinfo/pdns-users

[Pdns-users] dnsdist 1.7.0 released

[Remi Gacogne via Pdns-users]

Hi everyone!

We are proud to announce the release of dnsdist 1.7.0. This release 
contains several new exciting features since 1.6.1, as well as 
improvements and bug fixes. It contains one single change from the first 
release candidate, a fix for DynBlockRatioRule::warningRatioExceeded 
provided by Doug Freed.


In our view, the most exciting new feature of 1.7.0 is the support of 
outgoing DNS over TLS and DNS over HTTPS, as well as the ability to do 
"cross-protocol" queries, meaning a query received over a given protocol 
(UDP, TCP, DoT, DoH, ...) can be forwarded over a different one. Now 
that dnsdist is capable of contacting its backend over an encrypted 
channel, full end-to-end encryption is possible, offering improved 
confidentiality and integrity.


Among the new features is the ability to add a custom EDNS option to a 
query before forwarding it to a backend, via SetEDNSOptionAction. 
phonedph1 also contributed a new rule making it possible to route a 
query based on the number of outstanding queries in a pool, 
PoolOutstandingRule.


Pierre Grié from Nameshield contributed an XDP program to reply to 
blocked UDP queries with a truncated response directly from the kernel, 
in a similar way to what we were already doing using eBPF socket 
filters. This version adds support for eBPF pinned maps, allowing 
dnsdist to populate the maps using our dynamic blocking mechanism, and 
letting the external XDP program do the actual blocking or response.


The packet cache has been improved so that one can now configure which 
EDNS options should be ignored, raising the cache hit ratio behind 
customer-premises equipment. The incoming and outgoing protocols have 
been added to the output of the grepq command for a better understanding 
of the recently processed traffic.


Dimitrios Mavrommatis improved the handling of AXFR and IXFR queries, 
making it possible to reuse a TCP connection used for a zone transfer 
much more efficiently.


We added support for generating the still experimental SVCB and HTTPS 
records directly from dnsdist, offering potential benefits to both 
performance and privacy.


Our LMDB code has gained the ability to do range-based lookups, and is 
now more performant even for simple lookups.


Extending the per-thread custom load-balancing policies introduced in 
1.6.0, it is now possible to write blazing-fast, lock-less per-thread 
custom actions using the Lua foreign function interface.


Holger Hoffstätte also improved the reporting of an unavailable backend, 
making sure the existing metrics are no longer reported to prevent any 
confusion.


This release also reduces the memory footprint of dnsdist in several 
places, which makes it easier to use in resource-constrained environments.


Please see the dnsdist website [1] for the more complete changelog [2] 
and the current documentation.


Please send us all feedback and issues you might have via the mailing 
list, or in case of a bug, via GitHub [3].


The release tarball [4] and its signature [5] are available on the 
downloads website, and packages for several distributions are available 
from our repository [6].


With this release, the 1.4.x releases become EOL and the 1.5.x and 1.6.x 
releases go into critical security fixes only mode.


Finally, we would like to thank the PowerDNS community and all external 
contributors for their great work in this release!


[1]: https://dnsdist.org
[2]: https://dnsdist.org/changelog.html#change-1.7.0
[3]: https://github.com/PowerDNS/pdns/issues/new/choose
[4]:
https://downloads.powerdns.com/releases/dnsdist-1.7.0.tar.bz2
[5]:
https://downloads.powerdns.com/releases/dnsdist-1.7.0.tar.bz2.sig
[6]: https://repo.powerdns.com

Best regards,
--
Remi Gacogne
PowerDNS.COM BV - https://www.powerdns.com/


OpenPGP_signature
Description: OpenPGP digital signature
___
Pdns-users mailing list
Pdns-users@mailman.powerdns.com
https://mailman.powerdns.com/mailman/listinfo/pdns-users

Re: [Pdns-users] Recursor: Error writing TCP answer - broken pipe

[Remi Gacogne via Pdns-users]

Hi Christoph,

On 16/01/2022 11:27, Christoph via Pdns-users wrote:

I get about 2000 of these log events per day:

pdns-recursor[11727]: Error writing TCP answer to 109.70.100.132:31192: 
Broken pipe


109.70.100.132 is the IP address of an dnsdist instance.

setup:
DoH/DoT clients -> dnsdist -> recursors

Is there anything that can be optimized to avoid these errors?


My guess is that the initial client closed its TCP connection with 
dnsdist, leading dnsdist to close its TCP connection to the recursor as 
well. 1.7.0 might do a bit better in that regard because it reuses 
outgoing TCP connections more aggressively when possible, but the real 
fix might be to lower the severity of that log message in the recursor.


Best regards,
--
Remi Gacogne
PowerDNS.COM BV - https://www.powerdns.com/


OpenPGP_signature
Description: OpenPGP digital signature
___
Pdns-users mailing list
Pdns-users@mailman.powerdns.com
https://mailman.powerdns.com/mailman/listinfo/pdns-users

[Pdns-users] First release release of dnsdist 1.7.0

[Remi Gacogne via Pdns-users]

Hi everyone!

We are happy to announce the first release candidate of what will become 
dnsdist 1.7.0, with only one fix and one improvement since the second beta.


We fixed a crash introduced in 1.7.0-alpha1 that could occur when a DoH 
query was forwarded to a backend over TCP, DoT or DoH and the response 
was dropped by a rule.


We also improved the health-checks queries done over DoT so that we 
could use any cached TLS ticket when connecting to the server, but also 
save new tickets so that they can be used for later connections. That 
reduces the CPU load and improves response time on devices dealing with 
a low number of queries per second.


Please see the dnsdist website [1] for the more complete changelog [2] 
and the current documentation.


Please send us all feedback and issues you might have via the mailing 
list, or in case of a bug, via GitHub [3].


The release tarball [4] and its signature [5] are available on the 
downloads website, and packages for several distributions are available 
from our repository [6].


With the future 1.7.0 final release, the 1.4.x releases will be EOL and 
the 1.5.x and 1.6.x releases will go into critical security fixes only mode.


Finally, we would like to thank the PowerDNS community and all external 
contributors for their great work in this release!


[1]: https://dnsdist.org
[2]: https://dnsdist.org/changelog.html#change-1.7.0-rc1
[3]: https://github.com/PowerDNS/pdns/issues/new/choose
[4]:
https://downloads.powerdns.com/releases/dnsdist-1.7.0-rc1.tar.bz2
[5]:
hhttps://downloads.powerdns.com/releases/dnsdist-1.7.0-rc1.tar.bz2.sig
[6]: https://repo.powerdns.com

Best regards,
--
Remi Gacogne
PowerDNS.COM BV - https://www.powerdns.com/


OpenPGP_signature
Description: OpenPGP digital signature
___
Pdns-users mailing list
Pdns-users@mailman.powerdns.com
https://mailman.powerdns.com/mailman/listinfo/pdns-users

[Pdns-users] Second beta release of dnsdist 1.7.0

[Remi Gacogne via Pdns-users]

Hi everyone!

We are happy to announce the second beta release of dnsdist 1.7.0, with 
few fixes since the first beta, the most important one being a memory 
leak when reusing TLS sessions for outgoing DNS over TLS and DNS over 
HTTPS connections. During that work we stumbled upon a memory leak in 
some setups using GnuTLS which will have to be fixed in the library 
itself. After reporting it upstream we added a warning in dnsdist which 
will be removed when a fixed version of GnuTLS has been released.


We also fixed an error in the way we check for integer overflows in 
configuration values, which could have refused valid configurations.


Finally we added a function to see the current configuration of the 
internal web server.


Please see the dnsdist website [1] for the more complete changelog [2] 
and the current documentation.


Please send us all feedback and issues you might have via the mailing 
list, or in case of a bug, via GitHub [3].


The release tarball [4] and its signature [5] are available on the 
downloads website, and packages for several distributions are available 
from our repository [6].


With the future 1.7.0 final release, the 1.4.x releases will be EOL and 
the 1.5.x and 1.6.x releases will go into critical security fixes only mode.


Finally, we would like to thank the PowerDNS community and all external 
contributors for their great work in this release!


[1]: https://dnsdist.org
[2]: https://dnsdist.org/changelog.html#change-1.7.0-beta2
[3]: https://github.com/PowerDNS/pdns/issues/new/choose
[4]:
https://downloads.powerdns.com/releases/dnsdist-1.7.0-beta2.tar.bz2
[5]:
hhttps://downloads.powerdns.com/releases/dnsdist-1.7.0-beta2.tar.bz2.sig
[6]: https://repo.powerdns.com

Best regards,
--
Remi Gacogne
PowerDNS.COM BV - https://www.powerdns.com/


OpenPGP_signature
Description: OpenPGP digital signature
___
Pdns-users mailing list
Pdns-users@mailman.powerdns.com
https://mailman.powerdns.com/mailman/listinfo/pdns-users

[Pdns-users] First beta release of dnsdist 1.7.0

[Remi Gacogne via Pdns-users]

Hi everyone!

We are happy to announce the first beta release of dnsdist 1.7.0!

We introduced a fair number of improvements and new features since the 
second alpha, and we will now iron out the documentation and fix any 
bugs before hopefully releasing the first release candidate very soon.


The main new feature is the ability to use the same outgoing TCP or DNS 
over TLS connection for queries coming from different clients, leading 
to a huge decrease of the number of outgoing connections needed when the 
backend supports out-of-order processing.


We also added the exact transport type to dnstap and protocol buffer 
messages, making it possible to differentiate between plaintext queries 
and DNS over HTTPS or DNS over TLS ones.


Recently Pierre Grié from Nameshield contributed an XDP program to reply 
to blocked UDP queries with a truncated response directly from the 
kernel, in a similar way to what we were already doing using eBPF socket 
filters. This beta finally adds support for eBPF pinned maps, allowing 
dnsdist to populate the maps using our dynamic blocking mechanism, and 
letting the external XDP program do the actual blocking or response.


Stéphane Bortzmeyer helped us pinpoint a few issues in the encryption 
between dnsdist and its backends, notably in the way the outgoing 
connections are cached while waiting to be reused. That could have led 
to a waste of memory piling up over time.


We also fixed an issue where the threads handling incoming DoH queries 
could have stopped processing responses when they were completely 
overloaded by TLS handshakes, leading to a degradation of performance.


The last issue was that a backend was not properly marked as 
non-available when a certain exception was raised during a health-check 
attempt.


Finally Rosen Penev contributed a lot of clean up changes to make sure 
that we make the best of what C++17 can offer.


Please see the dnsdist website [1] for the more complete changelog [2] 
and the current documentation.


Please send us all feedback and issues you might have via the mailing 
list, or in case of a bug, via GitHub [3].


The release tarball [4] and its signature [5] are available on the 
downloads website, and packages for several distributions are available 
from our repository [6].


With the future 1.7.0 final release, the 1.4.x releases will be EOL and 
the 1.5.x and 1.6.x releases will go into critical security fixes only mode.


Finally, we would like to thank the PowerDNS community and all external 
contributors for their great work in this release!


[1]: https://dnsdist.org
[2]: https://dnsdist.org/changelog.html#change-1.7.0-beta1
[3]: https://github.com/PowerDNS/pdns/issues/new/choose
[4]:
https://downloads.powerdns.com/releases/dnsdist-1.7.0-beta1.tar.bz2
[5]:
hhttps://downloads.powerdns.com/releases/dnsdist-1.7.0-beta1.tar.bz2.sig
[6]: https://repo.powerdns.com

Best regards,
--
Remi Gacogne
PowerDNS.COM BV - https://www.powerdns.com/


OpenPGP_signature
Description: OpenPGP digital signature
___
Pdns-users mailing list
Pdns-users@mailman.powerdns.com
https://mailman.powerdns.com/mailman/listinfo/pdns-users

Re: [Pdns-users] resource-limits metrics

[Remi Gacogne via Pdns-users]

Hi Christoph,

On 10/24/21 10:49, Christoph via Pdns-users wrote:
while going over the list of prometheus metrics available in PowerDNS 
Recursor I found this one:




resource-limits

counts number of queries that could not be performed because of 
resource limits

https://docs.powerdns.com/recursor/metrics.html#resource-limits

I guess if this value is increasing regularly it is a sign of issues. 
What kind of resource limits are hit when this counter increases?
Are there other metrics that allow further understanding the possible 
root causes?


This counter is increased when we encounter a network issue that does 
not seem to be caused by the remote end but by a problem on our side, 
like if the recursor runs out of file descriptors or if we don't have a 
network route to contact a given IP address, for example.
I would suggest checking and likely increasing the number of file 
descriptors available to the recursor as a first step, and then trying 
to correlate the periods where that counter is increasing with a growth 
of others network-related counters.



Best regards,
--
Remi Gacogne
PowerDNS.COM BV - https://www.powerdns.com/


OpenPGP_signature
Description: OpenPGP digital signature
___
Pdns-users mailing list
Pdns-users@mailman.powerdns.com
https://mailman.powerdns.com/mailman/listinfo/pdns-users

[Pdns-users] Second alpha release of dnsdist 1.7.0

[Remi Gacogne via Pdns-users]

Hi everyone,

We are happy to announce the second alpha release of dnsdist 1.7.0!

We spent quite some time since alpha1 reproducing an issue reported by 
Stephane Bortzmeyer in our new outgoing DNS over TLS feature. The issue 
turned out to be triggered by the use of the GnuTLS provider, and to be 
only present with some versions of that library. We are still working 
with the GnuTLS project to get this issue resolved, but in the meantime 
we implemented a work-around in dnsdist itself. In addition to that 
work-around, this release contains a few new features, improvements and 
bug fixes.


Among the new features is the ability to add a custom EDNS option to a 
query before forwarding it to a backend, via SetEDNSOptionAction. 
phonedph1 also contributed a new rule making it possible to route a 
query based on the number of outstanding queries in a pool, 
PoolOutstandingRule.


The packet cache has been improved so that one can now configure which 
EDNS options should be ignored, raising the cache hit ratio behind 
customer-premises equipment. The incoming and outgoing protocols have 
been added to the output of the grepq command for a better understanding 
of the recently processed traffic. We also reduced the memory 
consumption of dnsdist in constrained environments a bit further.


Denis Machard reported that queries received over UDP and forwarded via 
a TCP, DoH or DoT were not properly cached. We also noticed that the 
includeDirectory configuration directive might not properly function if 
an exception was raised during the processing. Both issues are now fixed.


Please see the dnsdist website [1] for the more complete changelog [2] 
and the current documentation.


Please send us all feedback and issues you might have via the mailing 
list, or in case of a bug, via GitHub.


Release tarballs are available on the downloads website, and packages 
for several distributions are available from our repository.


With the future 1.7.0 final release, the 1.4.x releases will be EOL and 
the 1.5.x and 1.6.x releases will go into critical security fixes only mode.


Finally, we would like to thank the PowerDNS community and all external 
contributors for their great work in this release!


[1]: https://dnsdist.org
[2]: https://dnsdist.org/changelog.html#change-1.7.0-alpha2
[3]: https://github.com/PowerDNS/pdns/issues/new/choose
[4]:
https://downloads.powerdns.com/releases/dnsdist-1.7.0-alpha2.tar.bz2
[5]:
hhttps://downloads.powerdns.com/releases/dnsdist-1.7.0-alpha2.tar.bz2.sig
[6]: https://repo.powerdns.com

Best regards,
--
Remi Gacogne
PowerDNS.COM BV - https://www.powerdns.com/


OpenPGP_signature
Description: OpenPGP digital signature
___
Pdns-users mailing list
Pdns-users@mailman.powerdns.com
https://mailman.powerdns.com/mailman/listinfo/pdns-users

Re: [Pdns-users] SERVFAIL responses on malformed subdomain query

[Remi Gacogne via Pdns-users]

Hi Thibaud,

On 10/14/21 15:52, Thib D via Pdns-users wrote:
It seems like pdns auth servers are answering SERVFAIL queries when the 
subdomain is malformed in the query. It is testable on powerdns.com 
<http://powerdns.com> domain - which I assume is hosted on a pdns-auth 
backend.
[...] 
I am not sure what is the correct answer here, but I'm only seeing this 
on pdns-auth installations.  From the other authoritative nameservers 
I've tested, every single one of them is answering NXDOMAIN ( isc.org 
<http://isc.org> / knot-dns.cz <http://knot-dns.cz> / facebook.com 
<http://facebook.com> / google.com <http://google.com> / nlnetlabs...  ) 
in this case.


That behaviour can be configured via the 8bit-dns parameter [1], which 
default to false. It used to be an issue for some PowerDNS backends but 
my understanding is that it should be safe to turn it on nowadays.


[1]: https://doc.powerdns.com/authoritative/settings.html#bit-dns

Best regards,
--
Remi Gacogne
PowerDNS.COM BV - https://www.powerdns.com/


OpenPGP_signature
Description: OpenPGP digital signature
___
Pdns-users mailing list
Pdns-users@mailman.powerdns.com
https://mailman.powerdns.com/mailman/listinfo/pdns-users

[Pdns-users] First alpha release of dnsdist 1.7.0

[Remi Gacogne via Pdns-users]

Hi everyone,

We are proud to announce the first alpha release of dnsdist 1.7.0. This 
release contains several new exciting features, as well as improvements 
and bug fixes.


In our view, the most exciting new feature is the support of outgoing 
DNS over TLS and DNS over HTTPS, as well as the ability to do 
"cross-protocol" queries, meaning a query received over a given protocol 
(UDP, TCP, DoT, DoH, ...) can be forwarded over a different one. Now 
that dnsdist is capable of contacting its backend over an encrypted 
channel, full end-to-end encryption is possible, offering improved 
confidentiality and integrity.


This release also reduces the memory footprint of dnsdist in several 
places, which makes it easier to use in resource-constrained environments.


We added support for generating the still experimental SVCB and HTTPS 
records directly from dnsdist, offering potential benefits to both 
performance and privacy.


Our LMDB code has gained the ability to do range-based lookups, and is 
now more efficient even for simple lookups.


Extending the per-thread custom load-balancing policies introduced in 
1.6.0, it is now possible to write blazing-fast, lock-less per-thread 
custom actions using the Lua foreign function interface.


Dimitrios Mavrommatis improved the handling of AXFR and IXFR queries, 
making it possible to reuse a TCP connection used for a zone transfer 
much more efficiently.


Holger Hoffstätte also improved the reporting of an unavailable backend, 
making sure the existing metrics are no longer reported to prevent any 
confusion.


Please see the dnsdist website [1] for the more complete changelog [2] 
and the current documentation.


Please send us all feedback and issues you might have via the mailing 
list, or in case of a bug, via GitHub.


Release tarballs are available on the downloads website, and packages 
for CentOS 7 and 8, Debian Buster, Bullseye, and Ubuntu Bionic and Focal 
are available from our repository.


With the future 1.7.0 final release, the 1.4.x releases will be EOL and 
the 1.5.x releases will go into critical security fixes only mode.


Finally, we would like to thank the PowerDNS community and all external 
contributors for their great work in this release!


[1]: https://dnsdist.org
[2]: https://dnsdist.org/changelog.html#change-1.7.0-alpha1
[3]: https://github.com/PowerDNS/pdns/issues/new/choose
[4]:
https://downloads.powerdns.com/releases/dnsdist-1.7.0-alpha1.tar.bz2
[5]:
hhttps://downloads.powerdns.com/releases/dnsdist-1.7.0-alpha1.tar.bz2.sig
[6]: https://repo.powerdns.com

Best regards,
--
Remi Gacogne
PowerDNS.COM BV - https://www.powerdns.com/


OpenPGP_signature
Description: OpenPGP digital signature
___
Pdns-users mailing list
Pdns-users@mailman.powerdns.com
https://mailman.powerdns.com/mailman/listinfo/pdns-users

[Pdns-users] dnsdist 1.6.1 released

[Remi Gacogne via Pdns-users]

Hello!

We are happy to release dnsdist 1.6.1 today, a maintenance release 
fixing a few bugs reported since 1.6.0:


- Adding ECS failed for queries with records in the answer or additional 
section (Dimitrios Mavrommatis)
- The transport was not properly set in dnstap and protobuf messages for 
DoH queries
- The outstanding queries counter was not properly reset when some TCP 
I/O errors occurred

- The ability to load a new certificate on a DoH frontend was missing
- A missing header could have caused a compilation issue on some platforms

As usual there were also other smaller enhancements and fixes, please 
see the dnsdist website [1] for the more complete changelog [2] and the 
current documentation.


Please send us all feedback and issues you might have via the mailing 
list, or in case of a bug, via GitHub [3].


We are grateful to the PowerDNS community for the reporting of bugs, 
issues, feature requests, and especially to the submitters of fixes and 
implementations of features.


The release tarball [4] (signature [5]) is available on the downloads 
website, and packages for CentOS 7 and 8, Debian Buster and Bullseye, 
and Ubuntu Bionic and Focal are available from our repository [6].


[1]: https://dnsdist.org
[2]: https://dnsdist.org/changelog.html#change-1.6.1
[3]: https://github.com/PowerDNS/pdns/issues/new/choose
[4]:
https://downloads.powerdns.com/releases/dnsdist-1.6.1.tar.bz2
[5]:
https://downloads.powerdns.com/releases/dnsdist-1.6.1.tar.bz2.sig
[6]: https://repo.powerdns.com

Best regards,
--
Remi Gacogne
PowerDNS.COM BV - https://www.powerdns.com/


OpenPGP_signature
Description: OpenPGP digital signature
___
Pdns-users mailing list
Pdns-users@mailman.powerdns.com
https://mailman.powerdns.com/mailman/listinfo/pdns-users

Re: [Pdns-users] Status of dnsdist 1.6.1

[Remi Gacogne via Pdns-users]

Hello!

On 8/30/21 2:13 PM, labs--- via Pdns-users wrote:
I tried the 1.6.0.38 version but the problem still exists. I can see 
that you backported the patch 29 days ago but the 1.6.0.38 package is 
dated 18th may 2021. Does this version really contain the patch? Perhaps 
there should be newer nightly builds?


You are right, really sorry about that. The directories should have 
"reldnsdist16x" in their name, in addition to starting with 1.6.0. This 
one [1] should be good, as this time I properly checked that the commit 
number embedded in the name really matches the last one on the 
rel/dnsdist-1.6.x branch [2].


[1]: 
https://downloads.powerdns.com/autobuilt_browser/#/dnsdist/1.6.0.8.reldnsdist16x.g7cf5b6ef6

[2]: https://github.com/PowerDNS/pdns/commits/rel/dnsdist-1.6.x

Best regards,
--
Remi



OpenPGP_signature
Description: OpenPGP digital signature
___
Pdns-users mailing list
Pdns-users@mailman.powerdns.com
https://mailman.powerdns.com/mailman/listinfo/pdns-users

Re: [Pdns-users] recursor: Possible bug in accepting / rejecting additional answers?

[Remi Gacogne via Pdns-users]

Hi,

I think I have to clarify a bit here. The first question was why the 
recursor doesn't accept the A records from the delegated name server’s 
response. For the record I believe we are talking about this response, 
received from one of the servers returned in the delegation from one of 
the com name server:


;; QUESTION SECTION:
;solera.com.IN  MX

;; ANSWER SECTION:
solera.com. 300 IN  MX  10 
solera-com.mail.protection.outlook.com.


;; AUTHORITY SECTION:
solera.com. 1800IN  NS  dns2.adpclaims.com.
solera.com. 1800IN  NS  dns1.adpclaims.com.

;; ADDITIONAL SECTION:
dns1.adpclaims.com. 1800IN  A   170.76.174.203
dns2.adpclaims.com. 1800IN  A   170.76.174.204

The recursor can accept the records in the answer and authority sections 
because they are at or below solera.com, which we know this name server 
to be authoritative for. The A records in the additional section are in 
the adpclaims.com zone, and at this point we have no way of knowing 
whether this server is authoritative for that zone so we _have_ to 
reject them, otherwise we would open ourselves to a cache pollution 
security issue.
The A records in the response from the com name server were accepted 
because adpclaims.com is below com, which we knew the name server to be 
authoritative for.


Then the second part, the one Frank has been answering below, is about 
the recursor replacing the non-authoritative NS set with the 
authoritative one. There is a long discussion about that on our issue 
tracker [1]. Basically we follow rfc2181 section-5.4.1 and we believe 
it's the right call, but we do agree with Frank that it would be nice to 
be able to fall back to the non-authoritative NS set when that one is 
clearly broken. We are trying to find a way to implement that without 
opening ourselves to a security flaw, or making well-configured zones 
bear the burden of broken ones. As always, suggestions and pull requests 
are very welcome.


[1]: https://github.com/PowerDNS/pdns/issues/10594

Hope that helps,

Remi

On 8/30/21 9:55 AM, frank+pdns--- via Pdns-users wrote:

Hi Paul,

This is a design choice by PowerDNS, which is defendable: the domain is 
misconfigured and the RFCs don't clearly which option to take in such a 
case. Unfortunately, Google and Unbound toke a different option, so when 
the customer verifies against 8.8.8.8, it will just work. Also 
unfortunately, PowerDNS took the option of having the return depend on 
the state of cache, meaning that depending on the order you execute the 
queries in, you'll get a different result.


I've had long discussions with the core maintainers and discussion 
makers at PowerDNS, but – for now – they won't change this behaviour.


Kind Regards,

Frank



On 28 Aug 2021, at 9:43 AM, Paul Fletcher via Pdns-users 
> wrote:


Hello,
We are having problems with pdns-recursor when resolving an MX record 
for a domain whose delegation is partially mis-configured.  Whilst 
that mis-configuration is clearly the trigger for the problem, the 
behaviour of pdns is tunring a small problem into a big one, when 
other recursors do not appear to do so.

Version:4.5.5(also seen in earlier versions)
OS: CentOS7
Description of the problem:
Initial discovery of NS for the domain gets an answer from 
gtld-servers.  The answer includes:


  * 4 NS names; two are in the domain itself, and two are in an
unrelated zone.  TTL=172800
  * A records / IP addresses for those 4 names (one per name).  TTL=172800

Two of the IP addresses are incorrect.  The four name servers are 
cached, as are the four A records.
Recursor then goes on to one of the name servers, for which it has a 
valid IP.  (In fact the IP in the A record is for a different one of 
the name servers to the one which the initial answer said it was for, 
but it is nevertheless the IP of a valid name server for the domain).  
It queries the MX record, and gets back a response.  The response includes


  * The MX record, with TTL=300
  * 2 NS servers (two of the four which were in the parent response). 
TTL=1800

  * A records for those 2 servers.  TTL=1800

This time the A records are correct.  However, whilst recursor 
replaces the previous NS records in the cache, it does NOT replace the 
A records.  In older versions it says

“Accept answer? NO!”
In newer versions it says
“Removing record  in the 3 section”
So now if we look up the MX record again after its TTL has expired, 
recursor correctly identifies the names of the two name servers to use 
from cache.  It then tries to resolve those to IPs, which it does by 
using the incorrect A records that were cached from the first 
response.  And since they are not accessible, the query times out.  
Nothing works until the 1800 TTL on the name servers expires, at which 
point we go back to the start, getting 4 name servers and 4 IPs, 

Re: [Pdns-users] Status of dnsdist 1.6.1

[Remi Gacogne via Pdns-users]

Hi Oliver,

On 8/27/21 5:36 PM, labs--- via Pdns-users wrote:
there is a bug in handling notify packages in dnsdist which will be 
fixed in versions 1.6.1/.1.7: https://github.com/PowerDNS/pdns/pull/10419


I am longingly waiting for these releases because we use dnsdist in 
front of authoritative servers. Do you have any idea when these releases 
will come? As this bug causes some problems in our infrastructure, we 
think about using our build system to build debian packages from source 
instead of the packages from your repo. But I would be more satisfied if 
I could go on with your prebuild debian packages.


Is there any chance that your crystal ball has some information? This 
does not have to be exact, an answer a la "we plan a release in one 
month or two" would be sufficient for me to decide which way to go. If 
there is no information you can give me, that would be a useful 
information for me too. Then Rock Paper Scissors will help me.


I plan on releasing the first alpha release of 1.7.0 very soon, 
hopefully next week, and it's very likely we will release 1.6.1 just 
after that.


Note that the fix has already been backported to the rel/dnsdist-1.6.x 
branch and we automatically build packages from that branch so in the 
meantime you could use these. Look for 1.6.0.* directories under [1], 
like [2]. These directories contain bzipped tarballs that themselves 
contain the packages you are looking for.


These packages, while technically not a released version, are currently 
1.6.0 plus three fixes [3][4][5], so it should be pretty safe to run in 
production.


[1]: https://downloads.powerdns.com/autobuilt_browser/#/dnsdist/
[2]: 
https://downloads.powerdns.com/autobuilt_browser/#/dnsdist/1.6.0.38.master.ge218c1e58

[3]: https://github.com/PowerDNS/pdns/pull/10438
[4]: https://github.com/PowerDNS/pdns/pull/10538
[5]: https://github.com/PowerDNS/pdns/pull/10619

Hope that helps,
--
Remi



OpenPGP_signature
Description: OpenPGP digital signature
___
Pdns-users mailing list
Pdns-users@mailman.powerdns.com
https://mailman.powerdns.com/mailman/listinfo/pdns-users

Re: [Pdns-users] Injection Attacks Reloaded: Validating hostnames?

[Remi Gacogne via Pdns-users]

Hi Christoph,

On 8/14/21 1:11 PM, Christoph via Pdns-users wrote:
We were wondering if there is an easy way in Recursor's configuration to 
enable validation of hostnames similar to their python proof of concept 
[4]?


We don't have such an option at the moment, although it would not be too 
hard to implement via our Lua hooks.


> If there is no such option: Would you accept a feature request via GH
> to implement such an option?

I would personally not implement such a filter in a recursor, though, as 
the authors themselves acknowledge it would be challenging not to block 
legitimate records:
"Nevertheless, performing checks on DNS records is challenging: some 
applications, like SRV service discovery [38], require domain names with 
characters that are not allowed in hostnames (e.g., underscore). 
Defining a list of allowed characters so that legitimate applications 
would still work but injection attacks would be blocked should be 
further investigated and is not straightforward. In particular, it is 
difficult to foresee what characters and formats will be needed by 
future applications, hence a ‘too-restrictive’ list of allowed 
characters would make DNS less transparent, possibly introducing 
obstacles in deployment of new applications, or when adding new versions

or new features to existing applications."

I would be willing to accept a new rule in dnsdist, though, validating 
whether owner names and targets are valid hostnames, if there is any 
interest.


I'm also interested in your opinions on whether such validation might 
cause issues in practice.


My understanding is that restricting owner names and targets in queries 
and responses to valid hostnames, in a resolver, would lead to issues 
quite quickly, at the very least with SRV and SVCB records. I'm not 
really convinced it can be implemented at the stub resolver level either 
without breaking some applications.


Best regards,
--
Remi Gacogne
PowerDNS.COM BV - https://www.powerdns.com/
___
Pdns-users mailing list
Pdns-users@mailman.powerdns.com
https://mailman.powerdns.com/mailman/listinfo/pdns-users

[Pdns-users] dnsdist 1.6.0 released

[Remi Gacogne via Pdns-users]

ludes 32-bit Linux
platforms like arm and i386 before kernel version 5.1.

Finally, we would like to thank the PowerDNS community and all external
contributors for their great work in this release, and in particular
Stephane Bakhos, Stéphane Bortzmeyer, Georgeto, Matti Hiljanen, Avatar
Andreas Jakum, Nuitari, Oli Schacher, Sukhbir Singh, Thibmac and
Mischan Toosarani-Hausberger!

[1]: https://dnsdist.org
[2]: https://dnsdist.org/changelog.html#change-1.6.0
[3]: https://github.com/PowerDNS/pdns/issues/new/choose
[4]:
https://downloads.powerdns.com/releases/dnsdist-1.6.0.tar.bz2
[5]:
https://downloads.powerdns.com/releases/dnsdist-1.6.0.tar.bz2.sig
[6]: https://repo.powerdns.com

Best regards,
-- 
Remi Gacogne
PowerDNS.COM BV - https://www.powerdns.com/



pgp38IoYo93XA.pgp
Description: OpenPGP digital signature
___
Pdns-users mailing list
Pdns-users@mailman.powerdns.com
https://mailman.powerdns.com/mailman/listinfo/pdns-users

[Pdns-users] dnsdist 1.5.2 released

[Remi Gacogne via Pdns-users]

Hi everyone!

We are happy to release dnsdist 1.5.2 today, a maintenance release
fixing a few bugs reported since 1.5.1:

- A typo in prometheus metrics dnsdist_frontend_tlshandshakefailures
  (AppliedPrivacy)
- A hang when removing a server with more than one socket
- SNI availability on resumed sessions, by acknowledging the name sent
  by the client
- A crash when a DoH responses map is updated at runtime
- Dynamic Block RCode rules messing up the queries count
- EDNS in ServFail generated when no server is available
- A crash with DynBPF objects in client mode
- Add missing getEDNSOptions and getDO bindings for DNSResponse

As usual there were also other smaller enhancements and fixes, please
see the dnsdist website [1] for the more complete changelog [2] and the
current documentation.

Please send us all feedback and issues you might have via the mailing
list, or in case of a bug, via GitHub [3].

We are grateful to the PowerDNS community for the reporting of bugs,
issues, feature requests, and especially to the submitters of fixes and
implementations of features.

The release tarball [4] (signature [5]) is available on the downloads
website, and packages for CentOS 7 and 8, Debian Buster and Ubuntu
Bionic and Focal are available from our repository [6].

[1]: https://dnsdist.org
[2]: https://dnsdist.org/changelog.html#change-1.5.2
[3]: https://github.com/PowerDNS/pdns/issues/new/choose
[4]:
https://downloads.powerdns.com/releases/dnsdist-1.5.2.tar.bz2
[5]:
https://downloads.powerdns.com/releases/dnsdist-1.5.2.tar.bz2.sig
[6]: https://repo.powerdns.com

Best regards,
-- 
Remi Gacogne
PowerDNS.COM BV - https://www.powerdns.com/


pgpMmNiCxnf7h.pgp
Description: OpenPGP digital signature
___
Pdns-users mailing list
Pdns-users@mailman.powerdns.com
https://mailman.powerdns.com/mailman/listinfo/pdns-users

[Pdns-users] Second release candidate for dnsdist 1.6.0

[Remi Gacogne via Pdns-users]

Hi everyone,

We are happy to announce the second release candidate of what should
become dnsdist 1.6.0. This release contains very few changes since the
first release candidate, and thanks to the great feedback we received
on previous versions we expect to be able to release 1.6.0 final very
soon. The changed bits since -rc1 are:

- Only use eBPF for “drop” actions, and clean up the eBPF rules more
often
- Fix missing locks in DNSCrypt certificates management
- Make the backend queryLoad and dropRate values atomic

Please see the dnsdist website [1] for the more complete changelog [2]
and the current documentation.

Please send us all feedback and issues you might have via the mailing
list, or in case of a bug, via GitHub [3].

We are grateful to the PowerDNS community for the reporting of bugs,
issues, feature requests, and especially to the submitters of fixes and
implementations of features.

The release tarball [4] and its signature [5] are available on the
downloads website, and packages for CentOS 7 and 8, Debian Buster
and Ubuntu Bionic and Focal are available from our repository [6].

With the future 1.6.0 final release, the 1.3.x releases will be EOL and
the 1.4.x releases will go into critical security fixes only mode.

We would also like to take this opportunity to announce that we will
stop supporting systems using 32-bit time. This includes 32-bit Linux
platforms like arm and i386 before kernel version 5.1.

[1]: https://dnsdist.org
[2]: https://dnsdist.org/changelog.html#change-1.6.0-rc2
[3]: https://github.com/PowerDNS/pdns/issues/new/choose
[4]:
https://downloads.powerdns.com/releases/dnsdist-1.6.0-rc2.tar.bz2
[5]:
https://downloads.powerdns.com/releases/dnsdist-1.6.0-rc2.tar.bz2.sig
[6]: https://repo.powerdns.com

Best regards,
-- 
Remi Gacogne
PowerDNS.COM BV - https://www.powerdns.com/


pgpT2ywVdNg2g.pgp
Description: OpenPGP digital signature
___
Pdns-users mailing list
Pdns-users@mailman.powerdns.com
https://mailman.powerdns.com/mailman/listinfo/pdns-users

[Pdns-users] First release candidate for dnsdist 1.6.0

[Remi Gacogne via Pdns-users]

Hi everyone,

We are happy to announce the first release candidate of what should
become dnsdist 1.6.0. This release contains very few changes since the
third alpha:

- Add missing getEDNSOptions and getDO bindings for DNSResponse
- Fix some issues reported by Thread Sanitizer
- Lua: don’t destroy keys during table iteration
- Disable PMTU for IPv6 as well
- Replace pthread_rwlock with std::shared_mutex

Please see the dnsdist website [1] for the more complete changelog [2]
and the current documentation.

Please send us all feedback and issues you might have via the mailing
list, or in case of a bug, via GitHub [3].

We are grateful to the PowerDNS community for the reporting of bugs,
issues, feature requests, and especially to the submitters of fixes and
implementations of features.

Release tarballs are available on the downloads website [4], and
packages for CentOS 7 and 8, Debian Buster and Ubuntu Bionic and Focal
are available from our repository [5].

With the future 1.6.0 final release, the 1.3.x releases will be EOL and
the 1.4.x releases will go into critical security fixes only mode.

We would also like to take this opportunity to announce that we will
stop supporting systems using 32-bit time. This includes 32-bit Linux
platforms like arm and i386 before kernel version 5.1.

[1]: https://dnsdist.org
[2]: https://dnsdist.org/changelog.html#change-1.6.0-rc1
[3]: https://github.com/PowerDNS/pdns/issues/new/choose
[4]:
https://downloads.powerdns.com/releases/dnsdist-1.6.0-rc1.tar.bz2
[5]: https://repo.powerdns.com

Best regards,
-- 
Remi Gacogne
PowerDNS.COM BV - https://www.powerdns.com/


pgpYU7a0IyAnR.pgp
Description: OpenPGP digital signature
___
Pdns-users mailing list
Pdns-users@mailman.powerdns.com
https://mailman.powerdns.com/mailman/listinfo/pdns-users

Re: [Pdns-users] ECS not using proxied client IP?

[Remi Gacogne via Pdns-users]

Hi Mark,

On 4/17/21 12:37 AM, Nejedlo, Mark via Pdns-users wrote:
Using the same dnsdist/pdns_recursor setup as the previous, but with 
“ecs-add-for=0.0.0.0/0, ::/0" added to the configuration,  I see ECS 
with ::/56 as the client subnet.  Since dnsdist is using 
“newServer({address='[::1]:5353', useProxyProtocol=true, sockets=12})”, 
this suggests that pdns_recursor is ignoring the client IP that was 
proxied, and using the client IP from the UDP connection instead.


I did try 4.5beta2 as well, but the behavior didn’t change.

Have I missed some setting for telling pdns_recursor to use the proxied 
client IP in ECS?  Is this a bug?


That seems like a bug indeed, the interaction between the proxy protocol 
and EDNS Client Subnet was not properly handled. I opened a pull request 
[1] to fix it.

Thanks for reporting that issue!


[1]: https://github.com/PowerDNS/pdns/pull/10303

Best regards,
--
Remi Gacogne
PowerDNS.COM BV - https://www.powerdns.com/
___
Pdns-users mailing list
Pdns-users@mailman.powerdns.com
https://mailman.powerdns.com/mailman/listinfo/pdns-users

Re: [Pdns-users] CPU consumption of pdns_recursor

[Remi Gacogne via Pdns-users]

Hi,

On 4/6/21 6:25 PM, Nejedlo, Mark via Pdns-users wrote:

On Tuesday, April 6, 2021 10:04 AM, Remi Gacogne wrote:

On 4/6/21 4:18 PM, Nejedlo, Mark via Pdns-users wrote:

Would additional distributor threads really cause additional
worker

CPU usage?

That could happen if they have to fight for the incoming socket. Do
you have reuseport=yes in your configuration?


Either I'm deeply misunderstanding something (quite possible), or we
may be talking about different things.  If I understand correctly,
thundering herd problems should only show up on the distributor
threads, but my distributors are not very busy.  It is the workers
doing the actual DNS processing that show the high CPU, and I would
think the distributors address the workers individually, not via a
shared port (but maybe I'm wrong?)


You are right, sorry! The thundering herd would only show up on the 
distributor threads, and therefore could cause additional CPU usage but 
not _worker_ CPU usage indeed.



Dropping the distributors to one, which I'm planning to do anyway,
will eliminate the problem on the front end socket.  If the workers
do share the connection to the distributors, adding reuseport isn't
hard.


They don't, using reuseport should not make any difference if you have 
only one distributor, and not impact the _worker_ CPU usage indeed.



Do you really XPF, by the way? You are passing the initial client
IP in EDNS Client Subnet already, so that might be enough?


This is probably a misunderstanding on my part.  I was under the
impression that useClientSubnet=true told dnsdist that it needed to
pass the client IP, and addXPF/proxy protocol told it how to do so.
If I'm wrong, dropping XPF is easy enough.  Although, it sounds like
I also want to drop useClientSubnet in favor of the proxy protocol.


Right, these really are separate. useClientSubnet=true will add an EDNS 
Client Subnet option to the query, while addXPF will add a XPF record to 
the query. Having both is unlikely to be useful.
The proxy protocol would be my preferred option because it doesn't not 
interact with the packet cache.
EDNS Client subnet might also work but would likely require using 
dnsdist's packet cache and the zero scope feature to get the best 
performance.


Best regards,
--
Remi Gacogne
PowerDNS.COM BV - https://www.powerdns.com/
___
Pdns-users mailing list
Pdns-users@mailman.powerdns.com
https://mailman.powerdns.com/mailman/listinfo/pdns-users

Re: [Pdns-users] CPU consumption of pdns_recursor

[Remi Gacogne via Pdns-users]

On 4/6/21 4:18 PM, Nejedlo, Mark via Pdns-users wrote:

Would additional distributor threads really cause additional worker CPU usage?


That could happen if they have to fight for the incoming socket. Do you 
have reuseport=yes in your configuration?



Does the maintenance function block the worker while it's running?


Yes.


I see that XPF is enabled between dnsdist and the recursor, which likely
kills the recursor's packet cache. That might explain the bad
performance results.


Even with a short edns-subnet-whitelist?


I'm afraid so, yes, and since some of your responses depends on the 
client IP (EDNS Client Subnet is enabled for some domains) you can't 
really enable the packet cache in dnsdist, unless you know for sure that 
only a few domains are using EDNS Client Subnet, and that there is no 
CNAME to them from other domains. Then you could perhaps enable the 
packet cache in dnsdist and disable it for these domains only.


Do you really XPF, by the way? You are passing the initial client IP in 
EDNS Client Subnet already, so that might be enough?



Both 4.4/5 and proxy protocol were on my radar, but my priority was to address 
the CPU usage.  If there's performance gains to be had in upgrading, I can 
certainly do that.  Is 4.5GA likely to happen soon?


The proxy protocol adds a header outside of the DNS payload, so it would 
not kill your packet cache. If you get rid of EDNS Client Subnet and XPF 
between dnsdist and the recursor so you should get much better performance.
Even if you need to keep EDNS Client Subnet between dnsdist and the 
recursor, you could then try enabling dnsdist's packet cache with the 
EDNS zero scope feature [1] which let dnsdist know when it can cache an 
answer for all clients.


[1]: 
https://dnsdist.org/reference/config.html?highlight=disableZeroScope#newServer


--
Remi
___
Pdns-users mailing list
Pdns-users@mailman.powerdns.com
https://mailman.powerdns.com/mailman/listinfo/pdns-users

Re: [Pdns-users] CPU consumption of pdns_recursor

[Remi Gacogne via Pdns-users]

Hi,

On 4/6/21 8:35 AM, Otto Moerbeek via Pdns-users wrote:

On Mon, Apr 05, 2021 at 05:30:11PM +, Nejedlo, Mark via Pdns-users wrote:

Some thoughts:

2 distributior thread feels a bit overkill, 1 distributor thread
should be able to feed 8 workers. Did you do measurements to come to
this value?

Your maintenance function looks like it could run for a while if
timeouts happen. I don't know how bad that would be from the top of
my head, but it could have an impact.

Your packet cache hit ratio is extremenly low. Are you running dnsdist
with a packetcache in front of this recursor? Or can you explain it
from the type of queries you are getting?


I see that XPF is enabled between dnsdist and the recursor, which likely 
kills the recursor's packet cache. That might explain the bad 
performance results.

Would you mind sharing your dnsdist configuration as well?


If you are setting up a lab env, I certainly would try to use 4.4 or
4.5 (which is in beta) they both contain performance improvememnts.


And then using the proxy protocol instead of XPF could be a huge 
improvement.


Best regards,
--
Remi Gacogne
PowerDNS.COM BV - https://www.powerdns.com/
___
Pdns-users mailing list
Pdns-users@mailman.powerdns.com
https://mailman.powerdns.com/mailman/listinfo/pdns-users

[Pdns-users] Third Alpha Release of DNSDist 1.6.0

[Remi Gacogne via Pdns-users]

Hi everyone,

We are happy to announce the third alpha release of dnsdist 1.6.0. This
release contains a few fixes for issues reported in the second release
candidate:

- DNS over HTTPS queries with a non-zero ID were not properly handled.
  Very few DoH clients actually send an ID with a value different than
  0 but it does happen and is allowed by RFC 8484. Many thanks to Frank
  Denis for reporting the issue!
- The connect timeout was not used for outgoing TCP connections, and
  the write timeout was used instead.

In addition to these fixes, several improvements were made:

- Reduced memory usage for idle DNS over HTTPS and DNS over TLS
  connections, saving roughly 35 kB per connection.
- Smarter caching of outgoing TCP connections, ability to configure the
  number of concurrent incoming TCP connections per frontend, with more
  metrics.
- Sharding has been enabled in the ring buffers and the packet cache by
  default, leading to better performance in the default configuration.
- TLS renegotiation is now disabled by default, to prevent issues like
  CVE-2021-3449 in the future.

Please see the dnsdist website [1] for the more complete changelog [2]
and the current documentation.

Please send us all feedback and issues you might have via the mailing
list, or in case of a bug, via GitHub [3].

Release tarballs are available on the downloads website [4], and
packages for CentOS 7 and 8, Debian Buster and Ubuntu Bionic and Focal
are available from our repository [5].

With the future 1.6.0 final release, the 1.3.x releases will be EOL and
the 1.4.x releases will go into critical security fixes only mode.

We would also like to take this opportunity to announce that we will
stop supporting systems using 32-bit time. This includes 32-bit Linux
platforms like arm and i386 before kernel version 5.1.

[1]: https://dnsdist.org
[2]: https://dnsdist.org/changelog.html#change-1.6.0-alpha3
[3]: https://github.com/PowerDNS/pdns/issues/new/choose
[4]:
https://downloads.powerdns.com/releases/dnsdist-1.6.0-alpha3.tar.bz2
[5]: https://repo.powerdns.com

Best regards,
-- 
Remi Gacogne
PowerDNS.COM BV - https://www.powerdns.com/


pgpDFfnq882UY.pgp
Description: OpenPGP digital signature
___
Pdns-users mailing list
Pdns-users@mailman.powerdns.com
https://mailman.powerdns.com/mailman/listinfo/pdns-users

[Pdns-users] Second alpha release of dnsdist 1.6.0

[Remi Gacogne via Pdns-users]

Hello everyone,

We are happy to announce the second alpha release of dnsdist 1.6.0.
This release contains mostly fixes for issues reported in the first
release candidate:

- A race condition was found to sometimes occur at startup, making it
  possible for the first TCP connection to happen before the creation
  of TCP workers and lead to a crash.
- Stéphane Bortzmeyer reported many TCP timeouts with the first alpha
  that did not happen with 1.5.x. We unfortunately did not manage to
  reproduce these timeouts, but we spent quite some time expanding the
  coverage of our TCP code, uncovering several bugs in the process.
  Although we unfortunately cannot be sure that the issue experienced by
  Stéphane has been fixed, the resulting code has seen much more
  testing and we have received excellent feedback from other users in
  the meantime, leading to this second alpha candidate. 
- The cache cleaning algorithm did not properly remove expired entries
  from all shards, when more than one shard was used and
  "setCacheCleaningPercentage" set below 100%. This led to a drop in the
  cache efficiency in the long run.
- A null pointer dereference has been found when accessing a dynamic
  BPF block (DynBPF) object in client mode.
- A debug line was not properly removed in the web server code, logging
  a new line for every HTTP query.

In addition to these fixes, Sander Hoentjen contributed several
improvements to allow spoofing answers with multiple records, and Aki
Tuomi introduced automatic conversion to string for several objects in
Lua. Many thanks to them!

Please see the dnsdist website [1] for the more complete changelog [2]
and the current documentation.

Please send us all feedback and issues you might have via the mailing
list, or in case of a bug, via GitHub [3].

The tarball (signature) is available from our download server [4] and
packages for CentOS 7 and 8, Debian Buster and Ubuntu Bionic and Focal
are available from our repository [5].

With the future 1.6.0 final release, the 1.3.x releases will be EOL and
the 1.4.x releases will go into critical security fixes only mode.

We would also like to take this opportunity to announce that we will
stop supporting systems using 32-bit time. This includes 32-bit Linux
platforms like arm and i386 before kernel version 5.1.

[1]: https://dnsdist.org
[2]: https://dnsdist.org/changelog.html#change-1.6.0-alpha2
[3]: https://github.com/PowerDNS/pdns/issues/new/choose
[4]:
https://downloads.powerdns.com/releases/dnsdist-1.6.0-alpha2.tar.bz2
[5]: https://repo.powerdns.com

Best regards,
-- 
Remi Gacogne
PowerDNS.COM BV - https://www.powerdns.com/



pgpUsv0IYBfQ0.pgp
Description: OpenPGP digital signature
___
Pdns-users mailing list
Pdns-users@mailman.powerdns.com
https://mailman.powerdns.com/mailman/listinfo/pdns-users

[Pdns-users] First alpha release of dnsdist 1.6.0

[Remi Gacogne via Pdns-users]

.1.

Finally, we would like to thank the PowerDNS community and all external
contributors for their great work in this release, and in particular
Stephane Bakhos, Georgeto, Matti Hiljanen, Nuitari, Sukhbir Singh and
Mischan Toosarani-Hausberger!

[1]: https://dnsdist.org
[2]: https://dnsdist.org/changelog.html#change-1.6.0-alpha1
[3]: https://github.com/PowerDNS/pdns/issues/new/choose
[4]:
https://downloads.powerdns.com/releases/dnsdist-1.6.0-alpha1.tar.bz2
[5]: https://repo.powerdns.com

Best regards,
-- 
Remi Gacogne
PowerDNS.COM BV - https://www.powerdns.com/


pgpiOOZMB4uHS.pgp
Description: OpenPGP digital signature
___
Pdns-users mailing list
Pdns-users@mailman.powerdns.com
https://mailman.powerdns.com/mailman/listinfo/pdns-users

[Pdns-users] DNSDist 1.5.1 released

[Remi Gacogne via Pdns-users]

Hello everyone,

This release fixes a few issues discovered since 1.5.0:

- the thread handling responses sent from a backend was not stopped when
that backend was removed ;
- getEDNSOptions() would throw an exception for queries with an empty
additional section but records in the answer or authority sections  ;
- SetNegativeAndSOAAction was incorrectly adding EDNS to self-generated
responses when there was no EDNS in the query ;
- building with LLVM11 would generate an error.

It also adds a new command, clearConsoleHistory(), to prevent setups
issuing a very large number of console commands from consuming too much
memory.

Please see the dnsdist website [1] for the more complete changelog [2]
and the current documentation.

Release tarballs are available on the downloads website [3].

Several packages are also available in our repository [4]. Please be
aware that we have enabled a few additional features in our packages,
like DNS over HTTPS, DNS over TLS and DNSTAP support, on distributions
where the required dependencies were available.

[1]: https://dnsdist.org
[2]: https://dnsdist.org/changelog.html#change-1.5.1
[3]: https://downloads.powerdns.com/releases/dnsdist-1.5.1.tar.bz2
[4]: https://repo.powerdns.com

Best regards,
-- 
Remi Gacogne
PowerDNS.COM BV - https://www.powerdns.com/



signature.asc
Description: OpenPGP digital signature
___
Pdns-users mailing list
Pdns-users@mailman.powerdns.com
https://mailman.powerdns.com/mailman/listinfo/pdns-users

Re: [Pdns-users] PowerDNS Recursor build fails on openSUSE Tumbleweed/Factory (gcc 10)

[Remi Gacogne via Pdns-users]

Hi Michael,

On 9/8/20 11:39 AM, Michael Ströder via Pdns-users wrote:

> Currently building PowerDNS Recursor fails building on openSUSE
> Tumbleweed/Factory:
> 
> https://build.opensuse.org/package/live_build_log/home:stroeder:branches:server:dns/pdns-recursor/openSUSE_Tumbleweed/x86_64
> 
> Note that openSUSE Tumbleweed/Factory uses
> 
> gcc version 10.2.1 20200825 [revision
> c0746a1beb1ba073c7981eb09f55b3d993b32e5c] (SUSE Linux)
> 
> As you can see it builds on openSUSE Leap:
> 
> https://build.opensuse.org/package/show/home:stroeder:branches:server:dns/pdns-recursor
> 
> Is this an issue with newer gcc?

It's an issue caused by Boost >= 1.73, see [1]. We should probably
backport that patch, at least to 4.3.x, but we have not done so yet.

[1]: https://github.com/PowerDNS/pdns/pull/9070

Best regards,
-- 
Remi Gacogne
PowerDNS.COM BV - https://www.powerdns.com/



signature.asc
Description: OpenPGP digital signature
___
Pdns-users mailing list
Pdns-users@mailman.powerdns.com
https://mailman.powerdns.com/mailman/listinfo/pdns-users

[Pdns-users] dnsdist 1.5.0 released

[Remi Gacogne via Pdns-users]

://repo.powerdns.com

Best regards,

-- 
Remi Gacogne
PowerDNS.COM BV - https://www.powerdns.com/



signature.asc
Description: OpenPGP digital signature
___
Pdns-users mailing list
Pdns-users@mailman.powerdns.com
https://mailman.powerdns.com/mailman/listinfo/pdns-users

[Pdns-users] Fourth release candidate for dnsdist 1.5.0

[Remi Gacogne via Pdns-users]

Hello everyone,

While we expected the third release candidate for dnsdist 1.5.0 to be
the last one, a race condition that could lead to a crash was discovered
by Tomas Krizek from CZ.NIC with the DNS Shotgun tool, leading to a new
release candidate. This new release candidate has no changes except for
the fix [1] for this issue.

We want to once again thank everyone that contributed to the testing of
the alpha and the first three release candidates! Many thanks to Tomas
in particular this time!

Please see the dnsdist website [2] for the more complete changelog [3]
and the current documentation.

Release tarballs are available on the downloads website [4].

Several packages are also available in our repository [5]. Please be
aware that we have enabled a few additional features in our packages,
like DNS over HTTPS, DNS over TLS and DNSTAP support, on distributions
where the required dependencies were available.

[1]: https://github.com/PowerDNS/pdns/pull/9278
[2]: https://dnsdist.org
[3]: https://dnsdist.org/changelog.html#change-1.5.0rc4
[4]: https://downloads.powerdns.com/releases/dnsdist-1.5.0-rc4.tar.bz2
[5]: https://repo.powerdns.com

Best regards,
-- 
Remi Gacogne
PowerDNS.COM BV - https://www.powerdns.com/





signature.asc
Description: OpenPGP digital signature
___
Pdns-users mailing list
Pdns-users@mailman.powerdns.com
https://mailman.powerdns.com/mailman/listinfo/pdns-users

[Pdns-users] Third release candidate for dnsdist 1.5.0

[Remi Gacogne via Pdns-users]

Hello everyone,

We are very happy to announce the third release candidate of dnsdist
1.5.0. 1.5.0 contains several new exciting features and a few breaking
changes since 1.4.0 that were detailed in the announcement [1] of
alpha1. If you upgrade from 1.4.0, please see the upgrade guide [2] for
more information.
This new release candidate has very few changes since the second release
candidate except an important bug fix in DoH processing, and a few minor
improvements and cleanups:

- DoH processing could stop working if too many responses were processed
at the same time, filling the internal pipe (9211) ;
- compilation was broken on systems that do not define HOST_NAME_MAX
(9127) ;
- the detection of std::string has been enhanced by Rosen Penev (9207,
9213) ;
- optional masks were added to KeyValueLookupKeySourceIP (9144) ;
- an ACL was added to the internal web server (9229) ;
- and finally the sample configuration file was cleaned up to be more
helpful to new installations (9238).

The DoH processing issue was the last pending one we were aware of, so
hopefully this release candidate should be the last one!

We want to once again thank everyone that contributed to the testing of
alpha1 and the first two release candidates!

Please see the dnsdist website [3] for the more complete changelog [4]
and the current documentation.

Release tarballs are available on the downloads website [5].

Several packages are also available in our repository [6]. Please be
aware that we have enabled a few additional features in our packages,
like DNS over HTTPS, DNS over TLS and DNSTAP support, on distributions
where the required dependencies were available.

[1]: https://mailman.powerdns.com/pipermail/dnsdist/2020-March/000799.html
[2]: https://dnsdist.org/upgrade_guide.html#to-1-5-x
[3]: https://dnsdist.org
[4]: https://dnsdist.org/changelog.html#change-1.5.0rc3
[5]: https://downloads.powerdns.com/releases/dnsdist-1.5.0-rc3.tar.bz2
[6]: https://repo.powerdns.com

Best regards,
-- 
Remi Gacogne
PowerDNS.COM BV - https://www.powerdns.com/



signature.asc
Description: OpenPGP digital signature
___
Pdns-users mailing list
Pdns-users@mailman.powerdns.com
https://mailman.powerdns.com/mailman/listinfo/pdns-users

Re: [Pdns-users] why CAP_CHOWN?

[Remi Gacogne via Pdns-users]

Hi Michael,

On 5/16/20 10:43 PM, Michael Ströder via Pdns-users wrote:
> On 5/16/20 10:25 PM, bert hubert wrote:
>> On Sat, May 16, 2020 at 08:42:21PM +0200, Michael Ströder via Pdns-users 
>> wrote:
>>> But I wonder why CAP_CHOWN is set in CapabilityBoundingSet= and
>>> AmbientCapabilities= and I could not find a reason in the git history of
>>> that file.
>>
>> We chown the UNIX domain control socket to the 'setgid' and 'setuid'
>> setting.
>>
>> This is likely why we need CAP_CHOWN.
> 
> It seems to create the control socket just fine because the User= and
> Group= are set:
> 
> srwxr-xr-x 1 pdns pdns 0 May 16 22:39
> /run/pdns-recursor/pdns_recursor.controlsocket=
> 
> Anything more I could test to ensure that it's safe to remove CAP_CHOWN?

As far as I can tell the only call to chown() in the recursor is to
update the ownership of the Unix domain control socket to the value
defined by the "socket-owner" and "socket-group" settings. Therefore I
don't think we need CAP_CHOWN if these are not set (which is the default).

Best regards,
-- 
Remi Gacogne
PowerDNS.COM BV - https://www.powerdns.com/



signature.asc
Description: OpenPGP digital signature
___
Pdns-users mailing list
Pdns-users@mailman.powerdns.com
https://mailman.powerdns.com/mailman/listinfo/pdns-users

Re: [Pdns-users] recursor fail to resolve

[Remi Gacogne via Pdns-users]

On 5/1/20 10:31 PM, Sergio Cesar via Pdns-users wrote:
> Thus the question remains: what do I need to change in the recursor
> configuration to make it work as bind does and resolve even tough it
> looks like an issue at their end?

I don't know how bind does resolve but we are doing the right thing
here, we get a delegation to two NS (mail1.alestra.net.mx. and
dns.alestra.net.mx.) for s-s.mx. from the mx. zone, and both of these
servers fail to respond to the first request we send to them. There is
nothing else to try but return a SERVFAIL. This zone is broken and needs
to be fixed.

Remi

> On 5/1/2020 12:22 PM, Aki Tuomi wrote:
>> Can you try with 'dig' instead? Also the logs seem truncated. Although
>> I'm getting SERVFAIL intermittedly too, which suggests problem at
>> their end. Their servers seem unresponsive sometimes, especially if
>> you try
>>
>> dig s-s.mx @mail2.alestra.net.mx.
>> dig s-s.mx @dns.alestra.net.mx.
>>
>> and wait some time (like 10 seconds) in between.
>>
>> Aki
>>
>>
>>> On 05/01/2020 7:17 PM Sergio Cesar  wrote:
>>>
>>>   root@ns1:~# host s-s.mx
>>> Host s-s.mx not found: 2(SERVFAIL)
>>>
>>> root@ns1:~# cat /var/log/syslog | grep s-s.mx
>>> May  1 09:42:51 ns1 pdns_server[16452]: Remote 216.183.32.162 wants
>>> 's-s/mx.winc.net|A', do = 1, bufsize = 1232 (4096): packetcache MISS
>>> May  1 11:08:43 ns1 pdns_recursor[22995]: 3 [38702/1] question for
>>> 's-s.mx|A' from 216.183.32.182:60383
>>> May  1 11:08:46 ns1 pdns_recursor[22995]: 3 [38702/1] answer to question
>>> 's-s.m |A': 0 answers, 1 additional, took 5 packets, 3106.89 netw ms,
>>> 3110.29 tot ms, 0 throttled, 2 timeouts, 0 tcp connections, rcode=2
>>> May  1 12:14:25 ns1 pdns_recursor[22995]: 3 [39863/1] question for
>>> 's-s.mx|A' from 216.183.32.145:35773
>>> May  1 12:14:28 ns1 pdns_recursor[22995]: 3 [39863/1] answer to question
>>> 's-s.m |A': 0 answers, 0 additional, took 2 packets, 3006.53 netw ms,
>>> 3010.36 tot ms, 0 throttled, 2 timeouts, 0 tcp connections, rcode=2
>>>
>>>
>>> On 5/1/2020 12:12 PM, Aki Tuomi wrote:
>>>> Next step, try to resolve s-s.mx and check your logs. Like
>>>> /var/log/syslog?
>>>>
>>>> Aki
>>>>
>>>>> On 05/01/2020 7:09 PM Sergio Cesar  wrote:
>>>>>
>>>>>    Thank you for the reply.
>>>>>
>>>>> Here it is, not sure what that means.
>>>>> The recursor is running on the same server as the PDNS with a
>>>>> different
>>>>> IP address.  if that makes a difference.
>>>>>
>>>>> root@ns1:~# rec_control trace-regex s-s.mx
>>>>> ok
>>>>> ok
>>>>> ok
>>>>>
>>>>> On 5/1/2020 11:37 AM, Aki Tuomi wrote:
>>>>>>> On 05/01/2020 6:31 PM Sergio P Cesar via Pdns-users
>>>>>>>  wrote:
>>>>>>>
>>>>>>>     I am new with pdns, just installed a resolver 4.3.0-rc2 to
>>>>>>> learn and all
>>>>>>> seems to work but stumbled into an issue I cant resolve.
>>>>>>>
>>>>>>> My mailserver failed to deliver email to a few domains, in
>>>>>>> tracking it I
>>>>>>> found that their DNS will drop the first packet on every new
>>>>>>> query  but
>>>>>>> will respond on a second query ok and every one after that. (5
>>>>>>> minutes
>>>>>>> timeout) it will drop the 1st packet again.
>>>>>>> I was expecting the recursor to query the 2nd and 3rd server in
>>>>>>> their
>>>>>>> list but it does not look like it is doing that.
>>>>>>> It seems like it is caching the failure and does not query again
>>>>>>> at all
>>>>>>> for a while.
>>>>>>> I changed packetcache-servfail-ttl=0 and now it looks like after
>>>>>>> the 3rd
>>>>>>> query attempt it will work as the far end server now respond.
>>>>>>> Not sure this is correct setting  or I will have adverse effect
>>>>>>> setting
>>>>>>> this to 0.
>>>>>>>
>>>>>>> Perhaps I have not set something else that will tell the recursor
>>>>>>> to try
>>>>>>> the next server if the first one fail to respond or send a second
>>>>>>> packet
>>>>>>> or a retry.
>>>>>>> I used bind to test and it gets a response on the first try. I
>>>>>>> did not
>>>>>>> try to trace the packets from a bind query.
>>>>>>>
>>>>>>> Thanks
>>>>>>>
>>>>>>>
>>>>>> Try `rec_control trace-regex domain.com` and post that. Without
>>>>>> censoring the results.
>>>>>>
>>>>>> Aki
>>>
> ___
> Pdns-users mailing list
> Pdns-users@mailman.powerdns.com
> https://mailman.powerdns.com/mailman/listinfo/pdns-users


-- 
Remi Gacogne
PowerDNS.COM BV - https://www.powerdns.com/



signature.asc
Description: OpenPGP digital signature
___
Pdns-users mailing list
Pdns-users@mailman.powerdns.com
https://mailman.powerdns.com/mailman/listinfo/pdns-users

[Pdns-users] First release candidate for dnsdist 1.5.0

[Remi Gacogne via Pdns-users]

Hello everyone,

We are very happy to announce the first release candidate of dnsdist
1.5.0. 1.5.0 contains several new exciting features and a few breaking
changes since 1.4.0 that were detailed in the announcement of alpha1
[1]. If you upgrade from 1.4.0, please see the upgrade guide [2] for
more information.

This new release candidate has very few changes since alpha1:

- a compilation issue on OpenBSD was fixed (8955) ;
- the Lua binding for SuffixMatchNode::remove was added (8956) ;
- a regression introduced in 1.4.0 for DNSCrypt users was fixed (8974,
8976), with our thanks to Frank Denis for reporting the issue and
suggesting ways to fix it ;
- responses received from a backend with the QR bit not set are now
dropped ;
- an option to control the size of the TCP listen queue was added (8994).

We want to once again thank everyone that contributed to the testing of
alpha1!

Please see the dnsdist website [3] for the more complete changelog [4]
and the current documentation.

Release tarballs are available on the downloads website [5].

Several packages are also available in our repository [6]. Please be
aware that we have enabled a few additional features in our packages,
like DNS over HTTPS, DNS over TLS and DNSTAP support, on distributions
where the required dependencies were available.

[1]: https://mailman.powerdns.com/pipermail/dnsdist/2020-March/000799.html
[2]: https://dnsdist.org/upgrade_guide.html#to-1-5-x
[3]: https://dnsdist.org
[4]: https://dnsdist.org/changelog.html#change-1.5.0rc1
[5]: https://downloads.powerdns.com/releases/dnsdist-1.5.0-rc1.tar.bz2
[6]: https://repo.powerdns.com


Best regards,
-- 
Remi Gacogne
PowerDNS.COM BV - https://www.powerdns.com/



signature.asc
Description: OpenPGP digital signature
___
Pdns-users mailing list
Pdns-users@mailman.powerdns.com
https://mailman.powerdns.com/mailman/listinfo/pdns-users

Re: [Pdns-users] servfail-packets>0 but no data in servfail-queries ring buffer

[Remi Gacogne via Pdns-users]

Hi Martin,

On 4/9/20 9:56 AM, Martin Kellermann via Pdns-users wrote:
> I’m facing the fact, that sometimes the servfail-packets counter
> increases and i would debug this and find the reason why PowerDNS sends
> out a „servfail“ packet.
> 
> Actually today the counter increased from 0 to 2 and i don’t know why!
> 
> https://doc.powerdns.com/authoritative/performance.html#servfail-packets
> tells me, that this is due to a database problem.
> 
> https://doc.powerdns.com/authoritative/performance.html#ring-buffers
> tells me that the servfail-queries ring-buffer shows which queries have
> been causing servfails.
> 
> But when i look at this ring-buffer (server:8081/?ring=servfail-queries)
> there are no entries – it’s empty.

At a quick glance the only place in the code where we increase the
'servfail-packets' counter but do not add the offending query to the
'servfail-queries' ring-buffer is when we receive a query for a DNS name
that has an 8-bit byte in it and '8bit-dns' [1] is not set (which is the
default), so I assume that's what you are experiencing.
Note that in that case we also increase the 'corrupt-packets' counter
and place the offending query into the 'remotes-corrupt' ring-buffer, so
you might be able to figure out what query caused this. Be aware however
that there are other cases where we increase 'corrupt-packets' and
insert into 'remotes-corrupt', like a QR or TC bit set in a query, or a
query that we simply could not parse.

[1]: https://docs.powerdns.com/authoritative/settings.html#bit-dns

Best regards,
-- 
Remi Gacogne
PowerDNS.COM BV - https://www.powerdns.com/



signature.asc
Description: OpenPGP digital signature
___
Pdns-users mailing list
Pdns-users@mailman.powerdns.com
https://mailman.powerdns.com/mailman/listinfo/pdns-users

[Pdns-users] First alpha release of dnsdist 1.5.0

[Remi Gacogne via Pdns-users]

bz2


Best regards,
-- 
Remi Gacogne
PowerDNS.COM BV - https://www.powerdns.com/



signature.asc
Description: OpenPGP digital signature
___
Pdns-users mailing list
Pdns-users@mailman.powerdns.com
https://mailman.powerdns.com/mailman/listinfo/pdns-users

Re: [Pdns-users] dns update across dnsdist

[Remi Gacogne via Pdns-users]

On 2/11/20 12:39 PM, Marc Boisis via Pdns-users wrote:
> My dnsdist version is 1.3.3 and authoritative is 4.2.0

Thanks!

> I've found a diff with wireshark, before dnsdist I have just one
> aditional record containing the TSIG
> after dnsdist I have two additional records (TSIG and OPT with client
> subnet)

OK, so it looks like dnsdist is adding an OPT record with an EDNS Client
Subnet (in the wrong place, but that's a known issue that has only been
fixed recently, see [1]).
I'm also surprised that the authoritative server accepts such a DNS
packet where the TSIG record is not the last one, but let's forget that
for now.

> I try "newServer({address='127.0.0.1:5300', pool='auth-update',
> useClientSubnet=false })" or "newServer({address='127.0.0.1:5300',
> pool='auth-update', useClientSubnet=true })" but the result is the same.

Would you mind pasting your whole configuration? dnsdist doesn't add ECS
by default, so something in your configuration must be enabling ECS
addition somehow.

[1]: https://github.com/PowerDNS/pdns/issues/8098

Best regards,
-- 
Remi Gacogne
PowerDNS.COM BV - https://www.powerdns.com/



signature.asc
Description: OpenPGP digital signature
___
Pdns-users mailing list
Pdns-users@mailman.powerdns.com
https://mailman.powerdns.com/mailman/listinfo/pdns-users

Re: [Pdns-users] dns update across dnsdist

[Remi Gacogne via Pdns-users]

Hi Marc,

On 2/10/20 10:42 PM, Marc Boisis via Pdns-users wrote:
> Here is my config:
> [isc-dhcp] dns update>[dnsdist--->pdns authoritative]
> the isc dhcp server(v4.4.2) send a dns update query with a tsig
> key(hmac-md5). (I see it with tcpdump/wireshark).
> When the authoritative get the request, it said : "UPDATE (9470) from
> 127.0.0.1 for my-domain.com: TSIG key required, but packet does not
> contain key. Sending REFUSED"
> 
> my dnsdist config is:
> 
> |newServer({address='127.0.0.1:5300', pool='auth'})
> addAction(OpcodeRule(DNSOpcode.Update), PoolAction("auth") ) |
> 
> my authoritative config:
> 
> |allow-dnsupdate-from=127.0.0.0/8 dnsupdate=yes |
> 
> I miss something  ?

Would you mind sharing the exact versions of dnsdist and PowerDNS
authoritative server you are using?

Did you try capturing the packet leaving dnsdist toward the
authoritative server to confirm that the TSIG key is still there? Your
configuration does not require the addition of EDNS Client Subnet so
dnsdist shouldn't be altering the packet at all, but it would be nice to
know what the authoritative server actually receives.

Best regards,
-- 
Remi Gacogne
PowerDNS.COM BV - https://www.powerdns.com/



signature.asc
Description: OpenPGP digital signature
___
Pdns-users mailing list
Pdns-users@mailman.powerdns.com
https://mailman.powerdns.com/mailman/listinfo/pdns-users

Re: [Pdns-users] pdns-recursor Permissions Error

[Remi Gacogne]

On 1/7/20 2:41 PM, Sharone wrote:
> I apologize if this has been discussed before. I cannot seem to find a
> solution that works at the moment. I am trying to have this server poll
> data but I have the error below when I try to snmpwalk
>  
> * # sudo -u pdns rec_control version4.3.0-beta1.39.master.g0c1ebf7c*
> 
> 
> *# snmpwalk -v2c -c public localhost
> .1.3.6.1.4.1.8072.1.3.2.4.1.2iso.3.6.1.4.1.8072.1.3.2.4.1.2.8.112.100.110.115.45.114.101.99.1
> = STRING: "Fatal: Unable to generate local temporary file in directory
> '/var/run/pdns-recursor': Permission denied"*

I'm not sure of what your SNMP setup is, but it looks like the user
invoking rec_control does not have the rights to create a new file in
/var/run/pdns-recursor. What happens if you invoke the rec_control
command directly as the 'pdns' user?

Best regards,
-- 
Remi Gacogne
PowerDNS.COM BV - https://www.powerdns.com/



signature.asc
Description: OpenPGP digital signature
___
Pdns-users mailing list
Pdns-users@mailman.powerdns.com
https://mailman.powerdns.com/mailman/listinfo/pdns-users

Re: [Pdns-users] recursor is giving conflicting results for /etc/hosts entries

[Remi Gacogne]

Hi Mike,

On 1/4/20 6:39 PM, Mike wrote:

> I hate replying to my own message, but...
> 
>     The culprit was 'dnssec=validate'. Stupid me. Recursor is doing what
> I told it to do, and there's no way for it dnssec validate etc/hosts
> supplied entries.
> 
>     There still is the open question why it seems the first query would
> be responded to with the data in question, perhaps that is some other
> network issue (we anycast our resolvers).
> 
>     The next question would be - is there any way to specify 'dont
> dnssec validate entries loaded from etc/hosts', or perhaps this would be
> a job better suited to a lua script (which I am not up to speed on)?

I believe you are looking for addNTA(), see [1].

[1]: https://docs.powerdns.com/recursor/dnssec.html#negative-trust-anchors

Best regards,
-- 
Remi Gacogne
PowerDNS.COM BV - https://www.powerdns.com/



signature.asc
Description: OpenPGP digital signature
___
Pdns-users mailing list
Pdns-users@mailman.powerdns.com
https://mailman.powerdns.com/mailman/listinfo/pdns-users

Re: [Pdns-users] TLSA problemns

[Remi Gacogne]

Hi,

It might not be related but this domain has some DNSSEC-related issues,
for example the denial for _tcp.mail01.tkservers.com|A is not valid:

https://dnsviz.net/d/_tcp.mail01.tkservers.com/dnssec/

You might need to run pdnsutil rectify-zone 'tkservers.com'.


Best regards,

Remi

On 12/13/19 3:04 PM, steffanno...@gmail.com wrote:
> Yes it is my own.
> I use mysql replication 
> If i test the dns servers it works.
> 
> I also see the difference in the TTL, but the settings are in my dns for 
> several months.
> 
> The reasen why i test 8.8.8.8 is that SIDN uses them to test for tlsa/dane
> And my domains are failing for there test.
> 
> Met vriendelijke groet,
> Steffan Noord 
> 
> -Oorspronkelijk bericht-
> Van: Brian Candler  
> Verzonden: vrijdag 13 december 2019 14:44
> Aan: steffanno...@gmail.com; 'Pdns-users Users' 
> 
> Onderwerp: Re: [Pdns-users] TLSA problemns
> 
> On 13/12/2019 13:23, steffanno...@gmail.com wrote:
>> I have a strange problem.
>> When i do a:
>> dig _25._tcp.mail01.tkservers.com tlsa @8.8.8.8
>>
>> om getting sometimes a NOERROR and sometimes a NXDOMAIN
>>
>> When i change the 8.8.8.8 to my dns servers that it works fine.
>> When i use 1.1.1.1  it works fine
>>
>> Any idees why Google gives a NXDOMAIN randomly?
> 
> 8.8.8.8 will be a big anycast pool of caches, and you may hit a different one 
> with each query.  Other providers might have "sticky" load balancing.  Notice 
> how the TTL bounces up and down here:
> 
> $ dig @8.8.8.8 powerdns.com | grep '^powerdns\.com'
> powerdns.com.3599INA188.166.104.92 $ dig @8.8.8.8 
> powerdns.com | grep '^powerdns\.com'
> powerdns.com.3599INA188.166.104.92 $ dig @8.8.8.8 
> powerdns.com | grep '^powerdns\.com'
> powerdns.com.1227INA188.166.104.92 $ dig @8.8.8.8 
> powerdns.com | grep '^powerdns\.com'
> powerdns.com.3026INA188.166.104.92 $ dig @8.8.8.8 
> powerdns.com | grep '^powerdns\.com'
> powerdns.com.3595INA188.166.104.92
> 
> Is tkservers.com your own domain?
> 
> You would need to dig into the details, but there are a whole bunch of 
> possible reasons, most likely due to misconfiguration of tkservers.com 
> authoritative DNS.  Examples:
> 
> - synchronization problem between master and slaves
> - NS records in the delegation are different to the NS records in the zone
> 
> Or it could just be a temporary anomaly due to TTL expiring after a change, 
> and will eventually become consistent.
> 
> ___
> Pdns-users mailing list
> Pdns-users@mailman.powerdns.com
> https://mailman.powerdns.com/mailman/listinfo/pdns-users
> 


-- 
Remi Gacogne
PowerDNS.COM BV - https://www.powerdns.com/



signature.asc
Description: OpenPGP digital signature
___
Pdns-users mailing list
Pdns-users@mailman.powerdns.com
https://mailman.powerdns.com/mailman/listinfo/pdns-users

[Pdns-users] dnsdist 1.4.0 released

[Remi Gacogne]

Hello everyone,

After five release candidates, we are thrilled to finally announce the
release of dnsdist 1.4.0 !

This new major version has been used in production by several large
operators since the first release candidate, including the new DNS over
HTTPS feature, providing invaluable feedback.

This release has very few changes since the previous release candidate:
- names blocked by a SMT dynamic block are now lowercased ;
- we went back to selecting the cipher suites based on the server
preference instead of the client by default ;
- some typo, documentation and help messages have been fixed.

For those new to the 1.4.0 train, the main changes between 1.3.3 and
1.4.0 are:
- a new, much more scalable way of handling DNS over TCP and DNS over
TLS connections, with a lot of new metrics and options like OCSP stapling ;
- support for DNS over HTTPS ;
- a new experimental feature, the ability to look into a Key-Value store
like CDB or LMDB and to route a query based on the result of this lookup ;
- new rules and actions to deal with unexpected EDNS version (Dmitry
Alenichev) ;
- a new QNameSetRule rule, along with the DNSNameSet object, to match
exact qnames instead of doing suffix matching (Andrey Domas) ;
- a new ContinueAction has been added as well, allowing to keep
processing rules even after calling a normally terminal action, like
PoolAction ;
- we also added a few convenience functions to pseudonymize IP
addresses, as several users reported that they needed it to be
GDPR-compliant ;
- the health check mechanism has been improved with the new
checkInterval, checkTimeout and rise parameters, thanks notably to “1848” ;
- and, finally, we also improved the existing LogAction to make it much
more useful for debugging and accounting purposes.

Please see the upgrade guide [1] before upgrading from 1.3.x to 1.4.0,
as a few things have been cleaned up and might require updating your
existing configuration.

We want to once again thank everyone that contributed to the testing of
the previous release candidates!

Please see the dnsdist website [2] for the more complete changelog [3]
and the current documentation.

Release tarballs are available on the downloads website [4].

Several packages are also available in our repository [5].

[1]: https://dnsdist.org/upgrade_guide.html#x-to-1-4-0
[2]: https://dnsdist.org
[3]: https://dnsdist.org/changelog.html#change-1.4.0
[4]: https://downloads.powerdns.com/releases/dnsdist-1.4.0.tar.bz2
[5]: https://repo.powerdns.com/

Best regards,
-- 
Remi Gacogne
PowerDNS.COM BV - https://www.powerdns.com/



signature.asc
Description: OpenPGP digital signature
___
Pdns-users mailing list
Pdns-users@mailman.powerdns.com
https://mailman.powerdns.com/mailman/listinfo/pdns-users

[Pdns-users] dnsdist 1.4.0-rc5 released

[Remi Gacogne]

Hello everyone,

We are happy to announce the fifth release candidate of the 1.4.0
version of dnsdist. This release fixes a regression introduced in DNS
over HTTPS handling in 1.4.0-rc4 that could lead to a crash under heavy
load, because of a race condition.

The issue was reported during load-testing by one of our users a few
hours after the release and we were able to issue a fix [1] during the
week-end. We quickly advised DNS over HTTPS users to delay upgrading for
a bit, and after exposing the resulting code to various tests during a
couple days we are now confident that the issue has been resolved.

We want to thank everyone that contributed to the testing of the
previous release candidates, and invite you to contribute to the testing
of this hopefully last one!

Please see the dnsdist website [2] for the more complete changelog [3]
and the current documentation.

Release tarballs [4] are available on the downloads website.

Several packages are also available on our repository [5].

[1]: https://github.com/PowerDNS/pdns/pull/8471
[2]: https://dnsdist.org
[3]: https://dnsdist.org/changelog.html#change-1.4.0-rc5
[4]: https://downloads.powerdns.com/releases/dnsdist-1.4.0-rc5.tar.bz2
[5]: https://repo.powerdns.com/

Best regards,
-- 
Remi Gacogne
PowerDNS.COM BV - https://www.powerdns.com/



signature.asc
Description: OpenPGP digital signature
___
Pdns-users mailing list
Pdns-users@mailman.powerdns.com
https://mailman.powerdns.com/mailman/listinfo/pdns-users

[Pdns-users] Fourth release candidate for dnsdist 1.4.0

[Remi Gacogne]

Hello everyone,

We are very happy to announce the fourth release candidate of the 1.4.0
version of dnsdist. Unless a serious issue is discovered, we plan on
releasing the final 1.4.0 release in a couple of weeks with no or very
few changes from this release.

This version massively improves the metrics available regarding TLS
usage and errors for DNS over HTTPS and DNS over TLS clients, as
suggested by several large deployments.

It also fixes several minor issues, and improves the existing LogAction
to make it much more useful for debugging and accounting purposes.

We want to thank everyone that contributed to the testing of the
previous release candidates, and invite you to contribute to the testing
of this hopefully last one!

Please see the dnsdist website [1] for the more complete changelog [2]
and the current documentation.

Release tarballs [3] are available on the downloads website.

Several packages are also available on our repository [4].


[1]: https://dnsdist.org
[2]: https://dnsdist.org/changelog.html#change-1.4.0-rc4
[3]: https://downloads.powerdns.com/releases/dnsdist-1.4.0-rc4.tar.bz2
[4]: https://repo.powerdns.com/

-- 
Remi Gacogne
PowerDNS.COM BV - https://www.powerdns.com/



signature.asc
Description: OpenPGP digital signature
___
Pdns-users mailing list
Pdns-users@mailman.powerdns.com
https://mailman.powerdns.com/mailman/listinfo/pdns-users

[Pdns-users] Third release candidate for dnsdist 1.4.0

[Remi Gacogne]

Hello everyone,

We are very happy to announce the third, and hopefully last, release
candidate of the 1.4.0 version of dnsdist.

This version adds the ability to accept DNS over HTTPS queries over
HTTP, in order to be able to use dnsdist behind a TLS-offloading device,
and improves the management of TLS session ticket keys for DNS over HTTPS.
It also fixes several minor issues, and improves the DoH-related metrics
in our prometheus export.

We want to thank everyone that contributed to the testing of the beta
release, and invite you to contribute to the testing of this release
candidate!

Please see the dnsdist website [1] for the more complete changelog [2]
and the current documentation.

Release tarballs [3] are available on the downloads website.

Several packages are also available on our repository [4].


[1]: https://dnsdist.org
[2]: https://dnsdist.org/changelog.html#change-1.4.0-rc3
[3]: https://downloads.powerdns.com/releases/dnsdist-1.4.0-rc3.tar.bz2
[4]: https://repo.powerdns.com/

Best regards,
-- 
Remi Gacogne
PowerDNS.COM BV - https://www.powerdns.com/



signature.asc
Description: OpenPGP digital signature
___
Pdns-users mailing list
Pdns-users@mailman.powerdns.com
https://mailman.powerdns.com/mailman/listinfo/pdns-users

Re: [Pdns-users] DNSDist checkInterval qustion

[Remi Gacogne]

Hi,

On 9/18/19 11:56 AM, Pedro David Marco via Pdns-users wrote:
> I have changed the checkInterval parameter to 30 but DNSDist keeps
> cheking servers every 1 second (the default value).  
> 
> I have set it this way:
> 
> newServer({address="192.168.3.183", order=1, checkInterval=30})
> 
> do i have to do anything else to set the interval checks time?

First of all dnsdist has its own mailing-list at [1], which is better
suited to these questions.

Then please note that checkInterval was introduced in 1.4.0, so it won't
be applied if you are currently using 1.3.x or older.


[1]: https://mailman.powerdns.com/mailman/listinfo/dnsdist

Best regards,
-- 
Remi Gacogne
PowerDNS.COM BV - https://www.powerdns.com/



signature.asc
Description: OpenPGP digital signature
___
Pdns-users mailing list
Pdns-users@mailman.powerdns.com
https://mailman.powerdns.com/mailman/listinfo/pdns-users

Re: [Pdns-users] DNSdist cache question

[Remi Gacogne]

Hi,

On 9/17/19 8:38 PM, Pedro David Marco via Pdns-users wrote:
> i am new with DNSdist and it works like a charm... what a great software!  
> 
> i have a doubt about its cache:
> 
> I have set parameters newPacketCache with 86400, 0, 60,  60, true     
> 
> The cache seems to work OK but it seems TTL is only some seconds. After
> this time, it seems a query about a host that some seconds ago was in
> the cache is "asked to the Internet" insted to the cache.
> 
> Any idea why?

It's hard to tell what's going on without observing the actual query and
answer, but please note that dnsdist only caps the existing TTL, so it
won't cache an answer for longer than the TTL returned by the backend.

Best regards,

Remi



___
Pdns-users mailing list
Pdns-users@mailman.powerdns.com
https://mailman.powerdns.com/mailman/listinfo/pdns-users

[Pdns-users] Second release candidate for dnsdist 1.4.0

[Remi Gacogne]

Hello everyone,

We are very happy to announce the second release candidate of the 1.4.0
version of dnsdist.

This version adds one experimental feature, the ability to look into a
Key-Value store like CDB or LMDB and to route a query based on the
result of this lookup.
It also makes it possible to require a minimum TLS version for DNS over
TLS and DNS over HTTPS, and to send custom HTTP responses even for
queries received on the DoH port that are valid HTTP queries but not
necessarily valid DoH queries.

Note that starting with 1.4.0-rc2, our packages are now built against
the latest 2.2.6 version of libh2o, fixing several remote denial of
service issues (CVE-2019-9512, CVE-2019-9514 and CVE-2019-9515).

We want to thank everyone that contributed to the testing of the beta
release, and invite you to contribute to the testing of this release
candidate!

Please see the dnsdist website [1] for the more complete changelog [2]
and the current documentation.

Release tarballs [3] are available on the downloads website.

Several packages are also available on our repository [4].


[1]: https://dnsdist.org
[2]: https://dnsdist.org/changelog.html#change-1.4.0-rc2
[3]: https://downloads.powerdns.com/releases/dnsdist-1.4.0-rc2.tar.bz2
[4]: https://repo.powerdns.com/

Best regards,

-- 
Remi Gacogne
PowerDNS.COM BV - https://www.powerdns.com/



signature.asc
Description: OpenPGP digital signature
___
Pdns-users mailing list
Pdns-users@mailman.powerdns.com
https://mailman.powerdns.com/mailman/listinfo/pdns-users

[Pdns-users] First release candidate for dnsdist 1.4.0

[Remi Gacogne]

Hello everyone,

We are proud to announce the first release candidate of the 1.4.0
version of dnsdist. 1.4.0 brings a much more scalable way of handling
DNS over TCP and DNS over TLS connections since the first alpha release.
A major new feature since alpha2, and marquee feature of 1.4.0 compared
to 1.3.x, is the new DNS-over-HTTPS functionality.

Following a round of testing from several large scale users, this
version fixes several issues, most of them related to DNS over HTTPS
(7894, 7917, 7927, 8112), DNS over TCP (7974, 7979, 8003, 8030, 8067,
8078, 8079, 8113), or both (7915).

In addition to minor improvements, it also introduces several new features:
- a new ContinueAction allowing to keep processing rules even after
calling a normally terminal action, like PoolAction (8117)
- OCSP stapling for DNS over TLS and DNS over HTTPS (8141) ;
- custom HTTP headers for DNS over HTTPS responses (contributed by
Melissa Voegeli, 8148)
- actions, rules and Lua binding to interact with DoH queries and
generate DoH responses from dnsdist (8153).

We want to thank everyone that contributed to the testing of the beta
release, and invite you to contribute to the testing of this release
candidate!

Please see the dnsdist website [1] for the more complete changelog [2]
and the current documentation.

Release tarballs [3] are available on the downloads website.

Several packages are also available on our repository [4].


[1]: https://dnsdist.org
[2]: https://dnsdist.org/changelog.html#change-1.4.0-rc1
[3]: https://downloads.powerdns.com/releases/dnsdist-1.4.0-rc1.tar.bz2
[4]: https://repo.powerdns.com/

Best regards,
-- 
Remi Gacogne
PowerDNS.COM BV - https://www.powerdns.com/



signature.asc
Description: OpenPGP digital signature
___
Pdns-users mailing list
Pdns-users@mailman.powerdns.com
https://mailman.powerdns.com/mailman/listinfo/pdns-users

Re: [Pdns-users] dnsdist failed to compile on SmartOS

[Remi Gacogne]

Hi Stephan,

On 8/2/19 2:07 PM, qutic development wrote:
> the maintainer of pkgsrc tried to compile dnsdist v1.3.2, but if failed [1] 
> with:
> 
> error: cannot convert 'boost::logic::tribool' to 'bool' in return
> 
> Do anybody has an idea how to fix this?

This was fixed in 1.3.3 by [1], perhaps you could switch to 1.3.3?
Otherwise, if you really need to stick to 1.3.2, you could apply this
patch [2].

[1]: https://github.com/PowerDNS/pdns/pull/7092
[2]:
https://github.com/PowerDNS/pdns/commit/d7a263770fea869e058e34c96d1319e30659feb9.patch


Best regards,
-- 
Remi Gacogne
PowerDNS.COM BV - https://www.powerdns.com/



signature.asc
Description: OpenPGP digital signature
___
Pdns-users mailing list
Pdns-users@mailman.powerdns.com
https://mailman.powerdns.com/mailman/listinfo/pdns-users

Re: [Pdns-users] What is required for the dnsdist testCrypto() function to work?

[Remi Gacogne]

Hi,

On 7/4/19 12:47 PM, sth...@nethelp.no wrote:
> should I expect the testCrypto() function to work? Because it doesn't:
[...]
>> testCrypto()
> Crypto failed..

This error message is indeed not helpful at all.. I'm pretty sure it
just means that have not configured a session key with setKey(), since
this function mostly tests that the encryption between a console client
and dnsdist works, and is not related at all to TLS. It made sense
between the addition of DoT and DoH, but I agree it's quite misleading
nowadays.

> The reason for asking about the testCrypto() function is that I'm
> trying to get DoT working, so far without success.

It's completely unrelated to testCrypto(), could you paste your
configuration and explain what doesn't work?


Please be aware that dnsdist has its own mailing-list, by the way :-)

Best regards,
-- 
Remi Gacogne
PowerDNS.COM BV - https://www.powerdns.com/



signature.asc
Description: OpenPGP digital signature
___
Pdns-users mailing list
Pdns-users@mailman.powerdns.com
https://mailman.powerdns.com/mailman/listinfo/pdns-users

Re: [Pdns-users] specfic problem with efax.com

[Remi Gacogne]

On 6/20/19 4:01 PM, Mike wrote:
> I think you got it - the AA bit isn't set, so they are going to be
> failing lots of places. I noticed however that googledns didn't seem to
> have a problem with it. Wondering if this 'relaxed functionality' is
> just suicidal on google's part or perhaps a future enhancement possibility?

We used to try hard to be forgiving but this led to several issues,
especially when DNSSEC was involved, so we tend to be more strict with
regard to clear protocol violations.

Best regards,
-- 
Remi Gacogne
PowerDNS.COM BV - https://www.powerdns.com/



signature.asc
Description: OpenPGP digital signature
___
Pdns-users mailing list
Pdns-users@mailman.powerdns.com
https://mailman.powerdns.com/mailman/listinfo/pdns-users

Re: [Pdns-users] specfic problem with efax.com

[Remi Gacogne]

Hi Mike,

On 6/20/19 7:20 AM, Mike wrote:
>     I noticed tonight that resolving for 'efax.com' is failing and my
> resolvers (pdns_recursor) are returning 'servfail' while google dns is
> returing the data.
> 
> 
>     The specfic error I notice seems to be:
> 
>     Removing record 'inbound.efax.com|A|204.11.168.109' in the answer
> section without the AA bit set received from efax.com
> 
>     I am attaching a regex trace for 'efax' so you can see what I see. I
> guess my question here is this an efax.com problem or something I should
> try to work around with settings at my resolver?

All three servers authoritative for efax.com reply to queries for
efax.com or inbound.efax.com without the AA bit set, which is not valid.
IMHO this needs to be fixed on efax.com's side.

Best regards,
-- 
Remi Gacogne
PowerDNS.COM BV - https://www.powerdns.com/



signature.asc
Description: OpenPGP digital signature
___
Pdns-users mailing list
Pdns-users@mailman.powerdns.com
https://mailman.powerdns.com/mailman/listinfo/pdns-users

[Pdns-users] dnsdist 1.4.0-beta1 released

[Remi Gacogne]

Hello everyone,

We are very happy to announce the first beta release of the 1.4.0
version of dnsdist. This version fixes a crash in the DNS over HTTPS
(DoH) implementation and adds a new rule to route queries based on the
incoming TLS Server Name Indication (SNI) value. It also adds latency
histograms to the Prometheus export, courtesy of Marlin Cremers.

As with the alpha releases, your feedback will be much appreciated so we
can deliver a stable 1.4.0 final release!

Please see the dnsdist website [1] for the more complete changelog [2]
and the current documentation.

Release tarballs are available on the downloads website [3].

Several packages are also available on our repository [4].


[1]: https://dnsdist.org
[2]: https://dnsdist.org/changelog.html#change-1.4.0-beta1
[3]: https://downloads.powerdns.com/releases/dnsdist-1.4.0-beta1.tar.bz2
[4]: https://repo.powerdns.com/

Best regards,
-- 
Remi Gacogne
PowerDNS.COM BV - https://www.powerdns.com/




signature.asc
Description: OpenPGP digital signature
___
Pdns-users mailing list
Pdns-users@mailman.powerdns.com
https://mailman.powerdns.com/mailman/listinfo/pdns-users

Re: [Pdns-users] Recursor : Lua & udpQueryResponse questions

[Remi Gacogne]

Hi David,

> 1/ what is the timeout of a "udpQueryResponse" call via 
> dq.followUpFunction ? is there any relationship with the 
> "network-timeout" parameter ?

Yes, 'network-timeout' is applied there as well.

> 2/ my answer is a CNAME (with the FQDN found) with a specific TTL 
> ("cnameTTL=345600") and with a followCNAMERecords follow-up function 
> : dq:addAnswer(pdns.CNAME, dq.udpAnswer, cnameTTL) dq.rcode = 0 
> dq.followupFunction="followCNAMERecords"
> 
> But it seems that the response is only cached in the Packet Cache, 
> because 1 hour after the first udp server call, the resolver
> executes the udp server call again, and 1H is my default
> "packetcache-ttl" value. Maybe it's the wanted behaviour because I
> use the "nxdomain" hook ?

There are two different parts here, the CNAME that you craft via
dq:addAnswer(), and the target of that CNAME which is retrieved via
followCNAMERecords.
The first part will not be inserted into the record cache because it
does not came from an authoritative server and thus does not go through
the regular path.
The second one, the target of the CNAME, will be retrieved via the
normal resolution process and will therefore be inserted into the record
cache.
The final response will indeed be inserted into the packet cache.

> Is there an implementation that may put my answer in the Record Cache
> (with respect of my TTL) ?

I'm afraid we currently don't provide a way to interact with the record
cache from Lua, so I don't think it's possible.


Best regards,
-- 
Remi Gacogne
PowerDNS.COM BV - https://www.powerdns.com/



signature.asc
Description: OpenPGP digital signature
___
Pdns-users mailing list
Pdns-users@mailman.powerdns.com
https://mailman.powerdns.com/mailman/listinfo/pdns-users

[Pdns-users] dnsdist 1.4.0-alpha2 with DNS over HTTPS support released

[Remi Gacogne]

Hello everyone,

We are very happy to announce the second alpha release of the 1.4.0
version of dnsdist. This version keeps up the DNS privacy improvements
with the addition of a new major feature, DNS over HTTPS (DoH), and
contains very few changes apart from that.

As with the first alpha, your feedback will be much appreciated so we
can deliver a stable 1.4.0 final release!

Please see the dnsdist website [1] for the more complete changelog [2]
and the current documentation.

Release tarballs are available on the downloads website [3].

Several packages are also available on our repository [4].


[1]: https://dnsdist.org
[2]: https://dnsdist.org/changelog.html#change-1.4.0-alpha2
[3]: https://downloads.powerdns.com/releases/dnsdist-1.4.0-alpha2.tar.bz2
[4]: https://repo.powerdns.com/

Best regards,
-- 
Remi Gacogne
PowerDNS.COM BV - https://www.powerdns.com/



signature.asc
Description: OpenPGP digital signature
___
Pdns-users mailing list
Pdns-users@mailman.powerdns.com
https://mailman.powerdns.com/mailman/listinfo/pdns-users

Re: [Pdns-users] AXFR error using dnsdist

[Remi Gacogne]

Hi Marc,

On 4/25/19 8:24 PM, Marc Wijtkamp via Pdns-users wrote:
> setLocal('192.168.1.1')
[...]
> newServer({address='192.168.1.1', name='master', pool={'master'}})
[...]
> addAction(OrRule({QTypeRule(dnsdist.SOA), QTypeRule(dnsdist.AXFR),
> QTypeRule(dnsdist.IXFR)}), PoolAction('master'))

Am I missing something or are you routing AXFR and IXFR queries to
dnsdist itself, resulting in a loop?

Best regards,
-- 
Remi Gacogne
PowerDNS.COM BV - https://www.powerdns.com/



signature.asc
Description: OpenPGP digital signature
___
Pdns-users mailing list
Pdns-users@mailman.powerdns.com
https://mailman.powerdns.com/mailman/listinfo/pdns-users

Re: [Pdns-users] {Content?} Re: Recursor reply SRVFAIL from the first NS server and does not try other NS servers

[Remi Gacogne]

On 4/9/19 11:07 AM, Mohamad F. Barham wrote:
> this domain get resolved fine now from here, but the thing how can I
> test that my recursor is trying all NS servers specially when the first
> one is down, and not to reply with timeout while didnt check other NS
> servers.

Looking at the trace would tell you exactly that.

Best regards,

Remi

> 
> *From:* Pdns-users  on behalf
> of Remi Gacogne 
> *Sent:* Tuesday, April 9, 2019 11:14:02 AM
> *To:* pdns-users@mailman.powerdns.com
> *Subject:* {Content?} Re: [Pdns-users] Recursor reply SRVFAIL from the
> first NS server and does not try other NS servers
>  
> 
> Hi Mohamad,
> 
> Would you mind providing a trace, either by starting the recursor with
> --trace, which is very verbose, or by using:
> 
>  rec_control trace-regex safariaquapark.com
> 
> To enable tracing for this domain only. You can revert that later with
> 
>  rec_control trace-regex ''
> 
> In my own tests the recursor does try all NSs, but it looks like queries
> to ns1.i-net.ps and ns4.i-net.ps end up as timeout most of the time, at
> least from here.
> 
> Best regards,
> 
> Remi
> 
> On 4/9/19 8:42 AM, Mohamad F. Barham wrote:
>> I'm using 
>> 
>> PowerDNS Recursor 4.1.12
>> 
>> Using 64-bits mode. Built using gcc 4.8.5 20150623 (Red Hat 4.8.5-28) 
>> 
>> 
>> 
>> __ __
>> 
>> cid:image002.png@01D327F4.25E9A910
>> 
>>    
>> 
>> *Mohamad Barham__*
>> 
>> System administrator | Information Technology Department
>> 
>> Birzeit University
>> 
>> P.O.Box. 14, Birzeit, Palestine
>> 
>> Tel: + 970 22982012 | Mob: +970 597 861929 | Ext: 5616
>> 
>> mbar...@birzeit.edu | www.birzeit.edu <http://www.birzeit.edu/>
>> 
>> 
>>    
>> 
>> 
>> 
>> *From:* bert hubert 
>> *Sent:* Monday, April 8, 2019 2:13:12 PM
>> *To:* Mohamad F. Barham
>> *Cc:* pdns-users@mailman.powerdns.com
>> *Subject:* Re: [Pdns-users] Recursor reply SRVFAIL from the first NS
>> server and does not try other NS servers
>>  
>> On Mon, Apr 08, 2019 at 10:53:24AM +, Mohamad F. Barham wrote:
>>> I have pdns-recursor running on the campus, and I have issue with NS 
>>> servers :
>> 
>> Hi Mohamad,
>> 
>> Before we can investigate, which exact version of the PowerDNS Recursor are
>> you running? Do you run with any Lua scripts?
>> 
>>     Bert
>> 
>> ~~
>> The information contained in this communication is intended solely for
>> the use of the individual or entity to whom it is addressed and others
>> authorized to receive it. It may contain confidential or legally
>> privileged information. If you are not the intended recipient you are
>> hereby notified that any disclosure, copying, distribution or taking any
>> action in reliance on the contents of this information is strictly
>> prohibited and may be unlawful. If you have received this communication
>> in error, please notify us immediately by responding to this email and
>> then delete it from your system. The University is neither liable for
>> the proper and complete transmission of the information contained in
>> this communication nor for any delay in its receipt.
>> ~~
>> 
>> ___
>> Pdns-users mailing list
>> Pdns-users@mailman.powerdns.com
>> https://mailman.powerdns.com/mailman/listinfo/pdns-users
>> 
> 
> 
> -- 
> Remi Gacogne
> PowerDNS.COM BV - https://www.powerdns.com/
> 
> ~~
> The information contained in this communication is intended solely for
> the use of the individual or entity to whom it is addressed and others
> authorized to receive it. It may contain confidential or legally
> privileged information. If you are not the intended recipient you are
> hereby notified that any disclosure, copying, distribution or taking any
> action in reliance on the contents of this information is strictly
> prohibited and may be unlawful. If you have received this communication
> in error, please notify us immediately by responding to this email and
> then delete it from your system. The University is neither liable for
> the proper and complete transmission of the information contained in
> this communication nor for any delay in its receipt.
> ~~


-- 
Remi Gacogne
PowerDNS.COM BV - https://www.powerdns.com/



signature.asc
Description: OpenPGP digital signature
___
Pdns-users mailing list
Pdns-users@mailman.powerdns.com
https://mailman.powerdns.com/mailman/listinfo/pdns-users

Re: [Pdns-users] Recursor reply SRVFAIL from the first NS server and does not try other NS servers

[Remi Gacogne]

Hi Mohamad,

Would you mind providing a trace, either by starting the recursor with
--trace, which is very verbose, or by using:

 rec_control trace-regex safariaquapark.com

To enable tracing for this domain only. You can revert that later with

 rec_control trace-regex ''

In my own tests the recursor does try all NSs, but it looks like queries
to ns1.i-net.ps and ns4.i-net.ps end up as timeout most of the time, at
least from here.

Best regards,

Remi

On 4/9/19 8:42 AM, Mohamad F. Barham wrote:
> I'm using 
> 
> PowerDNS Recursor 4.1.12
> 
> Using 64-bits mode. Built using gcc 4.8.5 20150623 (Red Hat 4.8.5-28) 
> 
> 
> 
> __ __
> 
> cid:image002.png@01D327F4.25E9A910
> 
>   
> 
> *Mohamad Barham__*
> 
> System administrator | Information Technology Department
> 
> Birzeit University
> 
> P.O.Box. 14, Birzeit, Palestine
> 
> Tel: + 970 22982012 | Mob: +970 597 861929 | Ext: 5616
> 
> mbar...@birzeit.edu | www.birzeit.edu <http://www.birzeit.edu/>
> 
> 
>   
> 
> 
> 
> *From:* bert hubert 
> *Sent:* Monday, April 8, 2019 2:13:12 PM
> *To:* Mohamad F. Barham
> *Cc:* pdns-users@mailman.powerdns.com
> *Subject:* Re: [Pdns-users] Recursor reply SRVFAIL from the first NS
> server and does not try other NS servers
>  
> On Mon, Apr 08, 2019 at 10:53:24AM +, Mohamad F. Barham wrote:
>> I have pdns-recursor running on the campus, and I have issue with NS servers 
>> :
> 
> Hi Mohamad,
> 
> Before we can investigate, which exact version of the PowerDNS Recursor are
> you running? Do you run with any Lua scripts?
> 
>     Bert
> 
> ~~
> The information contained in this communication is intended solely for
> the use of the individual or entity to whom it is addressed and others
> authorized to receive it. It may contain confidential or legally
> privileged information. If you are not the intended recipient you are
> hereby notified that any disclosure, copying, distribution or taking any
> action in reliance on the contents of this information is strictly
> prohibited and may be unlawful. If you have received this communication
> in error, please notify us immediately by responding to this email and
> then delete it from your system. The University is neither liable for
> the proper and complete transmission of the information contained in
> this communication nor for any delay in its receipt.
> ~~~~~~
> 
> ___
> Pdns-users mailing list
> Pdns-users@mailman.powerdns.com
> https://mailman.powerdns.com/mailman/listinfo/pdns-users
> 


-- 
Remi Gacogne
PowerDNS.COM BV - https://www.powerdns.com/



signature.asc
Description: OpenPGP digital signature
___
Pdns-users mailing list
Pdns-users@mailman.powerdns.com
https://mailman.powerdns.com/mailman/listinfo/pdns-users

Re: [Pdns-users] PDNS-Recursor cache and forwarding-all-queries

[Remi Gacogne]

> On 07.03.19 10:48, Pedro David Marco via Pdns-users wrote:
>> is it possible with PDNS-Recursor to forward "all queries" to another
>> server???   in this scenario, does it queries its own cache before
>> forwarding the query?

First of all, why would you want to do that? If you want to forward
everything to another server with some caching, please have a look at
dnsdist instead.

Best regards,
-- 
Remi Gacogne
PowerDNS.COM BV - https://www.powerdns.com/



signature.asc
Description: OpenPGP digital signature
___
Pdns-users mailing list
Pdns-users@mailman.powerdns.com
https://mailman.powerdns.com/mailman/listinfo/pdns-users

Re: [Pdns-users] PDNS recursor dnssec settings

[Remi Gacogne]

Hi,

On 3/5/19 7:25 AM, 葉科貝 wrote:
> I'm testing new version pdns-recursor-4.2.0-0.alpha1.1 .
> 
> I set dnssec use mod process.
> 
> When I query a record without ad or do flag, I receive the message
> "Answer to host.com.tw|A for 210.59.165.80:59977 validates as Bogus" .
> 
> Under the mode process, isn't this verification done?
> 
> Is my understanding wrong?

dig does set the AD flag by default, which leads to unexpected results.
Would you mind trying with +noad, ie:

dig host.com.tw  @103.17.10.61 -p 5301 +noad

For more information please have a look at
https://doc.powerdns.com/recursor/dnssec.html#what-when if you haven't
done so already.

Best regards,
-- 
Remi Gacogne
PowerDNS.COM BV - https://www.powerdns.com/



signature.asc
Description: OpenPGP digital signature
___
Pdns-users mailing list
Pdns-users@mailman.powerdns.com
https://mailman.powerdns.com/mailman/listinfo/pdns-users

Re: [Pdns-users] DNS UPDATE failing (Failed PreReqqisites check)

[Remi Gacogne]

Hi,

On 2/4/19 11:11 AM, MRob wrote:

> Version is 4.0.0-alpha2 from repo where nothing newer available. Would
> it be productive to use repo supplied by powerdns.com, I mean is it
> possible a bug is in this version and has been fixed. 

Please start by upgrading to 4.1.6, yes. The alpha release shipped by
Ubuntu is broken in many ways and should not be used by anyone.

Best regards,
-- 
Remi Gacogne
PowerDNS.COM BV - https://www.powerdns.com/



signature.asc
Description: OpenPGP digital signature
___
Pdns-users mailing list
Pdns-users@mailman.powerdns.com
https://mailman.powerdns.com/mailman/listinfo/pdns-users

Re: [Pdns-users] pdns_recursor and records in additional section of replies

[Remi Gacogne]

On 1/23/19 2:08 PM, Thomas Mieslinger wrote:
> Lets take the output of
> 
> dig +dnssec  ns-de.ui-dns.de @a.nic.de
> 
> as an example. If the additional section was tweaked, pdns_recursor has
> no real chance to detect this.

That's actually a very good example because unless I'm mistaken, every
single one NS in the set requires a glue to be usable.

> Asking all other authoritative servers from the authority section is
> already done if I interpret the output of rec_control trace-regex
> correctly. A well prepared attacker should be able to tweak the
> additional section of the other delegating nameservers too, so that an
> attacked pdns_recursor ends up with something other than
> ns-de.ui-dns.de.    A 217.160.80.193 in the cache.
> 
> So I either filter away fragments (for the recursors) or I dnssec sign
> ui-dns.de (on my authoritative servers) to be safe.

You can filter away fragments but I'm afraid this will lead to timeouts,
or even to some domains not resolving anymore. Most of the
countermeasures are applicable to the authoritative servers, and there
isn't a lot one can do on the recursor's side.
One option is to lower the value of edns-outgoing-bufsize enough to
reduce the likelihood of getting fragmented answers in the first place,
which is what are doing by default in the (not yet released) 4.2.0
version, see [1], but you can also apply that setting today. Lowering
that value too much will lead to issues with authoritative servers that
do not handle queries over TCP, as Let's Encrypt recently learned the
hard way after switching to 512 bytes.

We are also experimenting with the scrubbing of most of the additional
records for 4.2.0, see [2], but we still need to accept some of these so
this is never going to perfectly prevent that issue.

Signing your domain with DNSSEC will prevent spoofed answers, but will
unfortunately not prevent a DoS since the glue records are not signed.

I'm afraid there is no silver bullet, although some measures can be
deployed to reduce the risk.

[1]: https://github.com/PowerDNS/pdns/pull/7307
[2]: https://github.com/PowerDNS/pdns/pull/7404

Best regards,
-- 
Remi Gacogne
PowerDNS.COM BV - https://www.powerdns.com/



signature.asc
Description: OpenPGP digital signature
___
Pdns-users mailing list
Pdns-users@mailman.powerdns.com
https://mailman.powerdns.com/mailman/listinfo/pdns-users

Re: [Pdns-users] pdns_recursor and records in additional section of replies

[Remi Gacogne]

Hi Thomas,

On 1/23/19 8:01 AM, Thomas Mieslinger wrote:
> I would like to better understand how pdns_recursor 4.1.x deals with
> records in the additional section of replies it gets from authoritative
> Servers.

These records, if the recursor considers that the authoritative server
is allowed to send them, are added to the cache and might be later used
for "infrastructure" queries, ie to retrieve the nameservers for a given
zone and their IPv4 and/or IPv6 addresses.

> In short I would like that pdns_recursor does not use information from
> additional sections. Just like pdns authoritative 4.1.x does not
> generate additional sections anymore.

Completely ignoring additional records would break zones that need glue
records to resolve, at the very least. What are you trying to achieve?

Best regards,
-- 
Remi Gacogne
PowerDNS.COM BV - https://www.powerdns.com/



signature.asc
Description: OpenPGP digital signature
___
Pdns-users mailing list
Pdns-users@mailman.powerdns.com
https://mailman.powerdns.com/mailman/listinfo/pdns-users

[Pdns-users] PowerDNS Recursor 4.1.9 Released

[Remi Gacogne]

Hello everyone,

We are very happy to announce the 4.1.9 release of the PowerDNS
Recursor. This release is fixing two security issues, and addressing a
shortcoming in the way incoming queries are distributed to threads under
heavy load.

This release fixes the following security issues:

- PowerDNS Security Advisory 2019-01 [1] (CVE-2019-3806): Lua hooks are
not called over TCP
- PowerDNS Security Advisory 2019-02 [2] (CVE-2019-3807): DNSSEC
validation is not performed for AA=0 responses

These issues respectively affect PowerDNS Recursor from 4.1.4 and 4.1.0,
up to and including 4.1.8. PowerDNS Recursor 4.0.x and below are not
affected.

Minimal patches are available at [3] and [4].

The changelog [5]:

- #7397: Load the Lua script in the distributor thread, check signature
for AA=0 answers (CVE-2019-3806, CVE-2019-3807)
- #7377: Try another worker before failing if the first pipe was full

The tarball [6] (signature [7]) is available at
https://downloads.powerdns.com/releases/ and packages for CentOS 6 and
7, Debian Jessie and Stretch, Ubuntu Bionic, Trusty and Xenial are
available from https://repo.powerdns.com/.

Please send us all feedback and issues you might have via the mailing
list [8], or in case of a bug, via GitHub [9].

[1]:
https://doc.powerdns.com/recursor/security-advisories/powerdns-advisory-2019-01.html
|2]:
https://doc.powerdns.com/recursor/security-advisories/powerdns-advisory-2019-02.html
[3]: https://downloads.powerdns.com/patches/2019-01/
[4]: https://downloads.powerdns.com/patches/2019-02/
[5]: https://doc.powerdns.com/recursor/changelog/4.1.html#change-4.1.9
[6]: https://downloads.powerdns.com/releases/pdns-recursor-4.1.9.tar.bz2
[7]: https://downloads.powerdns.com/releases/pdns-recursor-4.1.9.tar.bz2.sig
[8]: https://mailman.powerdns.com/mailman/listinfo/pdns-users
[9]: https://github.com/PowerDNS/pdns/issues/new

Best regards,
-- 
Remi Gacogne
PowerDNS.COM BV - https://www.powerdns.com/



signature.asc
Description: OpenPGP digital signature
___
Pdns-users mailing list
Pdns-users@mailman.powerdns.com
https://mailman.powerdns.com/mailman/listinfo/pdns-users

Re: [Pdns-users] Disabling DNSUPDATE for *some* zones?

[Remi Gacogne]

Hi Kevin,

On 1/2/19 2:15 AM, Kevin P. Fleming wrote:
> I've got PowerDNS Auth happily running and serving a number of domains
> (primary and two secondaries, NOTIFY/AXFR, IPv6, etc.).
> 
> I've enabled DNSUPDATE so that I can do Let's Encrypt DNS-01
> challenges for certificate issuance, and I use a TSIG key for the
> update requests. When setting up a cert for a new domain recently, I
> failed to set the domain metadata to indicate that the TSIG key would
> be required, and PowerDNS accepted the DNSUPDATE anyway (and emitted a
> log message to that effect).
> 
> I don't want this behavior, I want to disable DNSUPDATE for all
> domains which don't have a TSIG key set in their metadata. The only
> way I can see to do this would be to set ALLOW-DNSUPDATE-FROM at the
> domain level to an invalid address, so that all requests will fail,
> but I also have this set in the main configuration which might not be
> overridden by the domain metadata.
> 
> Is there another way to disable DNSUPDATE at the domain level?

I'm afraid I don't see any other way. I would advise opening a feature
request on GitHub [1] so it doesn't get lost.

[1]: https://github.com/PowerDNS/pdns/issues/new

Best regards,
-- 
Remi Gacogne
PowerDNS.COM BV - https://www.powerdns.com/



signature.asc
Description: OpenPGP digital signature
___
Pdns-users mailing list
Pdns-users@mailman.powerdns.com
https://mailman.powerdns.com/mailman/listinfo/pdns-users

Re: [Pdns-users] errno - 128 with mysql

[Remi Gacogne]

On 12/21/18 3:56 PM, Cliff Hayes wrote:
> I have to use 4.0.6 because authoritative + recursion was removed with 4.1.

I'm sorry to insist, but I really think you should consider the
following solutions to migrate to 4.1.0:

https://docs.powerdns.com/authoritative/guides/recursion.html

We don't intend on supporting 4.0.x forever so I'm afraid you will have
to migrate at some point, if only to a different software.

Best regards,

Remi

> On 12/21/2018 2:49 AM, frank+pdns--- via Pdns-users wrote:
>>
>> Hi Cliff,
>>
>> Besides the question about 4.0 vs 4.1 that Remi brought up, MySQL
>> errno 128 can mean a few things.
>>
>> Could you try to issues those MySQL queries by hand, when connecting
>> with the exact same user/password that PowerDNS uses to connect?
>>
>> Frank Louwers
>> Certified PowerDNS Consultant
>>
>>> On 21 Dec 2018, at 09:26, Remi Gacogne 
>>> wrote:
>>>
>>> Signed PGP part
>>> Hi,
>>>
>>> On 12/20/18 7:25 PM, Cliff Hayes wrote:
>>>> I have just successfully installed authoritative server 4.0.6 on Fedora
>>>> 28.  It appears proper results are being returned on DNS queries but I
>>>> and am now seeing the following errors which are new to me.  I tried
>>>> putting in 2018122001 for all records as the change_date and nothing
>>>> changed.  prio field is null.
>>>
>>>> Dec 20 12:14:32 Result field at row 0 column 2 has errno -128
>>>
>>> This sounds very similar to [1], which was fixed in 4.1.0 by [2]. Is
>>> there any reason you are still using the 4.0.x branch instead of the
>>> 4.1.x one?
>>>
>>> [1]: https://github.com/PowerDNS/pdns/issues/5675
>>> [2]: https://github.com/PowerDNS/pdns/pull/5820
>>>
>>> Regards,
>>> -- 
>>> Remi Gacogne
>>> PowerDNS.COM BV - https://www.powerdns.com/
>>>
>>>
>>>
>>
>> ___
>> Pdns-users mailing list
>> Pdns-users@mailman.powerdns.com
>> https://mailman.powerdns.com/mailman/listinfo/pdns-users
>>
> ___
> Pdns-users mailing list
> Pdns-users@mailman.powerdns.com
> https://mailman.powerdns.com/mailman/listinfo/pdns-users


-- 
Remi Gacogne
PowerDNS.COM BV - https://www.powerdns.com/



signature.asc
Description: OpenPGP digital signature
___
Pdns-users mailing list
Pdns-users@mailman.powerdns.com
https://mailman.powerdns.com/mailman/listinfo/pdns-users

Re: [Pdns-users] errno - 128 with mysql

[Remi Gacogne]

Hi,

On 12/20/18 7:25 PM, Cliff Hayes wrote:
> I have just successfully installed authoritative server 4.0.6 on Fedora
> 28.  It appears proper results are being returned on DNS queries but I
> and am now seeing the following errors which are new to me.  I tried
> putting in 2018122001 for all records as the change_date and nothing
> changed.  prio field is null.

> Dec 20 12:14:32 Result field at row 0 column 2 has errno -128

This sounds very similar to [1], which was fixed in 4.1.0 by [2]. Is
there any reason you are still using the 4.0.x branch instead of the
4.1.x one?

[1]: https://github.com/PowerDNS/pdns/issues/5675
[2]: https://github.com/PowerDNS/pdns/pull/5820

Regards,
-- 
Remi Gacogne
PowerDNS.COM BV - https://www.powerdns.com/



signature.asc
Description: OpenPGP digital signature
___
Pdns-users mailing list
Pdns-users@mailman.powerdns.com
https://mailman.powerdns.com/mailman/listinfo/pdns-users

Re: [Pdns-users] NOTIFY response timeout value? (repeat NOTIFY slave error)

[Remi Gacogne]

On 12/7/18 6:10 PM, MRob wrote:
> NOTIFY 3sec timeout is hardcoded? ANyone please confirm?

At a quick glance, it looks like the first attempt has a 3s timeout, the
second one 5s, the third one 9s and the last one 17s:

https://github.com/PowerDNS/pdns/blob/master/pdns/communicator.hh#L106

I did not actually test, though.

Best regards,

Remi

> On 2018-12-05 18:43, MRob wrote:
>> Hello, when supermaster send NOTIFY for large number of domain I think
>> some NOTIFYs get re-sent. On first time slave setup that cause errors
>> so I was looking do pdns have setting to delay re-NOTIFY timeout?
>>
>> Loglevel 6 doesnt say "no response so I will re-notify" however I see
>> hint of two notify response in master:
>>
>> 01:19:53 Queued notification of domain 'example.org' to 2.2.2.2:53
>> 01:19:57 Removed from notification list: 'example.org' to 2.2.2.2:53
>> (was acknowledged)
>> 01:20:13 Received spurious notify answer for 'example.org' from
>> 2.2.2.2:53
>> 01:20:31 AXFR happen successfully
>> 01:20:45 Received unsuccessful notification report for 'example.org'
>> from 2.2.2.2:53, error: Server Failure
>> 01:20:45 Received spurious notify answer for 'example.org' from
>> 2.2.2.2:53
>>
>> Slave show in logs 2 NOTIFY, notice time of number 2 is 1sec before
>> than which master said "removed from notify list (acknowledged)":
>>
>> 01:19:54 Received NOTIFY for example.org from 1.1.1.1 for which we are
>> not authoritative
>> 01:19:56 Received NOTIFY for example.org from 1.1.1.1 for which we are
>> not authoritative
>> 01:20:13 Created new slave zone 'example.org' from supermaster 1.1.1.1
>> 01:20:31 AXFR happen successfully
>> 01:20:44 Database error trying to create example.org for potential
>> supermaster 1.1.1.1: Database error trying to insert new domain
>> 'example.org.': Could not execute mysql statement: insert into domains
>> (type,name,master,account,last_check,notified_serial)
>> values(?,?,?,?,NULL,NULL): Duplicate entry 'example.org' for key
>> 'name_index'
>>
>> So I guess master wait 3sec for NOTIFY acknowledge then send
>> re-NOTIFY. On slave setup causing database error. Look like operation
>> is normal after so I can ignore but I wonder if there may be setting
>> to increase timeout?
> ___
> Pdns-users mailing list
> Pdns-users@mailman.powerdns.com
> https://mailman.powerdns.com/mailman/listinfo/pdns-users


-- 
Remi Gacogne
PowerDNS.COM BV - https://www.powerdns.com/



signature.asc
Description: OpenPGP digital signature
___
Pdns-users mailing list
Pdns-users@mailman.powerdns.com
https://mailman.powerdns.com/mailman/listinfo/pdns-users

Re: [Pdns-users] AXFR queued but not executing

[Remi Gacogne]

Hi,

On 11/30/18 9:18 PM, MRob wrote:
> Summary:
> 
> 1 - superslave create only entry in ``domains'' table but no records
> 2 - AXFR never retry, just reapeat ``No new unfresh slave domains, 1
> queued for AXFR already, 0 in progress''

1 queued for AXFR means it has been placed in the AXFR queue, which is
regularly processed by the threads doing the actual AXFR retrieval.
Since this domain is never moved to the "in progress" state, it looks
like no retrieval thread is picking it up. What the value of your
"retrieval-threads" setting?
Actually, would you mind posting your whole configuration so we being to
understand what's going on?


Best regards,
-- 
Remi Gacogne
PowerDNS.COM BV - https://www.powerdns.com/



signature.asc
Description: OpenPGP digital signature
___
Pdns-users mailing list
Pdns-users@mailman.powerdns.com
https://mailman.powerdns.com/mailman/listinfo/pdns-users

Re: [Pdns-users] PowerDNS recursor v4.0.9 gives dnssec validation bogus for this one domain, other sources says its fine

[Remi Gacogne]

Hi Pekka,

On 11/26/18 9:53 AM, Pekka Panula wrote:
> I have problem with this one domain where our PoweDNS recursors says its
> bogus and gives SERVFAIL.
> 
> When i am testing it and validating it using eg.
> https://dnssec-debugger.verisignlabs.com/ or http://dnsviz.net/ they say
> it’s ok, also Google and CloudFlare gives answers ok.
> 
> I did enabled powerdns domain trace for this domain, results are here:
> https://gist.github.com/ppanula/00f2fe4de7d12dbb7899dc02ea505a18
> 
> I’m not sure why PowerDNS recursors validation says bogus, pls help.
> 
> Also I have tested our PowerDNS recursors for other known DNSSEC domains
> and it gives OK answers.

Would you consider upgrading to the 4.1.x branch, currently 4.1.7?
DNSSEC validation in 4.0.x was marked as experimental and it's unlikely
that we will fix it.

I just tested and grimaldi.napoli.it is correctly resolved as insecure
on recent versions.

Best regards,
-- 
Remi Gacogne
PowerDNS.COM BV - https://www.powerdns.com/



signature.asc
Description: OpenPGP digital signature
___
Pdns-users mailing list
Pdns-users@mailman.powerdns.com
https://mailman.powerdns.com/mailman/listinfo/pdns-users

[Pdns-users] dnsdist 1.3.3 released

[Remi Gacogne]

our packages,
like DNS over TLS and DNSTap support, on distributions where the
required dependencies were available.


[1]: https://dnsdist.org
[2]: https://dnsdist.org/changelog.html
[3]: https://downloads.powerdns.com/releases/dnsdist-1.3.3.tar.bz2
[4]: https://repo.powerdns.com/

Best regards,

-- 
Remi Gacogne
PowerDNS.COM BV - https://www.powerdns.com/



signature.asc
Description: OpenPGP digital signature
___
Pdns-users mailing list
Pdns-users@mailman.powerdns.com
https://mailman.powerdns.com/mailman/listinfo/pdns-users

Re: [Pdns-users] DNSSEC-Problems on g.root-servers.net?

[Remi Gacogne]

On 9/17/18 10:46 AM, Stephane Bortzmeyer wrote:
>>  • NSEC3 proving non-existence of admin.ch/DS: No NSEC3 RR matches the 
>> SNAME (admin.ch).
>>  • NSEC3 proving non-existence of admin.ch/DS: No NSEC3 RR matches the 
>> SNAME (admin.ch).
>
> The real problem seems to be in .ch.

It indeed does look like h.nic.ch is currently serving invalid denial of
existence proofs.

Sep 17 10:54:12 [1]   admin.ch: Resolved 'ch' NS h.nic.ch to:
2a03:bd80:36::1:203:230, 85.119.5.230
Sep 17 10:54:12 [1]   admin.ch: Trying IP [2a03:bd80:36::1:203:230]:53,
asking 'admin.ch|DS'
Sep 17 10:54:12 [1]   admin.ch: Got 7 answers from h.nic.ch
(2a03:bd80:36::1:203:230), rcode=0 (No Error), aa=1, in 19ms
Sep 17 10:54:12 [1]   admin.ch: accept answer 'ch|SOA|a.nic.ch.
dns-operation.switch.ch. 2018091710 900 600 1123200 900' from 'ch'
nameservers? ttl=900, place=2 YES!
Sep 17 10:54:12 [1]   admin.ch: accept answer 'ch|RRSIG|SOA 8 1 900
20181017072134 20180917070659 43368 ch.
lqiFlvlLzpfZiJtXq2lA7xMEBcDZ8JkBVDyW9eGOiDf50tlSAFf7lfPbNvk4Kr5oGvYEfykiFyNRPbVhB7Q7td2MFc24rDuHmWodO5dHu8CP8npjQFRDVhK16xwe52gi+HhaIBEs3UgoJAhHbw6fUT39eISVq7nKQ+Zbi9H79VmSvsrXIDJpwxXYRxEnG16yUPDEjALs72wjQUVPK1AFqA=='
from 'ch' nameservers? ttl=900, place=2 RRSIG - separate
Sep 17 10:54:12 [1]   admin.ch: accept answer
'b3r86ai7q4714nt11g03efktr8e8uoqn.ch|NSEC3|1 1 2 563f2a03
B3RMRJ5UH7SCR184M2COCF3M5MATJUOU NS SOA RRSIG DNSKEY NSEC3PARAM' from
'ch' nameservers? ttl=900, place=2 YES!
Sep 17 10:54:12 [1]   admin.ch: accept answer
'b3r86ai7q4714nt11g03efktr8e8uoqn.ch|RRSIG|NSEC3 8 2 900 20181004034939
20180916113001 43368 ch.
v+kKyz9cwB8I2FTuEsQ29QqEGCqRsLQPNUKsyqYaX6ehEN2QH0/x8+O/iwAEBuRRV1w1oFJyCUKgDyUEbbZWHJHOICcyJtcZvsbuv2Pk9ZM1IhzpVoDaP/ty5458dinB5cL7+aFWcNflUKJGxFnEXtjwtft3SlB2yY6mXtolDVwDFZVlVDPGhcYcSmPtPkf4SENr0Ys0Ols+dBVE5eIL2g=='
from 'ch' nameservers? ttl=900, place=2 RRSIG - separate
Sep 17 10:54:12 [1]   admin.ch: accept answer
'n18tgf150r26u73788obf8kl1lddpdbm.ch|NSEC3|1 1 2 563f2a03
N19I6GLRO0S7IEK6ESINL5OJS1295DH4 NS DS RRSIG' from 'ch' nameservers?
ttl=900, place=2 YES!
Sep 17 10:54:12 [1]   admin.ch: accept answer
'n18tgf150r26u73788obf8kl1lddpdbm.ch|RRSIG|NSEC3 8 2 900 20181008010305
20180916113001 43368 ch.
n2mL4npemCPuXAgsz3fymS9x/hjVvD1HJc9ZLhF4KajHjjSxmRfL3Ba0WpnAh3is56n7qPtQrIpF2BrOxTj8A6hxWF7m8+TNBJqb/hc9XuLHu1F8mrwF59g/rdM0hKSHvW+9xB0wNIFEZwPtR8cG9WbdSJ/fJTe9T3dQE0eaRDsvcywS/Stu7OTAnEI+wsO7TSvFacuNgwXwUYQxDSv/Hw=='
from 'ch' nameservers? ttl=900, place=2 RRSIG - separate
Sep 17 10:54:12 [1]   admin.ch: OPT answer '.' from 'ch' nameservers

[...]

Sep 17 10:54:12 [1]   admin.ch: got negative caching indication for
'admin.ch|DS'
Sep 17 10:54:12 Do have: n18tgf150r26u73788obf8kl1lddpdbm.ch/NSEC3
Sep 17 10:54:12 1 1 2 563f2a03 N19I6GLRO0S7IEK6ESINL5OJS1295DH4
NS DS RRSIG
Sep 17 10:54:12 query hash: pqnb24ervdukiuq6j0ajbs6eeocm7v67
Sep 17 10:54:12 Do have: b3r86ai7q4714nt11g03efktr8e8uoqn.ch/NSEC3
Sep 17 10:54:12 1 1 2 563f2a03 B3RMRJ5UH7SCR184M2COCF3M5MATJUOU
NS SOA RRSIG DNSKEY NSEC3PARAM
Sep 17 10:54:12 query hash: pqnb24ervdukiuq6j0ajbs6eeocm7v67
Sep 17 10:54:12 Now looking for the closest encloser for admin.ch
Sep 17 10:54:12 1 1 2 563f2a03 N19I6GLRO0S7IEK6ESINL5OJS1295DH4
NS DS RRSIG
Sep 17 10:54:12 Comparing b3r86ai7q4714nt11g03efktr8e8uoqn (ch) against
n18tgf150r26u73788obf8kl1lddpdbm
Sep 17 10:54:12 1 1 2 563f2a03 B3RMRJ5UH7SCR184M2COCF3M5MATJUOU
NS SOA RRSIG DNSKEY NSEC3PARAM
Sep 17 10:54:12 Comparing b3r86ai7q4714nt11g03efktr8e8uoqn (ch) against
b3r86ai7q4714nt11g03efktr8e8uoqn
Sep 17 10:54:12 Closest encloser for admin.ch is ch
Sep 17 10:54:12 Looking for a NSEC3 covering the next closer name admin.ch
Sep 17 10:54:12 1 1 2 563f2a03 N19I6GLRO0S7IEK6ESINL5OJS1295DH4
NS DS RRSIG
Sep 17 10:54:12 Comparing pqnb24ervdukiuq6j0ajbs6eeocm7v67 against
n18tgf150r26u73788obf8kl1lddpdbm -> n19i6glro0s7iek6esinl5ojs1295dh4
Sep 17 10:54:12 Did not cover us (admin.ch),
start=n18tgf150r26u73788obf8kl1lddpdbm.ch,
us=pqnb24ervdukiuq6j0ajbs6eeocm7v67, end=n19i6glro0s7iek6esinl5ojs1295dh4
Sep 17 10:54:12 1 1 2 563f2a03 B3RMRJ5UH7SCR184M2COCF3M5MATJUOU
NS SOA RRSIG DNSKEY NSEC3PARAM
Sep 17 10:54:12 Comparing pqnb24ervdukiuq6j0ajbs6eeocm7v67 against
b3r86ai7q4714nt11g03efktr8e8uoqn -> b3rmrj5uh7scr184m2cocf3m5matjuou
Sep 17 10:54:12 Did not cover us (admin.ch),
start=b3r86ai7q4714nt11g03efktr8e8uoqn.ch,
us=pqnb24ervdukiuq6j0ajbs6eeocm7v67, end=b3rmrj5uh7scr184m2cocf3m5matjuou

Best regards,
-- 
Remi Gacogne
PowerDNS.COM BV - https://www.powerdns.com/



signature.asc
Description: OpenPGP digital signature
___
Pdns-users mailing list
Pdns-users@mailman.powerdns.com
https://mailman.powerdns.com/mailman/listinfo/pdns-users