Frequently stops working for 15-30 seconds at a time on Ubuntu 12.10

[Nick Salyzyn]

I'm not the only one experiencing this issue in the office. I've set up *.dev to point to 127.0.0.1 following the steps here: http://groups.drupal.org/node/16862. Usually when I ping "something.dev", it works, but sometimes it fails. I can hit something.dev:80 repeatedly with a web browser and eventually it will work. Restarting bind9 via `service bind9 restart` also works. This happens every 30 minutes or so.
---
ApportVersion: 2.6.1-0ubuntu9
Architecture: amd64
DistroRelease: Ubuntu 12.10
InstallationDate: Installed on 2012-12-04 (44 days ago)
InstallationMedia: Ubuntu 12.10 "Quantal Quetzal" - Release amd64 (20121017.5)
MarkForUpload: True
Package: bind9 1:9.8.1.dfsg.P1-4.2ubuntu3.1
PackageArchitecture: amd64
ProcCmdline: BOOT_IMAGE=/boot/vmlinuz-3.5.0-21-generic root=UUID=db53fba3-0464-4bcf-b53f-19c7f1a3c63d ro quiet splash vt.handoff=7
ProcVersionSignature: Ubuntu 3.5.0-21.32-generic 3.5.7.1
RelatedPackageVersions:
 bind9utils 1:9.8.1.dfsg.P1-4.2ubuntu3.1
 apparmor 2.8.0-0ubuntu5
SyslogBind9:

Tags: quantal
Uname: Linux 3.5.0-21-generic x86_64
UpgradeStatus: No upgrade log present (probably fresh install)
UserGroups: adm cdrom dip lpadmin plugdev sambashare sudo www-data
modified.conffile..etc.bind.named.conf.local: [modified]
mtime.conffile..etc.bind.named.conf.local: 2013-01-14T14:18:34.000718

[Alberto Salvia Novella (es20490446e)]

Thank you for taking the time to report this bug and helping to make Ubuntu better. Please execute the following command, as it will automatically gather debugging information, in a terminal:
apport-collect 1101002
When reporting bugs in the future please use apport by using 'ubuntu-bug' and the name of the package affected. You can learn more about this functionality at https://wiki.ubuntu.com/ReportingBugs.

[Nick Salyzyn (nsalyzyn)]

apport information

[Nick Salyzyn (nsalyzyn)]

apport information

[Nick Salyzyn (nsalyzyn)]

apport information

[Nick Salyzyn (nsalyzyn)]

I've provided the information requested - if there is anything else I can provide, please let me know. I did this after a reboot, so the issue may not have arisen in the logs yet. Right?

[Robie Basak (racb)]

Please could you take a copy of /etc/resolv.conf, attach it, and report the output of the following three commands? Please do all of this at the time when you're having the problem.

Command 1: "sudo netstat --inet -nlp|grep :53"
Command 2: "dig something.dev a @127.0.0.1"
Command 3: "dig something.dev a @127.0.1.1"

Once done, please change the bug status back to New.

[Robie Basak (racb)]

PS. you might have to install the dnsutils package to get the dig command.

[Nick Salyzyn (nsalyzyn)]

What the requests look like on failure

[Nick Salyzyn (nsalyzyn)]

Ran `ping something.dev` until it stopped failing, and here is the output of your 3 tests on success (just in case, for comparison)

[Nick Salyzyn (nsalyzyn)]

Content of resolv.conf

[Robie Basak (racb)]

Thanks for the extra information. Based on these logs, bind9 is behaving as expected, but your system is querying the dnsmasq and not bind, so this is why it's not working for you. Since this isn't a bug in bind9, I'm marking this bug as invalid in bind9.

The instructions you've followed need to be updated, since editing resolv.conf manually does not work by itself since 12.04. See https://www.stgraber.org/2012/02/24/dns-in-ubuntu-12-04/ for details.

I understand what you're trying to do and why you're trying to do it, but it won't work the way you're trying to do it. Specifying two resolv.conf nameserver entries that return different responses as your guide does it is wrong anyway.

Since Ubuntu desktop uses dnsmasq since 12.04, the easiest way to achieve what you need might be to adapt the dnsmasq section of the guide you're using, but I'm not familiar enough with dnsmasq to give you guidance here. In any case, as this isn't a bug this bug tracker isn't really the right venue. You could try looking on askubuntu.com and ask on there if you can't find an existing question that solves your problem.

[Thomas Hood (jdthood)]

Robie is right. In the failure case the resolver is contacting 127.0.1.1, where the NetworkManager-controlled dnsmasq process listens, rather than 127.0.0.1, where BIND named is listening.

Robie is right, too, in saying that the instructions you followed have to be reinterpreted for Ubuntu. In Ubuntu /etc/resolv.conf is a symbolic link to the file /run/resolvconf/resolv.conf which is dynamically generated by the resolvconf utility. You can't edit /etc/resolv.conf directly; instead you have to configure the software that sends nameserver information to resolvconf.

If you are running BIND named locally to provide general name service then you should almost certainly disable the NetworkManager-controlled dnsmasq process and use the local BIND instead. To disable the NetworkManager-controlled dnsmasq process, comment out the line "dns=dnsmasq" in /etc/NetworkManager/NetworkManager.conf, then

    sudo stop network-manager
    sudo killall dnsmasq
    sudo start network-manager

Next, configure BIND named to register its listen address with resolvconf. Edit /etc/default/bind9 and change "RESOLVCONF=no" to "RESOLVCONF=yes", then do

    sudo service bind9 restart