Installing Bind9 as a recursive server fails in a default install with no editing of files, does not work as a caching server as expected

Bug #1675221 reported by Nathaniel Homier
8
This bug affects 1 person
Affects Status Importance Assigned to Milestone
bind9 (Ubuntu)
Expired
Undecided
Unassigned

Bug Description

Description: Ubuntu 16.10
Release: 16.10

I checked a fresh install of Ubuntu 16.10 on a v machine and indeed the problem can be replicated.

I sudo apt install bind9
I did no touching or editing of any bind9 files. I left /etc/network/interfaces alone. In Gnome Network Manager I have a wired Ethernet connection set to a static manual setup. I had 192.168.0.1 for my DNS. I changed it to 127.0.0.1 and rebooted the computer. Upon the fresh login, Firefox failed to load any web sites due to DNS not working. I then set the DNS to 127.0.1.1 and again rebooted. Firefox and other programs like NTP failed DNS lookup. I then set the DNS to 192.168.0.1 and DNS started working again.

sudo apt install bind9 should install a working caching server and setting Gnome Network Manager to 127.0.0.1 should produce a working DNS system.

This worked perfectly on Ubuntu 15.10. I installed bind9 after having not used it until 16.10 and found that the plug and play, it just works bind9 no longer worked.

The following log entries are the only ones available.

Mar 22 18:24:42 frontier systemd-resolved[1588]: Using degraded feature set (UDP) for DNS server 127.0.1.1.

Mar 22 18:24:48 frontier systemd-resolved[1588]: Using degraded feature set (TCP) for DNS server 127.0.1.1.

Mar 21 22:10:27 frontier kernel: [ 79.504499] TCP: request_sock_TCP: Possible SYN flooding on port 53. Sending cookies. Check SNMP counters.

Bind9 config files are default and untouched.

ProblemType: Bug
DistroRelease: Ubuntu 16.10
Package: bind9 1:9.10.3.dfsg.P4-10.1ubuntu1.3
ProcVersionSignature: Ubuntu 4.8.0-41.44-generic 4.8.17
Uname: Linux 4.8.0-41-generic x86_64
ApportVersion: 2.20.3-0ubuntu8.2
Architecture: amd64
CurrentDesktop: Unity
Date: Wed Mar 22 18:28:48 2017
ProcEnviron:
 LANGUAGE=en_US
 PATH=(custom, no user)
 XDG_RUNTIME_DIR=<set>
 LANG=en_US.UTF-8
 SHELL=/bin/bash
RelatedPackageVersions:
 bind9utils 1:9.10.3.dfsg.P4-10.1ubuntu1.3
 apparmor 2.10.95-4ubuntu5.1
SourcePackage: bind9
UpgradeStatus: Upgraded to yakkety on 2016-10-17 (156 days ago)
modified.conffile..etc.apparmor.d.usr.sbin.named: [modified]
mtime.conffile..etc.apparmor.d.usr.sbin.named: 2017-03-21T22:06:47.196008

Revision history for this message
Nathaniel Homier (mechamechanism) wrote :
description: updated
Revision history for this message
Nathaniel Homier (mechamechanism) wrote :

Just tested Ubuntu 15.10 and Bind9 works out of the box. Could not test 16.04.2 because of issues with Virtualbox.

Revision history for this message
Christian Ehrhardt  (paelzer) wrote :

Hi Nathaniel,
I was trying to reproduce on 16.10.
by default answer came from my DNS
[...]
;; SERVER: 192.168.122.1#53(192.168.122.1)

# Installing bind9
sudo apt-get install bind9
# starting as not by default
sudo systemctl start bind9
# netstat shows me it runs on .53 by default it seems
$ sudo netstat -eeapn | grep named
tcp 0 0 127.0.0.1:53 0.0.0.0:* LISTEN 112 21000 2445/named
# well, fine set 127.0.0.53 in resolv.conf for now (what you do in the gnome network manager)
# ready and working, dig now reports me valid resolution from this
$dig ubuntu.com
[...]
;; SERVER: 127.0.0.53#53(127.0.0.53)
# I noted that 127.0.0.1:53 was also grabbed by named, so I checkd this and it was working as well
;; SERVER: 127.0.0.1#53(127.0.0.1)

! Not that I'd recommend running bind in default conf, a lot of things changed and I think this is much easier today without bind at all, see below for more

I compared the status and ports of the sys after installing and starting bind9
wily [2] and yakkety [3] - they are different, but bind=named in both grabbed what you expect.

Also I see:
modified.conffile..etc.apparmor.d.usr.sbin.named: [modified]
Does this have any meaning to the case?
What was the change?

BTW - isn't bind9 a bit heavy for this. You have dnsmask installed and intregated anyway.
And since 16.04 you also have systemd-resolve - maybe the introduction of that caused a change that affects your usual way to set up. dnsmasq doesn't cache by default, but [1] seems easier to me than adding bind as third.

[1]: http://askubuntu.com/questions/155163/how-do-i-enable-dns-caching-in-the-networkmanager-controlled-dnsmasq
[2]: http://paste.ubuntu.com/24240001/
[3]: http://paste.ubuntu.com/24240007/

Changed in bind9 (Ubuntu):
status: New → Incomplete
Revision history for this message
Launchpad Janitor (janitor) wrote :

[Expired for bind9 (Ubuntu) because there has been no activity for 60 days.]

Changed in bind9 (Ubuntu):
status: Incomplete → Expired
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.