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