resolved stub resolver doesn't provide RRSIG data in replies when DO/CD queries are sent to it

[wtoorop]

Submission type

• Bug report
• Request for enhancement (RFE)

systemd version the issue has been seen with

231-9git1? (the one that ships with ubuntu 16.10)

Used distribution

Ubuntu

In case of bug report: Expected behaviour you didn't see

When sending the DO bit in queries to 127.0.0.53, the returned data did not include DNSSEC data (i.e. the RRSIGs).
When asking for non-existent records, the DNSSEC proof of non-existance is missing.

In case of bug report: Unexpected behaviour you saw

When asking for non-existent records, the AD bit is also not set, as if systemd-resolved did not validate the non-existance of the requested record.

In case of bug report: Steps to reproduce the problem

> $ dig @127.0.0.53 nlnetlabs.nl +dnssec

; <<>> DiG 9.10.3-P4-Ubuntu <<>> @127.0.0.53 nlnetlabs.nl +dnssec
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 54947
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 65494
;; QUESTION SECTION:
;nlnetlabs.nl.			IN	A

;; ANSWER SECTION:
nlnetlabs.nl.		5332	IN	A	185.49.140.10

;; Query time: 0 msec
;; SERVER: 127.0.0.53#53(127.0.0.53)
;; WHEN: Tue Nov 08 15:29:19 CET 2016
;; MSG SIZE  rcvd: 57

$ dig @127.0.0.53 nonexistant.nlnetlabs.nl +dnssec

; <<>> DiG 9.10.3-P4-Ubuntu <<>> @127.0.0.53 nonexistant.nlnetlabs.nl +dnssec
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 3445
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 65494
;; QUESTION SECTION:
;nonexistant.nlnetlabs.nl.	IN	A

;; Query time: 3 msec
;; SERVER: 127.0.0.53#53(127.0.0.53)
;; WHEN: Tue Nov 08 15:29:43 CET 2016
;; MSG SIZE  rcvd: 53

[wtoorop]

But besides the bug report... thanks for bringing DNSSEC so close to the end-user!

[poettering]

Well, resolved is not supposed to be a DNS server, it's supposed to be exactly good enough so that libc-like DNS clients can resolve their stuff, and we carry enough info for the AD bit to be set. That's by design really. See the commit msg of b30bf55.

If we don't set AD properly for negative replies, that'd be a bug however, indeed.

[wtoorop]

Op 12-11-16 om 05:37 schreef Lennart Poettering:

Well, resolved is not supposed to be a DNS server, it's supposed to be
exactly good enough so that libc-like DNS clients can resolve their
stuff, and we carry enough info for the AD bit to be set.

Thanks Lennart. I understand systemd-resolved is not a fully fledged
DNS server (but a DNS interface on a stub resolver), but signatures
alongside the requested RRs would be good for applications that lookup
TLSA records (or SSHFP or other DANE like RRs) and confirm the validity
(or check the non-existance proof) themselves.

ldns and getdns can do this for example.

Perhaps this could be a enhancement request then?
Do you want me to put it in a separate issue?

Also, I have to admit that I cannot find it specified in the RFCs right
now, but it is conventional to return the DNSSEC data when the DO bit is
set. Returning only AD bit and not the signatures, NSEC's etc. is
normally done when you send a query with the AD bit set. Quote from
RFC6840 section 5.7 (last sentence implies DNSSEC data is requested with
the DO bit):

5.7. Setting the AD Bit on Queries

The semantics of the Authentic Data (AD) bit in the query were
previously undefined. Section 4.6 of [RFC4035] instructed resolvers
to always clear the AD bit when composing queries.

This document defines setting the AD bit in a query as a signal
indicating that the requester understands and is interested in the
value of the AD bit in the response. This allows a requester to
indicate that it understands the AD bit without also requesting
DNSSEC data via the DO bit.

[poettering]

well, if clients want to validate DNSSEC on their own, they should probably not involve resolved then I think...

But anyway, I'll turn this into an RFE, but I don't think this is really in focus for us.

[alexanderkjall]

Hi, I'm not sure if I'm seeing the same issue, or at least a variant of the same issue.

I configured my system (ubuntu 16.10) to use systemd as the dns resolver, and that broke lookups of RRSIG records.

If i try to use dig i get this result:

$ dig +dnssec xil.se RRSIG

; <<>> DiG 9.10.3-P4-Ubuntu <<>> +dnssec xil.se RRSIG
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: FORMERR, id: 14901
;; flags: qr rd ra; QUERY: 0, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0

;; WARNING: EDNS query returned status FORMERR - retry with '+nodnssec +noedns'

;; Query time: 0 msec
;; SERVER: 127.0.0.53#53(127.0.0.53)
;; WHEN: Sat Nov 19 17:51:55 CET 2016
;; MSG SIZE  rcvd: 12

