3

I followed this very nice tutorial to make my first DNS server on Debian Jessie (on my Raspberry Pi). It seems to have worked fine. I can ping:

ping myhostname.mydomain

and it works fine. The problem is that EVERYTIME I restart my raspberry Pi, I have to run

sudo service bind9 restart

or otherwise the DNS server won't start with my configuration and my DNS definitions won't work. Now I have to say that if I run htop, I can see bind9 running there, but nevertheless, I do ping and I get that hostname doesn't exist. Only after I restart bind9 manually, the DNS server works again.

I have to say that while I have been trying to fix this, I made bind9 run through Chroot as explained in the Debian page, but this didn't help.

I'm still very new to this, so please ask if you require any additional information. I don't know where to start looking for issues of bind9 to solve this problem.

Note: I started all this from a fresh installation.


Update based on questions from comments:

dig myhostname.mydomain

gives a timeout:

; <<>> DiG 9.9.5-9+deb8u3-Raspbian <<>> myhostname.mydomain
;; global options: +cmd
;; connection timed out; no servers could be reached

The command netstat -plnut returns

(Not all processes could be identified, non-owned process info
 will not be shown, you would have to be root to see it all.)
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name
tcp        0      0 127.0.0.1:53            0.0.0.0:*               LISTEN      -
tcp        0      0 0.0.0.0:22              0.0.0.0:*               LISTEN      -
tcp        0      0 127.0.0.1:953           0.0.0.0:*               LISTEN      -
tcp        0      0 127.0.0.1:6010          0.0.0.0:*               LISTEN      -
tcp6       0      0 :::80                   :::*                    LISTEN      -
tcp6       0      0 :::53                   :::*                    LISTEN      -
tcp6       0      0 :::22                   :::*                    LISTEN      -
tcp6       0      0 ::1:953                 :::*                    LISTEN      -
tcp6       0      0 ::1:6010                :::*                    LISTEN      -
udp        0      0 127.0.0.1:53            0.0.0.0:*                           -
udp        0      0 0.0.0.0:68              0.0.0.0:*                           -
udp        0      0 192.168.1.2:123         0.0.0.0:*                           -
udp        0      0 127.0.0.1:123           0.0.0.0:*                           -
udp        0      0 0.0.0.0:123             0.0.0.0:*                           -
udp        0      0 0.0.0.0:48851           0.0.0.0:*                           -
udp        0      0 0.0.0.0:5353            0.0.0.0:*                           -
udp6       0      0 :::546                  :::*                                -
udp6       0      0 :::53                   :::*                                -
udp6       0      0 2003:75:e15:c201:52:123 :::*                                -
udp6       0      0 fe80::ba27:ebff:fe7:123 :::*                                -
udp6       0      0 ::1:123                 :::*                                -
udp6       0      0 :::123                  :::*                                -
udp6       0      0 :::53420                :::*                                -
udp6       0      0 :::5353                 :::*                                -

After restarting, these two lines get added, which belong to the DNS server:

tcp        0      0 192.168.1.2:53          0.0.0.0:*               LISTEN      -
udp        0      0 192.168.1.2:53          0.0.0.0:*                           -
8
  • What do the logs say? And what kind of response do you get if any (dig output would be more helpful)? If applicable, can you show netstat -plnut when it doesn't work? Is it possible that named starts before some network configuration has been applied? – Håkan Lindqvist Oct 31 '15 at 13:36
  • @HåkanLindqvist Thank you for responding. I updated my answer with responses of my server. I'm not sure whether named starts before network configuration. Would you please propose a way to test that this is the reason and how to fix it? – The Quantum Physicist Oct 31 '15 at 14:06
  • It only bound to 127.0.0.1 for v4... that seems in line with not having any other interface up at the point when named started. – Håkan Lindqvist Oct 31 '15 at 14:28
  • 1
    From what I've seen it seems you'd want to look into why named starts before your network interfaces are up. – Håkan Lindqvist Oct 31 '15 at 15:06
  • 1
    @TheQuantumPhysicist update-rc didnt' work because network is up (but no address obtained) try the script. – Jacob Evans Oct 31 '15 at 15:44
2

1) Custom script to handle DHCP delays. (create files as root/sudo)

cat /usr/local/sbin/network-check

#!/bin/bash
while ! ifconfig | grep "192.168.1." > /dev/null; do
        #Network Down
        sleep 1
done
#Network up restart bind9
service bind9 restart

chmod a+x /usr/local/sbin/network-check

add a line before exit 0 in /etc/rc.local

network-check
exit 0

and then reboot

2) Set a static, network will start with an IP and then bind9 will start (and use that IP)

4
  • Thanks for the response. I executed sudo update-rc.d bind9 defaults 99, but didn't help. There's a DHCP server in my router that decides the IP of my RPi. How can I get resolv.conf to point to my localhost? Isn't generated automatically? As you asked for configs and logs, config is exactly like the link I provided, and logs, please be specific what log you need and I'll prepare it for you. – The Quantum Physicist Oct 31 '15 at 15:22
  • /var/log/messages or /var/log/syslog, the directions have some leeway in specifics, specifics make the difference, what IP are you binding the bind service to? DHCP will take longer to assign than bind takes to start, you may need to use a script to check if an IP address has been assigned (or internet is reachable) and then automatically restart bind9. – Jacob Evans Oct 31 '15 at 15:23
  • @TheQuantumPhysicist I added a script for you, give that a shot it may be the easiest option for you, typically you would use static IPs and send resolv.conf to localhost (and let bind9 communicate with root hints or public forwarders) – Jacob Evans Oct 31 '15 at 15:42
  • No problem, if you have other issues (network drops) you could add a cron-job but that seems excessive for your needs. Static IP is preferred & you wouldn't need the script (network is up and IP is up with network so update-rc command would work as your aren't waiting for negotiation) but the script would still work. – Jacob Evans Oct 31 '15 at 15:49
0

I recommend upgrading to BIND 9.10, which has the ability to automatically detect the changes to your system's IP addresses via the default yes setting for the automatic-interface-scan global option.

In BIND 9.9, the relevant option is interface-interval which controls how often BIND polls for interface changes. The default value is 60 minutes, which is too slow for your purposes.

Not the answer you're looking for? Browse other questions tagged or ask your own question.