FW: dnssec-validation? SOLVED

Mon Apr 17 11:33:22 UTC 2023

Hello. I just want to say everything seems to be working on my domain, and my primary dns server already performs validation
Dnssec-validation is set to auto, like on the secondary dns, and it's working.
When I perform 
Dig @dns www.dnssec-failed.org it already returns SERVFAIL and the rest seems fine.
It turns out that "managed-keys.bind" and "managed-keys.bind.jnl" were copied into the working folder from my previous dnssec impletation try.
Removed,  as indicated at: https://kb.isc.org/docs/aa-01182
And everythings seems fine.
The Kdi.ubi.pt*.....files also are aok after restarting the service.

Thank you all who took the time to clarify me about this.

Kind regards
David Carvalho

-----Original Message-----
From: Mark Andrews <marka at isc.org> 
Sent: 14 April 2023 02:35
To: David Carvalho <david at di.ubi.pt>
Cc: Evan Hunt <each at isc.org>; bind-users at lists.isc.org
Subject: Re: dnssec-validation?

> On 13 Apr 2023, at 19:23, David Carvalho via bind-users <bind-users at lists.isc.org> wrote:
> 
> Hello and thank you for the reply.
> My domain is "di.ubi.pt". The parent domain "ubi.pt" recently 
> configured DNSSEC (BIND 9.11) so it was time again for me to try to 
> set it up for my domain.
> 
> A few months ago I updated both dns servers to Oracle Linux 8, running 
> BIND
> 9.16.23 to prepare for this.
> They seem to be working fine as previously, running as both recursive 
> and authoritative for di.ubi.pt.
> 
> DNS2 has still "dnssec-validation auto;" on its  /etc/named.conf.
> I've found out that if I wanted my primary server to start answering 
> my internal requests for outside "di.ubi.pt" I had to change 
> dnssec-validation to "no".
> I still don't understand why, to be honest.

Look at your logs.  If named is having problems it will be logging error messages.

What does "rndc managed-keys status” report?

% rndc managed-keys status
view: secure
next scheduled event: Fri, 14 Apr 2023 02:04:19 GMT

    name: .
    keyid: 20326
algorithm: RSASHA256
flags: SEP
next refresh: Sat, 15 Apr 2023 00:53:04 GMT trusted since: Fri, 11 Aug 2017 01:07:03 GMT

view: forward
next scheduled event: Fri, 14 Apr 2023 02:04:19 GMT

    name: .
    keyid: 20326
algorithm: RSASHA256
flags: SEP
next refresh: Sat, 15 Apr 2023 00:53:04 GMT trusted since: Tue, 10 May 2022 05:09:01 GMT

view: external
next scheduled event: Fri, 14 Apr 2023 03:04:19 GMT

    name: .
    keyid: 20326
algorithm: RSASHA256
flags: SEP
next refresh: Fri, 14 Apr 2023 03:04:19 GMT trusted since: Thu, 10 Aug 2017 13:01:30 GMT % 

Are you using a forwarder?  Does the forwarder support DNSSEC?

Do you have an overly restrictive firewall?

What does “dig +cd +dnssec +multi . DNSKEY” return?

% dig +cd +dnssec +multi . DNSKEY
;; BADCOOKIE, retrying.

; <<>> DiG 9.19.11-dev <<>> +cd +dnssec +multi . DNSKEY ;; global options: +cmd ;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 10255 ;; flags: qr rd ra ad cd; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 1232 ; COOKIE: 9c2f2034f253efff010000006438ad22999ed76ba1835477 (good) ;; QUESTION SECTION:
;. IN DNSKEY

