[Bug 1785383] Re: missing EDNS0 record confuses systemd-resolved

[Steve Dodd]

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
Foundations Bugs, which is subscribed to systemd 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