Forwarded lookup failing on no valid RRSIG

Nicolas Bock nicolas.bock at canonical.com
Fri Dec 18 17:56:42 UTC 2020


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