and by using systemd-resolve directly i get this result:

$ systemd-resolve -t RRSIG xil.se
xil.se: resolve call failed: Specified resource record type 46 may not be used in a query.

[andersk]

well, if clients want to validate DNSSEC on their own, they should probably not involve resolved then I think...

If /etc/resolv.conf points to 127.0.0.53, what choice do they have?

[poettering]

If we don't set AD properly for negative replies, that'd be a bug however, indeed.

This bit should be fixed now with #5347. Dropping the v233 milestone hence, as what remains of this issue is mostly RFE.

[traud]

Please, help! Or in other words, I would like to have an answer to Anders’ question above. My very own app which does DANE, broke on Ubuntu 18.04 LTS. It worked great in Ubuntu 14.04 LTS and Ubuntu 16.04 LTS. This is a software bug for sure. Now, I have to report this somewhere, even if it is to myself.

A) Ubuntu
uses systemd-resolved on default and puts it in /etc/resolv.conf. In my case, just 127.0.0.53 is listed in that file. This is since Ubuntu 17.04, actually.

B) systemd-resolved
does not provide RRSIG. Therefore, the official example code gives:

Result is bogus: validation failure <www.nlnetlabs.nl. A IN>: no DNSKEY rrset for trust anchor . while building chain of trust.

C) Unbound
state in their example code, /etc/resolv.conf can be used for caching and when you trust that file/server. In former days, one did sudo apt install unbound which installed a DNS resolver at 127.0.0.1 and that creates a /etc/resolv.conf with just 127.0.0.1. Since Ubuntu 18.04 LTS this does not help, because systemd-resolved is still the only DNS server listed in /etc/resolv.conf after installing Unbound. Is this an issue of the package or just the tutorial?

D) Myself
Did I misunderstood that example code and my code should change:

• Should I test for /run/systemd/resolve/stub-resolv.conf, avoid /etc/resolv.conf, and use Unbound in full-resolver mode (without caching). Or
• Instead of /etc/resolv.conf, first I try ub_ctx_resolvconf(ctx, "/run/systemd/resolve/resolv.conf"). That is not encouraged by the man page…

E) End-Users
Or is this no bug at all, and an interested user should be educated to change the symbolic link of /etc/resolv.conf to /run/systemd/resolve/resolv.conf?

---

Another example
$ dig www.nlnetlabs.nl. A +dnssec
This does not give RRSIG on Ubuntu 18.04 LTS because resolved does not provide this feature. This worked in Ubuntu 16.04 LTS and earlier because my upstream DNS server provides DNSSEC caching.

$ dig @127.0.0.1 www.nlnetlabs.nl. A +dnssec
This approach works, after sudo apt install unbound. Therefore, another approach for my source code would be ub_ctx_set_fwd(ctx, "127.0.0.1").

$ dig @8.8.8.8 www.nlnetlabs.nl. A +dnssec
This approach—the DNS servers from Google—works always, of course.

---

Yet another example
With the tools from the package hash-slinger, I have to specify --resolvconf "/run/systemd/resolve/resolv.conf" to overwrite the default of /etc/resolv.conf. Otherwise, I get error messages like

Unsuccessful lookup or no data returned for OPENPGPKEY (rrtype 61)

---

There must be a totally easy answer, which I do not see. My app does not work on default in Ubuntu 18.04 LTS at all, because the DNS result is even ‘bogus’. Please, help!

I cross-posted this on the Unbound mailing-list…

[sidusnare]

If this is not a DNS server, perhaps we shouldn't use it as the default DNS server?

[traud]

Has anyone an idea where to report my bug: Is it A, B, C, D, or E? As explained on the Unbound mailing list, I found another workaround for Ubuntu 18.04 LTS: sudo apt install unbound resolvconf

[chrwei]

the work-around is easy, just specify the real dns server on your diag tools. this forces you to check what server resolved is actually using first, which is simple: systemd-resolve --status

[detly]

@traud I don't know the official answer, but I did (A). https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1782679

[exploide]

According to the BIND docs, the tool delv is the designated successor of dig, with better DNSSEC support built-in.

I stumbled over this issue here because I was wondering and debugging why delv was no longer able to resolve DNS names.

$ delv iana.org
;; no valid RRSIG resolving 'org/DS/IN': 127.0.0.53#53
;; no valid DS resolving 'iana.org/A/IN': 127.0.0.53#53
;; resolution failed: no valid DS

It's because systemd-resolved is used and RRSIG records are not passed through.

Of course, one can always manually tell delv to use @another-resolver but I think stuff should be functional by default and don't break standard tasks. Hence, it would be great if resolved could deliver also DNSSEC related records.