search

getdnsapi / stubby

Stubby is the name given to a mode of using getdns which enables it to act as a local DNS Privacy stub resolver (using DNS-over-TLS).
https://dnsprivacy.org/dns_privacy_daemon_-_stubby/
BSD 3-Clause "New" or "Revised" License
1.17k stars 97 forks source link

Stubby returns SERVFAIL for some domains #204

Open electrofloat opened 4 years ago

electrofloat commented 4 years ago

Hi!

So here is this issue: https://pastebin.com/P165c4kQ

Stubby's relevant configs:

    resolution_type: GETDNS_RESOLUTION_STUB
    dns_transport_list:
      - GETDNS_TRANSPORT_TLS
    listen_addresses:
      - 127.0.0.1@53000
    dnssec_return_status: GETDNS_EXTENSION_TRUE
    upstream_recursive_servers:
    - address_data: 1.1.1.1
    - address_data: 1.0.0.1
    - address_data: 8.8.8.8
    - address_data: 8.8.4.4

Versions:

ii  stubby                                                     1.4.0-1                            amd64                              modern asynchronous DNS API (stub resolver)
ii  libgetdns10:amd64                                          1.4.0-1                            amd64                              modern asynchronous DNS API (shared library)

OS:

Distributor ID: Ubuntu
Description:    Ubuntu 18.04.3 LTS
Release:        18.04
Codename:       bionic

It returns SERVFAIL, 1.1.1.1 and 8.8.8.8 are returning different results. Probably this is an issue like this one: https://community.cloudflare.com/t/1-1-1-1-dnssec-servfail-on-some-domains/66416 https://gitlab.labs.nic.cz/knot/knot-resolver/issues/359

But. Can this be avoided without the pain of letting the dns provider know they are doing it wrong and waiting for them to fix it?

ckotte commented 4 years ago

It also doesn't work with *.myqnapcloud.com

ckotte commented 4 years ago

@electrofloat Does it work if you use dig +cdflag coder.show? I tried unbound and I have the same issue there. However, I can resolve if I disable checking.

saradickinson commented 4 years ago

Thanks for flagging this issue. There is no workaround for this in Stubby itself - it is a result of how the upstream resolver behaves when it encounters an incorrectly configured zone and it seems to me that now both 1.1.1.1 and 8.8.8.8 are returning NOERROR/No Answer to e.g. dig @8.8.8.8 coder.show DS +dnssec (which many would argue is the correct thing for a resolver to do). Using DNSSEC validation means living with failures from incorrectly validating zones...