[Pdns-users] Rcode 3 NXDOMAIN for existing CNAME

2023-03-09 Thread Christoph via Pdns-users 

Hi,

let me start with some context information:

We are using the lego [1] ACME client
with a DNS challenge and desec.io as our DNS provider
and run into a problem that results in the failure of certificate renewals.

According to the lego developer the root cause is a DNS issue [2] in our 
environment.


We captured and inspected lego's DNS traffic when renewals fail,
to see whether we can confirm DNS as the root cause.
While looking at the DNS packet we noticed that the DNS server returns:
RCode: 3
even when it contains the relevant record in the answers.

Wireshark copy paste:
domain shortened to simplify

Domain Name System (response)
 Transaction ID: 0x18c6
 Flags: 0x8403 Standard query response, No such name
 1...    = Response: Message is a response
[...]
    0011 = Reply code: No such name (3)
 Questions: 1
 Answer RRs: 2
 Authority RRs: 6
 Additional RRs: 1
 Queries
 _acmE-cHAllenge.doh.applIEd-PRIvAcy.NeT: type A, class IN
 Answers
 _acmE-cHAllenge.doh.applIEd-PRIvAcy.NeT: type CNAME, class IN, 
cname doh.acme.applIEd-PRIvAcy.NeT

 _acmE-cHAllenge.doh.applIEd-PRIvAcy.NeT: type RRSIG, class IN
 Authoritative nameservers
 Additional records


We reached out to DeSEC and they confirmed and reproduced it
and provided an description of why this happens: PowerDNS Authoritative 
follows CNAMEs when they are on the same server. If the final lookup 
does not exist it returns NXDOMAIN to the first query

even when the qname from the first query does exist.

Example:

desired certificate is for: doh.applied-privacy.net

_acme-challenge.doh.applied-privacy.net CNAME
-> doh.acme.applied-privacy.net

The reason for the CNAME: lego gets an API key that
is authorized to write to the domain acme.applied-privacy.net only (not 
to applied-privacy.net) to reduce the impact on API key compromise.


lego has CNAME support for this setup and follows CNAMEs
before creating the TXT record, but since the first lookup returns 
NXDOMAIN already it attempts to use the API key for a zone it has no 
access to. It is not expected to get an NXDOMAIN Rcode for an existing 
CNAME record.


Does this behavior meet RFC standards? (so lego is wrong?)
Can the behavior be changed by a configuration setting?

thanks!
Christoph

[1] https://go-acme.github.io/lego/
[2] https://github.com/go-acme/lego/issues/1739

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

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

2023-03-09 Thread Stephane Bortzmeyer via Pdns-users 
On Thu, Mar 09, 2023 at 10:25:33AM +0100,
 Remi Gacogne via dnsdist  wrote 
 a message of 94 lines which said:

> https://downloads.powerdns.com/releases/dnsdist-8.0-rc2.tar.bz2

404. The correct one seems to be
.
___
Pdns-users mailing list
Pdns-users@mailman.powerdns.com
https://mailman.powerdns.com/mailman/listinfo/pdns-users

Re: [Pdns-users] master receiving notifies from slave

2023-03-09 Thread Curtis Maurand via Pdns-users 

I will check that out, thanks.

On 3/9/23 02:26, Klaus Darilion via Pdns-users wrote:


PDNS sends only NOTIFYs for SLAVE zones is slave-renotify is turned on 
(globally, or per zone in domainmetadata table).


So, if your SLAVEs shoudl not send NOTIFYs make sure to disable 
slave-renotify.


If a PDNS instance slaves zones from a master, but also acts as master 
to other slaves, then you can fine tune NOTIFYs.


I use "only-notify=" (empty value to disable all implizit NOTIFYs). 
Further I use "ALSO-NOTIFY" domainmetadata settings to specify NOTIFY 
targets per zone.


regards

Klaus

*Von:*Pdns-users  *Im Auftrag 
von *Curtis Maurand via Pdns-users

*Gesendet:* Donnerstag, 9. März 2023 00:06
*An:* pdns-users@mailman.powerdns.com
*Betreff:* [Pdns-users] master receiving notifies from slave

Hello,
I have a pair of powerdns servers running on a debian derivative 
equivalent to bullseye: Devuan chimaera.  I am running pdns 
authoritative version 4.7.3 from the powerdns debian repo.  Devuan 
does not use systemd.  I'm using sysvinit.  The upgrade removes 
/etc/init.d/pdns script which is not good nor can I find it in the 
sources even though the docs say it's in there. That's not really why 
I'm writing.


The slave server is sending notifies for one, and only one slave 
domain maurand.com to the master and the master (a supermaster) is 
refusing them, but they are happening several times per second.  Boths 
servers are behind NAT firewalls and that would be the reason for the 
private IP in the notify.


Mar  8 16:34:30 sirius pdns[27219]: Received NOTIFY for maurand.com from 
192.168.100.1 but we are primary (Refused)
Mar  8 16:34:35 sirius pdns[27219]: Received NOTIFY for maurand.com from 
192.168.100.1 but we are primary (Refused)

On the master  (208.105.217.26) I have:

 52 | maurand.com   | NULL   |   NULL | MASTER |  
2023030804 | NULL    | NULL    |   50 | NULL    |


On the slave (208.105.219.27) I have:

| 17 | maurand.com   | 208.105.217.26 | 1678315385 | SLAVE 
|    NULL | | NULL    | NULL    |


As I was typing out my cry for help, here, I may have solved this by 
upgrading the master to 4.7.3 from version 4.4.1 (which is what is in 
the debian repos), but after the upgrade, I still received a few more 
notifies after the upgrade, but It seems to have settled down.


I searched around the net for answers, but I can't find any.  I've 
been running powerdns for a very long time.  Does anyone have any 
ideas what might be causing this?


Thanks in advance,
Curtis


Curtis
https://curtis.maurand.com

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


--
Curtis
https://curtis.maurand.com
___
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

2023-03-09 Thread 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