Bug#911408: dnsmasq breaks systemd autopkgtest

[Simon Kelley]

On 07/11/2018 15:17, Michael Biebl wrote:
> Hi Simon,
> 
> I see that you reassigned this back to systemd, but I know too little
> about DNS(SEC) to assess the situation. So your help on this issue would
> be most welcome.
> 
> What I did is, to run the test against v2.79 and v2.80
> 
> This starts a dnsmasq process like this:
> nobody   11531  0.0  0.3  25260  3316 pts/1    S+   23:10   0:00 dnsmasq
> --keep-in-foreground --log-queries
> --log-facility=/tmp/tmp3_id7zsx/dnsmasq-vpn.log --conf-file=/dev/null
> --dhcp-leasefile=/dev/null --bind-interfaces --interface=testvpnrouter
> --except-interface=lo --address=/math.lab/10.241.3.3
> --address=/cantina.company/10.241.4.4
> 
> With v2.79 I get the following in the log files:
> ================================================
> # resolvectl query kettle.cantina.company
> kettle.cantina.company: 10.241.4.4
> 
> -- Information acquired via protocol DNS in 3.6ms.
> -- Data is authenticated: no
> 
> # cat /tmp/tmp3_id7zsx/dnsmasq-vpn.log
> Nov  6 23:10:39 dnsmasq[11531]: started, version 2.79 cachesize 150
> Nov  6 23:10:39 dnsmasq[11531]: compile time options: IPv6 GNU-getopt
> DBus i18n IDN DHCP DHCPv6 no-Lua TFTP conntrack ipset auth DNSSEC
> loop-detect inotify
> Nov  6 23:10:39 dnsmasq[11531]: reading /etc/resolv.conf
> Nov  6 23:10:39 dnsmasq[11531]: using nameserver 10.0.2.3#53
> Nov  6 23:10:39 dnsmasq[11531]: read /etc/hosts - 4 addresses
> Nov  6 23:17:38 dnsmasq[11531]: query[A] kettle.cantina.company from
> 10.241.3.1
> Nov  6 23:17:38 dnsmasq[11531]: config kettle.cantina.company is 10.241.4.4
> Nov  6 23:17:38 dnsmasq[11531]: query[A] kettle.cantina.company from
> 10.241.3.1
> Nov  6 23:17:38 dnsmasq[11531]: config kettle.cantina.company is 10.241.4.4
> 
> # journalctl -u systemd-resolved
> Nov 06 23:17:38 debian systemd-resolved[11545]: Using degraded feature
> set (UDP) for DNS server 10.241.3.1.
> Nov 06 23:17:38 debian systemd-resolved[11545]: Server 10.241.3.1 does
> not support DNSSEC, downgrading to non-DNSSEC mode.
> 
> 
> With v2.80
> ==========
> nobody   13333  0.0  0.3  25280  3328 pts/1    S+   23:29   0:00 dnsmasq
> --keep-in-foreground --log-queries
> --log-facility=/tmp/tmpf3unvou5/dnsmasq-vpn.log --conf-file=/dev/null
> --dhcp-leasefile=/dev/null --bind-interfaces --interface=testvpnrouter
> --except-interface=lo --address=/math.lab/10.241.3.3
> --address=/cantina.company/10.241.4.4
> 
> # resolvectl query kettle.cantina.company
> kettle.cantina.company: resolve call failed: DNSSEC validation failed:
> no-signature
> 
> # cat /tmp/tmpf3unvou5/dnsmasq-vpn.log
> Nov  6 23:29:09 dnsmasq[13333]: started, version 2.80 cachesize 150
> Nov  6 23:29:09 dnsmasq[13333]: compile time options: IPv6 GNU-getopt
> DBus i18n IDN DHCP DHCPv6 no-Lua TFTP conntrack ipset auth DNSSEC
> loop-detect inotify dumpfile
> Nov  6 23:29:09 dnsmasq[13333]: reading /etc/resolv.conf
> Nov  6 23:29:09 dnsmasq[13333]: using nameserver 10.0.2.3#53
> Nov  6 23:29:09 dnsmasq[13333]: read /etc/hosts - 4 addresses
> Nov  6 23:29:56 dnsmasq[13333]: query[A] kettle.cantina.company from
> 10.241.3.1
> Nov  6 23:29:56 dnsmasq[13333]: config kettle.cantina.company is 10.241.4.4
> Nov  6 23:29:56 dnsmasq[13333]: query[SOA] kettle.cantina.company from
> 10.241.3.1
> Nov  6 23:29:56 dnsmasq[13333]: config kettle.cantina.company is NODATA
> Nov  6 23:29:56 dnsmasq[13333]: query[DS] kettle.cantina.company from
> 10.241.3.1
> Nov  6 23:29:56 dnsmasq[13333]: config kettle.cantina.company is NODATA
> Nov  6 23:29:56 dnsmasq[13333]: query[SOA] cantina.company from 10.241.3.1
> Nov  6 23:29:56 dnsmasq[13333]: config cantina.company is NODATA
> Nov  6 23:29:56 dnsmasq[13333]: query[DS] cantina.company from 10.241.3.1
> Nov  6 23:29:56 dnsmasq[13333]: config cantina.company is NODATA
> Nov  6 23:29:56 dnsmasq[13333]: query[SOA] company from 10.241.3.1
> Nov  6 23:29:56 dnsmasq[13333]: forwarded company to 10.0.2.3
> Nov  6 23:29:56 dnsmasq[13333]: query[DNSKEY] company from 10.241.3.1
> Nov  6 23:29:56 dnsmasq[13333]: forwarded company to 10.0.2.3
> Nov  6 23:29:56 dnsmasq[13333]: query[DS] company from 10.241.3.1
> Nov  6 23:29:56 dnsmasq[13333]: forwarded company to 10.0.2.3
> Nov  6 23:29:56 dnsmasq[13333]: query[DNSKEY] . from 10.241.3.1
> Nov  6 23:29:56 dnsmasq[13333]: forwarded . to 10.0.2.3
> 
> # journalctl -u systemd-resolved
> Nov 06 23:29:56 debian systemd-resolved[13349]: DNSSEC validation failed
> for question cantina.company IN DS: no-signature
> Nov 06 23:29:56 debian systemd-resolved[13349]: DNSSEC validation failed
> for question cantina.company IN SOA: no-signature
> Nov 06 23:29:56 debian systemd-resolved[13349]: DNSSEC validation failed
> for question kettle.cantina.company IN DS: no-signature
> Nov 06 23:29:56 debian systemd-resolved[13349]: DNSSEC validation failed
> for question kettle.cantina.company IN SOA: no-signature
> Nov 06 23:29:56 debian systemd-resolved[13349]: DNSSEC validation failed
> for question kettle.cantina.company IN A: no-signature
> 
> So for some reason, with v2.80, DNSSEC is attempted for this query.
> Maybe you have an idea what's going on there.
> 
> Regards,
> Michael
> 


