Bug 248239

Summary:

local_unbound: Fails to resolve europris.no fail after 11.3->11.4 upgrade

Product:

Base System

Reporter:

atles

Component:

misc

Assignee:

Kubilay Kocak <koobs>

Status:

Closed Works As Intended

Severity:

Affects Some People

CC:

cy, des, emaste, eugen, ietf-dane, net, portmaster

Priority:

---

Keywords:

needs-qa, regression

Version:

11.4-RELEASE

Hardware:

amd64

OS:

Any

See Also:

https://github.com/NLnetLabs/unbound/issues/271

Attachments:

Description	Flags
Drill -DT	none

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

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