Re: [Pdns-users] DNSSEC: How to add TA for . to recursor of self hosted . zone

2024-03-05 Thread Jan Huijsmans via Pdns-users
On Tue, 5 Mar 2024 07:46:23 +0100
Otto Moerbeek  wrote:
> On Mon, Mar 04, 2024 at 05:01:12PM +0100, Jan Huijsmans via Pdns-users wrote:
> > Hello,
> > 
> > I'm tryting to setup a DNSSEC lab environment with an isolated DNS set.

*argh* PEBCAK... 

Had 2 major issues in my setup.

1. had no default-soa-edit set on authoritive.
   should work on pdns-only environments, but somehow the secondaries didn't
   notice RRSIG changes. No clue why, but as bind needs to be able to be
   secondary, this had to be set anyway.

2. Was testing via recursor with lua-script config option commented out...
   Not helping. :(
   Checking with rec_control get-tas didn't show my TA, so I manually added
   it and it worked. Diving deeper into my config and I found the # which I
   was sure I removed...

Regards,

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


Re: [Pdns-users] DNSSEC: How to add TA for . to recursor of self hosted . zone

2024-03-04 Thread Otto Moerbeek via Pdns-users
On Mon, Mar 04, 2024 at 05:01:12PM +0100, Jan Huijsmans via Pdns-users wrote:

> Hello,
> 
> I'm tryting to setup a DNSSEC lab environment with an isolated DNS set.
> 
> Service setup:
> 
> Servers
> - hidden master root server (pdns-auth 4.6.3-1)
> - queriable slave root servers (pdns-auth 4.6.3-1 & 4.8.4-1)
> - master + slave domain server (pdns-auth 4.8.4-1)
> - recursors on 4.9.2-1
> 
> pdns.conf of the auth instances include a .conf with
> gmysql=dnssec=yes
> 
> recursor.conf of the recursors include a lua-config file with clearTA() and 
> either either the addTA function with '.' and the DS content or 
> reedTrustAnchorsFromFile that points to a file with the output of
> 
> pdnsutil export-zone-ds .
> 
> All zones are, from lowest to highest zone, signed via the pdns secure-zone 
> command and the DS records are exported via pdnsutil export-zone-ds and that 
> output is added to the higher zone up to . .
> 
> When I use dig to request records directly from the authoritive instances, I 
> get answerd with RRSIG responces I expect. However, when I try via the 
> recursor, the . zone is not trusted.
> 
> The error the pdns recursor logs shows on a restart is:
> 
> msg="Failed to update . records" error="Got Bogus validation result for .|NS" 
> subsystem="housekeeping" level="0" prio="Error" tid="0" ts="1709563954.159" 
> exception="PDNSException"
> 
> When I request the DNSKEY from the . zone and add that to the root.key file 
> (checkes on a debian system what's in /usr/share/dns/root.key to find the 
> syntax) I read TA from via lua-config, then the result is the same.
> 
> Documentation used:
> - https://doc.powerdns.com/recursor/dnssec.html
> - https://doc.powerdns.com/recursor/lua-config/dnssec.html#addTA
> - https://doc.powerdns.com/authoritative/dnssec/index.html
> - https://doc.powerdns.com/authoritative/manpages/pdnsutil.1.html
> and what I could find with DDG.
> 
> dnssec is set to process in the recursor, but it refuses to answer when I use 
> dig, nelookup works. (so applications have no impact by this issue)
> 
> It looks to me I'm missing something simple in establishing the initial trust 
> of the . zone within the recursor, the rest looks like it works as it should.
> 
> Any help is appreciated.

Show your recursor.conf and your root hints.

-Otto

> 
> Regards,
> 
> Jan Huijsmans
> ___
> 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


[Pdns-users] DNSSEC: How to add TA for . to recursor of self hosted . zone

2024-03-04 Thread Jan Huijsmans via Pdns-users
Hello,

I'm tryting to setup a DNSSEC lab environment with an isolated DNS set.

Service setup:

Servers
- hidden master root server (pdns-auth 4.6.3-1)
- queriable slave root servers (pdns-auth 4.6.3-1 & 4.8.4-1)
- master + slave domain server (pdns-auth 4.8.4-1)
- recursors on 4.9.2-1

pdns.conf of the auth instances include a .conf with
gmysql=dnssec=yes

recursor.conf of the recursors include a lua-config file with clearTA() and 
either either the addTA function with '.' and the DS content or 
reedTrustAnchorsFromFile that points to a file with the output of

pdnsutil export-zone-ds .

All zones are, from lowest to highest zone, signed via the pdns secure-zone 
command and the DS records are exported via pdnsutil export-zone-ds and that 
output is added to the higher zone up to . .

When I use dig to request records directly from the authoritive instances, I 
get answerd with RRSIG responces I expect. However, when I try via the 
recursor, the . zone is not trusted.

The error the pdns recursor logs shows on a restart is:

msg="Failed to update . records" error="Got Bogus validation result for .|NS" 
subsystem="housekeeping" level="0" prio="Error" tid="0" ts="1709563954.159" 
exception="PDNSException"

When I request the DNSKEY from the . zone and add that to the root.key file 
(checkes on a debian system what's in /usr/share/dns/root.key to find the 
syntax) I read TA from via lua-config, then the result is the same.

Documentation used:
- https://doc.powerdns.com/recursor/dnssec.html
- https://doc.powerdns.com/recursor/lua-config/dnssec.html#addTA
- https://doc.powerdns.com/authoritative/dnssec/index.html
- https://doc.powerdns.com/authoritative/manpages/pdnsutil.1.html
and what I could find with DDG.

dnssec is set to process in the recursor, but it refuses to answer when I use 
dig, nelookup works. (so applications have no impact by this issue)

It looks to me I'm missing something simple in establishing the initial trust 
of the . zone within the recursor, the rest looks like it works as it should.

Any help is appreciated.

Regards,

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


Re: [Pdns-users] DNSSEC and

2023-08-22 Thread Xan Charbonnet via Pdns-users

Frank,

I so appreciate your help.  It sounds like my intended configuration 
should be fine, then.  I might suggest to the powers that be that the 
documentation address this question.


The reason I have two servers is for redundancy, so I'll probably give 
both instances write access, but as you say that should work fine.


Thanks again,
Xan




On 8/22/23 07:45, Frank Louwers wrote:

Hi Xan,

The weekly changes are not key rollovers, they are RRSIG 
updates/resignings. These are done on the fly (in online mode), and not 
stored in the database.


The backend only contains the ZSK/KSK/CSK, which will only change if you 
issue a command to roll them. Even if you would issue the change command 
on both servers, the new keys would be stored in the unique database if 
you have just 1 backend database, so both would use the new key (there 
might be short-term caching issues). Personally, I would only configure 
1 of the PowerDNS servers to have write access to the backend DB, the 
other ones would just have SELECT privileges on the db.


Cheers,

Frank




On 22 Aug 2023, at 14:25, Xan Charbonnet  wrote:

Thank you, Frank.

I am aiming to do online signing, but my concern is the weekly key 
rollover.  Wouldn't both PowerDNS instances attempt to perform key 
rollover on the same database at the same time?  Do they not step on 
each other's toes?


-Xan



On 8/22/23 07:03, Frank Louwers via Pdns-users wrote:

Hi Xan,
It depends which DNSSEC you choose. If you would pick "Online 
Signing" for instance (great unless you have very busy servers with 
lots of domains), the "keying data" is stored in the database as 
well, so both servers would use the same data to sign the zone, 
resulting in consistent signatures (as long as your MariaDB 
replication isn't broken).

Seehttps://doc.powerdns.com/authoritative/dnssec/modes-of-operation.html#online-signing 
> 
for more info and other ways of turning on DNSSEC on PowerDNS.
Frank
Frank Louwers
PowerDNS Certified Consultant @ Kiwazo.be
On 21 Aug 2023, at 17:03, Xan Charbonnet via Pdns-users 
 wrote:


Hello everyone,

We've been successfully using PowerDNS for some time, and are 
looking into enabling DNSSEC.


If two PowerDNS authoritative servers are set up for native 
replication, sharing a single MariaDB backend where the database is 
replicated using MariaDB's replication, how would DNSSEC be enabled? 
 If I just turn it on, wouldn't the two servers step on each other's 
toes when it came time to do a key rollover?  Or is that not a problem?


Thanks in advance.
___
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 




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


Re: [Pdns-users] DNSSEC and

2023-08-22 Thread Frank Louwers via Pdns-users
Hi Xan,

The weekly changes are not key rollovers, they are RRSIG updates/resignings. 
These are done on the fly (in online mode), and not stored in the database. 

The backend only contains the ZSK/KSK/CSK, which will only change if you issue 
a command to roll them. Even if you would issue the change command on both 
servers, the new keys would be stored in the unique database if you have just 1 
backend database, so both would use the new key (there might be short-term 
caching issues). Personally, I would only configure 1 of the PowerDNS servers 
to have write access to the backend DB, the other ones would just have SELECT 
privileges on the db.

Cheers,

Frank



> On 22 Aug 2023, at 14:25, Xan Charbonnet  wrote:
> 
> Thank you, Frank.
> 
> I am aiming to do online signing, but my concern is the weekly key rollover.  
> Wouldn't both PowerDNS instances attempt to perform key rollover on the same 
> database at the same time?  Do they not step on each other's toes?
> 
> -Xan
> 
> 
> 
> On 8/22/23 07:03, Frank Louwers via Pdns-users wrote:
>> Hi Xan,
>> It depends which DNSSEC you choose. If you would pick "Online Signing" for 
>> instance (great unless you have very busy servers with lots of domains), the 
>> "keying data" is stored in the database as well, so both servers would use 
>> the same data to sign the zone, resulting in consistent signatures (as long 
>> as your MariaDB replication isn't broken).
>> See 
>> https://doc.powerdns.com/authoritative/dnssec/modes-of-operation.html#online-signing
>>  for more info and other ways of turning on DNSSEC on PowerDNS.
>> Frank
>> Frank Louwers
>> PowerDNS Certified Consultant @ Kiwazo.be
>>> On 21 Aug 2023, at 17:03, Xan Charbonnet via Pdns-users 
>>>  wrote:
>>> 
>>> Hello everyone,
>>> 
>>> We've been successfully using PowerDNS for some time, and are looking into 
>>> enabling DNSSEC.
>>> 
>>> If two PowerDNS authoritative servers are set up for native replication, 
>>> sharing a single MariaDB backend where the database is replicated using 
>>> MariaDB's replication, how would DNSSEC be enabled?  If I just turn it on, 
>>> wouldn't the two servers step on each other's toes when it came time to do 
>>> a key rollover?  Or is that not a problem?
>>> 
>>> Thanks in advance.
>>> ___
>>> 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

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


Re: [Pdns-users] DNSSEC and

2023-08-22 Thread Xan Charbonnet via Pdns-users

Thank you, Frank.

I am aiming to do online signing, but my concern is the weekly key 
rollover.  Wouldn't both PowerDNS instances attempt to perform key 
rollover on the same database at the same time?  Do they not step on 
each other's toes?


-Xan



On 8/22/23 07:03, Frank Louwers via Pdns-users wrote:

Hi Xan,

It depends which DNSSEC you choose. If you would pick "Online Signing" 
for instance (great unless you have very busy servers with lots of 
domains), the "keying data" is stored in the database as well, so both 
servers would use the same data to sign the zone, resulting in 
consistent signatures (as long as your MariaDB replication isn't broken).


See 
https://doc.powerdns.com/authoritative/dnssec/modes-of-operation.html#online-signing  for more info and other ways of turning on DNSSEC on PowerDNS.


Frank


Frank Louwers
PowerDNS Certified Consultant @ Kiwazo.be

On 21 Aug 2023, at 17:03, Xan Charbonnet via Pdns-users 
 wrote:


Hello everyone,

We've been successfully using PowerDNS for some time, and are looking 
into enabling DNSSEC.


If two PowerDNS authoritative servers are set up for native 
replication, sharing a single MariaDB backend where the database is 
replicated using MariaDB's replication, how would DNSSEC be enabled? 
 If I just turn it on, wouldn't the two servers step on each other's 
toes when it came time to do a key rollover?  Or is that not a problem?


Thanks in advance.
___
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

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


Re: [Pdns-users] DNSSEC and

2023-08-22 Thread Frank Louwers via Pdns-users
Hi Xan,

It depends which DNSSEC you choose. If you would pick "Online Signing" for 
instance (great unless you have very busy servers with lots of domains), the 
"keying data" is stored in the database as well, so both servers would use the 
same data to sign the zone, resulting in consistent signatures (as long as your 
MariaDB replication isn't broken).

See 
https://doc.powerdns.com/authoritative/dnssec/modes-of-operation.html#online-signing
 for more info and other ways of turning on DNSSEC on PowerDNS.

Frank


Frank Louwers
PowerDNS Certified Consultant @ Kiwazo.be

> On 21 Aug 2023, at 17:03, Xan Charbonnet via Pdns-users 
>  wrote:
> 
> Hello everyone,
> 
> We've been successfully using PowerDNS for some time, and are looking into 
> enabling DNSSEC.
> 
> If two PowerDNS authoritative servers are set up for native replication, 
> sharing a single MariaDB backend where the database is replicated using 
> MariaDB's replication, how would DNSSEC be enabled?  If I just turn it on, 
> wouldn't the two servers step on each other's toes when it came time to do a 
> key rollover?  Or is that not a problem?
> 
> Thanks in advance.
> ___
> 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


[Pdns-users] DNSSEC and

2023-08-21 Thread Xan Charbonnet via Pdns-users

Hello everyone,

We've been successfully using PowerDNS for some time, and are looking 
into enabling DNSSEC.


If two PowerDNS authoritative servers are set up for native replication, 
sharing a single MariaDB backend where the database is replicated using 
MariaDB's replication, how would DNSSEC be enabled?  If I just turn it 
on, wouldn't the two servers step on each other's toes when it came time 
to do a key rollover?  Or is that not a problem?


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


Re: [Pdns-users] DNSSEC error

2023-08-18 Thread Brian Candler via Pdns-users

On 18/08/2023 10:12, Huber, Peter via Pdns-users wrote:
Thank you, I understand, that our server is not authoritative for .de. 
bur it seems our zone is no longer signed, but it was signed in the past.


There's a DS record in the parent zone:

$ dig @a.nic.de. uni-wh.de. ds
uni-wh.de.        86400    IN    DS    6632 14 2 
16556A7A06EC51AF8317D1CEF7EBF9F78D6214B648D83D14007C7820 A2561AF0


Therefore, if the zone isn't signed, then your names wouldn't resolve 
(by a DNSSEC-validating resolver).  But it all looks fine to me:


$ dig @8.8.8.8 uni-wh.de. +dnssec +trace

; <<>> DiG 9.10.6 <<>> @8.8.8.8 uni-wh.de. +dnssec +trace
; (1 server found)
;; global options: +cmd
.            38984    IN    NS    a.root-servers.net.
.            38984    IN    NS    b.root-servers.net.
.            38984    IN    NS    c.root-servers.net.
.            38984    IN    NS    d.root-servers.net.
.            38984    IN    NS    e.root-servers.net.
.            38984    IN    NS    f.root-servers.net.
.            38984    IN    NS    g.root-servers.net.
.            38984    IN    NS    h.root-servers.net.
.            38984    IN    NS    i.root-servers.net.
.            38984    IN    NS    j.root-servers.net.
.            38984    IN    NS    k.root-servers.net.
.            38984    IN    NS    l.root-servers.net.
.            38984    IN    NS    m.root-servers.net.
.            38984    IN    RRSIG    NS 8 0 518400 2023083017 
2023081716 11019 . 
Oui2ZZOta0+GnD7/uTK7N4X7WljjlYNw65RFma/tLxhpfnaxCRntCdl0 
ZH1p91FYWxOM0KimWnlUUivG3Xv4cbS4Bezj+4+tC1r1v3tPOGXKyvmV 
wmprioRC0JV8gIIw5Y6kxXk7BABmYYctCqONfRNluxW1YIkqFaRz7lm/ 
VFsMxXG42Q/C2OB+o8a0zQHEAoRN7RnC29H2a6cpwM0NmFkLnKY3k1UH 
hODGz0FUlEekGb99oaEhEj6GC+Khr0sHgdNCkMGaqSjtG+0m0LA4bDP+ 
66jebfxUFcIXyDKRny24qw5Xpnu/Zoq9GeYU6IC+kF5OlcOZ9/WGG/KE Q30F3g==

;; Received 525 bytes from 8.8.8.8#53(8.8.8.8) in 55 ms

de.            172800    IN    NS    a.nic.de.
de.            172800    IN    NS    f.nic.de.
de.            172800    IN    NS    l.de.net.
de.            172800    IN    NS    n.de.net.
de.            172800    IN    NS    s.de.net.
de.            172800    IN    NS    z.nic.de.
de.            86400    IN    DS    26755 8 2 
F341357809A5954311CCB82ADE114C6C1D724A75C0395137AA397803 5425E78D
de.            86400    IN    RRSIG    DS 8 1 86400 2023083105 
2023081804 11019 . 
Pb4neoqNz+vSDNnOh9VFn/eCi9AOy7ZzL3QmZRO2k+xsBRCQZyezRRXp 
+G8fowBatDtq8BSKrdHYNZmkENYUiVJ/bOIAZBdTzRYhg7B4nBrj/dqs 
SdnL+dS/1LKFjI43ttXaoY1Ut3UPPTg+o0lV1c2Mdo50bcP6l6XBa9Dd 
PHTr1Ww8QgDGgkEC0JrtoLemuQOKYDCNFQu3UY0Dg8dmS8Y7L2DjBry8 
vOOd9UashIihFM5ZbLc2yRVNbq5bSc+mB1U/9+sM8h7SClSJMm0aAeB6 
mWpflyCLLKEWYNu0aoLH6nfvSxTjfQoS2exhhUzioY+WaiK/IrI0b7PF rSBo1w==

;; Received 749 bytes from 193.0.14.129#53(k.root-servers.net) in 6 ms

uni-wh.de.        86400    IN    NS    dns-3.dfn.de.
uni-wh.de.        86400    IN    NS    dmz6.uni-wh.de.
uni-wh.de.        86400    IN    DS    6632 14 2 
16556A7A06EC51AF8317D1CEF7EBF9F78D6214B648D83D14007C7820 A2561AF0
uni-wh.de.        86400    IN    RRSIG    DS 8 2 86400 20230831065512 
20230817052512 23418 de. 
ZkkyTC5y59RsxU4WYmFF4VYm9WwZA6MjGUeKoNT2vJO+wEu+Cu2baqSg 
Ty1Qu7jmW1Jq09lWJaVHLczVXQ8OaYygAxAeWZnceUoKJdy9+CrVQz/Q 
9MxfmyoVgQ5Y+nllukSTCzhqf0hwg5Tys2NgytxpbrIBFxj5ve4dfyst 5vY=

;; Received 309 bytes from 194.246.96.1#53(z.nic.de) in 19 ms

uni-wh.de.        3600    IN    A    193.175.243.73
uni-wh.de.        3600    IN    RRSIG    A 14 2 3600 2023083100 
2023081000 6632 uni-wh.de. 
jeJVLcdTgZTEAfbv1wIKrYFracW6//zzHwINZP4jM0hpdz+iYrmld7ss 
uX2sU2ZfXlWClNY6GBd0GKD4yozlk8ZZHb6nnQu+k3TF+4Ti/vGO+XvY 2vcAgcMKstfeY/We

;; Received 191 bytes from 193.175.243.110#53(dmz6.uni-wh.de) in 27 ms

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


Re: [Pdns-users] DNSSEC error

2023-08-18 Thread Martin Kellermann via Pdns-users
DNSSEC seems to be fine:

https://dnsviz.net/d/uni-wh.de/dnssec/
https://dnssec-analyzer.verisignlabs.com/uni-wh.de



Von: Pdns-users  Im Auftrag von Huber, 
Peter via Pdns-users
Gesendet: Freitag, 18. August 2023 11:13
An: All about using and deploying powerdns 
Cc: Huber, Peter 
Betreff: Re: [Pdns-users] DNSSEC error

Thank you, I understand, that our server is not authoritative for .de. bur it 
seems our zone is no longer signed, but it was signed in the past. Do I have to 
resign uni-wh.de? How can this disappear?


dig @127.0.0.1 dmz6.uni-wh.de. rrsig

; <<>> DiG 9.18.12-0ubuntu0.22.04.2-Ubuntu <<>> @127.0.0.1 dmz6.uni-wh.de. rrsig
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: REFUSED, id: 51126
;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;dmz6.uni-wh.de.IN  RRSIG

;; Query time: 0 msec
;; SERVER: 127.0.0.1#53(127.0.0.1) (UDP)
;; WHEN: Fri Aug 18 11:07:37 CEST 2023
;; MSG SIZE  rcvd: 43



Von: Brian Candler mailto:b.cand...@pobox.com>>
Gesendet: Freitag, 18. August 2023 10:15
An: All about using and deploying powerdns 
mailto:pdns-users@mailman.powerdns.com>>
Cc: Huber, Peter mailto:peter.hu...@uni-wh.de>>
Betreff: Re: [Pdns-users] DNSSEC error

On 18/08/2023 08:53, Huber, Peter via Pdns-users wrote:
i have strange thing using the pdns resolver. My domain uni-wh.de was ok for a 
long time, now there seems to be a DNSSEC problem and I don’t know where this 
comes from, nor how to fix this.
What I am testing:

delv @193.175.243.110 uni-wh.de

You say the problem is with a "pdns resolver", but 193.175.243.110 is an 
authoritative server, not a recursor.
From the error output you gave, it looks like you're using a tool which wants 
to talk to a recursor:
;; chase DS servers resolving 'uni-wh.de/DS/IN': 193.175.243.110#53
;; REFUSED unexpected RCODE resolving 'de/NS/IN': 193.175.243.110#53
;; REFUSED unexpected RCODE resolving './NS/IN': 193.175.243.110#53
;; REFUSED unexpected RCODE resolving 'de/DS/IN': 193.175.243.110#53

Your authoritative server is (correctly) refusing to answer queries for domains 
it is not authoritative for, like ".de" and the root.

There are various online DNSSEC checkers. I checked a couple with uni-wh.de and 
they seem to think it's fine (and I can resolve it fine), so I don't think 
there's any problem.
___
Pdns-users mailing list
Pdns-users@mailman.powerdns.com
https://mailman.powerdns.com/mailman/listinfo/pdns-users


Re: [Pdns-users] DNSSEC error

2023-08-18 Thread Huber, Peter via Pdns-users
Thank you, I understand, that our server is not authoritative for .de. bur it 
seems our zone is no longer signed, but it was signed in the past. Do I have to 
resign uni-wh.de? How can this disappear?


dig @127.0.0.1 dmz6.uni-wh.de. rrsig

; <<>> DiG 9.18.12-0ubuntu0.22.04.2-Ubuntu <<>> @127.0.0.1 dmz6.uni-wh.de. rrsig
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: REFUSED, id: 51126
;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;dmz6.uni-wh.de.IN  RRSIG

;; Query time: 0 msec
;; SERVER: 127.0.0.1#53(127.0.0.1) (UDP)
;; WHEN: Fri Aug 18 11:07:37 CEST 2023
;; MSG SIZE  rcvd: 43



Von: Brian Candler 
Gesendet: Freitag, 18. August 2023 10:15
An: All about using and deploying powerdns 
Cc: Huber, Peter 
Betreff: Re: [Pdns-users] DNSSEC error

On 18/08/2023 08:53, Huber, Peter via Pdns-users wrote:
i have strange thing using the pdns resolver. My domain uni-wh.de was ok for a 
long time, now there seems to be a DNSSEC problem and I don’t know where this 
comes from, nor how to fix this.
What I am testing:

delv @193.175.243.110 uni-wh.de

You say the problem is with a "pdns resolver", but 193.175.243.110 is an 
authoritative server, not a recursor.
From the error output you gave, it looks like you're using a tool which wants 
to talk to a recursor:
;; chase DS servers resolving 'uni-wh.de/DS/IN': 193.175.243.110#53
;; REFUSED unexpected RCODE resolving 'de/NS/IN': 193.175.243.110#53
;; REFUSED unexpected RCODE resolving './NS/IN': 193.175.243.110#53
;; REFUSED unexpected RCODE resolving 'de/DS/IN': 193.175.243.110#53

Your authoritative server is (correctly) refusing to answer queries for domains 
it is not authoritative for, like ".de" and the root.

There are various online DNSSEC checkers. I checked a couple with uni-wh.de and 
they seem to think it's fine (and I can resolve it fine), so I don't think 
there's any problem.
___
Pdns-users mailing list
Pdns-users@mailman.powerdns.com
https://mailman.powerdns.com/mailman/listinfo/pdns-users


Re: [Pdns-users] DNSSEC error

2023-08-18 Thread Brian Candler via Pdns-users

On 18/08/2023 08:53, Huber, Peter via Pdns-users wrote:


i have strange thing using the pdns resolver. My domain uni-wh.de was 
ok for a long time, now there seems to be a DNSSEC problem and I don’t 
know where this comes from, nor how to fix this.


What I am testing:

delv @193.175.243.110 uni-wh.de

You say the problem is with a "pdns resolver", but 193.175.243.110 is an 
authoritative server, not a recursor.


From the error output you gave, it looks like you're using a tool which 
wants to talk to a recursor:


;; chase DS servers resolving 'uni-wh.de/DS/IN': 193.175.243.110#53
;; REFUSED unexpected RCODE resolving 'de/NS/IN': 193.175.243.110#53
;; REFUSED unexpected RCODE resolving './NS/IN': 193.175.243.110#53
;; REFUSED unexpected RCODE resolving 'de/DS/IN': 193.175.243.110#53

Your authoritative server is (correctly) refusing to answer queries for 
domains it is not authoritative for, like ".de" and the root.


There are various online DNSSEC checkers. I checked a couple with 
uni-wh.de and they seem to think it's fine (and I can resolve it fine), 
so I don't think there's any problem.
___
Pdns-users mailing list
Pdns-users@mailman.powerdns.com
https://mailman.powerdns.com/mailman/listinfo/pdns-users


[Pdns-users] DNSSEC error

2023-08-18 Thread Huber, Peter via Pdns-users
Hi,

i have strange thing using the pdns resolver. My domain uni-wh.de was ok for a 
long time, now there seems to be a DNSSEC problem and I don't know where this 
comes from, nor how to fix this.
What I am testing:

delv @193.175.243.110 uni-wh.de

;; chase DS servers resolving 'uni-wh.de/DS/IN': 193.175.243.110#53
;; REFUSED unexpected RCODE resolving 'de/NS/IN': 193.175.243.110#53
;; REFUSED unexpected RCODE resolving './NS/IN': 193.175.243.110#53
;; REFUSED unexpected RCODE resolving 'de/DS/IN': 193.175.243.110#53
;; broken trust chain resolving 'uni-wh.de/DNSKEY/IN': 193.175.243.110#53
;; broken trust chain resolving 'uni-wh.de/A/IN': 193.175.243.110#53
;; resolution failed: broken trust chain

dig @193.175.243.110 uni-wh.de +dnssec +short
A 14 2 3600 2023083100 2023081000 6632 uni-wh.de. 
jeJVLcdTgZTEAfbv1wIKrYFracW6//zzHwINZP4jM0hpdz+iYrmld7ss 
uX2sU2ZfXlWClNY6GBd0GKD4yozlk8ZZHb6nnQu+k3TF+4Ti/vGO+XvY 2vcAgcMKstfeY/We

There seems to be a valid key (till 2023083100) but the chain seems to be 
broken?

Can anyone give me a hint what I can do, where I have to look?

Thank you
Peter

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


Re: [Pdns-users] DNSSEC and CNAME records results NXDOMAIN

2022-04-22 Thread Marijn via Pdns-users

Thank you for investigating and pointing this out.
There was a zone with the domain name "." (just a dot), which caused the 
issue.

I removed this zone and now it seems to work.
Thank you very much for your help!

Klaus Darilion wrote on 2022-04-22 21:41:

I think I have found the problem:

Your name server also has configured a root zone:

# dig @ns1.mijn.host. sdfdsafdsagdafdgsdgffg.dfdsafs

; <<>> DiG 9.11.3-1ubuntu1.17-Ubuntu <<>> @ns1.mijn.host.
sdfdsafdsagdafdgsdgffg.dfdsafs
; (2 servers found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 55422
;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;sdfdsafdsagdafdgsdgffg.dfdsafs.IN  A

;; AUTHORITY SECTION:
.   3600IN  SOA ns1.mijn.host.
hostmaster. 1643556361 10800 3600 604800 3600


PowerDNS has a feature (or bug) to follow CNAMEs if PowerDNS finds the
target in its own zones. As your PowerDNS has also configured a root
zone, this root zone matches for egogo.nl (and any other zone) and
powerdns searches inside this root zone for the CNAME target. As the
CNAME target is not found in the local root zone, NXDOMAIN is
responded, and that may confuse resolvers to not follow the CNAME.

Hence, remove the root zone from your POwerDNS.

regards
Klaus




-Ursprüngliche Nachricht-
Von: Marijn 
Gesendet: Freitag, 22. April 2022 19:18
An: Klaus Darilion ; pdns-
us...@mailman.powerdns.com
Betreff: Re: [Pdns-users] DNSSEC and CNAME records results NXDOMAIN

I fill the records with the API.
However when I check the SOA file (see below) it looks correct
(hostmaster.egogo.eu).
But with "dig @ns1.mijn.host. autodiscover.egogo.eu" it shows an
incorrect value.

MariaDB [powerdns]> SELECT * FROM domains WHERE id = 9644;
+--+--++++-+-+
| id   | name | master | last_check | type   | notified_serial |
account |
+--+--++++-+-+
| 9644 | egogo.eu ||   NULL | MASTER |  1650634625 |
 |
+--+--++++-+-+
1 row in set (0.00 sec)

MariaDB [powerdns]> SELECT * FROM records WHERE domain_id = 9644;
+-+---++---+---
--+--+--+--+---+--+
| id  | domain_id | name   | type  | content
 | ttl  | prio |
disabled | ordername | auth |
+-+---++---+---
--+--+--+--+---+--+
| 7909392 |  9644 | egogo.eu   | NS| ns1.mijn.host
 | 3600 |0 |
   0 |   |1 |
| 7909393 |  9644 | egogo.eu   | NS| ns2.mijn.host
 | 3600 |0 |
   0 |   |1 |
| 7909394 |  9644 | egogo.eu   | NS| ns3.mijn.host
 | 3600 |0 |
   0 |   |1 |
| 7910921 |  9644 | autodiscover.egogo.eu  | CNAME |
autodiscover.outlook.com|
900 |0 |0 | autodiscover  |1 |
| 7910922 |  9644 | autodiscover2.egogo.eu | CNAME | egogo.nl
 |  900 |0 |
   0 | autodiscover2 |1 |
| 7910923 |  9644 | *.egogo.eu | A | 54.36.54.239
 |  900 |0 |
   0 | * |1 |
| 7910924 |  9644 | egogo.eu   | MX| mail.egogo.eu
 |  900 |   10 |
   0 |   |1 |
| 7910925 |  9644 | egogo.eu   | A | 54.36.54.239
 |  900 |0 |
   0 |   |1 |
| 7910926 |  9644 | egogo.eu   | SOA   | ns1.mijn.host
hostmaster.egogo.eu 1650634625 10800 3600 604800 3600 | 3600 |0 |
 0 |   |1 |
+-+---++---+---
--+--+--+--+---+--+
9 rows in set (0.01 sec)

MariaDB [powerdns]> SELECT * FROM cryptokeys WHERE domain_id = 9644;
+--+---+---++---+-
-

Re: [Pdns-users] DNSSEC and CNAME records results NXDOMAIN

2022-04-22 Thread Klaus Darilion via Pdns-users
I think I have found the problem:

Your name server also has configured a root zone:

# dig @ns1.mijn.host. sdfdsafdsagdafdgsdgffg.dfdsafs

; <<>> DiG 9.11.3-1ubuntu1.17-Ubuntu <<>> @ns1.mijn.host. 
sdfdsafdsagdafdgsdgffg.dfdsafs
; (2 servers found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 55422
;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;sdfdsafdsagdafdgsdgffg.dfdsafs.IN  A

;; AUTHORITY SECTION:
.   3600IN  SOA ns1.mijn.host. hostmaster. 
1643556361 10800 3600 604800 3600


PowerDNS has a feature (or bug) to follow CNAMEs if PowerDNS finds the target 
in its own zones. As your PowerDNS has also configured a root zone, this root 
zone matches for egogo.nl (and any other zone) and powerdns searches inside 
this root zone for the CNAME target. As the CNAME target is not found in the 
local root zone, NXDOMAIN is responded, and that may confuse resolvers to not 
follow the CNAME.

Hence, remove the root zone from your POwerDNS.

regards
Klaus



> -Ursprüngliche Nachricht-
> Von: Marijn 
> Gesendet: Freitag, 22. April 2022 19:18
> An: Klaus Darilion ; pdns-
> us...@mailman.powerdns.com
> Betreff: Re: [Pdns-users] DNSSEC and CNAME records results NXDOMAIN
> 
> I fill the records with the API.
> However when I check the SOA file (see below) it looks correct
> (hostmaster.egogo.eu).
> But with "dig @ns1.mijn.host. autodiscover.egogo.eu" it shows an
> incorrect value.
> 
> MariaDB [powerdns]> SELECT * FROM domains WHERE id = 9644;
> +--+--++++-+-+
> | id   | name | master | last_check | type   | notified_serial |
> account |
> +--+--++++-+-+
> | 9644 | egogo.eu ||   NULL | MASTER |  1650634625 |
>  |
> +--+--++++-+-+
> 1 row in set (0.00 sec)
> 
> MariaDB [powerdns]> SELECT * FROM records WHERE domain_id = 9644;
> +-+---++---+---
> --+--+--+--+---+--+
> | id  | domain_id | name   | type  | content
>  | ttl  | prio |
> disabled | ordername | auth |
> +-+---++---+---
> --+--+--+--+---+--+
> | 7909392 |  9644 | egogo.eu   | NS| ns1.mijn.host
>  | 3600 |0 |
>0 |   |1 |
> | 7909393 |  9644 | egogo.eu   | NS| ns2.mijn.host
>  | 3600 |0 |
>0 |   |1 |
> | 7909394 |  9644 | egogo.eu   | NS| ns3.mijn.host
>  | 3600 |0 |
>0 |   |1 |
> | 7910921 |  9644 | autodiscover.egogo.eu  | CNAME |
> autodiscover.outlook.com|
> 900 |0 |0 | autodiscover  |1 |
> | 7910922 |  9644 | autodiscover2.egogo.eu | CNAME | egogo.nl
>  |  900 |0 |
>0 | autodiscover2 |1 |
> | 7910923 |  9644 | *.egogo.eu | A | 54.36.54.239
>  |  900 |0 |
>0 | * |1 |
> | 7910924 |  9644 | egogo.eu   | MX| mail.egogo.eu
>  |  900 |   10 |
>0 |   |1 |
> | 7910925 |  9644 | egogo.eu   | A | 54.36.54.239
>  |  900 |0 |
>0 |   |1 |
> | 7910926 |  9644 | egogo.eu   | SOA   | ns1.mijn.host
> hostmaster.egogo.eu 1650634625 10800 3600 604800 3600 | 3600 |0 |
>  0 |   |1 |
> +-+---++---+---
> --+--+--+--+---+--+
> 9 rows in set (0.01 sec)
> 
> MariaDB [powerdns]> SELECT * FROM cryptokeys WHERE domai

Re: [Pdns-users] DNSSEC and CNAME records results NXDOMAIN

2022-04-22 Thread Marijn via Pdns-users
 ( 
SHA256 digest )
DS = egogo.eu. IN DS 14759 13 4 
559f28bb6bf445611ddfc34d1c590f784c9472a6ff1a2adae36225c0f597343ce318990ed86531d49bfdad0e35fef6b0 
; ( SHA-384 digest )



$ pdnsutil list-zone egogo.eu
$ORIGIN .
*.egogo.eu  900 IN  A   54.36.54.239
autodiscover.egogo.eu   900 IN  CNAME   autodiscover.outlook.com.
autodiscover2.egogo.eu  900 IN  CNAME   egogo.nl.
egogo.eu900 IN  A   54.36.54.239
egogo.eu900 IN  MX  10 mail.egogo.eu.
egogo.eu3600IN  NS  ns1.mijn.host.
egogo.eu3600IN  NS  ns2.mijn.host.
egogo.eu3600IN  NS  ns3.mijn.host.
egogo.eu	3600	IN	SOA	ns1.mijn.host hostmaster.egogo.eu 1650634625 10800 
3600 604800 3600



Klaus Darilion via Pdns-users schreef op 2022-04-22 18:59:

And how do you fill records into the mysql db? Can you show the
relevenat rows of the records and domains table?
regards
Klaus


-Ursprüngliche Nachricht-
Von: Pdns-users  Im
Auftrag von Marijn via Pdns-users
Gesendet: Freitag, 22. April 2022 18:54
An: pdns-users@mailman.powerdns.com
Betreff: Re: [Pdns-users] DNSSEC and CNAME records results NXDOMAIN

I have pdnsutil 4.5.4 running with MySQL backend and native MySQL
replication.

In pdns.conf I have the following value. Maybe the @ doesn't work?

default-soa-content=ns1.mijn.host hostmaster.@ 0 10800 3600 604800 
3600


Klaus Darilion schreef op 2022-04-22 18:06:
> I do not see any difference of the two cases. But in any case,
> returning an answer AND nxdomain is just broken.
>
>
> # dig @ns1.mijn.host. autodiscover.egogo.eu
> ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 62514
> ...
> ;; QUESTION SECTION:
> ;autodiscover.egogo.eu. IN  A
>
> ;; ANSWER SECTION:
> autodiscover.egogo.eu.  900 IN  CNAME
> autodiscover.outlook.com.
>
> ;; AUTHORITY SECTION:
> .   3600IN  SOA ns1.mijn.host.
> hostmaster. 1643556361 10800 3600 604800 3600
>
> this is a very broken setup. SOA reports "." = root zone.
>
> which pdns version/backend/ zone setup are you using?
>
> regards
> Klaus
>
>> -Ursprüngliche Nachricht-
>> Von: Pdns-users  Im
>> Auftrag von Marijn via Pdns-users
>> Gesendet: Freitag, 22. April 2022 16:39
>> An: pdns-users@mailman.powerdns.com
>> Betreff: [Pdns-users] DNSSEC and CNAME records results NXDOMAIN
>>
>> I have PowerDNS 4.5.1 running.
>>
>> DNSSEC is working on the domain:
>> https://dnssec-analyzer.verisignlabs.com/egogo.eu
>>
>> ---
>>
>> But when I have DNSSEC active and I create a CNAME record, which
>> doesn't
>> have DNSSEC, I get a NXDOMAIN error.
>>
>> ```
>> $ dig CNAME autodiscover.egogo.eu +short
>> autodiscover.outlook.com.
>> ```
>>
>> Here you can see the error
>> https://dnssec-analyzer.verisignlabs.com/autodiscover.egogo.eu
>>
>> - Zone egogo.eu (83.96.241.95) returns NXDOMAIN for
>> autodiscover.egogo.eu
>> - No NSEC records in response
>>
>> ---
>>
>> When I create a CNAME record to a domain with DNSSEC, it's working.
>> ```
>> $ dig CNAME autodiscover2.egogo.eu +short
>> egogo.nl.
>> ```
>> https://dnssec-analyzer.verisignlabs.com/autodiscover2.egogo.eu
>> - No errors
>>
>> ---
>>
>> Why is DNSSEC not working with CNAME record
autodiscover.outlook.com?
>> Or could there be something wrong in my configuration?
>> ___
>> 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

___
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


Re: [Pdns-users] DNSSEC and CNAME records results NXDOMAIN

2022-04-22 Thread Klaus Darilion via Pdns-users
And how do you fill records into the mysql db? Can you show the relevenat rows 
of the records and domains table?
regards
Klaus

> -Ursprüngliche Nachricht-
> Von: Pdns-users  Im
> Auftrag von Marijn via Pdns-users
> Gesendet: Freitag, 22. April 2022 18:54
> An: pdns-users@mailman.powerdns.com
> Betreff: Re: [Pdns-users] DNSSEC and CNAME records results NXDOMAIN
> 
> I have pdnsutil 4.5.4 running with MySQL backend and native MySQL
> replication.
> 
> In pdns.conf I have the following value. Maybe the @ doesn't work?
> 
> default-soa-content=ns1.mijn.host hostmaster.@ 0 10800 3600 604800 3600
> 
> Klaus Darilion schreef op 2022-04-22 18:06:
> > I do not see any difference of the two cases. But in any case,
> > returning an answer AND nxdomain is just broken.
> >
> >
> > # dig @ns1.mijn.host. autodiscover.egogo.eu
> > ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 62514
> > ...
> > ;; QUESTION SECTION:
> > ;autodiscover.egogo.eu. IN  A
> >
> > ;; ANSWER SECTION:
> > autodiscover.egogo.eu.  900 IN  CNAME
> > autodiscover.outlook.com.
> >
> > ;; AUTHORITY SECTION:
> > .   3600IN  SOA ns1.mijn.host.
> > hostmaster. 1643556361 10800 3600 604800 3600
> >
> > this is a very broken setup. SOA reports "." = root zone.
> >
> > which pdns version/backend/ zone setup are you using?
> >
> > regards
> > Klaus
> >
> >> -Ursprüngliche Nachricht-
> >> Von: Pdns-users  Im
> >> Auftrag von Marijn via Pdns-users
> >> Gesendet: Freitag, 22. April 2022 16:39
> >> An: pdns-users@mailman.powerdns.com
> >> Betreff: [Pdns-users] DNSSEC and CNAME records results NXDOMAIN
> >>
> >> I have PowerDNS 4.5.1 running.
> >>
> >> DNSSEC is working on the domain:
> >> https://dnssec-analyzer.verisignlabs.com/egogo.eu
> >>
> >> ---
> >>
> >> But when I have DNSSEC active and I create a CNAME record, which
> >> doesn't
> >> have DNSSEC, I get a NXDOMAIN error.
> >>
> >> ```
> >> $ dig CNAME autodiscover.egogo.eu +short
> >> autodiscover.outlook.com.
> >> ```
> >>
> >> Here you can see the error
> >> https://dnssec-analyzer.verisignlabs.com/autodiscover.egogo.eu
> >>
> >> - Zone egogo.eu (83.96.241.95) returns NXDOMAIN for
> >> autodiscover.egogo.eu
> >> - No NSEC records in response
> >>
> >> ---
> >>
> >> When I create a CNAME record to a domain with DNSSEC, it's working.
> >> ```
> >> $ dig CNAME autodiscover2.egogo.eu +short
> >> egogo.nl.
> >> ```
> >> https://dnssec-analyzer.verisignlabs.com/autodiscover2.egogo.eu
> >> - No errors
> >>
> >> ---
> >>
> >> Why is DNSSEC not working with CNAME record
> autodiscover.outlook.com?
> >> Or could there be something wrong in my configuration?
> >> ___
> >> 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
___
Pdns-users mailing list
Pdns-users@mailman.powerdns.com
https://mailman.powerdns.com/mailman/listinfo/pdns-users


Re: [Pdns-users] DNSSEC and CNAME records results NXDOMAIN

2022-04-22 Thread Marijn via Pdns-users
I have pdnsutil 4.5.4 running with MySQL backend and native MySQL 
replication.


In pdns.conf I have the following value. Maybe the @ doesn't work?

default-soa-content=ns1.mijn.host hostmaster.@ 0 10800 3600 604800 3600

Klaus Darilion schreef op 2022-04-22 18:06:

I do not see any difference of the two cases. But in any case,
returning an answer AND nxdomain is just broken.


# dig @ns1.mijn.host. autodiscover.egogo.eu
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 62514
...
;; QUESTION SECTION:
;autodiscover.egogo.eu. IN  A

;; ANSWER SECTION:
autodiscover.egogo.eu.  900 IN  CNAME   
autodiscover.outlook.com.


;; AUTHORITY SECTION:
.   3600IN  SOA ns1.mijn.host.
hostmaster. 1643556361 10800 3600 604800 3600

this is a very broken setup. SOA reports "." = root zone.

which pdns version/backend/ zone setup are you using?

regards
Klaus


-Ursprüngliche Nachricht-
Von: Pdns-users  Im
Auftrag von Marijn via Pdns-users
Gesendet: Freitag, 22. April 2022 16:39
An: pdns-users@mailman.powerdns.com
Betreff: [Pdns-users] DNSSEC and CNAME records results NXDOMAIN

I have PowerDNS 4.5.1 running.

DNSSEC is working on the domain:
https://dnssec-analyzer.verisignlabs.com/egogo.eu

---

But when I have DNSSEC active and I create a CNAME record, which 
doesn't

have DNSSEC, I get a NXDOMAIN error.

```
$ dig CNAME autodiscover.egogo.eu +short
autodiscover.outlook.com.
```

Here you can see the error
https://dnssec-analyzer.verisignlabs.com/autodiscover.egogo.eu

- Zone egogo.eu (83.96.241.95) returns NXDOMAIN for
autodiscover.egogo.eu
- No NSEC records in response

---

When I create a CNAME record to a domain with DNSSEC, it's working.
```
$ dig CNAME autodiscover2.egogo.eu +short
egogo.nl.
```
https://dnssec-analyzer.verisignlabs.com/autodiscover2.egogo.eu
- No errors

---

Why is DNSSEC not working with CNAME record autodiscover.outlook.com?
Or could there be something wrong in my configuration?
___
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


Re: [Pdns-users] DNSSEC and CNAME records results NXDOMAIN

2022-04-22 Thread Klaus Darilion via Pdns-users
I do not see any difference of the two cases. But in any case, returning an 
answer AND nxdomain is just broken.


# dig @ns1.mijn.host. autodiscover.egogo.eu
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 62514
...
;; QUESTION SECTION:
;autodiscover.egogo.eu. IN  A

;; ANSWER SECTION:
autodiscover.egogo.eu.  900 IN  CNAME   autodiscover.outlook.com.

;; AUTHORITY SECTION:
.   3600IN  SOA ns1.mijn.host. hostmaster. 
1643556361 10800 3600 604800 3600

this is a very broken setup. SOA reports "." = root zone. 

which pdns version/backend/ zone setup are you using?

regards
Klaus

> -Ursprüngliche Nachricht-
> Von: Pdns-users  Im
> Auftrag von Marijn via Pdns-users
> Gesendet: Freitag, 22. April 2022 16:39
> An: pdns-users@mailman.powerdns.com
> Betreff: [Pdns-users] DNSSEC and CNAME records results NXDOMAIN
> 
> I have PowerDNS 4.5.1 running.
> 
> DNSSEC is working on the domain:
> https://dnssec-analyzer.verisignlabs.com/egogo.eu
> 
> ---
> 
> But when I have DNSSEC active and I create a CNAME record, which doesn't
> have DNSSEC, I get a NXDOMAIN error.
> 
> ```
> $ dig CNAME autodiscover.egogo.eu +short
> autodiscover.outlook.com.
> ```
> 
> Here you can see the error
> https://dnssec-analyzer.verisignlabs.com/autodiscover.egogo.eu
> 
> - Zone egogo.eu (83.96.241.95) returns NXDOMAIN for
> autodiscover.egogo.eu
> - No NSEC records in response
> 
> ---
> 
> When I create a CNAME record to a domain with DNSSEC, it's working.
> ```
> $ dig CNAME autodiscover2.egogo.eu +short
> egogo.nl.
> ```
> https://dnssec-analyzer.verisignlabs.com/autodiscover2.egogo.eu
> - No errors
> 
> ---
> 
> Why is DNSSEC not working with CNAME record autodiscover.outlook.com?
> Or could there be something wrong in my configuration?
> ___
> 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


[Pdns-users] DNSSEC and CNAME records results NXDOMAIN

2022-04-22 Thread Marijn via Pdns-users

I have PowerDNS 4.5.1 running.

DNSSEC is working on the domain:
https://dnssec-analyzer.verisignlabs.com/egogo.eu

---

But when I have DNSSEC active and I create a CNAME record, which doesn't 
have DNSSEC, I get a NXDOMAIN error.


```
$ dig CNAME autodiscover.egogo.eu +short
autodiscover.outlook.com.
```

Here you can see the error 
https://dnssec-analyzer.verisignlabs.com/autodiscover.egogo.eu


- Zone egogo.eu (83.96.241.95) returns NXDOMAIN for 
autodiscover.egogo.eu

- No NSEC records in response

---

When I create a CNAME record to a domain with DNSSEC, it's working.
```
$ dig CNAME autodiscover2.egogo.eu +short
egogo.nl.
```
https://dnssec-analyzer.verisignlabs.com/autodiscover2.egogo.eu
- No errors

---

Why is DNSSEC not working with CNAME record autodiscover.outlook.com?
Or could there be something wrong in my configuration?
___
Pdns-users mailing list
Pdns-users@mailman.powerdns.com
https://mailman.powerdns.com/mailman/listinfo/pdns-users


Re: [Pdns-users] DNSSEC : One key by client to update only this client's dynamic A record

2021-06-22 Thread Kevin P. Fleming via Pdns-users
This is not related to DNSSEC, but can still be done.

At A.dyndns.xxx.com you'd have a CNAME which points to an A record at
A.customers.dyndns.xxx.com, and the user's TSIG key would only allow
modifying the record(s) in that subzone. So you'd have one  subzone
per customer, and the TSIG keys would allow access to one subzone
each.

On Tue, Jun 22, 2021 at 2:18 PM David J. via Pdns-users
 wrote:
>
> Hello everyone,
>
> I would like to configure my own dyndns service. I managed to configure
> and make it work.
> I try now to secure this service.
>
> I followed with success this doc :
> https://doc.powerdns.com/authoritative/dnsupdate.html). However, as far
> as I understand there is only one key for the whole zone Which means,
> any client can update any record.
>
> I would like to be able to generate one key per client (dnssec-keygen -n
> host ?) and authorize this key to be able to update only the associated
> record.
> Example :
> - The zone is dyndns.xxx.com
> - A client would like to have the dynamic record A.dyndns.xxx.com
> - B would like B.dyndns.xxx.com
> - A must be able to update A.dyndns.xxx.com and only this record
> - Same for B.
>
> Can someone  give me an hint, an URL to achieve that with pdns please ?
> Did I miss something in the doc ?
>
> Thank you very much,
>
> Best regards,
>
> --
> David J
> ___
> 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


[Pdns-users] DNSSEC : One key by client to update only this client's dynamic A record

2021-06-22 Thread David J. via Pdns-users

Hello everyone,

I would like to configure my own dyndns service. I managed to configure 
and make it work.

I try now to secure this service.

I followed with success this doc : 
https://doc.powerdns.com/authoritative/dnsupdate.html). However, as far 
as I understand there is only one key for the whole zone Which means, 
any client can update any record.


I would like to be able to generate one key per client (dnssec-keygen -n 
host ?) and authorize this key to be able to update only the associated 
record.

Example :
- The zone is dyndns.xxx.com
- A client would like to have the dynamic record A.dyndns.xxx.com
- B would like B.dyndns.xxx.com
- A must be able to update A.dyndns.xxx.com and only this record
- Same for B.

Can someone  give me an hint, an URL to achieve that with pdns please ? 
Did I miss something in the doc ?


Thank you very much,

Best regards,

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


Re: [Pdns-users] DNSSEC Algorithm Rollover Documentation

2021-05-04 Thread Tony Finch via Pdns-users
Klaus Darilion  wrote:
> Daniel Stirnimann  wrote:
> >
> > Tony Finch has also documented how to do an algorithm rollover,
> > https://www.dns.cam.ac.uk/news/2020-01-15-rollover.html
>
> I am not sure - Is this the conservative or liberal approach? I would
> think this is not conservative as the new DNSKEYs are published together
> with the new RRSIGs.

Correct, it's the easy "liberal" approach. The "conservative" approach was
necessary to work with very old versions of unbound which were excessively
strict. (There is a requirement in the DNSSEC RFCs that is supposed to
apply to signers only, but unbound also checked it as a validator.)

That issue is long gone now.

I felt safe using the easier "liberal" approach following reports from a
number of TLDs that it worked OK for them. (I can't remember which ones
now, but they did presentations at past DNS-OARC meetings.)

> Further, in the liberal approach, it is necessary that KSK and ZSK
> algorithm rollover must be done at the same time, or may it be allowed
> to just introduce a KSK with new algorithm and still use the old ZSK?

DNSSEC algorithms are a whole-zone thing. You will probably find that if
you generate only one key for a new algorithm, your signer will use it as
a CSK ("combined", signing both zone and keys).

In any case, before you change the DS records, the whole zone has to be
signed with the new algorithm and you have to wait for all old
single-algorithm signatures to expire from caches - even if you do a
double-DS rollover. This is so that if a validator sees both old and new
algorithm in your DS records, and chooses to prefer the newer algorithm
and ignore the old and busted algorithm, it is still sure to be able to
validate.

Tony (explaining in detail for everyone on the list, not just those in the
headers of this message!)
-- 
f.anthony.n.finchhttps://dotat.at/
Lands End to St Davids Head including the Bristol Channel: West or
northwest 4 to 6. Rough until later in west, otherwise slight or
moderate. Showers. Good, occasionally moderate.

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


Re: [Pdns-users] DNSSEC Algorithm Rollover Documentation

2021-05-04 Thread Pieter Lexis via Pdns-users
Hi Klaus,

On 5/4/21 10:44 PM, Klaus Darilion via Pdns-users wrote:
> Thanks - the description of the conservative approach makes clear why the 
> "published" column in PDNS was introduced: I guess active=1 and publish=0 
> means that RRSIG will be produced but the key itself is not published as 
> DNSKEY.

Correct!

-- 
Pieter Lexis
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] DNSSEC Algorithm Rollover Documentation

2021-05-04 Thread Klaus Darilion via Pdns-users
Hi Daniel!

> -Ursprüngliche Nachricht-
> Von: Daniel Stirnimann 
> Gesendet: Montag, 3. Mai 2021 11:27
> An: Klaus Darilion ; Pdns-
> us...@mailman.powerdns.com
> Betreff: Re: [Pdns-users] DNSSEC Algorithm Rollover Documentation
> 
> Hello Klaus,
> 
> The DNSSEC Operational Practices (RFC 6781) documents this in chapter
> 4.1.4 Algorithm Rollovers:
> https://tools.ietf.org/html/rfc6781#section-4.1.4
> 
> The document mentions both a conservative and a liberal approach. 

Thanks - the description of the conservative approach makes clear why the 
"published" column in PDNS was introduced: I guess active=1 and publish=0 means 
that RRSIG will be produced but the key itself is not published as DNSKEY.

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


Re: [Pdns-users] DNSSEC Algorithm Rollover Documentation

2021-05-04 Thread Klaus Darilion via Pdns-users
Hi Daniel!

Thanks for the info.

> -Ursprüngliche Nachricht-
> Von: Daniel Stirnimann 
> Gesendet: Montag, 3. Mai 2021 11:27
> An: Klaus Darilion ; Pdns-
> us...@mailman.powerdns.com
> Betreff: Re: [Pdns-users] DNSSEC Algorithm Rollover Documentation
> 
> Hello Klaus,
> 
> The DNSSEC Operational Practices (RFC 6781) documents this in chapter
> 4.1.4 Algorithm Rollovers:
> https://tools.ietf.org/html/rfc6781#section-4.1.4
> 
> The document mentions both a conservative and a liberal approach. You
> can follow the liberal approach as by now all software handle this case
> correctly.

The question is - are all ISPs using the new software versions that support the 
liberal approach?

> It has even been done by TLDs.

That's a good indicator.

> Tony Finch has also documented how to do an algorithm rollover,
> https://www.dns.cam.ac.uk/news/2020-01-15-rollover.html

I am not sure - Is this the conservative or liberal approach? I would think 
this is not conservative as the new DNSKEYs are published together with the new 
RRSIGs.

Further, in the liberal approach, it is necessary that KSK and ZSK algorithm 
rollover must be done at the same time, or may it be allowed to just introduce 
a KSK with new algorithm and still use the old ZSK?

thanks
Klaus


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


Re: [Pdns-users] DNSSEC Algorithm Rollover Documentation

2021-05-03 Thread Daniel Stirnimann via Pdns-users
Hello Klaus,

The DNSSEC Operational Practices (RFC 6781) documents this in chapter
4.1.4 Algorithm Rollovers:
https://tools.ietf.org/html/rfc6781#section-4.1.4

The document mentions both a conservative and a liberal approach. You
can follow the liberal approach as by now all software handle this case
correctly. It has even been done by TLDs.

Tony Finch has also documented how to do an algorithm rollover,
https://www.dns.cam.ac.uk/news/2020-01-15-rollover.html

Daniel



On 03.05.21 10:25, Klaus Darilion via Pdns-users wrote:
> Hi all!
> 
> Is there somewhere documentation for an algorithm rollover?
> 
> The cryptokeys table recently received the "published" column to "Implement 
> published and unpublished dnskeys to allow algorith rollovers.":
> https://github.com/PowerDNS/pdns/commit/3391829938b4544a59c93c4734532ce2fdc311bf#diff-de175d2b28860458f7c4a143ab82aa94b44e5ac11fc51008fb4ac9b414130f91
> 
> But I do not find any documentation when to "publish" or "unpublish" a key 
> during an algorithm rollover. In may case the key handling is completely 
> outside of PDNS.
> 
> Thanks
> Klaus
> ___
> Pdns-users mailing list
> Pdns-users@mailman.powerdns.com
> https://mailman.powerdns.com/mailman/listinfo/pdns-users
> 

-- 
SWITCH
Daniel Stirnimann, SWITCH-CERT
Werdstrasse 2, P.O. Box, 8021 Zurich, Switzerland
phone +41 44 268 15 15, direct +41 44 268 16 24
daniel.stirnim...@switch.ch, www.switch.ch
___
Pdns-users mailing list
Pdns-users@mailman.powerdns.com
https://mailman.powerdns.com/mailman/listinfo/pdns-users


[Pdns-users] DNSSEC Algorithm Rollover Documentation

2021-05-03 Thread Klaus Darilion via Pdns-users
Hi all!

Is there somewhere documentation for an algorithm rollover?

The cryptokeys table recently received the "published" column to "Implement 
published and unpublished dnskeys to allow algorith rollovers.":
https://github.com/PowerDNS/pdns/commit/3391829938b4544a59c93c4734532ce2fdc311bf#diff-de175d2b28860458f7c4a143ab82aa94b44e5ac11fc51008fb4ac9b414130f91

But I do not find any documentation when to "publish" or "unpublish" a key 
during an algorithm rollover. In may case the key handling is completely 
outside of PDNS.

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


[Pdns-users] DNSSEC reference recommendation

2021-04-05 Thread Daniel reply via Pdns-users
Are there any recommendations for DNSSEC configuration information? Most of 
what I've found is either very superficial examples or warnings to avoid 
implementing without expert administration. Even something current that 
explains NSEC vs NSEC3 would be nice.

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


Re: [Pdns-users] DNSSEC UDP problems

2021-03-09 Thread Steffan via Pdns-users
Thanks
I downgraded pdns without problems

Met vriendelijke groet,
Steffan Noord 

-Oorspronkelijk bericht-
Van: Brian Candler  
Verzonden: dinsdag 9 maart 2021 16:12
Aan: steffanno...@gmail.com; 'pdns-users-ml' 
Onderwerp: Re: [Pdns-users] DNSSEC UDP problems

On 09/03/2021 14:01, Steffan via Pdns-users wrote:
> [powerdns-auth-master]
> name=PowerDNS repository for PowerDNS Authoritative Server - master 
> branch 
> baseurl=http://repo.powerdns.com/centos/$basearch/$releasever/auth-mas
> ter

For production use, you would be better with the "version 4.4.X" 
branch.  "master" branch is for testing the bleeding edge.


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


Re: [Pdns-users] DNSSEC UDP problems

2021-03-09 Thread Brian Candler via Pdns-users

On 09/03/2021 14:01, Steffan via Pdns-users wrote:

[powerdns-auth-master]
name=PowerDNS repository for PowerDNS Authoritative Server - master branch
baseurl=http://repo.powerdns.com/centos/$basearch/$releasever/auth-master


For production use, you would be better with the "version 4.4.X" 
branch.  "master" branch is for testing the bleeding edge.


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


Re: [Pdns-users] DNSSEC UDP problems

2021-03-09 Thread Steffan via Pdns-users
Oke thanxs.
Then i will remove the dnssec from that domains 

Met vriendelijke groet,
Steffan Noord 

-Oorspronkelijk bericht-
Van: Pdns-users  Namens Pieter Lexis 
via Pdns-users
Verzonden: dinsdag 9 maart 2021 15:32
Aan: pdns-users@mailman.powerdns.com
Onderwerp: Re: [Pdns-users] DNSSEC UDP problems

Hi,

On 3/9/21 3:01 PM, Steffan via Pdns-users wrote:
>> Are you actually using AXFR to transfer the zone to the nameservers? 
>> Or are
> you using database replication? Because ALIAS live-signing is not 
> implemented, only signing on AXFR-out is implemented. This is in the 
> documentation I sent you earlier and there's an open >ticket[1] (point 
> 6) as well.
> 
> Im using mysql backend on both dns servers Both are set up as masters, 
> and mysql is replicated from the master DB server

So the answer to my question was "No, the public nameservers serve the expanded 
ALIASes directly". Which is exactly the situation in which the expanded ALIAS 
records are not signed, leading to the issues you have.

The only way to get a signed, expanded ALIAS response is to AXFR from a hidden 
primary to public secondaries. PowerDNS will then sign the expanded ALIAS data 
when it serves out the AXFR.

I hope this clears up the confusion somewhat.

>> 1 - https://github.com/PowerDNS/pdns/issues/3838
> 
> -im sorry for the beginners question.. for so far i know it has 
> allways works

Live-signing expanded ALIAS records never worked, in any version of PowerDNS. 
This is on our wish-list, but no work has been done there, as all known ALIAS 
installations use the AXFR method.

Cheers,

Pieter

--
Pieter Lexis
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


Re: [Pdns-users] DNSSEC UDP problems

2021-03-09 Thread Pieter Lexis via Pdns-users
Hi,

On 3/9/21 3:01 PM, Steffan via Pdns-users wrote:
>> Are you actually using AXFR to transfer the zone to the nameservers? Or are
> you using database replication? Because ALIAS live-signing is not
> implemented, only signing on AXFR-out is implemented. This is in the
> documentation I sent you earlier and there's an open >ticket[1] (point 6) as
> well.
> 
> Im using mysql backend on both dns servers
> Both are set up as masters, and mysql is replicated from the master DB
> server

So the answer to my question was "No, the public nameservers serve the
expanded ALIASes directly". Which is exactly the situation in which the
expanded ALIAS records are not signed, leading to the issues you have.

The only way to get a signed, expanded ALIAS response is to AXFR from a
hidden primary to public secondaries. PowerDNS will then sign the
expanded ALIAS data when it serves out the AXFR.

I hope this clears up the confusion somewhat.

>> 1 - https://github.com/PowerDNS/pdns/issues/3838
> 
> -im sorry for the beginners question.. for so far i know it has allways
> works

Live-signing expanded ALIAS records never worked, in any version of
PowerDNS. This is on our wish-list, but no work has been done there, as
all known ALIAS installations use the AXFR method.

Cheers,

Pieter

-- 
Pieter Lexis
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] DNSSEC UDP problems

2021-03-09 Thread Steffan via Pdns-users


Hi,
> Running bleeding edge in production is not recommended. Although we
haven't had big issues in the master branch for quite a while. Just keep
that in mind :).

Hm i just yum updated.

[powerdns-auth-master]
name=PowerDNS repository for PowerDNS Authoritative Server - master branch
baseurl=http://repo.powerdns.com/centos/$basearch/$releasever/auth-master
gpgkey=https://repo.powerdns.com/CBC8B383-pub.asc
gpgcheck=1
enabled=1
priority=90
includepkg=pdns*"

>Are you actually using AXFR to transfer the zone to the nameservers? Or are
you using database replication? Because ALIAS live-signing is not
implemented, only signing on AXFR-out is implemented. This is in the
documentation I sent you earlier and there's an open >ticket[1] (point 6) as
well.

Im using mysql backend on both dns servers
Both are set up as masters, and mysql is replicated from the master DB
server



>1 - https://github.com/PowerDNS/pdns/issues/3838

-im sorry for the beginners question.. for so far i know it has allways
works

Im using:

outgoing-axfr-expand-alias=yes #added 09-03-2021
setuid=pdns
setgid=pdns
launch=gmysql
gmysql-host=127.0.0.1
gmysql-user=x
gmysql-password=x
gmysql-dbname=
gmysql-dnssec
query-local-address6=
resolver=208.67.220.220
expand-alias=yes
master=yes 

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


Re: [Pdns-users] DNSSEC UDP problems

2021-03-09 Thread Pieter Lexis via Pdns-users
Hi,

On 3/9/21 2:44 PM, Steffan via Pdns-users wrote:
> Hm that was a one time error
> 
> Upgraded to:
>   pdns-4.5.0-0.alpha0.master.826.gd1a09d600.1pdns

Running bleeding edge in production is not recommended. Although we
haven't had big issues in the master branch for quite a while. Just keep
that in mind :).

> Now no errors are found in the log 
> Still the message
> 
>   Found 1 RRSIGs over DNSKEY RRset
>   RRSIG=51602 and DNSKEY=51602/SEP verifies the DNSKEY RRset
>   crazyforprint.nl A RR has value 199.59.242.153
>   No RRSIGs found

Are you actually using AXFR to transfer the zone to the nameservers? Or
are you using database replication? Because ALIAS live-signing is not
implemented, only signing on AXFR-out is implemented. This is in the
documentation I sent you earlier and there's an open ticket[1] (point 6)
as well.

Cheers,

Pieter

1 - https://github.com/PowerDNS/pdns/issues/3838

-- 
Pieter Lexis
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] DNSSEC UDP problems

