Ok, the include is solved, so I'll help you with the other problems you're having.
The Debian way is just that, the Debian way. I agree that in principle, it should sync up with what the O'reilly says, but there are many possible reasons why it doesn't. The Debian BIND setup is probably unchanged in several years. Just because they tell you not to add zones directly to named.conf doesn't mean that you cannot, just that the package maintainer feels that you should not. It makes much sense across the board to tell people not to mess up their named.conf, and simply add zones to the included local file. Again, if you don't like that, cool, then add them directly to named.conf, and test it out with the aforementioned named-checkconf, which along with its sister named-checkzone, can find 99% of your problems.
Secondly, if you're really unhappy with the Debian package, there is a simple fix. Move their named.conf somewhere just to be safe, and use one of the thousands of named.conf files that exist on the internet. An even better but more technical response would be to build your own BIND. To begin with, BIND 9.4.0 is now the official release from ISC, the makers of the BIND software. It has several great new features, like blocking access to the cache, and always improved functionality. Because of the way Debian works, it will probably be 6 months if not longer before BIND 9.4 makes it into stable. So download the tarball, ./configure, make, make install, and have at it. The Debian people tried to make a generic configuration that will work for most of the users most of the time, but not all of the people all of the time. If you don't like their setup, you're not dealing with Redmond WA people anymore, you can change everything as you see fit.
It seems like you're a little confused as to what named.conf does. All that does is list the nameservers that your box should use. You can add a default domain to search incomplete domain names in, but there isn't much else it does. A simple /etc/resolv.conf on a nameserver could be as simple as
Code:
search yourdomain.com
nameserver 127.0.0.1
That would tag yourdomain.com onto any non-FQDN, so saying ping beavis actually asks BIND for "ping beavis.yourdomain.com". You don't need to add a search line, but most people do that for their nameserver, just to allow short names.
Also, I don't know where the "3 resolv.confs" are coming from. I have many servers running Etch stable, and they all have only /etc/resolv.conf, and my laptop and desktop (both Sid) have only /etc/resolv.conf. I'm guessing you added some package that did that for some reason, but that is just a suspicion, not something I can back up with hard fact.
The FQDN for the nameserver would be set in the zonefile for the domain. Useing my earlier example of beavis.yourdomain.com, the way to do that would be to define beavis.yourdomain.com IN A 1.2.3.4 in the yourdomain.com file, and it isn't anything more than that.
Troubleshooting the resolver would be as simple as doing digs pointed at the localhost from the nameserver. Something like:
Code:
dig google.com @127.0.0.1
If it answers, it is working. If it doesn't, check if named is running with
If that doesn't show anything, then named crashed for some reason, restart it.
Debian's /etc/default is more a question of what users/processes should be linked, like BIND starting as root, but running as named instead of root. The list of possible startups is in /etc/init.d, and it is different for each runlevel, which can be found in /etc/rcX.d/, where X = 1,2,3,4,5. The command update-rc.d can be used to alter where things startup in the boot process. If you installed BIND from the apt-get or aptitude tools, it will have all that installed, and running without human intervention. I hope and pray that all servers are GUI free, but we have too many people who think looking at pictures somehow helps them to manage servers. I would hope there isn't a graphical way to manipulate the startup scripts, but there probably is.
Peace,
JimBass