;; ANSWER SECTION:
. 88321 IN DNSKEY 257 3 8 (
AwEAAaz/tAm8yTn4Mfeh5eyI96WSVexTBAvkMgJzkKTO
iW1vkIbzxeF3+/4RgWOq7HrxRixHlFlExOLAJr5emLvN
7SWXgnLh4+B5xQlNVz8Og8kvArMtNROxVQuCaSnIDdD5
LKyWbRd2n9WGe2R8PzgCmr3EgVLrjyBxWezF0jLHwVN8
efS3rCj/EWgvIWgb9tarpVUDK/b58Da+sqqls3eNbuv7
pr+eoZG+SrDK6nWeL3c6H5Apxz7LjVc1uTIdsIXxuOLY
A4/ilBmSVIzuDWfdRUfhHdY6+cn8HFRm+2hM8AnXGXws
9555KrUB5qihylGa8subX2Nn6UwNR1AkUTV74bU=
) ; KSK; alg = RSASHA256 ; key id = 20326 . 88321 IN DNSKEY 256 3 8 ( AwEAAbF1LAxEQPtClEQno48k6u7JjCOfVfwdENOxQUrX
0JbpN5DnKGMAKIfdiWa5oDeKQ3OoQ58yCC8vjtaaGFDg
pJxoLwqzhBYHPGFgins5HIERcCQPGAJKWu/ku4XLh+Fu
7UyBubDCelxKTbnj26EwbochltRqGIE8hbwSXEzRNo4g
+NXkaRMq2FFbaBtEE82yTmZUgFRYAFUvfGTPWblyZGtk
epVuHyNb0w/u24dpsz+uyCZZR04cHfRrWOKvqD3lDOwC
4+sqd6f7F841R0N2tqSh/WDUZzWdvPBaBOz0FWFLb9po
rIeZ3Jm08tAMHa+3SGRXfK4RAmxVCmIQQypGabE=
) ; ZSK; alg = RSASHA256 ; key id = 60955 . 88321 IN RRSIG DNSKEY 8 0 172800 (
20230502000000 20230411000000 20326 .
ID/zjsZ8MPaJMm4Ilw9PESU92a/MvPFKlKkE8d2qAbDV
fMGYQikmls8z0fIorVfoGECgiEey42+Y4Bk99qTEFxPr
Cml12/xyJcmzQICQcr28djuMMA+yY7w57GuRLkE+LTnl
5IdlucNf52gS/eKSBIjKH3hNYElH6BwIbTHKV5Jh1ZJg
FTo+FRtrniR4HlhhHaydDVLc2A8FG3Whl1kyATDlqcLr
F6yqbjAhNR0+Ak26gd5BkY9kwOYCMZ2KQ1RBKRmG3Dbk
tohYVHbH2j6B6kfIjooRwY5hWyNQnBZP6LOHQLyfYrUT
R3EK438G9VW0tXvNqL3ssDhuxhbFy7x3hw== )

;; Query time: 0 msec
;; SERVER: ::1#53(::1) (UDP)
;; WHEN: Fri Apr 14 11:32:18 AEST 2023
;; MSG SIZE  rcvd: 892

% 

> Yesterday I set dnssec-validation to auto on my primary server, but as 
> I wrote before, although outside tools showed everything was fine, my 
> server kept answering "SERVFAIL" to my client queries. I don't think I 
> tested dnssec-validation to no when dnssec was enabled, nor if this 
> makes much sense, but I can try.
> 
> Kind regards
> David
> 
> 
> 
> 
> 
> 
> On Wed, Apr 12, 2023 at 05:41:33PM +0100, David Carvalho via 
> bind-users
> wrote:
>> After reverting my primary dns configuration, and asking my provider 
>> to remove the DNSKEY, I had to include dnssec-validation no; 
>> otherwise it would keep answering with SERVFAIL
>> 
>> I noticed the server was constantly trying to reach top domain dns
> servers.
>> 
>> Is this dnssec-validation mandatory? Any help appreciated.
> 
> dnssec-validation can be set three ways:
> - "no" (validation is never performed)
> - "yes" (validation *may* be performed, but only if you have also
>   configured a trust anchor in named.conf)
> - "auto" (validation will be performed using the standard root zone
>   trust anchor, which is built in to BIND and doesn't need to be
>   configured by hand).
> 
> The default is "auto". When it's set to that, your server will query 
> the root name servers in order to confirm that the 
> automatically-configured trust anchor is correct.  You said it was 
> "trying to" reach the root, which suggests it wasn't succeeding?  If 
> so, that would explain why everything that wasn't locally authoritative would return SERVFAIL.
> 
> Note that this is related to *recursive* queries, that is, queries for 
> zones that are not served by your secondary server.  It should have 
> nothing to do with whether your own domain is signed, or whether 
> there's a DS record for it in the parent zone. My guess is, you had 
> the authoritative configuration working fine (otherwise presumably 
> dnssec-analyzer would've complained), but recursive isn't working.
> 
> Unfortunately, since you haven't provided any configuration info or 
> even the name of the domain you were trying to set up, I can't make 
> any more educated guesses than that.
> 
> --
> Evan Hunt -- each at isc.org
> Internet Systems Consortium, Inc.
> 
> --
> Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
> from this list
> 
> ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information.
> 
> 
> bind-users mailing list
> bind-users at lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users

--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742              INTERNET: marka at isc.org