2021-03-09 Thread Steffan via Pdns-users
Hm that was a one time error

Upgraded to:
  pdns-4.5.0-0.alpha0.master.826.gd1a09d600.1pdns

Now no errors are found in the log 
Still the message

Found 1 RRSIGs over DNSKEY RRset
RRSIG=51602 and DNSKEY=51602/SEP verifies the DNSKEY RRset
crazyforprint.nl A RR has value 199.59.242.153
No RRSIGs found


Met vriendelijke groet,
Steffan Noord 

-Oorspronkelijk bericht-
Van: Pdns-users  Namens Pieter Lexis 
via Pdns-users
Verzonden: dinsdag 9 maart 2021 14:36
Aan: pdns-users@mailman.powerdns.com
Onderwerp: Re: [Pdns-users] DNSSEC UDP problems

Hi Steffen,

On 3/9/21 2:20 PM, Steffan via Pdns-users wrote:
> Hm that explanes a lot 
> 
> expand-alias=yes  was allready enabled i now have 
> outgoing-axfr-expand-alias=yes enabled  and restarted pdns
> 
> But it is still complaines abouth the A record
> 
> Error resolving for crazyforprint.nl ALIAS 81159.bodis.com over UDP, 
> A-record query returned Query Refused, returning SERVFAIL

