Hi and thanks for the reply.
"Do you have an overly restrictive firewall?" - yes. Tried to reach the network
guy but he won't be here this week. But it is unlikely, because dns2 is working
fine and, from what I've been told, they are in the same ACL group.
-------------------------------------
This is my output:
rndc managed-keys status
view: _default
next scheduled event: Thu, 13 Apr 2023 10:18:05 GMT
name: .
keyid: 0
algorithm: 0
flags: (none)
next refresh: Thu, 26 Jan 2023 16:05:04 GMT
no trust
-----------------------------------
dig +cd +dnssec +multi . DNSKEY
; <<>> DiG 9.11.36-RedHat-9.11.36-5.el8_7.2 <<>> +cd +dnssec +multi . DNSKEY
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 39638
;; flags: qr rd ra cd; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 1232
; COOKIE: 01c1387577eb123601000000643910a2f6b0163c1001c9b2 (good)
;; QUESTION SECTION:
;. IN DNSKEY
;; ANSWER SECTION:
. 92475 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
. 92475 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
. 92475 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: 193.136.66.1#53(193.136.66.1)
;; WHEN: Fri Apr 14 09:36:50 WEST 2023
;; MSG SIZE rcvd: 893
--------------------------------------------
Outside tests also seem to be ok. Didn't find anything yet in the logs.
I will compare (again) my named.conf on the primary and secondary server to
find why dnssec-validation needs to be off on the primary.
Thanks!
David
-----Original Message-----
From: Mark Andrews <ma...@isc.org>
Sent: 14 April 2023 02:35
To: David Carvalho <da...@di.ubi.pt>
Cc: Evan Hunt <e...@isc.org>; bind-users@lists.isc.org
Subject: Re: dnssec-validation?
> On 13 Apr 2023, at 19:23, David Carvalho via bind-users
> <bind-users@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 -- e...@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@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: ma...@isc.org
--
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@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
