You’ve two options in your master’s BIND config for a given zone: notify yes – will send notifications to all of the published NS records for the domain. notify explicit – will send notifications only to those IPs listed in the also-notify configuration. In either case, the slaves must be configured with allow-notify that accepts … Read more
Your setup is doing what it’s supposed to do: You modify a zone file, including updating the SOA serial. You run rndc reload on master. Master sends notify/notifies on zone change. Slave(s) requests zone transfers. BIND is not monitoring file changes i.e. it’s normal that it doesn’t do this automatically. You must run rndc reload … Read more
For your master zones, they should go in /etc/bind/zones because they’re config. Secondary (slave) zones should be in /var/cache/bind/secondary or similar, because it’s just cached data that can be retrieved from the master if the data is lost.
When you listen-on 127.0.0.1 or localhost or ::1, and/or allow-query from localhost only, bind will answer only to queries originating from the same computer that runs bind. (It set this way in “testing” probably because they probably just meant to test that bind works without opening it to outside for security reasons.) It is normal … Read more
It is generally considered a good practice to serve localhost, 0.0.127.in-addr.arpa and the RFC-1918 reverse zones on your internal DNS system to prevent sending queries from them out to the internet. It saves time (you get replies for those queries quickly), bandwidth (no requests leaving your network for zones that shouldn’t exist), and relieves the … Read more
In a nutshell: Forwarding: just passes the DNS query to another DNS server (e.g. your ISP’s). Home routers use forwarding to pass DNS queries from your home network’s clients to your ISP’s DNS servers. For example, for foo.example.com, a forwarding DNS server would first check its cache (did it already ask this question before), and … Read more