Your upstream resolver (in the 'resolver' setting) sends REFUSED for some 
reason. when it is queried for 81159.bodis.com. You'll have to find out why 
that is.

Cheers,

Pieter

--
Pieter Lexis
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


Re: [Pdns-users] DNSSEC UDP problems

2021-03-09 Thread Pieter Lexis via Pdns-users
Hi Steffen,

On 3/9/21 2:20 PM, Steffan via Pdns-users wrote:
> Hm that explanes a lot 
> 
> expand-alias=yes  was allready enabled
> i now have outgoing-axfr-expand-alias=yes enabled  and restarted pdns
> 
> But it is still complaines abouth the A record
> 
> Error resolving for crazyforprint.nl ALIAS 81159.bodis.com over UDP, A-record 
> query returned Query Refused, returning SERVFAIL

Your upstream resolver (in the 'resolver' setting) sends REFUSED for
some reason. when it is queried for 81159.bodis.com. You'll have to find
out why that is.

Cheers,

Pieter

-- 
Pieter Lexis
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] DNSSEC UDP problems

2021-03-09 Thread Steffan via Pdns-users
Hm that explanes a lot 

expand-alias=yes  was allready enabled
i now have outgoing-axfr-expand-alias=yes enabled  and restarted pdns

pdnsutil check-zone crazyforprint.nl
Checked 5 records of 'crazyforprint.nl', 0 errors, 0 warnings.

