aused
trouble). But more importantly, to do NSEC3 correctly, we need to be
able to prove existence of these shorter names. The type=NULL records
entry gives us a place to store the NSEC3 hash of these names."
Thanks everyone.
On 20.11.2017 09:00, Mislav | SysAdmin wrote:
Anyone has some other
Anyone has some other ideas how to troubleshoot this, or can confirm
that this is normal behavior in new 4.1.0.?
On 16.11.2017 15:36, Mislav | SysAdmin wrote:
Is this something new by default in 4.1.0? We don't have DNSSEC
enabled in old environment, if this is DNSSEC related.
Is this something new by default in 4.1.0? We don't have DNSSEC enabled
in old environment, if this is DNSSEC related.
On 16.11.2017 15:25, David wrote:
On 2017-11-16 2:07 AM, Mislav | SysAdmin wrote:
Hi. I've the following setup:
1) pdns server version 3.1 - with mysql backe
Hi. I've the following setup:
1) pdns server version 3.1 - with mysql backend
2) pdns server version 4.1.0 - with mysql backend
What I'm trying to do is:
- replace version 3.1 with 4.1.0 and I've installed clean version of
4.1.0 to a new server and I'm trying to this this now:
https://doc.power
This all finally makes sense. Thank you very much Brian, big time.
On 13.11.2017 11:01, Brian Candler wrote:
On 13/11/2017 09:50, Mislav | SysAdmin wrote:
Yes, "ns1.private.ch" is a made-up name, that's correct. I'm running
Debian 9 with pdns-recursor-server installed vi
_recursor, but if I
do it from outside, recursing goes through pdns_server and that is the
problem.
On 13.11.2017 10:30, Brian Candler wrote:
On 13/11/2017 09:05, Mislav | SysAdmin wrote:
Hi. I've noticed some problems with CNAME resolving on our pdns
server. Here is the example:
$ n
Hi. I've noticed some problems with CNAME resolving on our pdns server.
Here is the example:
$ nslookup mobile-universe.ch ns1.private.ch
Server: ns1.private.ch
Address: private#53
Non-authoritative answer:
Name: mobile-universe.ch
Address: 18.194.35.161
$ nslookup www.mobile-unive
