search

getdnsapi / getdns

A modern asynchronous DNS API https://getdnsapi.net/
Other
468 stars 126 forks source link

Stubby failing to resolve domain when DNSSEC is on even if that domain does not uses DNSSEC #423

Closed sylveon closed 5 years ago

sylveon commented 5 years ago

When trying to resolve moodle.cdsl.qc.ca (which is not protected by DNSSEC) through stubby resolution will fail, saying the validation is BOGUS. However when trying to resolve it using a third party DNS directly, for example 1.1.1.1, resolution succeeds. Resolving DNSSEC protected domains however works fine, because I can resolve my own domain, charlesmilette.net. Both zero configuration DNSSEC and manual trust anchors expose this issue. It starts resolving fine once DNSSEC is disabled.

Here's my config

resolution_type: GETDNS_RESOLUTION_STUB

dns_transport_list:
  - GETDNS_TRANSPORT_TLS
tls_authentication: GETDNS_AUTHENTICATION_REQUIRED
tls_query_padding_blocksize: 128
edns_client_subnet_private : 1
round_robin_upstreams: 1
idle_timeout: 10000

listen_addresses:
  - 127.0.2.2@5353
  - 0::2@5353

dnssec: GETDNS_EXTENSION_TRUE
appdata_dir: "/var/cache/stubby"
dnssec_trust_anchors: "/etc/trusted-key.key"

upstream_recursive_servers:
  - address_data: 1.1.1.1
    tls_auth_name: "cloudflare-dns.com"
  - address_data: 1.0.0.1
    tls_auth_name: "cloudflare-dns.com"
  - address_data: 2606:4700:4700::1111
    tls_auth_name: "cloudflare-dns.com"
  - address_data: 2606:4700:4700::1001
    tls_auth_name: "cloudflare-dns.com"

This site used to work, I don't know if it's a change from the school or a change in stubby that broke it.

wtoorop commented 5 years ago

@sylveon , Acknowledged, I can reproduce.

For unsigned domains, DNSSEC validation requires also the proof from a parent domain that a child domain is not signed. A lookup (with getdns_query) for cdsl.qc.ca. DS returns INSECURE, therefore everything below cdsl.qc.ca (as well as cdsl.qc.ca itself) should be INSECURE .

I'll look into it and come back with a patch (and probably a quickfix release). Thanks for reporting!

wtoorop commented 5 years ago

Hi @sylveon , I found the culprit. The problem was in the abortion of scheduled requests (for names below an insecure delegation). The detection of an insecure delegation was not working properly for delegations of more than one label. This is fixed with the following patch.

0002-Issue-423-Fix-insecure-delegation-detection-while-sc.patch.gz

I guess we'll have to do a bugfix release. Thanks again for reporting

sylveon commented 5 years ago

Sorry for the delay, I can confirm that the issue has been resolved in 1.5.2.