But it is still complaines abouth the A record

Error resolving for crazyforprint.nl ALIAS 81159.bodis.com over UDP, A-record 
query returned Query Refused, returning SERVFAIL

Met vriendelijke groet,
Steffan Noord 

-Oorspronkelijk bericht-
Van: Pdns-users  Namens Pieter Lexis 
via Pdns-users
Verzonden: dinsdag 9 maart 2021 13:45
Aan: pdns-users@mailman.powerdns.com
Onderwerp: Re: [Pdns-users] DNSSEC UDP problems

Hi Steffen,

On 3/9/21 1:35 PM, Steffan via Pdns-users wrote:
> This domain is not using a A record
> 
> But a ALIAS and CNAME
> 
> Is that why dnssec failes?

Yes, see
https://doc.powerdns.com/authoritative/guides/alias.html#alias-and-dnssec

Cheers,

Pieter
--
Pieter Lexis
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


Re: [Pdns-users] DNSSEC UDP problems

2021-03-09 Thread Pieter Lexis via Pdns-users
Hi Steffen,

On 3/9/21 1:35 PM, Steffan via Pdns-users wrote:
> This domain is not using a A record
> 
> But a ALIAS and CNAME
> 
> Is that why dnssec failes?

Yes, see
https://doc.powerdns.com/authoritative/guides/alias.html#alias-and-dnssec

Cheers,

Pieter
-- 
Pieter Lexis
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] DNSSEC UDP problems

2021-03-09 Thread frank+pdns--- via Pdns-users
Hi Steffan,

Well, it clearly responds to a request for an A record...

Can you tell us a bit more about this zone? What does "pdnsutil check-zone 
crazyforprint.nl <http://crazyforprint.nl/>" say?

In general, it's a very bad idea to use CNAME records at the apex of a domain.

Frank

> On 9 Mar 2021, at 13:35, Steffan via Pdns-users 
> mailto:pdns-users@mailman.powerdns.com>> 
> wrote:
> 
> This domain is not using a A record
> But a ALIAS and CNAME
> Is that why dnssec failes?
>  
>  
> Met vriendelijke groet,
> Steffan Noord 
>  
> Van: frank+p...@tembo.be <mailto:frank+p...@tembo.be>  <mailto:frank+p...@tembo.be>> 
> Verzonden: dinsdag 9 maart 2021 13:34
> Aan: steffanno...@gmail.com <mailto:steffanno...@gmail.com>
> CC: pdns-users-ml 
> Onderwerp: Re: [Pdns-users] DNSSEC UDP problems
>  
> Hi Steffan,
>  
> Sometimes the dnsviz.net <http://dnsviz.net/> debugger is quite complete but 
> can be overwhelming at first. The Versisign Analyser can be easier to perform 
> basic checks. https://dnssec-analyzer.verisignlabs.com/crazyforprint.nl 
> <https://dnssec-analyzer.verisignlabs.com/crazyforprint.nl>.
>  
> In this case, it seems the zone is not properly signed, but DS records are 
> present in the parent zone:
>  
> While an RRSIG record does exist for e.g. the NS record for that zone:
>  
> ~ ❯ dig NS crazyforprint.nl <http://crazyforprint.nl/>. @ns1.tikklik.nl 
> +dnssec   
>  
> ...
> ;; ANSWER SECTION:
> crazyforprint.nl <http://crazyforprint.nl/>.   28800IN
>NS  ns2.tikklik.nl <http://ns2.tikklik.nl/>.
> crazyforprint.nl <http://crazyforprint.nl/>.   28800IN
>RRSIG   NS 13 2 28800 2021031800 2021022500 51602 crazyforprint.nl 
> <http://crazyforprint.nl/>. 
> PdcCtYO9yLGiUoz+c5WiajyiaLHOpiAvEpJkS4Ew99fJ5xWOX0vJZAA3 
> 4tAMzRJHO+aFBYvf7TvKWyL1Y8ytJQ==
> crazyforprint.nl <http://crazyforprint.nl/>.   28800IN
>NS  ns1.tikklik.nl <http://ns1.tikklik.nl/>.
>  
>  
> No RRSIG records are present for e.g. the A record:
>  
> ~ ❯ dig A crazyforprint.nl <http://crazyforprint.nl/>. @ns1.tikklik.nl 
> +dnssec   
>   
> ...
> ;; ANSWER SECTION:
> crazyforprint.nl <http://crazyforprint.nl/>.   10071IN
>A 199.59.242.153
>  
>  
> As the parent indicates that the zone is supposed to be signed, this results 
> in verification failures.
>  
>  
> Kind Regards,
>  
> Frank
> 
> 
>> On 9 Mar 2021, at 13:13, Steffan via Pdns-users 
>> mailto:pdns-users@mailman.powerdns.com>> 
>> wrote:
>>  
>> Hello,
>> 
>> Suddenly im getting DNSSE|C warnings.
>> Any idees what im missing here?
>> 
>> When analysing the dns with dnsviz.net <http://dnsviz.net/> im seeing
>> 
>> " The server(s) were not responsive to queries over UDP. 
>> (2a00:1bd0:740:1:2::2, 2a00:1bd0:740:1:46::162)
>> 
>> 
>> I dont understand why,
>> I disabled the firewall for testing
>> 
>> netstat -tulpn | grep pdns
>> tcp0  0 0.0.0.0:53  0.0.0.0:*   LISTEN   
>>861967/pdns_server
>> tcp6   0  0 :::53   :::*LISTEN   
>>861967/pdns_server
>> udp0  0 0.0.0.0:11597   0.0.0.0:*
>>861967/pdns_server
>> udp0  0 0.0.0.0:53  0.0.0.0:*
>>861967/pdns_server
>> udp6   0  0 :::12790:::* 
>>861967/pdns_server
>> udp6   0  0 :::53   :::* 
>>861967/pdns_server
>> 
>> 
>> 
>> Mar  9 13:07:30 ns1 systemd[1]: Starting PowerDNS Authoritative Server...
>> Mar  9 13:07:30 ns1 pdns_server[861967]: Loading 
>> '/usr/lib64/pdns/libgmysqlbackend.so'
>> Mar  9 13:07:30 ns1 pdns_server[861967]: This is a standalone pdns
>> Mar  9 13:07:30 ns1 pdns_server[861967]: Listening on controlsocket in 
>> '/run/pdns/pdns.controlsocket'
>> Mar  9 13:07:30 ns1 pdns_server[861967]: UDP server bound to 0.0.0.0:53
>> Mar  9 13:07:30 ns1 pdns_server[861967]: UDP server bound to [::]:53
>> Mar  9 13:07:30 ns1 pdns_server[861967]: TCP serv

Re: [Pdns-users] DNSSEC UDP problems

2021-03-09 Thread Pieter Lexis via Pdns-users
Hi Steffen,

On 3/9/21 1:13 PM, Steffan via Pdns-users wrote:
> Suddenly im getting DNSSE|C warnings.
> Any idees what im missing here?
> 
> When analysing the dns with dnsviz.net im seeing
> 
> " The server(s) were not responsive to queries over UDP. 
> (2a00:1bd0:740:1:2::2, 2a00:1bd0:740:1:46::162)
> 
> I dont understand why,
> I disabled the firewall for testing
> 
> netstat -tulpn | grep pdns
> tcp0  0 0.0.0.0:53  0.0.0.0:*   LISTEN
>   861967/pdns_server
> tcp6   0  0 :::53   :::*LISTEN
>   861967/pdns_server
> udp0  0 0.0.0.0:11597   0.0.0.0:* 
>   861967/pdns_server
> udp0  0 0.0.0.0:53  0.0.0.0:* 
>   861967/pdns_server
> udp6   0  0 :::12790:::*  
>   861967/pdns_server
> udp6   0  0 :::53   :::*  
>   861967/pdns_server

>From my vantage points (multiple networks) I can reach those nameservers
over IPv6. If SIDN or DNSVIZ can't, there probably is an issue with the
IPv6 routing along the path from them to your nameservers. Problems like
this _usually_ mean a network, firewall, or middle-box is doing things
to either the incoming query or the outgoing response from the nameserver.

However, your actual problem is this message:

crazyforprint.nl/A: No RRSIG covering the RRset was returned in the
response. (5.22.255.2, 46.182.222.162, UDP_-_EDNS0_4096_D_KN)

This is the case over v4 _and_ v6. The zone is signed, but no RRSIG is
sent on the response for the A record of crazyforprint.nl. Can you
describe your set up, including the full configuration of PowerDNS
(without passwords). Can you also check what `pdnsutil check-zone
crazyforprint.nl` and `pdnsutil show-zone crazyforprint.nl` reports?

The SOA and DNSKEY responses do carry RRSIGs, which is weird though. Is
there a cache or middle box in front of the auth that strips these?

Cheers,

Pieter
-- 
Pieter Lexis
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] DNSSEC UDP problems

2021-03-09 Thread Steffan via Pdns-users
This domain is not using a A record

But a ALIAS and CNAME

Is that why dnssec failes?

 

 

Met vriendelijke groet,

Steffan Noord 

 

Van: frank+p...@tembo.be  
Verzonden: dinsdag 9 maart 2021 13:34
Aan: steffanno...@gmail.com
CC: pdns-users-ml 
Onderwerp: Re: [Pdns-users] DNSSEC UDP problems

 

Hi Steffan,

 

Sometimes the dnsviz.net <http://dnsviz.net>  debugger is quite complete but 
can be overwhelming at first. The Versisign Analyser can be easier to perform 
basic checks. https://dnssec-analyzer.verisignlabs.com/crazyforprint.nl.

 

In this case, it seems the zone is not properly signed, but DS records are 
present in the parent zone:

 

While an RRSIG record does exist for e.g. the NS record for that zone:

 

~ ❯ dig NS crazyforprint.nl <http://crazyforprint.nl> . @ns1.tikklik.nl +dnssec 

   

...

;; ANSWER SECTION:

crazyforprint.nl <http://crazyforprint.nl> .   28800IN  
 NS  ns2.tikklik.nl <http://ns2.tikklik.nl> .

crazyforprint.nl <http://crazyforprint.nl> .   28800IN  
 RRSIG   NS 13 2 28800 2021031800 2021022500 51602 crazyforprint.nl 
<http://crazyforprint.nl> . 
PdcCtYO9yLGiUoz+c5WiajyiaLHOpiAvEpJkS4Ew99fJ5xWOX0vJZAA3 
4tAMzRJHO+aFBYvf7TvKWyL1Y8ytJQ==

crazyforprint.nl <http://crazyforprint.nl> .   28800IN  
 NS  ns1.tikklik.nl <http://ns1.tikklik.nl> .

 

 

No RRSIG records are present for e.g. the A record:

 

~ ❯ dig A crazyforprint.nl <http://crazyforprint.nl> . @ns1.tikklik.nl +dnssec  

   

...

;; ANSWER SECTION:

crazyforprint.nl <http://crazyforprint.nl> .   10071IN  
 A 199.59.242.153

 

 

As the parent indicates that the zone is supposed to be signed, this results in 
verification failures.

 

 

Kind Regards,

 

Frank





On 9 Mar 2021, at 13:13, Steffan via Pdns-users 
mailto:pdns-users@mailman.powerdns.com> > 
wrote:

 

Hello,

Suddenly im getting DNSSE|C warnings.
Any idees what im missing here?

When analysing the dns with dnsviz.net <http://dnsviz.net>  im seeing

" The server(s) were not responsive to queries over UDP. (2a00:1bd0:740:1:2::2, 
2a00:1bd0:740:1:46::162)


I dont understand why,
I disabled the firewall for testing

netstat -tulpn | grep pdns
tcp0  0 0.0.0.0:53  0.0.0.0:*   LISTEN  
861967/pdns_server
tcp6   0  0 :::53   :::*LISTEN  
861967/pdns_server
udp0  0 0.0.0.0:11597   0.0.0.0:*   
861967/pdns_server
udp0  0 0.0.0.0:53  0.0.0.0:*   
861967/pdns_server
udp6   0  0 :::12790:::*
861967/pdns_server
udp6   0  0 :::53   :::*
861967/pdns_server



Mar  9 13:07:30 ns1 systemd[1]: Starting PowerDNS Authoritative Server...
Mar  9 13:07:30 ns1 pdns_server[861967]: Loading 
'/usr/lib64/pdns/libgmysqlbackend.so'
Mar  9 13:07:30 ns1 pdns_server[861967]: This is a standalone pdns
Mar  9 13:07:30 ns1 pdns_server[861967]: Listening on controlsocket in 
'/run/pdns/pdns.controlsocket'
Mar  9 13:07:30 ns1 pdns_server[861967]: UDP server bound to 0.0.0.0:53
Mar  9 13:07:30 ns1 pdns_server[861967]: UDP server bound to [::]:53
Mar  9 13:07:30 ns1 pdns_server[861967]: TCP server bound to 0.0.0.0:53
Mar  9 13:07:30 ns1 pdns_server[861967]: TCP server bound to [::]:53
Mar  9 13:07:30 ns1 pdns_server[861967]: PowerDNS Authoritative Server 
4.5.0-alpha0.810.master.ge95f1270a (C) 2001-2021 PowerDNS.COM 
<http://PowerDNS.COM>  BV
Mar  9 13:07:30 ns1 pdns_server[861967]: Using 64-bits mode. Built using gcc 
8.3.1 20191121 (Red Hat 8.3.1-5) on Mar  4 2021 17:46:55 by root@8780793e1b61.
Mar  9 13:07:30 ns1 pdns_server[861967]: 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.
Mar  9 13:07:30 ns1 pdns_server[861967]: DNS Proxy launched, local port 33452, 
remote 208.67.220.220:53
Mar  9 13:07:30 ns1 pdns_server[861967]: Not validating response for security 
status update, this is a non-release version
Mar  9 13:07:30 ns1 pdns_server[861967]: Master/slave communicator launching
Mar  9 13:07:30 ns1 pdns_server[861967]: Creating backend connection for TCP
Mar  9 13:07:30 ns1 pdns_server[861967]: About to create 3 backend threads for 
UDP
Mar  9 13:07:30 ns1 systemd[1]: Started PowerDNS Authoritative Server.
Mar  9 13:07:30 ns1 pdns_server[861967]: Done launching threads, ready to 
distribute questions
Mar  9 13:07:30

Re: [Pdns-users] DNSSEC UDP problems

2021-03-09 Thread frank+pdns--- via Pdns-users
Hi Steffan,

Sometimes the dnsviz.net debugger is quite complete but can be overwhelming at 
first. The Versisign Analyser can be easier to perform basic checks. 
https://dnssec-analyzer.verisignlabs.com/crazyforprint.nl.

In this case, it seems the zone is not properly signed, but DS records are 
present in the parent zone:

While an RRSIG record does exist for e.g. the NS record for that zone:

~ ❯ dig NS crazyforprint.nl. @ns1.tikklik.nl +dnssec
...
;; ANSWER SECTION:
crazyforprint.nl.   28800   IN  NS  ns2.tikklik.nl.
crazyforprint.nl.   28800   IN  RRSIG   NS 13 2 28800 2021031800 
2021022500 51602 crazyforprint.nl. 
PdcCtYO9yLGiUoz+c5WiajyiaLHOpiAvEpJkS4Ew99fJ5xWOX0vJZAA3 
4tAMzRJHO+aFBYvf7TvKWyL1Y8ytJQ=crazyforprint.nl.   28800   IN  NS  
ns1.tikklik.nl.


No RRSIG records are present for e.g. the A record:

~ ❯ dig A crazyforprint.nl. @ns1.tikklik.nl +dnssec
...
;; ANSWER SECTION:
crazyforprint.nl.   10071   IN  A   199.59.242.153


As the parent indicates that the zone is supposed to be signed, this results in 
verification failures.


Kind Regards,

Frank

> On 9 Mar 2021, at 13:13, Steffan via Pdns-users 
>  wrote:
>
> Hello,
>
> Suddenly im getting DNSSE|C warnings.
> Any idees what im missing here?
>
> When analysing the dns with dnsviz.net im seeing
>
> " The server(s) were not responsive to queries over UDP. 
> (2a00:1bd0:740:1:2::2, 2a00:1bd0:740:1:46::162)
>
>
> I dont understand why,
> I disabled the firewall for testing
>
> netstat -tulpn | grep pdns
> tcp0  0 0.0.0.0:53  0.0.0.0:*   LISTEN
>   861967/pdns_server
> tcp6   0  0 :::53   :::*LISTEN
>   861967/pdns_server
> udp0  0 0.0.0.0:11597   0.0.0.0:* 
>   861967/pdns_server
> udp0  0 0.0.0.0:53  0.0.0.0:* 
>   861967/pdns_server
> udp6   0  0 :::12790:::*  
>   861967/pdns_server
> udp6   0  0 :::53   :::*  
>   861967/pdns_server
>
>
>
> Mar  9 13:07:30 ns1 systemd[1]: Starting PowerDNS Authoritative Server...
> Mar  9 13:07:30 ns1 pdns_server[861967]: Loading 
> '/usr/lib64/pdns/libgmysqlbackend.so'
> Mar  9 13:07:30 ns1 pdns_server[861967]: This is a standalone pdns
> Mar  9 13:07:30 ns1 pdns_server[861967]: Listening on controlsocket in 
> '/run/pdns/pdns.controlsocket'
> Mar  9 13:07:30 ns1 pdns_server[861967]: UDP server bound to 0.0.0.0:53
> Mar  9 13:07:30 ns1 pdns_server[861967]: UDP server bound to [::]:53
> Mar  9 13:07:30 ns1 pdns_server[861967]: TCP server bound to 0.0.0.0:53
> Mar  9 13:07:30 ns1 pdns_server[861967]: TCP server bound to [::]:53
> Mar  9 13:07:30 ns1 pdns_server[861967]: PowerDNS Authoritative Server 
> 4.5.0-alpha0.810.master.ge95f1270a (C) 2001-2021 PowerDNS.COM BV
> Mar  9 13:07:30 ns1 pdns_server[861967]: Using 64-bits mode. Built using gcc 
> 8.3.1 20191121 (Red Hat 8.3.1-5) on Mar  4 2021 17:46:55 by root@8780793e1b61.
> Mar  9 13:07:30 ns1 pdns_server[861967]: 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.
> Mar  9 13:07:30 ns1 pdns_server[861967]: DNS Proxy launched, local port 
> 33452, remote 208.67.220.220:53
> Mar  9 13:07:30 ns1 pdns_server[861967]: Not validating response for security 
> status update, this is a non-release version
> Mar  9 13:07:30 ns1 pdns_server[861967]: Master/slave communicator launching
> Mar  9 13:07:30 ns1 pdns_server[861967]: Creating backend connection for TCP
> Mar  9 13:07:30 ns1 pdns_server[861967]: About to create 3 backend threads 
> for UDP
> Mar  9 13:07:30 ns1 systemd[1]: Started PowerDNS Authoritative Server.
> Mar  9 13:07:30 ns1 pdns_server[861967]: Done launching threads, ready to 
> distribute questions
> Mar  9 13:07:30 ns1 pdns_server[861967]: Cleared signature cache.
>
> Met vriendelijke groet,
> Steffan Noord
>
> ___
> Pdns-users mailing list
> Pdns-users@mailman.powerdns.com
> https://mailman.powerdns.com/mailman/listinfo/pdns-users

