[getdns-users] First release candidate for getdns-1.2.1 - but still trouble

[Willem Toorop]

Thanks Andreas,

I think I know what the issue is.  Your /etc/resolv.conf is pointing to
127.0.0.1, and that will be used to do the DNS queries to start Zero
configuration DNSSEC (i.e. lookup of data.iana.org).  However doing a
query to Stubby listening on 127.0.0.1, in turn triggers another lookup
for data.iana.org etc. because it wants to validate.

So there is clearly a chicken and egg problem here that needs to be
resolved.  Unfortunately sending the meta queries with the CD flag
(checking disabled) won't help, because this is translated in stubby to
the dnssec_return_all_statuses extension, which will also trigger Zero
configuration DNSSEC.

I have to rethink the meta queries for Zero configuration DNSSEC, which
is inline with what I'm planning to do at the IETF hackathon (i.e. DANE
authenticating DNS-over-TLS upstreams, which also involves meta-queries
which cannot be done without working upstream!).  So if you don't mind,
I will release 1.2.1 which has a lot of stability fixes anyway, and
create an github issue for this specific problem, to be addressed in
(hopefully) an soon future release.

Thanks for reporting though!

-- Willem

Op 08-11-17 om 01:03 schreef A. Schulze:
> 
> 
> Am 07.11.2017 um 13:27 schrieb Willem Toorop:
>> Andreas,
>>
>> Are you very certain you use the latest  getdns library?  i.e. the 1.2.1
>> release candidate from the tarball from the website, or git checkout
>> from the release/1.2.1 branch.
> I'm very sure to use the right version:
> 
> # ldd /usr/bin/stubby | grep getdns
>         libgetdns.so.6 => /usr/lib/x86_64-linux-gnu/libgetdns.so.6
> 
> # strings /usr/lib/x86_64-linux-gnu/libgetdns.so.6 | grep -F 1.2
> 1.2.1-rc1
> getdns 1.2.1-rc1 configured on 2017-11-07T16:39:09Z for the December 2015 version of the API
> 
>>  I have recent commits that make dnssec
>> validation work with bind upstreams (i.e. the dnsovertls.sinodun.com
>> ones).  You can check by using the getdnsapi.net upstream instead of the
>> sinodun (which is unbound and didn't have the issue).
> 
> nothing changed between dnsovertls.sinodun.com and getdnsapi.net
>  
>> Also, I am pretty sure you were able to validate the root DNSKEY rrset
>> with the trust anchor you provided (you can check with dig . dnskey
>> +dnssec), because otherwise the root-achors.xml and p7s files would have
>> been downloaded from data.iana.org.
> 
> running "strace -f stubby 2>&1 | grep -e ^open -e ^stat" I found a problem:
> 
> stubby try to stat "/etc/unbound/getdns-root.key" which did not exist.
> I copied my /etc/unbound/root.key to that name and get answers now.
> But only for questions without DO flag.
> 
>> About that.  If you do not configure a trust-anchor and don't have a
>> trust-anchor on the default location, getdns will fetch them from
>> iana.org for you.
> I never saw any download activity.
> 
>> The actual output of stubby -i might be helpful.
> # cat .stubby.yml
> dns_transport_list:
>   - GETDNS_TRANSPORT_TLS
> tls_authentication: GETDNS_AUTHENTICATION_REQUIRED
> dnssec_return_status: GETDNS_EXTENSION_TRUE
> listen_addresses:
>   - 127.0.0.1
> upstream_recursive_servers:
>   - address_data: 185.49.141.37
>     tls_auth_name: "getdnsapi.net"
>     tls_pubkey_pinset:
>       - digest: "sha256"
>         value: foxZRnIh9gZpWnl+zEiKa0EJ2rdCGroMWm02gaxSc9Q=
> 
> # stubby -i > /tmp/stubby-i.txt 2>&1
> 
> ... file attached ...
> 
> one other point to note:
> using strace I also saw stubby try to find the CA file in /etc/ssl/certs.
> There is no other error message then "validation failed" if a required CA file is not present.
> 
> 
> Andreas
> 
> 
> 
> _______________________________________________
> Users mailing list
> Users at getdnsapi.net
> https://getdnsapi.net/mailman/listinfo/users
>