Reverting the patch "resolved-Mitigate-DVE-2018-0001-by-retrying-
NXDOMAIN-with.patch" solves this problem for me. My best guess is that
the following patch segment changes some key logic:
@@ -388,12 +388,12 @@ static int dns_transaction_pick_server(DnsTransaction *t)
{
if (!server)
return -ESRCH;
- /* If we changed the server invalidate the feature level clamping, as
the new server might have completely
- * different properties. */
- if (server != t->server)
+ /* If we changed the server invalidate the current & clamp feature
levels, as the new server might have
+ * completely different properties. */
+ if (server != t->server) {
t->clamp_feature_level = _DNS_SERVER_FEATURE_LEVEL_INVALID;
-
- t->current_feature_level = dns_server_possible_feature_level(server);
+ t->current_feature_level =
dns_server_possible_feature_level(server);
+ }
Note that it makes the assignment dependent on the test, I don't know if
this was intentional or not.
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to dnsmasq in Ubuntu.
https://bugs.launchpad.net/bugs/1785383
Title:
missing EDNS0 record confuses systemd-resolved
Status in dnsmasq package in Ubuntu:
New
Status in systemd package in Ubuntu:
New
Bug description:
dnsmasq 2.79 and below omits EDNS0 OPT records when returning an empty
answer for a domain it is authoritative for. systemd-resolved seems to
get confused by this in certain circumstances; when using the stub
resolver and requesting an address for which there are no AAAA
records, there can sometimes be a five second hang in resolution.
This is fixed by upstream commit
http://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=commit;h=1682d15a744880b0398af75eadf68fe66128af78
Not sure if it is worth cherry picking? I imagine the most likely
trigger will be dnsmasq on routers which are not likely to be running
Ubuntu, but maybe just in case.
I also think there are some logic issues in systemd-resolved, upstream
bug filed:
https://github.com/systemd/systemd/issues/9785
Simple-ish test case:
---
IFACE=dummy0
SUBNET=10.0.0
ip link add $IFACE type dummy
ifconfig $IFACE ${SUBNET}.1/24
dnsmasq -h -R -d -C /dev/null -2 $IFACE -z -i $IFACE -I lo
--host-record=test.test,${SUBNET}.1 &
dig -t a test.test @10.0.0.1 | grep EDNS
# should return "; EDNS ..."
dig -t aaaa test.test @10.0.0.1 | grep EDNS
# again, should return "; EDNS ..." but doesn't
---
To reproduce the systemd-resolved side of the problem
---
# as above, but
# now configure systemd-resolved to look at only 10.0.0.1, then
systemd-resolve --reset-server-features
# should exhibit five second delay then connect, assuming sshd is running :)
ssh test.test
---
ProblemType: Bug
DistroRelease: Ubuntu 18.04
Package: dnsmasq-base 2.79-1
ProcVersionSignature: Ubuntu 4.15.0-23.25-generic 4.15.18
Uname: Linux 4.15.0-23-generic x86_64
ApportVersion: 2.20.9-0ubuntu7.2
Architecture: amd64
Date: Sat Aug 4 11:33:56 2018
InstallationDate: Installed on 2018-05-31 (64 days ago)
InstallationMedia: Xubuntu 18.04 LTS "Bionic Beaver" - Release amd64
(20180426)
ProcEnviron:
TERM=xterm
PATH=(custom, no user)
LANG=en_GB.UTF-8
SHELL=/bin/bash
SourcePackage: dnsmasq
UpgradeStatus: No upgrade log present (probably fresh install)
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/dnsmasq/+bug/1785383/+subscriptions
--
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help : https://help.launchpad.net/ListHelp