Frank Louwers
PowerDNS Certified Consultant @ Kiwazo.be




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


Re: [Pdns-users] DNSSEC UDP problems

2021-03-09 Thread Steffan via Pdns-users
I dont think so
Im getting warnings from SIDN

validation failure : no signatures from 127.0.0.1
IPv6 address rec

Met vriendelijke groet,
Steffan Noord 

-Oorspronkelijk bericht-
Van: Klaus Darilion  
Verzonden: dinsdag 9 maart 2021 13:18
Aan: steffanno...@gmail.com
Onderwerp: AW: [Pdns-users] DNSSEC UDP problems

Maybe just a routing problem form dnsviz.net? dnsviz is known to have
someimtes IPv6 routing problems.

regards
Klaus

> -Ursprüngliche Nachricht-
> Von: Pdns-users  Im Auftrag 
> von Steffan via Pdns-users
> Gesendet: Dienstag, 9. März 2021 13:14
> An: pdns-users@mailman.powerdns.com
> Betreff: [Pdns-users] DNSSEC UDP problems
> 
> Hello,
> 
> Suddenly im getting DNSSE|C warnings.
> Any idees what im missing here?
> 
> When analysing the dns with dnsviz.net im seeing
> 
> " The server(s) were not responsive to queries over UDP.
> (2a00:1bd0:740:1:2::2, 2a00:1bd0:740:1:46::162)
> 
> 
> I dont understand why,
> I disabled the firewall for testing
> 
> netstat -tulpn | grep pdns
> tcp0  0 0.0.0.0:53  0.0.0.0:*   LISTEN
> 861967/pdns_server
> tcp6   0  0 :::53   :::*LISTEN
861967/pdns_server
> udp0  0 0.0.0.0:11597   0.0.0.0:*
> 861967/pdns_server
> udp0  0 0.0.0.0:53  0.0.0.0:*
861967/pdns_server
> udp6   0  0 :::12790:::*
861967/pdns_server
> udp6   0  0 :::53   :::*
861967/pdns_server
> 
> 
> 
> Mar  9 13:07:30 ns1 systemd[1]: Starting PowerDNS Authoritative Server...
> Mar  9 13:07:30 ns1 pdns_server[861967]: Loading 
> '/usr/lib64/pdns/libgmysqlbackend.so'
> Mar  9 13:07:30 ns1 pdns_server[861967]: This is a standalone pdns Mar  
> 9 13:07:30 ns1 pdns_server[861967]: Listening on controlsocket in 
> '/run/pdns/pdns.controlsocket'
> Mar  9 13:07:30 ns1 pdns_server[861967]: UDP server bound to 
> 0.0.0.0:53 Mar  9 13:07:30 ns1 pdns_server[861967]: UDP server bound 
> to [::]:53 Mar  9 13:07:30 ns1 pdns_server[861967]: TCP server bound 
> to 0.0.0.0:53 Mar  9 13:07:30 ns1 pdns_server[861967]: TCP server 
> bound to [::]:53 Mar  9 13:07:30 ns1 pdns_server[861967]: PowerDNS 
> Authoritative Server 4.5.0-alpha0.810.master.ge95f1270a (C) 2001-2021 
> PowerDNS.COM BV Mar  9 13:07:30 ns1 pdns_server[861967]: Using 64-bits 
> mode. Built using gcc
> 8.3.1 20191121 (Red Hat 8.3.1-5) on Mar  4 2021 17:46:55 by 
> root@8780793e1b61.
> Mar  9 13:07:30 ns1 pdns_server[861967]: 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.
> Mar  9 13:07:30 ns1 pdns_server[861967]: DNS Proxy launched, local 
> port 33452, remote 208.67.220.220:53 Mar  9 13:07:30 ns1 
> pdns_server[861967]: Not validating response for security status 
> update, this is a non-release version Mar  9 13:07:30 ns1 
> pdns_server[861967]: Master/slave communicator launching Mar  9 
> 13:07:30 ns1 pdns_server[861967]: Creating backend connection for TCP 
> Mar  9 13:07:30 ns1 pdns_server[861967]: About to create 3 backend 
> threads for UDP Mar  9 13:07:30 ns1 systemd[1]: Started PowerDNS 
> Authoritative Server.
> Mar  9 13:07:30 ns1 pdns_server[861967]: Done launching threads, ready 
> to distribute questions Mar  9 13:07:30 ns1 pdns_server[861967]: 
> Cleared signature cache.
> 
> Met vriendelijke groet,
> Steffan Noord
> 
> ___
> 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


[Pdns-users] DNSSEC UDP problems

2021-03-09 Thread Steffan via Pdns-users
Hello,

Suddenly im getting DNSSE|C warnings.
Any idees what im missing here?

When analysing the dns with dnsviz.net im seeing

" The server(s) were not responsive to queries over UDP. (2a00:1bd0:740:1:2::2, 
2a00:1bd0:740:1:46::162)


I dont understand why,
I disabled the firewall for testing

netstat -tulpn | grep pdns
tcp0  0 0.0.0.0:53  0.0.0.0:*   LISTEN  
861967/pdns_server
tcp6   0  0 :::53   :::*LISTEN  
861967/pdns_server
udp0  0 0.0.0.0:11597   0.0.0.0:*   
861967/pdns_server
udp0  0 0.0.0.0:53  0.0.0.0:*   
861967/pdns_server
udp6   0  0 :::12790:::*
861967/pdns_server
udp6   0  0 :::53   :::*
861967/pdns_server



Mar  9 13:07:30 ns1 systemd[1]: Starting PowerDNS Authoritative Server...
Mar  9 13:07:30 ns1 pdns_server[861967]: Loading 
'/usr/lib64/pdns/libgmysqlbackend.so'
Mar  9 13:07:30 ns1 pdns_server[861967]: This is a standalone pdns
Mar  9 13:07:30 ns1 pdns_server[861967]: Listening on controlsocket in 
'/run/pdns/pdns.controlsocket'
Mar  9 13:07:30 ns1 pdns_server[861967]: UDP server bound to 0.0.0.0:53
Mar  9 13:07:30 ns1 pdns_server[861967]: UDP server bound to [::]:53
Mar  9 13:07:30 ns1 pdns_server[861967]: TCP server bound to 0.0.0.0:53
Mar  9 13:07:30 ns1 pdns_server[861967]: TCP server bound to [::]:53
Mar  9 13:07:30 ns1 pdns_server[861967]: PowerDNS Authoritative Server 
4.5.0-alpha0.810.master.ge95f1270a (C) 2001-2021 PowerDNS.COM BV
Mar  9 13:07:30 ns1 pdns_server[861967]: Using 64-bits mode. Built using gcc 
8.3.1 20191121 (Red Hat 8.3.1-5) on Mar  4 2021 17:46:55 by root@8780793e1b61.
Mar  9 13:07:30 ns1 pdns_server[861967]: 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.
Mar  9 13:07:30 ns1 pdns_server[861967]: DNS Proxy launched, local port 33452, 
remote 208.67.220.220:53
Mar  9 13:07:30 ns1 pdns_server[861967]: Not validating response for security 
status update, this is a non-release version
Mar  9 13:07:30 ns1 pdns_server[861967]: Master/slave communicator launching
Mar  9 13:07:30 ns1 pdns_server[861967]: Creating backend connection for TCP
Mar  9 13:07:30 ns1 pdns_server[861967]: About to create 3 backend threads for 
UDP
Mar  9 13:07:30 ns1 systemd[1]: Started PowerDNS Authoritative Server.
Mar  9 13:07:30 ns1 pdns_server[861967]: Done launching threads, ready to 
distribute questions
Mar  9 13:07:30 ns1 pdns_server[861967]: Cleared signature cache.

Met vriendelijke groet,
Steffan Noord 

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


[Pdns-users] DNSSEC signature expirations

2020-06-19 Thread Mike via Pdns-users
Hello,

    I have dnssec set up for my domains and powerdns made it a dead
simple. Its been operating without issue for quite a while now without
problem, but then I had a strange network issue and one of my slave
servers couldn't get fresh AXFR from the hidden master, resulting in
inconsistent data on one of the four servers for my domains, resulting
in a periodic dnssec validation failure that was a bit difficult to
troubleshoot. I am now adding some more automated testing to my internal
systems monitoring regime so that I can be notified in the future if any
domain approaches the signature expiration date. But, powerdns seems to
assign have relatively short signature expiration times, and I want to
understand the process a bit more. It seems like powerdns just always
gives a 2 week expiration and doesn't refresh or update that until it
has like a week left before expiration. I caught the bit about Thursdays
etc and I get that. But, I might want something different... paypal.com
for example, seems to always be fresh at 30 days for example. I likely
would want a longer expiration than the powerdns default because, if
there is a problem, maybe I need some time to fix underlying issues. Or
maybe I just like the idea of refreshing the signature once per day. I
do trust the developers to know way more than I, but I'd love to know
where these knobs are and how to tweak them if possible.


Thanks.

Mike-

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


Re: [Pdns-users] dnssec and lua-config--file

2020-05-13 Thread Brian Candler via Pdns-users

On 13/05/2020 09:05, Pierrick CHOVELON wrote:

Thx, both of you.
It works like a charm.

Great.  Also look at the "auth-zones" option - depending on your use 
case it may be another option.


https://docs.powerdns.com/recursor/settings.html#auth-zones


I'll have a look on the forward-zones-file. Are modifications taken on 
the fly or it is necessary to restart the recursor ?


I believe that if you use forward-zones-file, then "rec_control 
reload-zones" will be sufficient without a full restart.


https://docs.powerdns.com/recursor/manpages/rec_control.1.html#commands


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


Re: [Pdns-users] dnssec and lua-config--file

2020-05-13 Thread Pierrick CHOVELON via Pdns-users
Thx, both of you.
It works like a charm.

I'll have a look on the forward-zones-file. Are modifications taken on the
fly or it is necessary to restart the recursor ?

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


Re: [Pdns-users] dnssec and lua-config--file

2020-05-13 Thread Brian Candler via Pdns-users

On 13/05/2020 08:18, Pierrick CHOVELON via Pdns-users wrote:


Now, let's imagine I want to resolve foo.example.net 
 and also bar.example.net 
.


Do I have to create two zone files one for foo.example.net 
 and one for bar.example.net 
) like I did previously ? or is it possible to 
have a single one file (example.net ) in which I 
add the two records ?

In that case, will it have some issue with others records ?


Pdns separates the recursor and authoritate server roles.

At the recursor, you will need forward rules for foo.example.net and 
bar.example.net pointing to your authoritative server, which is 
providing the fake/non-public data for foo.example.net and 
bar.example.net.  "forward-zones-file" is the easiest way to do that.


At the authoritative server, I'd say it's least confusing if you also 
create separate zones for foo.example.net and bar.example.net.  However 
you *could* make it authoritative for example.net (or .net, or even the 
entire DNS root).  If it's private auth DNS, and it's not going to be 
receiving delegated queries from anyone else on the Internet, it doesn't 
matter.


Are you trying to mix in individual private hosts to a public domain?  
The way I prefer to handle this is to have a single domain for private 
DNS, e.g. int.example.net, and put everything under there - 
foo.int.example.net, bar.int.example.net.  It's a lot cleaner, less work 
to manage, and less opportunity for mistakes.


Also, in the public DNS I put an NS record for int.example.net pointing 
to a separate public-facing DNS server with an empty zone file for 
int.example.net.  This server permits dynamic DNS updates from my 
internal machines - I use it for responding to dns01 challenges for 
LetsEncrypt certificates.  This means internal machines can have valid 
certificates, even though foo.int.example.net is not reachable from the 
public Internet, and its address is not visible in the public DNS either.


Regards,

Brian.

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


Re: [Pdns-users] dnssec and lua-config--file

2020-05-13 Thread Pierrick CHOVELON via Pdns-users
Hi,

Thank you very much, it works. (I've some typos in the named.conf files
too).
For the hint file, it was in the default configuration.

Now, let's imagine I want to resolve foo.example.net and also
bar.example.net.

Do I have to create two zone files one for foo.example.net  and one for
bar.example.net) like I did previously ? or is it possible to have a single
one file (example.net) in which I add the two records ?
In that case, will it have some issue with others records ?

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


Re: [Pdns-users] dnssec and lua-config--file

2020-05-12 Thread Nico CARTRON via Pdns-users
On 12-May-2020 19:11 CEST,  wrote:

> Hi,
> 
> Yes I do :
> 
> cat recursor.conf | grep -v '^\s*$\|^\s*\#'
> config-dir=/etc/powerdns
> dnssec-log-bogus=yes
> hint-file=/usr/share/dns/root.hints
> local-address=0.0.0.0
> local-port=3334
> *lua-config-file=/etc/powerdns/recursor.lua*
> quiet=yes
> security-poll-suffix=
> setgid=pdns
> setuid=pdns
> trace=fail
> forward-zones=example.net=192.168.1.28:
> 
> Maybe I'm using the wrong syntax in forward-zones ...

Nope, the syntax is correct.

However, in your original email, you said that you wanted to:

   - resolve normally example.net (I fixed a typo in the domain name,
 since you wrote `exemple.net`)
   - forward the request foo.example.net to an internal authoritative
   server

Your configuration forwards *all* requests to `example.net` to the
192.168.1.28 server.
You should replace it with:
forward-zones=foo.example.net=192.168.1.28: 

Also, can you send the result of a request for
.foo.example.net, e.g. using dig?

Side question: why using `hint-file`? Are you using a specific root
servers configuration? If not, you don't need that.

Cheers,

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


Re: [Pdns-users] dnssec and lua-config--file

2020-05-12 Thread Pierrick CHOVELON via Pdns-users
Hi,

Yes I do :

cat recursor.conf | grep -v '^\s*$\|^\s*\#'
config-dir=/etc/powerdns
dnssec-log-bogus=yes
hint-file=/usr/share/dns/root.hints
local-address=0.0.0.0
local-port=3334
*lua-config-file=/etc/powerdns/recursor.lua*
quiet=yes
security-poll-suffix=
setgid=pdns
setuid=pdns
trace=fail
forward-zones=example.net=192.168.1.28:

Maybe I'm using the wrong syntax in forward-zones ...

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


Re: [Pdns-users] dnssec and lua-config--file

2020-05-12 Thread Nico CARTRON via Pdns-users
Hi Pierre,

On 12-May-2020 16:59 CEST,  wrote:

> Hello,
> 
> I'm testing pdns-recursor and I'd like to config it in order to :
> 
>- resolves normally exemple.net
>- forwards the request foo.example.net to an internal authoritative
>server
> 
> I've read the documentation, and found :
> https://docs.powerdns.com/recursor/settings.html#forward-zones
> I've seen the remark regarding DNSSEC and thus use a lua-config-file in
> which I added, to not use DNSSEC for this particular domain name :
> addNTA("foo.example.net", "test")
> 
> However, I can't get any answer and the log is quite obvious :
> "Wants DNSSEC processing in query A ..."
> 
> It seems that my lua file isn't taken.
> Am I wrong ? How can I check whether the lua file is used or not .

Did you specify the path to your Lua file in the recursor.conf file?
Something like:

lua-config-file=

If so, can you share you recursor.conf?

Cheers,

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


[Pdns-users] dnssec and lua-config--file

2020-05-12 Thread Pierrick CHOVELON via Pdns-users
Hello,

I'm testing pdns-recursor and I'd like to config it in order to :

   - resolves normally exemple.net
   - forwards the request foo.example.net to an internal authoritative
   server

I've read the documentation, and found :
https://docs.powerdns.com/recursor/settings.html#forward-zones
I've seen the remark regarding DNSSEC and thus use a lua-config-file in
which I added, to not use DNSSEC for this particular domain name :
addNTA("foo.example.net", "test")

However, I can't get any answer and the log is quite obvious :
"Wants DNSSEC processing in query A ..."

It seems that my lua file isn't taken.
Am I wrong ? How can I check whether the lua file is used or not .

Thx in advance

__
*Pierrick CHOVELON I *Ingénieur système

*Advanced Software I IT*
+33 4 77 43 27 05
pierrick.chove...@savoye.com
*SAVOYE - 8, rue de la Richelandière - 42100 - Saint-Etienne - France*
*Savoye recrute !  - *www.savoye.com
___
Pdns-users mailing list
Pdns-users@mailman.powerdns.com
https://mailman.powerdns.com/mailman/listinfo/pdns-users


Re: [Pdns-users] DNSSEC and SOA records

2019-07-22 Thread Nico CARTRON
Hi Tamer,

On 21-Jul-2019 22:10 CEST,  wrote:

> Hello,
> 
> I have setup PowerDNS 4.2.0-rc2 through the CentOS 7 repository. Everything
> works fine except SOA replies in AUTHORITY SECTIONs with DNSSEC enabled. We
> are testing the domain through the well-known validator Internet.nl and it
> results in a BOGUS validation. They state that it's because test.nizari.nl
> is not returning SOA records in the AUTHORITY SECTION.

so the zone you're testing with is test.nizari.nl, right?
It seems there's no delegation for this zone, hence no SOA.

> The following works and returns a proper SOA answer:
> dig soa nizari.nl
> dig soa test.nizari.nl @ns1.nizari.nl
> dig soa test.nizari.nl @1.1.1.1
> dig soa test.nizari.nl @8.8.8.8 +cd
> 
> The following does not work and results in a SERVFAIL:
> dig soa test.nizari.nl
> dig soa test.nizari.nl @8.8.8.8
> 
> Is this normal behaviour or is there something wrong with my config? The
> nameservers run simply in a MySQL cluster.
> 
> pdns.conf:
> local-address=0.0.0.0
> local-ipv6=::
> local-port=5300
> launch=gmysql,geoip
> gmysql-host=
> gmysql-user=
> gmysql-dbname=
> gmysql-password=
> geoip-database-files
> loglevel=9
> enable-lua-records=yes
> edns-subnet-processing=yes
> log-dns-queries=yes
> gmysql-dnssec=yes
> disable-syslog=yes
> resolver=8.8.8.8,[2001:4860:4860::]

