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