Correct it is not validating. Additionally it isn’t even DNSSES aware. It will need to be updated for you to validate through it.
-- Mark Andrews > On 19 Dec 2020, at 05:07, Nicolas Bock <nicolas.b...@canonical.com> wrote: > > Hi Mark, > > Thanks so much for the reply. I ran this command and am > getting the following: > > $ dig +dnssec ds com @10.0.0.3 > > ; <<>> DiG 9.10.6 <<>> +dnssec ds com @10.0.0.3 > ;; global options: +cmd > ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 36260 > ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 > > ;; OPT PSEUDOSECTION: > ; EDNS: version: 0, flags:; udp: 4096 > ;; QUESTION SECTION: > ;com. IN DS > > ;; ANSWER SECTION: > com. 63779 IN DS 30909 8 2 > E2D3C916F6DEEAC73294E8268FB5885044A833FC5459588F4A9184CF C41A5766 > > ;; Query time: 307 msec > ;; SERVER: 10.0.0.3#53(10.0.0.3) > ;; WHEN: Fri Dec 18 11:26:28 CST 2020 > ;; MSG SIZE rcvd: 80 > > In other words, the forwarder returns a Delegation Signer > record but not an RRset Signature record. Presumably that > means that that the forwarder is not validating the zone? > > Thanks, > > Nick > >> On Thu, Dec 17 2020, Mark Andrews wrote: >> >> DNSSEC requires that forwarders support DNSSEC. Check that the forwarders >> return >> DNSSEC records when they are queried. The forwarders should also be >> validating to >> filter spoofed responses from the internet. You should be getting a answer >> like >> this if the forwarders are validating. >> >> [beetle:~] marka% dig +dnssec ds com >> >> ; <<>> DiG 9.15.4 <<>> +dnssec ds com >> ;; global options: +cmd >> ;; Got answer: >> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 31284 >> ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1 >> >> ;; OPT PSEUDOSECTION: >> ; EDNS: version: 0, flags: do; udp: 4096 >> ; COOKIE: 5cf268bbbafd31a9010000005fdc081a24542baf0ffea0bb (good) >> ;; QUESTION SECTION: >> ;com. IN DS >> >> ;; ANSWER SECTION: >> com. 40483 IN DS 30909 8 2 >> E2D3C916F6DEEAC73294E8268FB5885044A833FC5459588F4A9184CF C41A5766 >> com. 40483 IN RRSIG DS 8 1 86400 20201229170000 >> 20201216160000 26116 . >> cgPgcSi6cq++komd2l+PzrCsawleAikedcwcGk5PbNr1onkXZGNypJoF >> 7QQJ4GjMf4b7t+bO5f8szmo0cd2bz+DD0DMXoqUSFvEH4gOX9naoHcm0 >> 90MS5Wfdeg43gNDSot/U74RJS1CS50U3SreFd2ZFIik9MlCHrSFLf/9V >> 7EqTJrs3xz9d/EG34O6qjaEqdw4GW40d3sA6kDGtSC+I9t4rttSEeasZ >> FnkZWLCOvzOLfYQlCVqaWpYCnvNdoQUPsbmDCEJf22tanPUft59hPRMu >> HmJAOKj77vy+kQWXaBcBo//NUX2asBLus8S7sJ9BDxpGUAsS9o+TdRlq YkIHBA== >> >> ;; Query time: 0 msec >> ;; SERVER: 127.0.0.1#53(127.0.0.1) >> ;; WHEN: Fri Dec 18 12:38:34 AEDT 2020 >> ;; MSG SIZE rcvd: 395 >> >> [beetle:~] marka% >> >> >>>> On 18 Dec 2020, at 11:36, Nicolas Bock <nicolas.b...@canonical.com> wrote: >>> >>> Hi, >>> >>> When I configure my named to forward to our corporate DNS >>> servers (10.0.0.2 and 10.0.0.3), I end up getting error >>> messages such as >>> >>> Dec 17 20:58:06 dns-server named[843946]: fetch: www.canonical.com/A >>> Dec 17 20:58:06 dns-server named[843946]: fetch: com/DS >>> Dec 17 20:58:06 dns-server named[843946]: delete_node(): >>> 0x7fa7e331e010 www.canonical.com (bucket 15) >>> Dec 17 20:58:06 dns-server named[843946]: delete_node(): >>> 0x7fa7e331b080 com (bucket 2) >>> Dec 17 20:58:06 dns-server named[843946]: no valid RRSIG resolving >>> 'com/DS/IN': 10.0.0.2#53 >>> Dec 17 20:58:06 dns-server named[843946]: delete_node(): >>> 0x7fa7e331b080 com (bucket 2) >>> Dec 17 20:58:06 dns-server named[843946]: no valid RRSIG resolving >>> 'com/DS/IN': 10.0.0.3#53 >>> Dec 17 20:58:06 dns-server named[843946]: delete_node(): >>> 0x7fa7e331b080 com (bucket 2) >>> Dec 17 20:58:06 dns-server named[843946]: no valid DS resolving >>> 'www.canonical.com/A/IN': 10.0.0.2#53 >>> Dec 17 20:58:06 dns-server named[843946]: delete_node(): >>> 0x7fa7e331e010 www.canonical.com (bucket 15) >>> Dec 17 20:58:06 dns-server named[843946]: validating >>> www.canonical.com/A: bad cache hit (com/DS) >>> Dec 17 20:58:06 dns-server named[843946]: delete_node(): >>> 0x7fa7e331e010 www.canonical.com (bucket 15) >>> Dec 17 20:58:06 dns-server named[843946]: broken trust chain resolving >>> 'www.canonical.com/A/IN': 10.0.0.3#53 >>> >>> I don't quite understand why. Are 10.0.0.{2,3} incorrectly >>> set up for DNSSEC? It looks like DNSSEC is already breaking >>> for com. How can I trace what the root cause is? >>> >>> Thanks! >>> >>> Nick >>> _______________________________________________ >>> Please 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 > _______________________________________________ Please 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