Also, why are you using the 'resolver' setting without 'expand-alias'?
This setting is not meant to specify the resolver to send recursive requests to,
but is related to the ALIAS records
(https://doc.powerdns.com/authoritative/guides/alias.html).

Cheers,

-- 
Nico

> If there is something wrong with my config, why does 1.1.1.1 work and
> 8.8.8.8 not?
> I see no errors in the logs and all other DNS related stuff is working.
> 
> DNSVIZ results are OK.
>
> Any help or tips can be of use, I have been debugging this for three days
> now. Thank you for reading!
___
Pdns-users mailing list
Pdns-users@mailman.powerdns.com
https://mailman.powerdns.com/mailman/listinfo/pdns-users


[Pdns-users] DNSSEC and SOA records

2019-07-21 Thread Tamer Canki
Hello,

I have setup PowerDNS 4.2.0-rc2 through the CentOS 7 repository. Everything
works fine except SOA replies in AUTHORITY SECTIONs with DNSSEC enabled. We
are testing the domain through the well-known validator Internet.nl and it
results in a BOGUS validation. They state that it's because test.nizari.nl
is not returning SOA records in the AUTHORITY SECTION.

The following works and returns a proper SOA answer:
dig soa nizari.nl
dig soa test.nizari.nl @ns1.nizari.nl
dig soa test.nizari.nl @1.1.1.1
dig soa test.nizari.nl @8.8.8.8 +cd

The following does not work and results in a SERVFAIL:
dig soa test.nizari.nl
dig soa test.nizari.nl @8.8.8.8

Is this normal behaviour or is there something wrong with my config? The
nameservers run simply in a MySQL cluster.

pdns.conf:
local-address=0.0.0.0
local-ipv6=::
local-port=5300
launch=gmysql,geoip
gmysql-host=
gmysql-user=
gmysql-dbname=
gmysql-password=
geoip-database-files
loglevel=9
enable-lua-records=yes
edns-subnet-processing=yes
log-dns-queries=yes
gmysql-dnssec=yes
disable-syslog=yes
resolver=8.8.8.8,[2001:4860:4860::]

If there is something wrong with my config, why does 1.1.1.1 work and
8.8.8.8 not?
I see no errors in the logs and all other DNS related stuff is working.

DNSVIZ results are OK.

Any help or tips can be of use, I have been debugging this for three days
now. Thank you for reading!
___
Pdns-users mailing list
Pdns-users@mailman.powerdns.com
https://mailman.powerdns.com/mailman/listinfo/pdns-users


Re: [Pdns-users] DNSSEC same key for all

2019-05-20 Thread bert hubert
On Mon, May 20, 2019 at 10:56:33AM +0200, Bart Mortelmans wrote:
> If you're using MySQL backend, then I guess you could turn the cryptokeys
> table into a view that would return the same key for every domain name. But
> in general I think that would be bad practice and creating a new KEYSET for
> every domain name at the registry would be preferable.

So as a general note, running PowerDNS on MySQL views has uncovered
performance problems, memory leaks and bugs - most likely within MySQL.

So before attempting MySQL views for PowerDNS operations, please test really
well & know that if you report problems, the first thing we'll do is ask if
you can reproduce them using our unmodified schema.

We've not heard of problems when using PostgreSQL views. I just found out
that sqlite also has views, and we've also not heard problems about those.
But I'm unsure if anyone is doing that.

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


Re: [Pdns-users] DNSSEC same key for all

2019-05-20 Thread azurit

Ok, thanks everyone for suggestions!

azur





Citát frank+pdns--- via Pdns-users :


Hi Azur,

Ha, indeed, it seems they did…

Best practise would still be to have a 1:1 relationship between a  
keyset and a domain, so create a new keyset for every dnssec-domain.


If you do want to reuse your dnssec keys, you have a few options:

- fiddle with the custom query options in pdns.conf to return “the  
correct record” for a domain, maybe based on a view in the db?


- keep the “golden” cryptokey you want to use somewhere in your  
code, and use the API or the DB to insert that particular key as the  
domain’s cryptokey. Disadvantage: whenever you want to change the  
key, you’d have to update all the cryptokey records


- rethink everything, go the recommended route and use a different  
DS/KEYSET for every domain (which means creating a new KEYSET for  
every domain)


Kind Regards,

Frank Louwers
Certified PowerDNS Consultant @ Kiwazo.be 








On 20 May 2019, at 10:41, azu...@pobox.sk  wrote:

Hi Frank,

it's mandatory for .CZ domains, so if you don't sign every domain  
with the same key, you need to register a KEYSET for every domain.  
So this is what i'm trying to solve.






Citát frank+pdns--- via Pdns-users >:



Hi Azur,

It’s possible to do so, by manipulating the database directly (see  
the cryptokeys table).


However, let’s take a step back: what problem are you trying to  
solve? As far as I know, there’s not a single TLD where the use of  
KEYSETs is mandatory. Some offer it as an extra feature, but I am  
not aware of any TLD where this would be mandatory.


Kind Regards,

Frank Louwers
Certified PowerDNS Consultant @ Kiwazo.be 
___
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  





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


Re: [Pdns-users] DNSSEC same key for all

2019-05-20 Thread frank+pdns--- via Pdns-users
Hi Azur,

Ha, indeed, it seems they did…

Best practise would still be to have a 1:1 relationship between a keyset and a 
domain, so create a new keyset for every dnssec-domain.

If you do want to reuse your dnssec keys, you have a few options:

- fiddle with the custom query options in pdns.conf to return “the correct 
record” for a domain, maybe based on a view in the db?

- keep the “golden” cryptokey you want to use somewhere in your code, and use 
the API or the DB to insert that particular key as the domain’s cryptokey. 
Disadvantage: whenever you want to change the key, you’d have to update all the 
cryptokey records

- rethink everything, go the recommended route and use a different DS/KEYSET 
for every domain (which means creating a new KEYSET for every domain)

Kind Regards,

Frank Louwers
Certified PowerDNS Consultant @ Kiwazo.be 







> On 20 May 2019, at 10:41, azu...@pobox.sk  wrote:
> 
> Hi Frank,
> 
> it's mandatory for .CZ domains, so if you don't sign every domain with the 
> same key, you need to register a KEYSET for every domain. So this is what i'm 
> trying to solve.
> 
> 
> 
> 
> 
> Citát frank+pdns--- via Pdns-users  >:
> 
>> Hi Azur,
>> 
>> It’s possible to do so, by manipulating the database directly (see the 
>> cryptokeys table).
>> 
>> However, let’s take a step back: what problem are you trying to solve? As 
>> far as I know, there’s not a single TLD where the use of KEYSETs is 
>> mandatory. Some offer it as an extra feature, but I am not aware of any TLD 
>> where this would be mandatory.
>> 
>> Kind Regards,
>> 
>> Frank Louwers
>> Certified PowerDNS Consultant @ Kiwazo.be 
>> ___
>> 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 
> 

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


Re: [Pdns-users] DNSSEC same key for all

2019-05-20 Thread Bart Mortelmans

Hi,


If you're using MySQL backend, then I guess you could turn the 
cryptokeys table into a view that would return the same key for every 
domain name. But in general I think that would be bad practice and 
creating a new KEYSET for every domain name at the registry would be 
preferable.



Bart Mortelmans


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


Re: [Pdns-users] DNSSEC same key for all

2019-05-20 Thread azurit

Hi Frank,

it's mandatory for .CZ domains, so if you don't sign every domain with  
the same key, you need to register a KEYSET for every domain. So this  
is what i'm trying to solve.






Citát frank+pdns--- via Pdns-users :


Hi Azur,

It’s possible to do so, by manipulating the database directly (see  
the cryptokeys table).


However, let’s take a step back: what problem are you trying to  
solve? As far as I know, there’s not a single TLD where the use of  
KEYSETs is mandatory. Some offer it as an extra feature, but I am  
not aware of any TLD where this would be mandatory.


Kind Regards,

Frank Louwers
Certified PowerDNS Consultant @ Kiwazo.be
___
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


Re: [Pdns-users] DNSSEC same key for all

2019-05-20 Thread frank+pdns--- via Pdns-users
Hi Azur,

It’s possible to do so, by manipulating the database directly (see the 
cryptokeys table).

However, let’s take a step back: what problem are you trying to solve? As far 
as I know, there’s not a single TLD where the use of KEYSETs is mandatory. Some 
offer it as an extra feature, but I am not aware of any TLD where this would be 
mandatory.

Kind Regards,

Frank Louwers
Certified PowerDNS Consultant @ Kiwazo.be
___
Pdns-users mailing list
Pdns-users@mailman.powerdns.com
https://mailman.powerdns.com/mailman/listinfo/pdns-users


[Pdns-users] DNSSEC same key for all

2019-05-20 Thread azurit

Hi,

while using DNSSEC, is it possible to use the same key for all  
domains? This is needed for some TLDs, which are using KEYSET instead  
of DS record. Thanks for info.


azur


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


Re: [Pdns-users] DNSSEC with MySQL backend and replication

2019-05-16 Thread frank+pdns--- via Pdns-users
Hi Alun,

> We currently edit records by way of PowerAdmin, which updates the master 
> database directly and so “PowerDNS Auth A” instance is not actually used or 
> interacted with, normally. Zone/record updates are replicated to the “edge” 
> Auth servers (B and C) via MySQL replication. We would like to enable DNSSec 
> on a few of our domains, at least as a proof of concept. A few questions…
>  
> I assume I need to enable gmysql-dnssec on ALL PowerDNS Auth instances (A,B 
> and C)?
> Will PowerDNS commands to enable DNSSec signing of a zone need executed on 
> “PowerDNS Auth A” ONLY (which will add the relevant records to the database 
> and replicate them to B and C)?
> Given that PowerAdmin talks directly to the database, any record changes here 
> likely to cause a problem with these signed domains?
> Should I look at a newer GUI that implements the DNSSec commands and 
> interacts with PowerDNS API instead?

This is a setup we’ve built a few times for customers of ours, with these exact 
same components (we usually do add dnsdist for easier DDoS and abuse 
mitigation).

Unless you have a large number of queries against your nameservers, I would 
recommend to do “online signing” in PowerDNS, as described in 
https://docs.powerdns.com/authoritative/dnssec/modes-of-operation.html#online-signing
 
.
 In that mode, only the keys is stored in the database, and thus you’d need to 
enable this feature on each of your PowerDNS auth servers.

Once you configure all instances to handle DNSSEC, there’s nothing extra to 
configure: the key info is stored in the database, the flags that enable dnssec 
are stored in the database, so as long as your replication works, you’re good!

While you could continue to work directly in the database, we do recommend 
people to use the API. When enabling DNSSEC, it’s very import to “rectify” the 
database structure after all changes. Using the API, this becomes much easier 
than fiddling with the DB directly. PowerAdmin can be configured to talk 
directly to the API.

As a precaution, I would enable the API only on the min PowerDNS server, and 
would grant the PowerDNS “slaves” read-only access to their own databases, to 
prevent accidental changes in these nodes.

Hope this helps!

Frank Louwers
Certified PowerDNS Consultant @ Kiwazo


>  
> Thanks in advance…
>  
> Regards,
>  
> Alun.
>  
>  
> 
> 
>  
> Alun
>  James
> Senior Systems Engineer
> 
> T: +44 (0) 28 9033 1122
> E: aja...@tibus.com 
> W: www.tibus.com 
> 
>     
>    
> 
> Tibus is a wholly-owned division of Wireless.
>  
>  
> 
> 
> ___
> 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


Re: [Pdns-users] DNSSEC with MySQL backend and replication

2019-05-16 Thread Bjoern Franke
Hi,

>  
> 
> I assume I need to enable gmysql-dnssec on ALL PowerDNS Auth instances
> (A,B and C)?
> 
> Will PowerDNS commands to enable DNSSec signing of a zone need executed
> on “PowerDNS Auth A” ONLY (which will add the relevant records to the
> database and replicate them to B and C)?

I haven't used PowerAdmin for a while, but as it executes the signing
command and the signing command adds the relevant records to the
database, this should work.

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


[Pdns-users] DNSSEC with MySQL backend and replication

2019-05-16 Thread Alun James
Hi,

Just a few queries on implementing DNSSec with a MySQL backend, if I could 
trouble someone for their thoughts an recommendations?

Currently our PowerDNS Auth infra looks like below:


+-+  +-+
| PowerDNS Auth B |  | PowerDNS Auth C |
+-+  +-+
|  MYSQL SLAVE|  |  MYSQL SLAVE|
+---^-+  +---^-+
||
||
|  +--+  |
|  |  PowerAdmin  |  |
MASTER/SLAVE|  +--+---+  |MASTER/SLAVE
REPLICATION | |  |REPLICATION
|  +--v---+  |
+--+ MYSQL MASTER +--+
   +--^---+
  |
  |
   +--+--+
   | PowerDNS Auth A |
  +-+

We currently edit records by way of PowerAdmin, which updates the master 
database directly and so "PowerDNS Auth A" instance is not actually used or 
interacted with, normally. Zone/record updates are replicated to the "edge" 
Auth servers (B and C) via MySQL replication. We would like to enable DNSSec on 
a few of our domains, at least as a proof of concept. A few questions...

I assume I need to enable gmysql-dnssec on ALL PowerDNS Auth instances (A,B and 
C)?
Will PowerDNS commands to enable DNSSec signing of a zone need executed on 
"PowerDNS Auth A" ONLY (which will add the relevant records to the database and 
replicate them to B and C)?
Given that PowerAdmin talks directly to the database, any record changes here 
likely to cause a problem with these signed domains?
Should I look at a newer GUI that implements the DNSSec commands and interacts 
with PowerDNS API instead?

Thanks in advance...

Regards,

Alun.




[Tibus 
Logo][Separator]Alun
 James
Senior Systems Engineer
T: +44 (0) 28 9033 1122
E: aja...@tibus.com
W: 
www.tibus.com
[http://frontend.open.ms-dev.web.tibus.net/zesty/tibus-sig-new/assets/icon-fb.png]
  
[http://frontend.open.ms-dev.web.tibus.net/zesty/tibus-sig-new/assets/icon-tw.png]
    
[http://frontend.open.ms-dev.web.tibus.net/zesty/tibus-sig-new/assets/icon-li.png]
 
Tibus is a wholly-owned division of Wireless.



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


Re: [Pdns-users] DNSSEC, wich key for the registrar

2019-03-12 Thread Kevin Olbrich
All three is correct. Only the best would be required but keeping them all
upstream helps with old clients or resolvers, who understand DNSSEC but not
latest crypto.

Kevin


Am Di., 12. März 2019 um 20:14 Uhr schrieb Asanka Gunasekara <
asan...@talkup.com.au>:

> Hi David,
>
> I added all 3 DS keys to registrar when i setup my DNSSEC settings.
>
> According to your info:
> Key Tag : 58353
> Algorythm: [13] ECDSA Curve P-256 with SHA-256
> Digest Type: (1/2/4)
> Digest : x/y/z
>
> Hope this helps.
>
> Kind Regards,
> Asanka Gunasekara
>
> *P**:* 1300 825 587
> *E**: *supp...@talkup.com.au | *W:* www.talkup.com.au
> *Postal Address: *PO Box 24, Varsity Lakes QLD 4227
>
> Please consider the environment before printing this e-mail This email 
> message and any attachments are confidential. If you are not the intended 
> recipient, you are notified that any unauthorised disclosure, copying, 
> distribution or use of this information is strictly prohibited. If you have 
> received this email in error, please notify us immediately by return email, 
> or telephone 1300 825 587, and destroy the original message. We have taken 
> precautions to minimise the risk of transmitting software viruses, but we 
> advise you to carry out your own virus checks on any attachment to this 
> message. We cannot accept liability for any loss or damage caused by software 
> viruses.
>
> On 12/03/2019 11:13:25 PM, David REYNAUD  wrote:
>
> Hi,
>
>
>
> After enabling DNSEC for a zone, wich key should i setup/configure on the
> registrar database ?
>
>
>
> When i do a « pdnsutil show-zone myzone.com » we have many keys. See
> sample below :
>
>
>
> pdnsutil show-zone myzone.com
>
> >This is a Native zone
>
> >Metadata items:
>
> >API-RECTIFY 1
>
> >SOA-EDIT-APIDEFAULT
>
> >Zone has NSEC semantics
>
> >keys:
>
> >ID = 1 (CSK), flags = 257, tag = 58353, algo = 13, bits = 256 Active
> ( ECDSAP256SHA256 )
>
> >CSK DNSKEY = myzone.com. IN DNSKEY 257 3 13 w== ; (
> ECDSAP256SHA256 )
>
> >DS = myzone.com. IN DS 58353 13 1 x ; ( SHA1 digest )
>
> >DS = myzone.com. IN DS 58353 13 2 yyy ; ( SHA256 digest )
>
> >DS = myzone.com. IN DS 58353 13 4 z ; (
> SHA-384 digest )
>
>
>
> Should i copy/paste the key DNSKEY (ECDSAP256SHA256) or one of the three
> DS (SHA1 digest, SHA256 digest, SHA-384 digest) ?
>
>
>
> Thanks for the help.
>
>
>
>
>
> David REYNAUD
>
>
>
>
>
> 
>  Virus-free.
> www.avast.com
> 
> <#m_887826018406715995_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
> ___
> 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


Re: [Pdns-users] DNSSEC, wich key for the registrar

2019-03-12 Thread Asanka Gunasekara
Hi David,

I added all 3 DS keys to registrar when i setup my DNSSEC settings.

According to your info:
Key Tag : 58353
Algorythm: [13] ECDSA Curve P-256 with SHA-256
Digest Type: (1/2/4)
Digest : x/y/z

Hope this helps.

Kind Regards,
Asanka Gunasekara

P: 1300 825 587
E: supp...@talkup.com.au [http://talkup.com.au/] | W: www.talkup.com.au 
[http://www.talkup.com.au/]
Postal Address: PO Box 24, Varsity Lakes QLD 4227

Please consider the environment before printing this e-mail This email message 
and any attachments are confidential. If you are not the intended recipient, 
you are notified that any unauthorised disclosure, copying, distribution or use 
of this information is strictly prohibited. If you have received this email in 
error, please notify us immediately by return email, or telephone 1300 825 587, 
and destroy the original message. We have taken precautions to minimise the 
risk of transmitting software viruses, but we advise you to carry out your own 
virus checks on any attachment to this message. We cannot accept liability for 
any loss or damage caused by software viruses.
On 12/03/2019 11:13:25 PM, David REYNAUD  wrote:
Hi,
 
After enabling DNSEC for a zone, wich key should i setup/configure on the 
registrar database ?
 
When i do a « pdnsutil show-zone myzone.com » we have many keys. See sample 
below :
 
pdnsutil show-zone myzone.com 
>This is a Native zone
>Metadata items:
>    API-RECTIFY 1
>    SOA-EDIT-API    DEFAULT
>Zone has NSEC semantics
>keys:
>ID = 1 (CSK), flags = 257, tag = 58353, algo = 13, bits = 256 Active ( 
>ECDSAP256SHA256 )
>CSK DNSKEY = myzone.com. IN DNSKEY 257 3 13 w== ; ( 
>ECDSAP256SHA256 )
>DS = myzone.com. IN DS 58353 13 1 x ; ( SHA1 digest )
>DS = myzone.com. IN DS 58353 13 2 yyy ; ( SHA256 digest )
>DS = myzone.com. IN DS 58353 13 4 z ; ( 
>SHA-384 digest )
 
Should i copy/paste the key DNSKEY (ECDSAP256SHA256) or one of the three DS 
(SHA1 digest, SHA256 digest, SHA-384 digest) ?
 
Thanks for the help.
 
 
David REYNAUD
 

---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus
___
Pdns-users mailing list
Pdns-users@mailman.powerdns.com
https://mailman.powerdns.com/mailman/listinfo/pdns-users


[Pdns-users] DNSSEC, wich key for the registrar

2019-03-12 Thread David REYNAUD
Hi,

After enabling DNSEC for a zone, wich key should i setup/configure on the 
registrar database ?

When i do a < pdnsutil show-zone myzone.com > we have many keys. See sample 
below :

pdnsutil show-zone myzone.com
>This is a Native zone
>Metadata items:
>API-RECTIFY 1
>SOA-EDIT-APIDEFAULT
>Zone has NSEC semantics
>keys:
>ID = 1 (CSK), flags = 257, tag = 58353, algo = 13, bits = 256 Active ( 
>ECDSAP256SHA256 )
>CSK DNSKEY = myzone.com. IN DNSKEY 257 3 13 w== ; ( 
>ECDSAP256SHA256 )
>DS = myzone.com. IN DS 58353 13 1 x ; ( SHA1 digest )
>DS = myzone.com. IN DS 58353 13 2 yyy ; ( SHA256 digest )
>DS = myzone.com. IN DS 58353 13 4 z ; ( 
>SHA-384 digest )

Should i copy/paste the key DNSKEY (ECDSAP256SHA256) or one of the three DS 
(SHA1 digest, SHA256 digest, SHA-384 digest) ?

Thanks for the help.


David REYNAUD

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


Re: [Pdns-users] dnssec workflow

2019-01-15 Thread Pieter Lexis
Hi Mike,

Many questions, let's go through them one-by-one.

On 1/14/19 7:22 PM, mike+li...@yourtownonline.com wrote:
> I have been experimenting with dnssec and powerdns. I have a domain
> singed, ds records at my registrar, all looks good and it passes tests
> on various dnssec validation sites. What Im not clear about however, is
> what is the workflow needed for ongoing maintenance?

No, PowerDNS automatically refreshes the DNSSEC signatures every
week[1]. If you slave(s) are PowerDNS, they will re-transfer the zone if
they see the signatures change (even when the SOA serial is not
increased). If you slave(s) are not PowerDNS, you'll need to set the
default-soa-edit-signed setting[2] to something that makes sense for
your SOA serial[3].

> I don't understand
> automatic key expiration and whether or if I must care.

(note, this is an opinion) You'll only need to rotate your keys when
they are compromised. PowerDNS itself does not support automatically
rotating keys, but it can be done manually (and those steps could be
automated by you)[4,5]

> Also, I don't
> see why or if I need to care about having zsk and ksk in my zone; seems
> to work without, unless these are pertaining to domains I sub-delegate?

Having a ZSK means that you can roll that key without notifying your
parent zone/registrar. If you don't plan on rotating (often), a single
key (known as a CSK, combined signing key) is fine.

> And, if I decide that my existing ds at my registrar has aged
> sufficiently, what is the procedure for replacement that keeps my domain
> valid thru the rollover?

See [4].

> Im sorry, it's just that some of these topics are not really covered
> well...

They are, but I admit the documentation is a bit messy. If you have an
idea on how to improve this, please let us know via an issue[6]. Or,
even better, open a pull-request with the changes.

I hope this clarifies things for you. If not, feel free to respond on
the mailinglist and we'll be happy to help.

Cheers,

Pieter

1 -
https://doc.powerdns.com/authoritative/dnssec/modes-of-operation.html#signatures
2 -
https://doc.powerdns.com/authoritative/settings.html#default-soa-edit-signed
3 -
https://doc.powerdns.com/authoritative/dnssec/operational.html#soa-edit-ensure-signature-freshness-on-slaves
4 - https://doc.powerdns.com/authoritative/guides/kskroll.html
5 - https://doc.powerdns.com/authoritative/guides/zskroll.html
6 - https://github.com/PowerDNS/pdns/issues/new

-- 
Pieter Lexis
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] dnssec workflow

2019-01-14 Thread mike+lists
Hello,


    I have been experimenting with dnssec and powerdns. I have a domain
singed, ds records at my registrar, all looks good and it passes tests
on various dnssec validation sites. What Im not clear about however, is
what is the workflow needed for ongoing maintenance? I don't understand
automatic key expiration and whether or if I must care. Also, I don't
see why or if I need to care about having zsk and ksk in my zone; seems
to work without, unless these are pertaining to domains I sub-delegate?
And, if I decide that my existing ds at my registrar has aged
sufficiently, what is the procedure for replacement that keeps my domain
valid thru the rollover?

    Im sorry, it's just that some of these topics are not really covered
well...


Thank you.

Mike-

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


Re: [Pdns-users] DNSSEC NSEC vs. NSEC3 broad vs. inclusive vs. narrow

2018-10-29 Thread Kevin Olbrich
Hi!

Thank you very much!

These zones only contain records that can be public. None of them need to
be hidden (why hide DNS? IP will still be reachable on it's own).
It's just, that I was shocked that I leak more data with DNSSEC then
without it (sure, DNSSEC has more pro's then con's).
On an apache server, you would disable the version string, just because
nobody needs to know, since the admin will already know through other
sources.

As I am not familiar with the process behind NSEC and NSEC3, what is the
way to go? Keep NSEC or move to NSEC3?

If zone walking is no concern, which mode is more compatible with AXFR to
foreign servers?

If you don’t care that someone might enumerate every name in your zone(zone
> walk), then use NSEC.

Source:
https://www.internetsociety.org/resources/deploy360/2014/dnssecnsec-vs-nsec3/

Actually none of them should cause the problem I have.

I am just confused as my main problem is the CAA SRVFAIL on AXFR-slaves
because of DNSSEC validation problems (which must involve NSEC because the
record is not set).

Kevin

Am Mo., 29. Okt. 2018 um 14:09 Uhr schrieb Aki Tuomi :

> While the DNSCurve page provides excellent information about how your DNS
> data can be figured out using NSEC/NSEC3, it does fail to answer why DNS
> data should be considered private in the first place.
>
> If your security model relies on people not finding out your magical DNS
> record names, you might want consider again.
>
> Aki
> On 29.10.2018 14.39, Kevin Olbrich wrote:
>
> Hi again,
>
> I have now updated to Pdns 4.1.4 and will test if the problem is still
> present.
>
> In the meantime I read this doc:
> https://dnscurve.org/espionage2.html
>
> Now I am unsure if NSEC3 is the way to go.
> What's best practice?
>
> Kevin
>
>
> Am Mo., 29. Okt. 2018 um 13:14 Uhr schrieb Kevin Olbrich :
>
>> Hi!
>>
>> I read this doc:
>> https://doc.powerdns.com/authoritative/dnssec/modes-of-operation.html
>>
>> PowerDNS Authoritative Server 4.1.1
>>
>> Currently all zones are DNSSEC signed with NSEC by default.
>> We noticed a problem with non-existent CAA records: The zone is native
>> and replicated via AXFR to an external service.
>> If I query the master, the result is "not found". If I query the external
>> server, it replies with SRVFAIL.
>> This changes as soon as I set a CAA, the lookup succeeds.
>>
>> I think I have narrowed it down to NSEC. As NSEC3 makes zone-walking more
>> difficult, I would like to switch.
>> I tried "pdnsutil set-nsec3 example.com" which set some default values
>> and changed zone from NSEC to NSEC3.
>>
>> Before I do this change with 600+ Zones, what is the best practice
>> setting for NSEC/NSEC3?
>> The docs state broad vs. inclusive vs. narrow but without any more
>> information.
>>
>> And finally: Would this solve the CAA with replication problem?
>>
>> Thank you very much.
>>
>> Kevin
>>
>
> ___
> Pdns-users mailing 
> listPdns-users@mailman.powerdns.comhttps://mailman.powerdns.com/mailman/listinfo/pdns-users
>
>
___
Pdns-users mailing list
Pdns-users@mailman.powerdns.com
https://mailman.powerdns.com/mailman/listinfo/pdns-users


Re: [Pdns-users] DNSSEC NSEC vs. NSEC3 broad vs. inclusive vs. narrow

2018-10-29 Thread Aki Tuomi
While the DNSCurve page provides excellent information about how your
DNS data can be figured out using NSEC/NSEC3, it does fail to answer why
DNS data should be considered private in the first place.

If your security model relies on people not finding out your magical DNS
record names, you might want consider again.

Aki

On 29.10.2018 14.39, Kevin Olbrich wrote:
> Hi again,
>
> I have now updated to Pdns 4.1.4 and will test if the problem is still
> present.
>
> In the meantime I read this doc:
> https://dnscurve.org/espionage2.html
>
> Now I am unsure if NSEC3 is the way to go.
> What's best practice?
>
> Kevin
>
>
> Am Mo., 29. Okt. 2018 um 13:14 Uhr schrieb Kevin Olbrich  >:
>
> Hi!
>
> I read this doc:
> https://doc.powerdns.com/authoritative/dnssec/modes-of-operation.html
>
> PowerDNS Authoritative Server 4.1.1
>
> Currently all zones are DNSSEC signed with NSEC by default.
> We noticed a problem with non-existent CAA records: The zone is
> native and replicated via AXFR to an external service.
> If I query the master, the result is "not found". If I query the
> external server, it replies with SRVFAIL.
> This changes as soon as I set a CAA, the lookup succeeds.
>
> I think I have narrowed it down to NSEC. As NSEC3 makes
> zone-walking more difficult, I would like to switch.
> I tried "pdnsutil set-nsec3 example.com "
> which set some default values and changed zone from NSEC to NSEC3.
>
> Before I do this change with 600+ Zones, what is the best practice
> setting for NSEC/NSEC3?
> The docs state broad vs. inclusive vs. narrow but without any more
> information.
>
> And finally: Would this solve the CAA with replication problem?
>
> Thank you very much.
>
> Kevin
>
>
> ___
> 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


Re: [Pdns-users] DNSSEC-Problems on g.root-servers.net?

2018-09-17 Thread Christian Renner
>> 
>> The real problem seems to be in .ch.
> 
> It indeed does look like h.nic.ch is currently serving invalid denial of
> existence proofs.

I think you’re right, thanks to both of you!
I’ll contact SWITCH (the guys behind .ch) about the issue.

Thanks again & regards
Christian



signature.asc
Description: Message signed with OpenPGP
___
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?

2018-09-17 Thread 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


Re: [Pdns-users] DNSSEC-Problems on g.root-servers.net?

2018-09-17 Thread Stephane Bortzmeyer
On Mon, Sep 17, 2018 at 08:39:38AM +,
 Christian Renner  wrote 
 a message of 23 lines which said:

> DNSViz always shows the same behaviour:
> 
> http://dnsviz.net/d/onba.zkb.ch/dnssec/
> http://dnsviz.net/d/www.admin.ch/dnssec/
> 
> Errors (3)
>   • ./DNSKEY: No response was received from the server over UDP (tried 4 
> times). (2001:500:12::d0d, UDP_0_EDNS0_32768_512)
>   • 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 first error seems to be a (probably temporary) IPv6 routing issue
between dnsviz.net and g.root-servers.net. It works for me, and,
anyway, this would not prevent validation.

The real problem seems to be in .ch.

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


[Pdns-users] DNSSEC-Problems on g.root-servers.net?

2018-09-17 Thread Christian Renner
Hi

Since about 20 hours we see many dnssec validation errors on all of our pdns 
recursors.
A few recent examples:

Sep 17 10:12:37 ac-rns2 pdns_recursor[24059]: Answer to onba.zkb.ch|A for 
178.22.104.86:36796 validates as Bogus
Sep 17 10:12:25 ac-rns2 pdns_recursor[24059]: Answer to cdn.migros.ch|A for 
185.104.84.182:34036 validates as Bogus
Sep 17 10:12:48 ac-rns1 pdns_recursor[111558]: Answer to smtp.phys.ethz.ch|A 
for 83.150.57.154:52291 validates as Bogus
Sep 17 10:12:37 ac-rns1 pdns_recursor[111558]: Answer to www.admin.ch|A for 
212.25.2.169:59487 validates as Bogus

Anyone else with the same issues?


DNSViz always shows the same behaviour:

http://dnsviz.net/d/onba.zkb.ch/dnssec/
http://dnsviz.net/d/www.admin.ch/dnssec/

Errors (3)
• ./DNSKEY: No response was received from the server over UDP (tried 4 
times). (2001:500:12::d0d, UDP_0_EDNS0_32768_512)
• 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).


2001:500:12::d0d is g.root-servers.net

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


Re: [Pdns-users] dnssec domain validates as bogus

2018-03-14 Thread Remi Gacogne
On 03/14/2018 01:35 PM, Greg Antic wrote:
> I posted all the outputs without removing anything, do you refer the 
> rec_control trace, if so that is all that was outputted?

Yes, a full trace would start with something like this:

Mar 14 13:52:42 0 [2/1] question for 'cape-epic.com|A' from 127.0.0.1:36254
Mar 14 13:52:42 [2] cape-epic.com: Wants DNSSEC processing, auth data in
query for A
Mar 14 13:52:42 [2] cape-epic.com: Looking for CNAME cache hit of
'cape-epic.com|CNAME'
Mar 14 13:52:42 [2] cape-epic.com: No CNAME cache hit of
'cape-epic.com|CNAME' found
Mar 14 13:52:42 [2] cape-epic.com: No cache hit for 'cape-epic.com|A',
trying to find an appropriate NS record

which we don't have in the trace you posted, so we don't see the initial
query.

Then if the client requested DNSSEC validation (dig cape-epic.com
@127.0.0.1 with the version I'm using), it ends up with:

Mar 14 13:54:03 [2] cape-epic.com: status=got results, this level of
recursion done
Mar 14 13:54:03 [2] cape-epic.com: validation status is Secure
Mar 14 13:54:03 Starting validation of answer to cape-epic.com|A for
127.0.0.1:47766
Mar 14 13:54:03 Answer to cape-epic.com|A for 127.0.0.1:47766 validates
correctly
Mar 14 13:54:03 0 [2/1] answer to question 'cape-epic.com|A': 1 answers,
1 additional, took 5 packets, 1576.42 netw ms, 1583.5 tot ms, 0
throttled, 1 timeouts, 0 tcp connections, rcode=0, dnssec=Secure

And if the client didn't (dig cape-epic.com @127.0.0.1 +nodnssec +noadflag):

Mar 14 13:53:31 [2] cape-epic.com: status=got results, this level of
recursion done
Mar 14 13:53:31 [2] cape-epic.com: validation status is Indeterminate
Mar 14 13:53:31 0 [2/1] answer to question 'cape-epic.com|A': 1 answers,
1 additional, took 2 packets, 33.106 netw ms, 35.287 tot ms, 0
throttled, 0 timeouts, 0 tcp connections, rcode=0

That's the expected behavior with dnssec=process. If you want to disable
validation no matter what the client is asking for, use dnssec=off.

-- 
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 domain validates as bogus

2018-03-14 Thread Greg Antic
Hi Remi,

I posted all the outputs without removing anything, do you refer the 
rec_control trace, if so that is all that was outputted?

I note in the logs: [14337] Retrieving DNSKeys for cape-epic.com Mar 12 
11:15:23 ns4.hosted.bz pdns_recursor[1404]: [14337]  cape-epic.com: Wants  
DNSSEC processing, auth data in query for DNSKEY

The website is saying it wants DNSSEC processing. I don’t believe the problem 
is coming from the client side. 

-Original Message-
From: Pdns-users [mailto:pdns-users-boun...@mailman.powerdns.com] On Behalf Of 
Remi Gacogne
Sent: Wednesday, 14 March 2018 1:31 PM
To: pdns-users@mailman.powerdns.com
Subject: Re: [Pdns-users] dnssec domain validates as bogus

Hi Greg,

We can't see the beginning of the trace for the query so we can't know for 
sure, but if you are indeed running with dnssec=process this line hints at the 
fact that the client requested validation:

"Sending out SERVFAIL for cape-epic.com|A because recursor or query demands it 
for Bogus results"

Please be aware that recent version of dig set the AD and DO bits to 1 by 
default, and you have to use +nodnssec +noadflag to be sure they are not set.

Best regards,

Remi

On 03/12/2018 10:22 AM, Greg Antic wrote:
> Hi Remi,
> 
> Thanks. Yes I read [1] during my troubleshooting. When doing a dig or just 
> browsing from the FTTH customer the A record would not get returned. When I 
> "turned off" the dnssec we were answered with the A record. I tested this on 
> version 4.1.1 and 4.0.6. 
> 
> See below traces and journal log, the trace receives the A record but 
> if you specifically query it you get SERVFAIL
> 
> Current DNSSEC config:
> dnssec=process
> dnssec-log-bogus=yes
> 
> 
> rec_control trace-regex 'cape-epic.com'
> ok
> ok
> ok
> 
> dig a cape-epic.com +trace -b 41.x.y.z
> 
> ; <<>> DiG 9.10.3-P4-Ubuntu <<>> a cape-epic.com +trace -b 41.x.y.z ;; 
> global options: +cmd
> .   3420IN  NS  b.root-servers.net.
> .   3420IN  NS  e.root-servers.net.
> .   3420IN  NS  i.root-servers.net.
> .   3420IN  NS  d.root-servers.net.
> .   3420IN  NS  k.root-servers.net.
> .   3420IN  NS  m.root-servers.net.
> .   3420IN  NS  l.root-servers.net.
> .   3420IN  NS  h.root-servers.net.
> .   3420IN  NS  c.root-servers.net.
> .   3420IN  NS  g.root-servers.net.
> .   3420IN  NS  f.root-servers.net.
> .   3420IN  NS  a.root-servers.net.
> .   3420IN  NS  j.root-servers.net.
> .   3420IN  RRSIG   NS 8 0 518400 2018032505 
> 2018031204 41824 . 
> dSAaK8AjXy31BE5RQ+2a/F+ZLfOdStqejfFkKhRSyGptTP0GjSB/Q6pi 
> vB/lI3725G+qEylD7MylOQqyvE1uA/CU3KJDNc00xbGTlEFiTbarzK6p 
> gwbReoujqD09C3ZKGKqAkpql4LHwe5LB4kcD8eapBzs+tCFS8ioNW9kF 
> XOpeTaeB/yJxSPS/AwQSwZGnmW/XOkh13iurfa69tOlJ/3f5Zw5FLsoQ 
> 2u2sL2ZSFUzkBiSlPA3eLgzYiWwBubfrA7HJudhktUkK/LK4IaK+U7u/ 
> FuBMwGyLjARCltI9Q8wR1S/x93UmEi1XF4FCRwCWE7jj1QjBv93M+q5m j8SZwQ==
> ;; Received 540 bytes from 127.0.0.1#53(127.0.0.1) in 0 ms
> 
> com.172800  IN  NS  d.gtld-servers.net.
> com.172800  IN  NS  b.gtld-servers.net.
> com.172800  IN  NS  k.gtld-servers.net.
> com.172800  IN  NS  l.gtld-servers.net.
> com.172800  IN  NS  e.gtld-servers.net.
> com.172800  IN  NS  a.gtld-servers.net.
> com.172800  IN  NS  j.gtld-servers.net.
> com.172800  IN  NS  h.gtld-servers.net.
> com.172800  IN  NS  m.gtld-servers.net.
> com.172800  IN  NS  i.gtld-servers.net.
> com.172800  IN  NS  f.gtld-servers.net.
> com.172800  IN  NS  c.gtld-servers.net.
> com.172800  IN  NS  g.gtld-servers.net.
> com.86400   IN  DS  30909 8 2 
> E2D3C916F6DEEAC73294E8268FB5885044A833FC5459588F4A9184CF C41A5766
> com.86400   IN  RRSIG   DS 8 1 86400 2018032505 
> 2018031204 41824 . 
> P1ZaS7sTZ3Cyn5XPnodl1rgsi6yZujPwnm8sWHG/pFXc3+muO+YFIe9S 
> dF5aOqzitsIJIc4Sp3M1aRjiOakvgVPx4IiSVinBUWA84HPeZ0I+eyUK 
> 7KUFRH24ixXGhJGjzIdj867RwatqGq64veehKAU2xUcaitysyaewEJ2K 
> qM060xVV38rkXZA2WIpEz7fTZqyJ/7jfRmZTkixkEWfZbIWhht4OWCqa 
> j

Re: [Pdns-users] dnssec domain validates as bogus

2018-03-14 Thread Remi Gacogne
sor[1404]: [14337]  cape-epic.com: 
> Wants DNSSEC processing, auth data in query for DNSKEY
> Mar 12 11:15:23 ns4.hosted.bz pdns_recursor[1404]: [14337]  cape-epic.com: 
> DNSKEY is negatively cached via 'cape-epic.com' for another 1003 seconds
> Mar 12 11:15:23 ns4.hosted.bz pdns_recursor[1404]: [14337]  cape-epic.com: 
> updating validation state with negative cache content for cape-epic.com to 
> Bogus
> Mar 12 11:15:23 ns4.hosted.bz pdns_recursor[1404]: [14337] Retrieved 0 
> DNSKeys for cape-epic.com, state is Bogus
> Mar 12 11:15:23 ns4.hosted.bz pdns_recursor[1404]: [14337] cape-epic.com: 
> determining status after receiving this packet
> Mar 12 11:15:23 ns4.hosted.bz pdns_recursor[1404]: [14337] cape-epic.com: 
> answer is in: resolved to '154.0.167.107|A'
> Mar 12 11:15:23 ns4.hosted.bz pdns_recursor[1404]: [14337] cape-epic.com: got 
> upwards/level NS record 'cape-epic.com' -> 'pdns12.domaincontrol.com.', had 
> 'cape-epic.com
> Mar 12 11:15:23 ns4.hosted.bz pdns_recursor[1404]: [14337] cape-epic.com: got 
> upwards/level NS record 'cape-epic.com' -> 'pdns11.domaincontrol.com.', had 
> 'cape-epic.com
> Mar 12 11:15:23 ns4.hosted.bz pdns_recursor[1404]: [14337] cape-epic.com: got 
> upwards/level NS record 'cape-epic.com' -> 'ns.otherdns.com.', had 
> 'cape-epic.com'
> Mar 12 11:15:23 ns4.hosted.bz pdns_recursor[1404]: [14337] cape-epic.com: got 
> upwards/level NS record 'cape-epic.com' -> 'ns.otherdns.net.', had 
> 'cape-epic.com'
> Mar 12 11:15:23 ns4.hosted.bz pdns_recursor[1404]: [14337] cape-epic.com: got 
> upwards/level NS record 'cape-epic.com' -> 'ns.dns2.co.za.', had 
> 'cape-epic.com'
> Mar 12 11:15:23 ns4.hosted.bz pdns_recursor[1404]: [14337] cape-epic.com: got 
> upwards/level NS record 'cape-epic.com' -> 'ns.dns1.co.za.', had 
> 'cape-epic.com'
> Mar 12 11:15:23 ns4.hosted.bz pdns_recursor[1404]: [14337] cape-epic.com: 
> status=got results, this level of recursion done
> Mar 12 11:15:23 ns4.hosted.bz pdns_recursor[1404]: [14337] cape-epic.com: 
> validation status is Bogus
> Mar 12 11:15:23 ns4.hosted.bz pdns_recursor[1404]: Starting validation of 
> answer to cape-epic.com|A for 41.x.y.z:58365
> Mar 12 11:15:23 ns4.hosted.bz pdns_recursor[1404]: Answer to cape-epic.com|A 
> for 41.x.y.z:58365 validates as Bogus
> Mar 12 11:15:23 ns4.hosted.bz pdns_recursor[1404]: Sending out SERVFAIL for 
> cape-epic.com|A because recursor or query demands it for Bogus results
> 
> -Original Message-
> From: Pdns-users [mailto:pdns-users-boun...@mailman.powerdns.com] On Behalf 
> Of Remi Gacogne
> Sent: Friday, 09 March 2018 5:20 PM
> To: pdns-users@mailman.powerdns.com
> Subject: Re: [Pdns-users] dnssec domain validates as bogus
> 
> Hi Greg,
> 
> On 03/09/2018 03:44 PM, Greg Antic wrote:
>> We are running recursor 4.1.1. We are having a problem with a domain 
>> that is signed with bogus dnssec records, the domain is cape-epic.com.
>> We have tried the different dnssec modes but only process-no-validate 
>> allows the domain to be resolved. We tried adding an nta for the 
>> domain but the domain still would not resolve.
>>
>> Does anyone have any suggestions how we can accommodate and still 
>> resolve bogus domains but still offer dnssec validation?
> 
> Running with dnssec=process should only return a ServFail if the client 
> actually asks for DNSSEC validation, as described in [1].
> Adding a NTA should also work, would you mind sharing your configuration and 
> a trace (running with --trace or enabling it for this single domain via 
> rec_control trace-regex 'cape-epic.com')?
> 
> 
> [1]: https://doc.powerdns.com/recursor/dnssec.html#what-when
> 
> Best regards,
> 
> --
> Remi Gacogne
> PowerDNS.COM BV - https://www.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


Re: [Pdns-users] dnssec domain validates as bogus

2018-03-12 Thread Greg Antic
Hi Pieter,

To add to the info submitted to Remi:

> Can you tell us how you added the NTA?
rec_control add-nta cape-epic.com

> Are you fronting the recursor with dnsdist?
No

-Original Message-
From: Pdns-users [mailto:pdns-users-boun...@mailman.powerdns.com] On Behalf Of 
Pieter Lexis
Sent: Friday, 09 March 2018 5:22 PM
To: pdns-users@mailman.powerdns.com
Subject: Re: [Pdns-users] dnssec domain validates as bogus

Hi Greg,

On Fri, 9 Mar 2018 14:44:31 +
Greg Antic <greg.an...@stc.za.com> wrote:

> We are running recursor 4.1.1. We are having a problem with a domain that is 
> signed with bogus dnssec records, the domain is cape-epic.com. We have tried 
> the different dnssec modes but only process-no-validate allows the domain to 
> be resolved. We tried adding an nta for the domain but the domain still would 
> not resolve.
> 
> Does anyone have any suggestions how we can accommodate and still resolve 
> bogus domains but still offer dnssec validation?
> 
> Answer to cape-epic.com|A for 41.77.x.y:36426 validates as Bogus

* Can you tell us how you added the NTA?
* Are you fronting the recursor with dnsdist?
* The fact that it validates as Bogus does *not* mean that the client
  gets a SERVFAIL, this depends on the dnssec setting and the flags the
  client sends. (but with an NTA it should always be insecure, so please
  answer the first question).


Best regards,

Pieter

--
Pieter Lexis
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


Re: [Pdns-users] dnssec domain validates as bogus

2018-03-12 Thread Greg Antic
.com' -> 'ns.otherdns.net.', had 
'cape-epic.com'
Mar 12 11:15:23 ns4.hosted.bz pdns_recursor[1404]: [14337] cape-epic.com: got 
upwards/level NS record 'cape-epic.com' -> 'ns.dns2.co.za.', had 'cape-epic.com'
Mar 12 11:15:23 ns4.hosted.bz pdns_recursor[1404]: [14337] cape-epic.com: got 
upwards/level NS record 'cape-epic.com' -> 'ns.dns1.co.za.', had 'cape-epic.com'
Mar 12 11:15:23 ns4.hosted.bz pdns_recursor[1404]: [14337] cape-epic.com: 
status=got results, this level of recursion done
Mar 12 11:15:23 ns4.hosted.bz pdns_recursor[1404]: [14337] cape-epic.com: 
validation status is Bogus
Mar 12 11:15:23 ns4.hosted.bz pdns_recursor[1404]: Starting validation of 
answer to cape-epic.com|A for 41.x.y.z:58365
Mar 12 11:15:23 ns4.hosted.bz pdns_recursor[1404]: Answer to cape-epic.com|A 
for 41.x.y.z:58365 validates as Bogus
Mar 12 11:15:23 ns4.hosted.bz pdns_recursor[1404]: Sending out SERVFAIL for 
cape-epic.com|A because recursor or query demands it for Bogus results

-Original Message-
From: Pdns-users [mailto:pdns-users-boun...@mailman.powerdns.com] On Behalf Of 
Remi Gacogne
Sent: Friday, 09 March 2018 5:20 PM
To: pdns-users@mailman.powerdns.com
Subject: Re: [Pdns-users] dnssec domain validates as bogus

Hi Greg,

On 03/09/2018 03:44 PM, Greg Antic wrote:
> We are running recursor 4.1.1. We are having a problem with a domain 
> that is signed with bogus dnssec records, the domain is cape-epic.com.
> We have tried the different dnssec modes but only process-no-validate 
> allows the domain to be resolved. We tried adding an nta for the 
> domain but the domain still would not resolve.
> 
> Does anyone have any suggestions how we can accommodate and still 
> resolve bogus domains but still offer dnssec validation?

Running with dnssec=process should only return a ServFail if the client 
actually asks for DNSSEC validation, as described in [1].
Adding a NTA should also work, would you mind sharing your configuration and a 
trace (running with --trace or enabling it for this single domain via 
rec_control trace-regex 'cape-epic.com')?


[1]: https://doc.powerdns.com/recursor/dnssec.html#what-when

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] dnssec domain validates as bogus

2018-03-09 Thread Pieter Lexis
Hi Greg,

On Fri, 9 Mar 2018 14:44:31 +
Greg Antic  wrote:

> We are running recursor 4.1.1. We are having a problem with a domain that is 
> signed with bogus dnssec records, the domain is cape-epic.com. We have tried 
> the different dnssec modes but only process-no-validate allows the domain to 
> be resolved. We tried adding an nta for the domain but the domain still would 
> not resolve.
> 
> Does anyone have any suggestions how we can accommodate and still resolve 
> bogus domains but still offer dnssec validation?
> 
> Answer to cape-epic.com|A for 41.77.x.y:36426 validates as Bogus

* Can you tell us how you added the NTA?
* Are you fronting the recursor with dnsdist?
* The fact that it validates as Bogus does *not* mean that the client
  gets a SERVFAIL, this depends on the dnssec setting and the flags the
  client sends. (but with an NTA it should always be insecure, so please
  answer the first question).


Best regards,

Pieter

-- 
Pieter Lexis
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] dnssec domain validates as bogus

2018-03-09 Thread Remi Gacogne
Hi Greg,

On 03/09/2018 03:44 PM, Greg Antic wrote:
> We are running recursor 4.1.1. We are having a problem with a domain
> that is signed with bogus dnssec records, the domain is cape-epic.com.
> We have tried the different dnssec modes but only process-no-validate
> allows the domain to be resolved. We tried adding an nta for the domain
> but the domain still would not resolve.
> 
> Does anyone have any suggestions how we can accommodate and still
> resolve bogus domains but still offer dnssec validation?

Running with dnssec=process should only return a ServFail if the client
actually asks for DNSSEC validation, as described in [1].
Adding a NTA should also work, would you mind sharing your configuration
and a trace (running with --trace or enabling it for this single domain
via rec_control trace-regex 'cape-epic.com')?


[1]: https://doc.powerdns.com/recursor/dnssec.html#what-when

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] dnssec domain validates as bogus

2018-03-09 Thread Greg Antic
Hi List,

We are running recursor 4.1.1. We are having a problem with a domain that is 
signed with bogus dnssec records, the domain is cape-epic.com. We have tried 
the different dnssec modes but only process-no-validate allows the domain to be 
resolved. We tried adding an nta for the domain but the domain still would not 
resolve.

Does anyone have any suggestions how we can accommodate and still resolve bogus 
domains but still offer dnssec validation?

Answer to cape-epic.com|A for 41.77.x.y:36426 validates as Bogus

Best Regards,

Greg

[cid:image002.jpg@01D3B7C5.E5572410]SMART TECHNOLOGY CENTRE (PTY) LTD
+27.87.310.1751 / Tel
greg.an...@stc.za.com
Block 10, Townsend Office Park
1 Townsend Road, Bedfordview, 2008
www.stc.za.com
LEVEL-TWO B-BBEE contributor

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


Re: [Pdns-users] DNSSEC Expiry with slaves

2017-09-08 Thread Troy Kelly
Pieter,

Thank-you for the advice!

Apologies for the delay responding - I was waiting to see how things would
play out.

Unfortunately - we still had domains expire with the settings below
configured.

#

# default-soa-edit  Default SOA-EDIT value

#

# default-soa-edit=
default-soa-edit=INCEPTION-EPOCH


#

# default-soa-edit-signed   Default SOA-EDIT value for signed zones
#
# default-soa-edit-signed=
default-soa-edit-signed=INCEPTION-EPOCH

Am I missing something else that I need to be doing to trigger a rollover +
increment automatically?

Thanks in advance,
Troy




Troy Kelly

Chief Executive Officer

180 Sansome Street, Level 2, San Francisco, CA 94104


p. +1-650-215-6253   |   p. +61-2-8039-4567   |   e. troy.ke...@really.ai



On 24 August 2017 at 17:28, Pieter Lexis  wrote:

> Hello Troy,
>
> On Thu, 24 Aug 2017 12:05:48 +1000
> Troy Kelly  wrote:
>
> > We recently implemented DNSSEC, and then more recently had several of the
> > RRSIG's expire - and those domains become unoperational.
> >
> > We use PowerDNS as a stealth master, with public nameservers supplied by
> > one of our infrastructure providers.
> >
> > Where we don't make regular changes to the domain - we are going to keep
> > experiencing this expiry issue.
> >
> > Is there some (cron job?) solution that we can implement to roll over and
> > notify a domain before the RRSIG's expire?
> >
> > I had thought of a weekly pdnsutil increase-serial for every domain - but
> > it seems like a real kludge of a solution.
>
> You can use the default-soa-edit-signed configuration item[1] to set the
> default SOA-EDIT metadata value for signed domains.
> The possible values and their outcomes are described on the
> documentation[2].
> In short, the SOA-EDIT value edits the SOA serial after retrieving it from
> the datastore so slaves see a higher SOA when the RRSIG roils.
> INCREMENT-WEEKS is a safe value that will add the number of weeks since
> the UNIX epoch to the SOA serial, but please read the whole page.
>
> Good luck!
>
> Pieter
>
>
> 1 - https://doc.powerdns.com/authoritative/settings.html#
> default-soa-edit-signed
> 2 - https://doc.powerdns.com/authoritative/dnssec/
> operational.html#soa-edit-ensure-signature-freshness-on-slaves
>
> --
> Pieter Lexis
> PowerDNS.COM BV -- https://www.powerdns.com
> ___
> Pdns-users mailing list
> Pdns-users@mailman.powerdns.com
> https://mailman.powerdns.com/mailman/listinfo/pdns-users
>

-- 
This email and any attachments may contain confidential or privileged 
information and may be protected by copyright. You must not use or disclose 
them other than for the purposes for which they were supplied. The 
confidentiality and privilege attached to this message and attachment is 
not waived by reason of mistaken delivery to you. If you are not the 
intended recipient, you must not use, disclose, retain, forward or 
reproduce this message or any attachments. If you receive this message in 
error please notify the sender by return email or telephone, and destroy 
and delete all copies. Really Really, Inc. does not accept any 
responsibility for any loss or damage that may result from reliance on, or 
use of, any information contained in this email and/or attachments.
___
Pdns-users mailing list
Pdns-users@mailman.powerdns.com
https://mailman.powerdns.com/mailman/listinfo/pdns-users


Re: [Pdns-users] DNSSEC Expiry with slaves

2017-08-24 Thread Pieter Lexis
Hello Troy,

On Thu, 24 Aug 2017 12:05:48 +1000
Troy Kelly  wrote:

> We recently implemented DNSSEC, and then more recently had several of the
> RRSIG's expire - and those domains become unoperational.
> 
> We use PowerDNS as a stealth master, with public nameservers supplied by
> one of our infrastructure providers.
> 
> Where we don't make regular changes to the domain - we are going to keep
> experiencing this expiry issue.
> 
> Is there some (cron job?) solution that we can implement to roll over and
> notify a domain before the RRSIG's expire?
> 
> I had thought of a weekly pdnsutil increase-serial for every domain - but
> it seems like a real kludge of a solution.

You can use the default-soa-edit-signed configuration item[1] to set the 
default SOA-EDIT metadata value for signed domains.
The possible values and their outcomes are described on the documentation[2].
In short, the SOA-EDIT value edits the SOA serial after retrieving it from the 
datastore so slaves see a higher SOA when the RRSIG roils.
INCREMENT-WEEKS is a safe value that will add the number of weeks since the 
UNIX epoch to the SOA serial, but please read the whole page.

Good luck!

Pieter


1 - https://doc.powerdns.com/authoritative/settings.html#default-soa-edit-signed
2 - 
https://doc.powerdns.com/authoritative/dnssec/operational.html#soa-edit-ensure-signature-freshness-on-slaves

-- 
Pieter Lexis
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] DNSSEC Expiry with slaves

2017-08-23 Thread Troy Kelly
Thank you in advance for your advice, I'm sure this is a simple one - I
just can't find anything that seems to resolve our issue.

We recently implemented DNSSEC, and then more recently had several of the
RRSIG's expire - and those domains become unoperational.

We use PowerDNS as a stealth master, with public nameservers supplied by
one of our infrastructure providers.

Where we don't make regular changes to the domain - we are going to keep
experiencing this expiry issue.

Is there some (cron job?) solution that we can implement to roll over and
notify a domain before the RRSIG's expire?

I had thought of a weekly pdnsutil increase-serial for every domain - but
it seems like a real kludge of a solution.

Cheers, Troy

-- 
This email and any attachments may contain confidential or privileged 
information and may be protected by copyright. You must not use or disclose 
them other than for the purposes for which they were supplied. The 
confidentiality and privilege attached to this message and attachment is 
not waived by reason of mistaken delivery to you. If you are not the 
intended recipient, you must not use, disclose, retain, forward or 
reproduce this message or any attachments. If you receive this message in 
error please notify the sender by return email or telephone, and destroy 
and delete all copies. Really Really, Inc. does not accept any 
responsibility for any loss or damage that may result from reliance on, or 
use of, any information contained in this email and/or attachments.
___
Pdns-users mailing list
Pdns-users@mailman.powerdns.com
https://mailman.powerdns.com/mailman/listinfo/pdns-users


Re: [Pdns-users] dnssec support

2017-08-14 Thread Pieter Lexis
Hello Curtis,

On Mon, 14 Aug 2017 08:55:02 -0400
Curtis Maurand  wrote:

> Hello,
> I've been scouring the docs all morning looking for an answer, but no
> dice.  What do I need to do to get dnssec compiled in?  The doc's nor
> ./configure --help is much help on this.  All I see is to add the -dnssec,
> but configure tells me it doesn't know how to build gmysql-dnssec
> --Curtis

Compiling the authoritative server will give you DNSSEC support out of the box 
(as we link in OpenSSL).
The `-dnssec` option is for configuring the server in pdns.conf, e.g.: 
`gmysql-dnssec=yes` enables DNSSEC for the mysql backend.

Can you tell us why this was unclear so we can amend the documentaion?

Best regards,

Pieter

-- 
Pieter Lexis
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] dnssec support

2017-08-14 Thread Curtis Maurand
Hello,
I've been scouring the docs all morning looking for an answer, but no
dice.  What do I need to do to get dnssec compiled in?  The doc's nor
./configure --help is much help on this.  All I see is to add the -dnssec,
but configure tells me it doesn't know how to build gmysql-dnssec
--Curtis
___
Pdns-users mailing list
Pdns-users@mailman.powerdns.com
https://mailman.powerdns.com/mailman/listinfo/pdns-users


Re: [Pdns-users] DNSSEC issue in bind to pdns migration

2017-08-14 Thread Pieter Lexis
Hello Thibaud,

On Mon, 14 Aug 2017 12:28:03 +0200
Thib D  wrote:

> I am currently trying to transfer my zones running on bind9 to PowerDNS
> with a bind-backend.
> I want my AXFR dig queries to answer the same between pdns and bind9. The
> configuration on pdns and bind is the same.
> 
> AXFR queries are all fine except for the zones that have RRSIG and NSEC3
> records.
> AXFR answers from PDNS are not returning any of these records but BIND
> returns all of them.

Have you migrated the DNSSEC key material *or* have imported the RRSIGs and set 
the PRESIGNED[1] metadata?

> I read that there was the possibility to create database but I'm not sure
> why I would need to do this, because I just want the queries to return
> whats acutally written in the zonefiles.

Please see our DNSSEC migration guide for more information[2].

If you need more help, please provide the steps you took to migrate the zones.

Best regards,

Pieter

1 - https://doc.powerdns.com/authoritative/domainmetadata.html#presigned
2 - https://doc.powerdns.com/authoritative/dnssec/migration.html
-- 
Pieter Lexis
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] DNSSEC issue in bind to pdns migration

