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.