bind newb needing guidance

Wed Sep 13 01:25:03 UTC 2006

Nick Jones wrote:
> Hello everyone, I've been trying to configure bind with webmin at get
> it working persistently through a reboot.  Basically I had DNS working
> with bind 8, then I rebooted my XServe running Yellow dog.  DNS was no
> longer working, I noticed the process named was in fact running, so
> tried to remove the /etc/named.conf and recreate the whole thing using
> webmin.  This got it working, although now I don't know why, because
> deleting the named.conf and starting over no longer does the trick.
>
> A major part of the problem is that I can't figure out where this
> thing logs information.  All I've been able to find is useless log
> information in messages (syslogd).
>
> tail /var/log/messages
> Sep 12 13:34:22 localhost named[23691]: the key 'rndckey' is too short
> to be secure
> Sep 12 13:34:22 localhost named[23691]: the key 'rndckey' is too short
> to be secure
> Sep 12 13:40:51 localhost named[23691]: loading configuration from
> '/etc/named.conf'
> Sep 12 13:40:51 localhost named[23691]: the key 'rndckey' is too short
> to be secure
> Sep 12 13:40:51 localhost named[23691]: the key 'rndckey' is too short
> to be secure
> Sep 12 13:41:14 localhost named[23691]: loading configuration from
> '/etc/named.conf'
> Sep 12 13:41:14 localhost named[23691]: the key 'rndckey' is too short
> to be secure
> Sep 12 13:41:14 localhost named[23691]: the key 'rndckey' is too short
> to be secure
> Sep 12 14:06:45 localhost named[23691]: loading configuration from
> '/etc/named.conf'
> Sep 12 14:06:45 localhost named[23691]: the key 'rndckey' is too short
> to be secure
>
> ie.  useless
>
> These look like just annoying, pointless messages.  rndckey was
> created by webmin, so not sure why it's not secure.
>   
You should probably talk to the webmin folks about that.
>   I want log information that gives me some indication as to why i get
> "Host lcn.gige.uiowa.edu not found: 3(NXDOMAIN)" instead of an
> address.  
I don't know why you'd expect the *server* to tell you that in the logs. 
It's just answering with the data that it's been given. I think your 
main problem is that you used the "newbie" tool (host) for doing DNS 
lookups. If you want to do any kind of serious troubleshooting of DNS 
problems, you should use "dig", or something similar which shows you the 
entire response. In this particular case, it would be very helpful to 
know what SOA record is in the Authority Section of the response (host 
doesn't show the contents of the Authority Section, at least not by 
default). If the SOA is for the gige.uiowa.edu zone, then at least that 
tells you gige.uiowa.edu loaded properly. If the SOA is for the root 
zone, then I'd drill down further and find out what is wrong with 
gige.uiowa.edu at a zone level, as opposed to focusing on the 
lcn.gige.uiowa.edu name in particular. Using the right tool can get you 
much further along.
> I have a client pointing to this host's DNS that fails and
> the server that runs DNS pointing to 127.0.0.1 that fails at resolving
> as well.  Here are my config files.
>
> named.conf
>
> options {
>         directory "/etc";
>         pid-file "/var/run/named.pid";
>         };
>
> zone "." {
>         type hint;
>         file "/etc/db.cache";
>         };
> zone "gige.uiowa.edu" {
>         type master;
>         file "/etc/gige.uiowa.edu.hosts";
>         };
> zone "0.10.10.in-addr.arpa" {
>         type master;
>         file "/etc/10.10.0.rev";
>         };
> controls {
>         inet 127.0.0.1 port 953 allow { 127.0.0.1; } keys { rndc-key; };
>         };
> logging {
>         channel all_info {
>                 file "/var/log/named.log";
>                 severity debug 2;
>                 print-severity yes;
>                 };
>         category default {
>                 all_info;
>                 };
>         };
>
> key rndc-key {
>         algorithm hmac-md5;
>         secret "DMwaMWNnWjvuQ69JR6c5AQ==";
>         };
> zone "." {
>         type hint;
>         file "/etc/rootdns";
>         };
>   
Looks like you've defined your hints file twice. That might not be the 
source of your problem, but it certainly doesn't help matters.
> gige.uiowa.edu.hosts
>
> gige.uiowa.edu. IN      SOA     lcn.gige.uiowa.edu. nicholas-jones.uiowa.edu. (
>                         1158085878
>                         10800
>                         3600
>                         604800
>                         30M )
> gige.uiowa.edu. IN      NS      lcn.gige.uiowa.edu.
> gige.uiowa.edu. IN      A       10.10.0.19
> adams.gige.uiowa.edu.   IN      A       10.10.0.55
> lcn.gige.uiowa.edu.     IN      A       10.10.0.19
>
>
> 10.10.0.rev
>
> 0.10.10.in-addr.arpa.   IN      SOA     10.10.0.19. nicholas-jones.uiowa.edu. (
>                         1158085892
>                         10800
>                         3600
>                         604800
>                         30M )
> 0.10.10.in-addr.arpa.   IN      NS      10.10.0.19.
>   
NS records point at names, not addresses. You've pointed this NS record 
at the *name* "10.10.0.19", which most likely doesn't exist (it's 
theoretically possible, I guess, with an internal root zone, that you 
could have defined a "19" TLD, a "0.19" SLD and so forth, but it seems 
unlikely).
> 19.0.10.10.in-addr.arpa.        IN      PTR     gige.uiowa.edu.
> 55.0.10.10.in-addr.arpa.        IN      PTR     adams.gige.uiowa.edu.
>
>
>
> [root at localhost log]# ps -A | grep named
> 23691 ?        00:00:00 named
>
>
> [root at localhost log]# ls -l /var/run/named.pid
> lrwxrwxrwx  1 root root 41 Sep 12 13:34 /var/run/named.pid ->
> /var/named/chroot/var/run/named/named.pid
>
> [root at localhost log]# ls -l /var/named/chroot/var/run/named/named.pid
> -rw-r--r--  1 named named 6 Sep 12 14:06
> /var/named/chroot/var/run/named/named.pid
>
>
>
> Anybody see any problems??
>
> If webmin is the problem, please tell me (if you know) how to modify
> the above files so that it works.  Also, how did a problem like "turn
> this hostname into an IP" get solved by implementing configuration
> nightmare that is BIND instead of something much easier to configure.
>  I mean there should be a default where all you do is enter basic info
> along with the mappings, and if you want to get more complicated than
> that, well, it may be tough going to configure, but at least you have
> a base/default state that works for testing.  Anyway that's my bind
> rant, and probably a lot of people's bind rant.
>   
BIND fills a network infrastructure niche, there is too much variation 
in people's requirements and expectations to provide a "generic" set of 
configs and zone data. To even attempt that is to risk creating a whole 
generation of DNS "admins" who only know how to configure a single 
forward and a single reverse zone, on a certain bit-boundary for their 
network address range, with MX records reflecting only a particular 
email infrastructure, A records reflecting only a particular web 
infrastructure, etc. and who get completely flummoxed if asked to 
configure anything beyond that cookie-cutter model. You wouldn't ask 
someone who was unfamiliar with routing technology or theory to 
configure your Cisco, would you? When it comes to infrastructure, you 
want people to know what they're doing, not just blindly following some 
pre-packaged examples. Infrastructure is, by definition, what other 
things rely upon. So you want it as well-configured and stable as possible.

In part, I think we in the BIND/DNS area, have been spoilt by the 
presence of an excellent text on the subject, Cricket Liu's 
_DNS_and_BIND_ book, which pretty much starts from the beginning and 
leads the reader through to some fairly sophisticated setups. Folks who 
read that book rarely have the kind of frustrations you're experiencing, 
at least with respect to basic setup. There's also a "cookbook" 
companion book, which suits those more oriented towards a hands-on approach.

As for webmin, I've never used it. But I suspect it may have caused more 
harm than good in your case.

                                       - Kevin