2017-08-14 Thread Thib D
Hello pdns-user !

I am currently trying to transfer my zones running on bind9 to PowerDNS
with a bind-backend.
I want my AXFR dig queries to answer the same between pdns and bind9. The
configuration on pdns and bind is the same.

AXFR queries are all fine except for the zones that have RRSIG and NSEC3
records.
AXFR answers from PDNS are not returning any of these records but BIND
returns all of them.

I read that there was the possibility to create database but I'm not sure
why I would need to do this, because I just want the queries to return
whats acutally written in the zonefiles.

Thanks for your help,

Best regards,

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


Re: [Pdns-users] DNSSEC via API

2017-05-15 Thread Christian Hofstaedtler
> On 15 May 2017, at 16:40, Siniša Burina  wrote:
> 
> Is there currently any way to easily turn on/off DNSSEC via API call(s)?
> Or is the implementation planned for the near future?
> 
> https://doc.powerdns.com/md/httpapi/api_spec/#zone95collection ...

git master has implementations for all the key management functions. It should 
be possible to DNSSEC-enable a zone using those.

The boolean flags (dnssec/nsec3narrow/presigned) are still not implemented, but 
should be easy.

Cheers,
C.

-- 
Christian Hofstaedtler / Deduktiva GmbH (FN 418592 b, HG Wien)
www.deduktiva.com / +43 1 353 1707



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


