DNS lookup through Netgear DG834G V4 router slow or times out

[Colin Law]

Update:
On Zesty I am seeing a timeout both with systemd-resolve and dnslookup rather than just a slow resolution. The workaround in comment #6 which disables DNSSEC still corrects the problem.
---

On up to date Yakkety if I specify my Netgear router as the DNS server (via Network Manager) then DNS lookup takes about 30 seconds. I see the delay when I run, for example,
systemd-resolve www.google.com
or
wget www.google.com

I do not see the same delay if I run
nslookup www.google.com

A clue may be that in syslog I see
Aug 3 21:20:56 dibbler systemd-resolved[2362]: Using degraded feature set (UDP+EDNS0+DO) for DNS server 127.0.1.1.
Aug 3 21:21:16 dibbler systemd-resolved[2362]: Using degraded feature set (UDP+EDNS0) for DNS server 127.0.1.1.
Aug 3 21:21:32 dibbler systemd-resolved[2362]: Using degraded feature set (UDP) for DNS server 127.0.1.1.

I do not see the issue if I specify an external DNS server.
I do not see the issue on 16.04, nor previous versions, or on other devices connected to the network. I have been using this router for years.

ProblemType: Bug
DistroRelease: Ubuntu 16.10
Package: systemd 231-1
ProcVersionSignature: Ubuntu 4.4.0-33.52-generic 4.4.15
Uname: Linux 4.4.0-33-generic x86_64
ApportVersion: 2.20.3-0ubuntu2
Architecture: amd64
CurrentDesktop: Unity
Date: Wed Aug 3 21:24:07 2016
InstallationDate: Installed on 2016-08-02 (1 days ago)
InstallationMedia: Ubuntu 16.10 "Yakkety Yak" - Alpha amd64 (20160802)
MachineType: Hewlett-Packard Presario CQ57 Notebook PC
ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-4.4.0-33-generic root=UUID=aaca48e9-0f14-4b6b-ad60-fe93989c14b8 ro quiet splash vt.handoff=7
SourcePackage: systemd
UpgradeStatus: No upgrade log present (probably fresh install)
dmi.bios.date: 12/17/2011
dmi.bios.vendor: Hewlett-Packard
dmi.bios.version: F.47
dmi.board.asset.tag: Base Board Asset Tag
dmi.board.name: 3577
dmi.board.vendor: Hewlett-Packard
dmi.board.version: 24.49
dmi.chassis.asset.tag: Chassis Asset Tag
dmi.chassis.type: 10
dmi.chassis.vendor: Hewlett-Packard
dmi.chassis.version: Chassis Version
dmi.modalias: dmi:bvnHewlett-Packard:bvrF.47:bd12/17/2011:svnHewlett-Packard:pnPresarioCQ57NotebookPC:pvr068E120000204910000620100:rvnHewlett-Packard:rn3577:rvr24.49:cvnHewlett-Packard:ct10:cvrChassisVersion:
dmi.product.name: Presario CQ57 Notebook PC
dmi.product.version: 068E120000204910000620100
dmi.sys.vendor: Hewlett-Packard

[Colin Law (colin-law)]

Having updated the router to the latest firmware (5.01.17) the problem appears to be resolved (even though the release notes made no mention of DNS. Marking this bug as invalid.

[Colin Law (colin-law)]

I am marking this New again as it has not actually been fixed by upgrading the router. It now appears that the symptom is intermittent. I have not been able to determine what it is that triggers it to fail or work.

[Martin Pitt (pitti)]

Can you please generate a debug log for resolving a name when this takes a long time?

  sudo systemctl stop systemd-resolved
  sudo SYSTEMD_LOG_LEVEL=debug script -c /lib/systemd/systemd-resolved /tmp/debug.txt

then in another terminal

  systemd-resolve www.google.com

Control-C the resolved process in the first terminal, and attach /tmp/debug.txt here. Thanks!

[Martin Pitt (pitti)]

Thanks! I forwarded this to https://github.com/systemd/systemd/issues/3980 .

Can you please try how this behaves when disabling DNSSEC?

  printf '[Resolve]\nDNSSEC=no\n' | sudo tee /etc/systemd/resolved.conf.d/nodnssec.conf
  sudo systemctl restart systemd-resolved

and then resolve something?

[Colin Law (colin-law)]

Disabling DNSSEC appears to have solved the problem.
(I had to manually create /etc/systemd/resolved.conf.d/ before the command would run)

[Martin Pitt (pitti)]

Thanks for checking. So you can keep this workaround in place for the time being.

[Colin Law (colin-law)]

Thanks Martin.

[Pauli Virtanen (pauli-virtanen)]

I'm seeing a similar issue on current Ubuntu Yakkety with Android phone AP via WPA2-personal:

$ systemd-resolve www.guugle.com
www.guugle.com: 208.73.210.200
                208.73.210.214
                208.73.211.178
                208.73.210.217
-- Information acquired via protocol DNS in 13.6889s.
-- Data is authenticated: no

`host www.guugle.com` and nslookup on the other hand return immediately during this time. Disabling DNSSEC and restarting systemd-resolved using the instructions above has no effect (the above trace is after disabling).

syslog contains the lines:

Oct 31 20:25:41 xxxxx systemd-resolved[5309]: Using degraded feature set (UDP+EDNS0+DO) for DNS server 127.0.0.1.

resolv.conf contains only `nameserver 127.0.0.1`. The problem disappears if I add also the line `nameserver 192.168.43.1` (that's the upstream DNS) --- however, the following line appears in the logs:

Oct 31 20:34:05 xxxxx systemd-resolved[5309]: Using degraded feature set (UDP) for DNS server 192.168.43.1.

[Gannet (ken20001)]

Hello. I'm recently upgraded to Zesty and the same messages in journalctl (too many):

бер 05 14:33:56 p5q3 systemd-resolved[1223]: Using degraded feature set (UDP) for DNS server 127.0.1.1.

Also:

~$ nslookup google.com
;; connection timed out; no servers could be reached

But:

~$ systemd-resolve google.com
google.com: 216.58.209.174
            2a00:1450:400d:802::200e

-- Information acquired via protocol DNS in 65.9ms.
-- Data is authenticated: no

Also, I'm experiencing some difficulties connecting by some software, for example teamviewer can't connect at all.

[Colin Law (colin-law)]

@Gannet, I don't understand why you have changed the description. For me I see a slow lookup, it does eventually resolve. Does the workaround in #6 fix it? If not then it is a different bug.

[Gianfranco Costamagna (costamagnagianfranco)]

@Colin, can you please reply to what upstream asked?
https://github.com/systemd/systemd/issues/3980#issuecomment-279779991

[Colin Law (colin-law)]

I have replied to the upstream comment, however with Zesty I am seeing a slightly different symptom. Both systemd-resolve and nslookup both timeout rather than just being slow. Disabling DNSSEC still fixes it however.

[Colin Law (colin-law)]

This is particularly annoying when installing Ubuntu, as the system knows the network is connected, but DNS does not work so it can't actually do anything useful.

[Laurent Simon (stratic)]

Same case than Gannet after Zesty upgrade. Disabling DNSEC does not fix anything.

[Colin Law (colin-law)]

Laurent, if disabling DNSSEC does not fix it then it is not the same bug. I suggest submitting a new bug.

[Dan Streetman (ddstreet)]

please reopen if this is still an issue