Forwarded lookup failing on no valid RRSIG

classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

Forwarded lookup failing on no valid RRSIG

Nicolas Bock
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
[hidden email]
https://lists.isc.org/mailman/listinfo/bind-users
Reply | Threaded
Open this post in threaded view
|

Re: Forwarded lookup failing on no valid RRSIG

Mark Andrews
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 <[hidden email]> 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
> [hidden email]
> 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: [hidden email]

_______________________________________________
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
[hidden email]
https://lists.isc.org/mailman/listinfo/bind-users
Reply | Threaded
Open this post in threaded view
|

Re: Forwarded lookup failing on no valid RRSIG

Nicolas Bock
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 <[hidden email]> 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
>> [hidden email]
>> 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
[hidden email]
https://lists.isc.org/mailman/listinfo/bind-users
Reply | Threaded
Open this post in threaded view
|

Re: Forwarded lookup failing on no valid RRSIG

@lbutlr
On 18 Dec 2020, at 10:56, Nicolas Bock <[hidden email]> wrote:
> ;; ANSWER SECTION:
> com. 63779 IN DS 30909 8 2 E2D3C916F6DEEAC73294E8268FB5885044A833FC5459588F4A9184CF C41A5766

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

This is what I get when checking against my bind server.

;; ANSWER SECTION:
com. 43195 IN DS 30909 8 2 E2D3C916F6DEEAC73294E8268FB5885044A833FC5459588F4A9184CF C41A5766
com. 43195 IN RRSIG DS 8 1 86400 20201230050000 20201217040000 26116 . y2okmC5beWCbF84ZmlSM1ALT6Rd3xw9t41MEv6d8ITX8F8PV2Y/RDHvo 81ZlZK5sNsJFGXsTGyI+u5MrpSzlrD+6QXrE/h5Bt+YIvPI18DK4r5vk 4676uoPTnU+Lg/3CJOV73BkLhmZ4B50jV5vwnDXHobX8stKtuUyIA5hE Uvh1a5znj3mQRrmCXjuQ+Sb5DOORAymJdLlo3RzXs2LurDnnxml4DlnT b1BG/tXjOsK/H/QLH7jkPg/9OBQqB7eROkZO+qMQFkkMxmMXFvnR9Mxx mDcftsZ7d+/JiYflQh+PHEh3ncnOlLD2+O/FV5Qe9vugmGVybTuf7INt /TiF7g==

--
Steak and suspicious-organ pie

_______________________________________________
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
[hidden email]
https://lists.isc.org/mailman/listinfo/bind-users
Reply | Threaded
Open this post in threaded view
|

Re: Forwarded lookup failing on no valid RRSIG

Mark Andrews
In reply to this post by Nicolas Bock
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 <[hidden email]> 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 <[hidden email]> 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
>>> [hidden email]
>>> 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
[hidden email]
https://lists.isc.org/mailman/listinfo/bind-users
Reply | Threaded
Open this post in threaded view
|

Re: Forwarded lookup failing on no valid RRSIG

Nicolas Bock
Thanks Mark. Am I correct then that I need to either convince the administrator of that DNS to enable DNSSEC or configure my DNS with `dnssec-validation = no`?

Thanks,

Nick


On Fri, Dec 18, 2020 at 3:07 PM Mark Andrews <[hidden email]> wrote:
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 <[hidden email]> 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 <[hidden email]> 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
>>> [hidden email]
>>> 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
[hidden email]
https://lists.isc.org/mailman/listinfo/bind-users
Reply | Threaded
Open this post in threaded view
|

Re: Forwarded lookup failing on no valid RRSIG

Matthew Pounsett


On Fri, 18 Dec 2020 at 18:08, Nicolas Bock <[hidden email]> wrote:
Thanks Mark. Am I correct then that I need to either convince the administrator of that DNS to enable DNSSEC or configure my DNS with `dnssec-validation = no`?

The upstream administrator isn't required to be validating DNSSEC for this to work, but in order for your DNS server to do DNSSEC validation, their DNS server must be DNSSEC aware enough to be requesting DNSSEC data when it queries the authoritative DNS servers.  Of course, the resilience of the whole thing would also be improved by that server also validating.

If they can't or won't update their server, then yes, you'll either have to disable validation yourself, or select a better upstream.  Personally I'd go looking for a better upstream (or just stop using a forwarder entirely, and do your own direct recursion, if that's possible in your environment).

_______________________________________________
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
[hidden email]
https://lists.isc.org/mailman/listinfo/bind-users
Reply | Threaded
Open this post in threaded view
|

Re: Forwarded lookup failing on no valid RRSIG

Mark Andrews


> On 21 Dec 2020, at 06:04, Matthew Pounsett <[hidden email]> wrote:
>
>
>
> On Fri, 18 Dec 2020 at 18:08, Nicolas Bock <[hidden email]> wrote:
> Thanks Mark. Am I correct then that I need to either convince the administrator of that DNS to enable DNSSEC or configure my DNS with `dnssec-validation = no`?
>
> The upstream administrator isn't required to be validating DNSSEC for this to work, but in order for your DNS server to do DNSSEC validation, their DNS server must be DNSSEC aware enough to be requesting DNSSEC data when it queries the authoritative DNS servers.  Of course, the resilience of the whole thing would also be improved by that server also validating.

Matthew, there is a difference between sometimes getting answers out of a forwarder that isn’t validating that validate and a system that is working.  If the forwarder is not validating then the system cannot recover from situations that a iterative validating resolver can recover from.

It is bad advice to deploy validating clients behind forwarders that are not validating.

> If they can't or won't update their server, then yes, you'll either have to disable validation yourself, or select a better upstream.  Personally I'd go looking for a better upstream (or just stop using a forwarder entirely, and do your own direct recursion, if that's possible in your environment).

--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742              INTERNET: [hidden email]

_______________________________________________
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
[hidden email]
https://lists.isc.org/mailman/listinfo/bind-users
Reply | Threaded
Open this post in threaded view
|

Re: Forwarded lookup failing on no valid RRSIG

Nicolas Bock

On Sun, Dec 20 2020, Mark Andrews wrote:

>> On 21 Dec 2020, at 06:04, Matthew Pounsett <[hidden email]> wrote:
>>
>>
>>
>> On Fri, 18 Dec 2020 at 18:08, Nicolas Bock <[hidden email]> wrote:
>> Thanks Mark. Am I correct then that I need to either convince the administrator of that DNS to enable DNSSEC or configure my DNS with `dnssec-validation = no`?
>>
>> The upstream administrator isn't required to be validating DNSSEC for this to work, but in order for your DNS server to do DNSSEC validation, their DNS server must be DNSSEC aware enough to be requesting DNSSEC data when it queries the authoritative DNS servers.  Of course, the resilience of the whole thing would also be improved by that server also validating.
>
> Matthew, there is a difference between sometimes getting answers out of a forwarder that isn’t validating that validate and a system that is working.  If the forwarder is not validating then the system cannot recover from situations that a iterative validating resolver can recover from.

Thanks Matthew and Mark for the details. I will have a chat
with the upstream administrator and see whether I can
convince them to enable full DNSSEC on their end. At least
at this point I have a better grasp of what and why I am
seeing those messages.

Thanks!

Nick

> It is bad advice to deploy validating clients behind forwarders that are not validating.
>
>> If they can't or won't update their server, then yes, you'll either have to disable validation yourself, or select a better upstream.  Personally I'd go looking for a better upstream (or just stop using a forwarder entirely, and do your own direct recursion, if that's possible in your environment).

_______________________________________________
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
[hidden email]
https://lists.isc.org/mailman/listinfo/bind-users