Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
wtoorop opened this issue Nov 8, 2016 · 13 comments

Comments

9 participants
@wtoorop
Copy link

commented Nov 8, 2016

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

This comment has been minimized.

Copy link
Author

commented Nov 8, 2016

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

@poettering

This comment has been minimized.

Copy link
Member

commented Nov 11, 2016

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.

@poettering poettering changed the title [systemd-resolved] 127.0.0.53 server strips DNSSEC resolved doesn't set AD properly for negative replies on stub listener Nov 11, 2016

@poettering poettering added the resolve label Nov 11, 2016

@poettering poettering added this to the v233 milestone Nov 11, 2016

@wtoorop

This comment has been minimized.

Copy link
Author

commented Nov 12, 2016

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

This comment has been minimized.

Copy link
Member

commented Nov 14, 2016

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.

@poettering poettering added the RFE 🎁 label Nov 14, 2016

@poettering poettering changed the title resolved doesn't set AD properly for negative replies on stub listener resolved stub resolver doesn't provide RRSIG data in replies when DO/CD queries are sent to it Nov 14, 2016

@poettering poettering modified the milestone: v233 Nov 18, 2016

@alexanderkjall

This comment has been minimized.

Copy link

commented Nov 19, 2016

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

This comment has been minimized.

Copy link

commented Dec 4, 2016

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 added a commit to poettering/systemd that referenced this issue Feb 15, 2017

resolved: propagate AD bit for NXDOMAIN into stub replies
When we managed to prove non-existance of a name, then we should
properly propagate this to clients by setting the AD bit on NXDOMAIN.

See: systemd#4621
@poettering

This comment has been minimized.

Copy link
Member

commented Feb 15, 2017

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.

@poettering poettering removed this from the v233 milestone Feb 15, 2017

poettering added a commit to poettering/systemd that referenced this issue Feb 17, 2017

resolved: propagate AD bit for NXDOMAIN into stub replies
When we managed to prove non-existance of a name, then we should
properly propagate this to clients by setting the AD bit on NXDOMAIN.

See: systemd#4621
@traud

This comment has been minimized.

Copy link

commented May 14, 2018

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

This comment has been minimized.

Copy link

commented Jun 3, 2018

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

@traud

This comment has been minimized.

Copy link

commented Jul 5, 2018

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

This comment has been minimized.

Copy link

commented Dec 27, 2018

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

This comment has been minimized.

Copy link

commented Dec 27, 2018

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

@exploide

This comment has been minimized.

Copy link

commented Jun 18, 2019

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.