Forwarded lookup failing on no valid RRSIG
Mark Andrews
marka at isc.org
Fri Dec 18 22:07:48 UTC 2020
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.bock at 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.bock at 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 at lists.isc.org
>>> https://lists.isc.org/mailman/listinfo/bind-users
>
More information about the bind-users
mailing list