I have just set up (successfully I hope) a DNS server at with some name server records
There's no need to hope. You can test it.
dig is an amazing tool for playing around with DNS.
To start with, DNS cannot be completely self-contained. Someone else somewhere must know about you so they can find the nameservers you have just set up. This someone should be your registrar. They will have passed this on to their parent organisation who will publish the info in their nameservers. If your nameservers are also part of the same domain they serve, you will also have to tell your registrar what their IP addresses are so the parent can provide glue. This is the only step that takes some time that you can't control or get around with
So the first query you need to make with
dig is to find out what everyone knows about your nameservers. (Technically, this isn't the first query... you need to know where the root servers are then ask them where your TLD is then ask your TLD where yours are, but we can skip that for now.)
dig example.com NS
This query should return your namserver records (something like
ns2.example.com) and hopefully an ADDITIONAL section with the IP addresses of your nameservers. If it doesn't have the ADDITIONAL section, this one should:
dig @ns1.example.com example.com NS
Once you have verified that your parent zone knows about your nameservers, you can test that they are working correctly by firing various different queries at them. This is done using the @ syntax above.
There is no waiting for "propagation" at this stage. If you add a new record and restart bind, you can make a query using the @ syntax to specify your nameserver and you will see that new record immediately. If you change a record, you will see that change immediately too, even if you had just done the same query and would normally expect the result to be cached, because the authoritative nameservers don't cache their own records.
I always recommend intodns.com because they do a whole bunch of queries for you and will let you know of any problems they see, such as only having one nameserver or having all of your nameservers on the same autonomous system.
As for forwarders, these serve a different purpose. These are for domains that you are not authoritative for. When one of your clients queries
google.com, you don't know the answer so you have to go and ask someone else. You could mess around with all that asking the root servers for the
com nameservers and then asking the
com nameservers for the
google.com nameservers and then asking the
google.com nameservers for the A record for
google.com or you could just use a forwarder. Your DNS server asks someone else's DNS server to do all the running around for you, then you present the answer back to the client as if you had done all the hard work. (It would be polite at this stage to cache the result.)
So to answer your questions:
- Yes you can use more than two forwarders. This can be to spread the load across the different servers and for redundancy if one or more of them go down, although bind can happily resolve queries without any forwarders at all so it's fine if they all go down.
- No, forwarders are for resolving other people's domains, not serving your own domains.
- OpenDNS run public nameservers, as do Level 3 (although it seems they only continue doing this out of the goodness of their hearts because so many people depend on them). Many other people do too. A ServerFault answer is not a good place to keep such a list as it changes over time. A search for "Public DNS" is more likely to result in a good answer forever.
- Restarting bind doesn't affect any upstream or downstream servers unless you have changed values in your zones or the IP address of the server.
- You can reload zones using
rndc reload. Any slave servers you have configured will check the master server after their waiting period is up and will update any zones as long as the serial has been incremented.
If you're going to run your own nameservers, get this book. Many of the other books there are well worth reading/owning.