Thanks for the additional information: I think I can see what's
happening here, and it's a combination of things, as usual.

There is a bug in dnsmasq (as I mentioned before) that if the query has
the ad bit set, (requesting DNSSEC validation) then in this particular
case (answer comes from --address in the command line or config file)
the ad bit is set in the answer, even though the answer is NOT DNSSEC
validated.

This bug also exists in 2.79, which made me think that it was not the
source of the problem. As you found, the change in 2.80 which triggers
the error is

commit 1682d15a744880b0398af75eadf68fe66128af78
Author: Simon Kelley <simon at thekelleys.org.uk>
Date:   Fri Aug 3 20:38:18 2018 +0100

    Add missing EDNS0 section.
    EDNS0 section missing in replies to EDNS0-containing queries where
    answer generated from --local=/<domain>/


So in 2.79, the test gets an answer with the ad bit set (bad), but no
EDNS0 header, and (I guess) decides that it isn't DNSSEC validated,
because EDSN0 is compulsory for DNSSEC. In 2.80, the EDNS0 header is
present, which is correct, it really should be there, but the
pre-existing bug with the ad-bit is now triggered, because the answer
has everything it needs to make it look like it should have DNSSEC
validation, but it doesn't have the relevant signatures.

The two bugs in 2.79 cancelled each other out. The one remaining in 2.80
is now made patent by the fix of the other.

To test this, please could you apply

http://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=commit;h=a220545c4277cba534be5ef4638b5076fc7d2cf4

to 2.80 and run the test again? If that fixes the problem, I'll gladly
take to bug back and issue a 2.80-2 with that fix.

Sorry for the back-and-forth. I've not worked out how to run the systemd
test suite and reproduce the problem here.


Cheers,

Simon.



-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://alioth-lists.debian.net/pipermail/pkg-systemd-maintainers/attachments/20181108/5d7ebb05/attachment-0002.sig>