Re: [Pdns-users] dnssec for .us tld

2017-05-07 Thread Pieter Lexis
Hello Fabian,

On Sat, 06 May 2017 19:59:33 +
"Fabian A. Santiago"  wrote:

> what dnssec algorithms are supported by the .us tld? 

I don't believe there could be restrictions on the algorithms of sld's. They 
might restrict digest algorithms for the DS records, although they FAQ[1] does 
not mention this. Contacting your registrar about this will get you further.

best regards,

Pieter

1 - http://www.about.us/faqs


-- 
Pieter Lexis
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] dnssec for .us tld

2017-05-06 Thread Fabian A. Santiago
what dnssec algorithms are supported by the .us tld? 

--

Thanks,

Fabian S.

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


Re: [Pdns-users] dnssec problem

2017-02-22 Thread Steffan Noord
I know
On the other hand i cant believe that SIDN sents false emails


Met vriendelijke groet,
Steffan Noord 


-Oorspronkelijk bericht-
Van: Arsen STASIC [mailto:arsen.sta...@univie.ac.at] 
Verzonden: woensdag 22 februari 2017 13:18
Aan: Steffan Noord <steffanno...@gmail.com>
CC: pdns-users@mailman.powerdns.com
Onderwerp: Re: [Pdns-users] dnssec problem

Hi,

Even http://dnsviz.net/d/cicgroup.nl/dnssec/ finds no problems!

I see no reason why SIDN indicates a validation error.

cheers
Arsen Stasic

* Steffan Noord <steffanno...@gmail.com> [2017-02-22 12:39 (+0100)]:
> Hello List,
> 
>  
> 
> Im getting a email from SIDN (dutch nl registry) with a validation error
> 
> validation failure <_sidn._dnssec-valcheck._2080627548.cicgroup.nl. A IN>:
No DNSKEY record for key cicgroup.nl. while building chain of trust
> 
>  
> 
> When im looking at the registry I see:
> 
> Keytag  37540
> 
> Vlag  257 (KSK)
> 
> Algoritme RSA/SHA-256 (8)
> 
> Publieke sleutel
AwEAAajn4T1mAUlfYO+mM68uR0wvUuvkIw+D7T6xDDZrfLJ..
> 
>  
> 
> In my DNS
> 
> pdnssec show-zone cicgroup.nl | grep ID
> 
> ID = 1396 (KSK), tag = 22639, algo = 8, bits = 2048 Active: 1 (
RSASHA256 )
> 
> ID = 1398 (KSK), tag = 49816, algo = 8, bits = 2048 Active: 1 (
RSASHA256 )
> 
> ID = 1401 (KSK), tag = 37540, algo = 8, bits = 2048 Active: 1 (
RSASHA256 )
> 
> ID = 1397 (ZSK), tag = 4929, algo = 8, bits = 1024  Active: 1 (
RSASHA256 )
> 
>  
> 
>  
> 
> Any idees what is wrong?
> 
> It has worked for a very long time without a error.
> 
>  
> 
> Just a sitenote I see that there are multiple keys enabled.
> Some other domains has only one.
> Is that correct?
> 
>  
> 
>  
> 
> Met vriendelijke groet,
> 
> Steffan Noord 
> 
>  
> 
>  
> 
> Met vriendelijke groet,
> 
> Steffan Noord 
> 
>  
> 

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


Re: [Pdns-users] dnssec problem

2017-02-22 Thread Arsen STASIC
Hi,

Even http://dnsviz.net/d/cicgroup.nl/dnssec/ finds no problems!

I see no reason why SIDN indicates a validation error.

cheers
Arsen Stasic

* Steffan Noord  [2017-02-22 12:39 (+0100)]:
> Hello List,
> 
>  
> 
> Im getting a email from SIDN (dutch nl registry) with a validation error
> 
> validation failure <_sidn._dnssec-valcheck._2080627548.cicgroup.nl. A IN>: No 
> DNSKEY record for key cicgroup.nl. while building chain of trust
> 
>  
> 
> When im looking at the registry I see:
> 
> Keytag  37540
> 
> Vlag  257 (KSK)
> 
> Algoritme RSA/SHA-256 (8)
> 
> Publieke sleutel   
> AwEAAajn4T1mAUlfYO+mM68uR0wvUuvkIw+D7T6xDDZrfLJ..
> 
>  
> 
> In my DNS
> 
> pdnssec show-zone cicgroup.nl | grep ID
> 
> ID = 1396 (KSK), tag = 22639, algo = 8, bits = 2048 Active: 1 ( RSASHA256 
> )
> 
> ID = 1398 (KSK), tag = 49816, algo = 8, bits = 2048 Active: 1 ( RSASHA256 
> )
> 
> ID = 1401 (KSK), tag = 37540, algo = 8, bits = 2048 Active: 1 ( RSASHA256 
> )
> 
> ID = 1397 (ZSK), tag = 4929, algo = 8, bits = 1024  Active: 1 ( RSASHA256 
> )
> 
>  
> 
>  
> 
> Any idees what is wrong?
> 
> It has worked for a very long time without a error.
> 
>  
> 
> Just a sitenote I see that there are multiple keys enabled.
> Some other domains has only one.
> Is that correct?
> 
>  
> 
>  
> 
> Met vriendelijke groet,
> 
> Steffan Noord 
> 
>  
> 
>  
> 
> Met vriendelijke groet,
> 
> Steffan Noord 
> 
>  
> 
___
Pdns-users mailing list
Pdns-users@mailman.powerdns.com
https://mailman.powerdns.com/mailman/listinfo/pdns-users


[Pdns-users] dnssec problem

2017-02-22 Thread Steffan Noord
Hello List,

 

Im getting a email from SIDN (dutch nl registry) with a validation error

validation failure <_sidn._dnssec-valcheck._2080627548.cicgroup.nl. A IN>: No 
DNSKEY record for key cicgroup.nl. while building chain of trust

 

When im looking at the registry I see:

Keytag  37540

Vlag  257 (KSK)

Algoritme RSA/SHA-256 (8)

Publieke sleutel   AwEAAajn4T1mAUlfYO+mM68uR0wvUuvkIw+D7T6xDDZrfLJ..

 

In my DNS

pdnssec show-zone cicgroup.nl | grep ID

ID = 1396 (KSK), tag = 22639, algo = 8, bits = 2048 Active: 1 ( RSASHA256 )

ID = 1398 (KSK), tag = 49816, algo = 8, bits = 2048 Active: 1 ( RSASHA256 )

ID = 1401 (KSK), tag = 37540, algo = 8, bits = 2048 Active: 1 ( RSASHA256 )

ID = 1397 (ZSK), tag = 4929, algo = 8, bits = 1024  Active: 1 ( RSASHA256 )

 

 

Any idees what is wrong?

It has worked for a very long time without a error.

 

Just a sitenote I see that there are multiple keys enabled.
Some other domains has only one.
Is that correct?

 

 

Met vriendelijke groet,

Steffan Noord 

 

 

Met vriendelijke groet,

Steffan Noord 

 

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


Re: [Pdns-users] dnssec related questions

2016-09-01 Thread Peter van Dijk

Hello Peter,

On 26 Aug 2016, at 14:49, Keresztes Péter-Zoltán wrote:

I was wondering when securing a zone if there is any security 
difference between using nsec3 and nsec3-narrow beside the fact that 
nsec3 needs the zone to be rectified after each change while 
nsec3-narrow does not need that.


With NSEC3 (non-narrow), somebody can easily get all your NSEC3 records 
(of which you have roughly as many as there are names in your zone), and 
then do an offline brute force to find the actual names in your zones - 
more info at https://dnscurve.org/nsec3walker.html


Narrow prevents this by generating a very small (narrow) NSEC3 for every 
negative response, at a higher CPU cost, and terrible cache hit rates if 
somebody starts sending you random queries.


If you care about enumeration, narrow might be of interest (but keep in 
mind there are many ways for somebody to find out the contents of your 
zones).


Kind regards,
--
Peter van Dijk
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] dnssec related questions

2016-08-26 Thread Keresztes Péter-Zoltán
Hello, 

I was wondering when securing a zone if there is any security difference 
between using nsec3 and nsec3-narrow beside the fact that nsec3 needs the zone 
to be rectified after each change while nsec3-narrow does not need that.

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


  1   2   >