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