Bug 248239 - local_unbound: Fails to resolve europris.no fail after 11.3->11.4 upgrade
Summary: local_unbound: Fails to resolve europris.no fail after 11.3->11.4 upgrade
Status: Closed Works As Intended
Alias: None
Product: Base System
Classification: Unclassified
Component: misc (show other bugs)
Version: 11.4-RELEASE
Hardware: amd64 Any
: --- Affects Some People
Assignee: Kubilay Kocak
URL:
Keywords: needs-qa, regression
Depends on:
Blocks:
 
Reported: 2020-07-24 10:45 UTC by atles
Modified: 2020-07-28 02:00 UTC (History)
7 users (show)

See Also:


Attachments
Drill -DT (5.31 KB, text/plain)
2020-07-27 09:41 UTC, atles
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description atles 2020-07-24 10:45:30 UTC
Resolving europris.no fail using local_unbound in Freebsd 11.4, this worked on Freebsd 11.3.

Worked around disabling dnssec by setting "val-permissive-mode: yes" in unbound.conf

The verisign dnssec test reports no errors on this domain.
https://dnssec-analyzer.verisignlabs.com/europris.no
Comment 1 atles 2020-07-24 10:46:02 UTC
All other dnssec secured domains work fine
Comment 2 atles 2020-07-24 12:11:40 UTC
Update:
I did some more digging, and it seems that only openssl 1.1.x supports the ed25519 signatures and local_unbound is compiled against openssl 1.0.2

This will break dnssec once domain hosts starts signing with ed25519 only.

Another test domain that breaks is ed25519.nl
Comment 3 atles 2020-07-24 12:49:16 UTC
I upgraded the server from 11.3 to 11.4 a few days ago, i would presume that ed25519 is broken on 11.3 too.
Comment 4 Eugene Grosbein freebsd_committer 2020-07-24 13:07:14 UTC
You have multiple options: install openssl using recent ports or packages then install the port dns/unbound; or upgrade to FreeBSD 12.1 that has newver openssl in base system.

FreeBSD 11 base system won't get stock openssl updated to 1.1+
Comment 5 atles 2020-07-24 13:13:19 UTC
If FreeBSD 11 base wont get updated openssl, dnssec validation should be disabled in unbound_local since more and more domains are signed with ed25519.
Comment 6 Eugene Grosbein freebsd_committer 2020-07-24 13:21:49 UTC
(In reply to atles from comment #5)

This is up to local administrator. Tools, not policy.
Comment 7 Viktor Dukhovni 2020-07-24 17:43:23 UTC
If ed25519 is not supported in a resolver, it should treat zones that are signed only with ed25519 as "unsigned".  If it instead ServFails, then that's a bug.  What exactly happens with lookup for the reported zone?

It's DS RRs list only ed25519:

  europris.no. IN DS 25323 15 2 ...
  europris.no. IN DS 25323 15 4 ...

But its DNSKEY RRset has both P256 and ED25519 keys and is signed by all:

  europris.no. IN DNSKEY 257 3 15 ...
  europris.no. IN DNSKEY 256 3 15 ...
  europris.no. IN DNSKEY 257 3 13 ...
  europris.no. IN DNSKEY 256 3 13 ...
  europris.no. IN RRSIG DNSKEY 13 2 3600 <validity> 14997 ...
  europris.no. IN RRSIG DNSKEY 13 2 3600 <validity> 46820 ...
  europris.no. IN RRSIG DNSKEY 15 2 3600 <validity> 25323 ...
  europris.no. IN RRSIG DNSKEY 15 2 3600 <validity> 39946 ...

The SOA is signed with both ZSKs:

  europris.no. IN SOA ns1.hyp.net. hostmaster@domeneshop.no. ...
  europris.no. IN RRSIG SOA 13 2 3600 <validity> 14997 ...
  europris.no. IN RRSIG SOA 15 2 3600 <validity> 39946

A resolver that does not support ed25519 should treat this zone as unsigned, since the DS RRs don't include any other algorithm.  Perhaps with P256 in the DNSKEY RRset, the resolver failed to reach that conclusion?  That would be a bug.
Or does the resolver "think" it has ed25519 support, expecting it to work, and then reports errors when loading ed25519 keys fails?

While not having ed25519 is not a bug, failing to resolve DNSSEC domains that require ed25519 is a bug.  So this looks prematurely closed.
Comment 8 Viktor Dukhovni 2020-07-25 03:28:33 UTC
The authoritative text covering unsupported DS algorithms is:

  https://tools.ietf.org/html/rfc4035#section-5.2)

where we see (https://tools.ietf.org/html/rfc4035#page-27)

  If the validator does not support any of the algorithms listed in an
  authenticated DS RRset, then the resolver has no supported
  authentication path leading from the parent to the child.  The
  resolver should treat this case as it would the case of an
  authenticated NSEC RRset proving that no DS RRset exists, as
  described above.

So a resolver that does not support ed25519 should be able to resolve the reported zone, treating it as insecure.
Comment 9 Eugene Grosbein freebsd_committer 2020-07-25 08:52:49 UTC
Reopen.

Unbound is contributed software developed outside of FreeBSD Project.
Current upstream version is 1.10.1, and so is local_unbound in FreeBSD Ports, and FreeBSD 13-CURRENT, stable/12 and stable/11.

Dear submitter, please report the bug to the upstream as we need their opinion on the problem: do they confirm the bug and will they fix the bug in future version of unbound? If yes, the correct way is fixing the bug upstream and then import new version to FreeBSD.
Comment 10 Cy Schubert freebsd_committer 2020-07-25 16:56:21 UTC
des@ is another stakeholder.
Comment 11 Viktor Dukhovni 2020-07-25 18:07:15 UTC
I'd still like a more detailed report from the OP than "resolving ... fail".  What exactly is the response from the resolver (output of "dig europris.no @localhost")?  What does "unbound-host -d -D europris.no" show?

Even if the problem report goes upstream to unbound, they too will a better error report than just "fail".
Comment 12 atles 2020-07-27 09:41:59 UTC
Created attachment 216796 [details]
Drill -DT

Drill -DT www.europris.no on Freebsd 11.4 against local_unbound.
Comment 13 atles 2020-07-27 10:26:49 UTC
https://github.com/NLnetLabs/unbound/issues/271

Added issue upstream
Comment 14 Chris Hutchinson 2020-07-27 17:19:57 UTC
Unless the version of unbound I'm running is newer
than the version in question. The answer I get is
is correct:

# head -n3 unbound.log | grep start
Jan 26 11:11:58 unbound[63414:0] info: start of service (unbound 1.7.3).

# drill -v
drill version 1.6.17 (ldns version 1.6.17)
Written by NLnet Labs.

Copyright (c) 2004-2008 NLnet Labs.
Licensed under the revised BSD license.
There is NO warranty; not even for MERCHANTABILITY or FITNESS
FOR A PARTICULAR PURPOSE.

# drill -TD europris.no.
;; Number of trusted keys: 1
;; Domain: .
[T] . 172800 IN DNSKEY 256 3 8 ;{id = 46594 (zsk), size = 2048b}
. 172800 IN DNSKEY 257 3 8 ;{id = 20326 (ksk), size = 2048b}
Checking if signing key is trusted:
New key: .	172800	IN	DNSKEY	256 3 8 <LONG-HASH> ;{id = 46594 (zsk), size = 2048b}
	Trusted key: .	172800	IN	DNSKEY	257 3 8 <LONG-HASH> ;{id = 20326 (ksk), size = 2048b}
	Trusted key: .	172800	IN	DNSKEY	256 3 8 <LONG-HASH> ;{id = 46594 (zsk), size = 2048b}
Key is now trusted!
	Trusted key: .	172800	IN	DNSKEY	257 3 8 <LONG-HASH> ;{id = 20326 (ksk), size = 2048b}
[T] no. 86400 IN DS 29471 8 2 <LONG-HASH> 
;; Domain: no.
[T] no. 3600 IN DNSKEY 257 3 8 ;{id = 29471 (ksk), size = 2048b}
no. 3600 IN DNSKEY 256 3 8 ;{id = 35961 (zsk), size = 1024b}
Checking if signing key is trusted:
New key: no.	3600	IN	DNSKEY	256 3 8 <LONG-HASH> ;{id = 35961 (zsk), size = 1024b}
	Trusted key: .	172800	IN	DNSKEY	257 3 8 <LONG-HASH> ;{id = 20326 (ksk), size = 2048b}
	Trusted key: .	172800	IN	DNSKEY	256 3 8 <LONG-HASH> ;{id = 46594 (zsk), size = 2048b}
	Trusted key: .	172800	IN	DNSKEY	257 3 8 <LONG-HASH> ;{id = 20326 (ksk), size = 2048b}
	Trusted key: no.	3600	IN	DNSKEY	257 3 8 <LONG-HASH> ;{id = 29471 (ksk), size = 2048b}
	Trusted key: no.	3600	IN	DNSKEY	256 3 8 <LONG-HASH> ;{id = 35961 (zsk), size = 1024b}
Key is now trusted!
[T] europris.no. 7200 IN DS 25323 15 2 <LONG-HASH> 
europris.no. 7200 IN DS 25323 15 4 <LONG-HASH> 
;; Domain: europris.no.
;; Signature ok but no chain to a trusted key or ds record
[S] europris.no. 3600 IN DNSKEY 256 3 13 ;{id = 14997 (zsk), size = 256b}
europris.no. 3600 IN DNSKEY 257 3 15 ;{id = 25323 (ksk), size = 0b}
europris.no. 3600 IN DNSKEY 256 3 15 ;{id = 39946 (zsk), size = 0b}
europris.no. 3600 IN DNSKEY 257 3 13 ;{id = 46820 (ksk), size = 256b}
[S] europris.no.	3600	IN	A	194.63.248.52
;;[S] self sig OK; [B] bogus; [T] trusted

OTOH in any case the real solution (if required) would be from the (unbound) developer(s).
With a WARN (from @secteam) as necessary to those affected, in the meantime.

--Chris
Comment 15 Viktor Dukhovni 2020-07-27 17:52:29 UTC
Comment on attachment 216796 [details]
Drill -DT

The drill output you provide shows everything working correctly:

>$ drill -DT www.europris.no ;; Number of trusted keys: 1 ;; Domain: .
>[T] . 172800 IN DNSKEY 257 3 8 ;{id = 20326 (ksk), size = 2048b}
>    . 172800 IN DNSKEY 256 3 8 ;{id = 46594 (zsk), size = 2048b} Checking if signing key is trusted:
>New key: .      172800  IN      DNSKEY  256 3 8 <blob> ;{id = 46594 (zsk), size = 2048b}
>        Trusted key: .  172800  IN      DNSKEY  257 3 8 <blob> ;{id = 20326 (ksk), size = 2048b}
>        Trusted key: .  172800  IN      DNSKEY  257 3 8 <blob> ;{id = 20326 (ksk), size = 2048b}
>        Trusted key: .  172800  IN      DNSKEY  256 3 8 <blob> ;{id = 46594 (zsk), size = 2048b}
>Key is now trusted!
>[T] no. 86400 IN DS 29471 8 2 <blob>
>;; Domain: no.
>[T] no. 3600 IN DNSKEY 256 3 8 ;{id = 35961 (zsk), size = 1024b}
>    no. 3600 IN DNSKEY 257 3 8 ;{id = 29471 (ksk), size = 2048b} Checking if signing key is trusted:
>New key: no.    3600    IN      DNSKEY  256 3 8 <blob> ;{id = 35961 (zsk), size = 1024b}
>        Trusted key: .  172800  IN      DNSKEY  257 3 8 <blob> ;{id = 20326 (ksk), size = 2048b}
>        Trusted key: .  172800  IN      DNSKEY  257 3 8 <blob> ;{id = 20326 (ksk), size = 2048b}
>        Trusted key: .  172800  IN      DNSKEY  256 3 8 <blob> ;{id = 46594 (zsk), size = 2048b}
>        Trusted key: no.        3600    IN      DNSKEY  256 3 8 <blob> ;{id = 35961 (zsk), size = 1024b}
>Key is now trusted!
>        Trusted key: no.        3600    IN      DNSKEY  257 3 8 <blob> ;{id = 29471 (ksk), size = 2048b}
>[T] europris.no. 7200 IN DS 25323 15 2 <blob>
>europris.no. 7200 IN DS 25323 15 4 <blob>
>;; Domain: europris.no.
>;; Signature ok but no chain to a trusted key or ds record
>[S] europris.no. 3600 IN DNSKEY 256 3 15 ;{id = 39946 (zsk), size = 0b}
>    europris.no. 3600 IN DNSKEY 257 3 13 ;{id = 46820 (ksk), size = 256b}
>    europris.no. 3600 IN DNSKEY 257 3 15 ;{id = 25323 (ksk), size = 0b}
>    europris.no. 3600 IN DNSKEY 256 3 13 ;{id = 14997 (zsk), size = 256b}
>;; No DS for www.europris.no.
>;; No ds record for delegation

The DS algorithm is not supported, so it is treated as absent, and the DNSKEY
RRset is reported as self-signed[S].

>;; Domain: www.europris.no.
>;; No DNSKEY record found for www.europris.no.
>[U] No data found for: www.europris.no. type A
>;;[S] self sig OK; [B] bogus; [T] trusted

There are apparently no A records for www.europris.no, though there is a CNAME record:

  www.europris.no. IN CNAME m2-varnish-production-1583682531.eu-west-1.elb.amazonaws.com.
  www.europris.no. IN RRSIG CNAME 13 3 300 20200822020208 20200723020208 14997 europris.no. <blob>
  www.europris.no. IN RRSIG CNAME 15 3 300 20200822020208 20200723020208 39946 europris.no. <blob>

It appears that "drill -D -T <domain>" does not report the CNAME or A records, while "drill -D"
or "drill -T" alone do.

I see no issue here.
Comment 16 Chris Hutchinson 2020-07-27 18:36:57 UTC
As I indicated in my last coment. I see no problem(s) here.
Further investigation(s)

# drill -TD www.europris.no. 
...
;; Domain: europris.no.
;; Signature ok but no chain to a trusted key or ds record
[S] europris.no. 3600 IN DNSKEY 256 3 13 ;{id = 14997 (zsk), size = 256b}
europris.no. 3600 IN DNSKEY 257 3 15 ;{id = 25323 (ksk), size = 0b}
europris.no. 3600 IN DNSKEY 256 3 15 ;{id = 39946 (zsk), size = 0b}
europris.no. 3600 IN DNSKEY 257 3 13 ;{id = 46820 (ksk), size = 256b}
;; No DS for www.europris.no.;; No ds record for delegation
;; Domain: www.europris.no.
;; No DNSKEY record found for www.europris.no.
[U] No data found for: www.europris.no. type A
;;[S] self sig OK; [B] bogus; [T] trusted

# drill -TD www.europris.no. CNAME
...
;; Domain: europris.no.
;; Signature ok but no chain to a trusted key or ds record
[S] europris.no. 3600 IN DNSKEY 256 3 13 ;{id = 14997 (zsk), size = 256b}
europris.no. 3600 IN DNSKEY 256 3 15 ;{id = 39946 (zsk), size = 0b}
europris.no. 3600 IN DNSKEY 257 3 13 ;{id = 46820 (ksk), size = 256b}
europris.no. 3600 IN DNSKEY 257 3 15 ;{id = 25323 (ksk), size = 0b}
;; No DS for www.europris.no.;; No ds record for delegation
;; Domain: www.europris.no.
;; No DNSKEY record found for www.europris.no.
[S] www.europris.no.	300	IN	CNAME	m2-varnish-production-1583682531.eu-west-1.elb.amazonaws.com.
;;[S] self sig OK; [B] bogus; [T] trusted

Both return the expected outcome under the circumstances.

There is NO bug here. :-)

--Chris
Comment 17 Kubilay Kocak freebsd_committer freebsd_triage 2020-07-28 02:00:42 UTC
Upstream comments:

> If unbound is compiled with a version of OpenSSL that does not support ed25519,
> then a domain that is only signed with ed25519 is treated as insecure.
>
> So this is expected behavior.

If upstream resolution changes, please re-open this issue with additional information