You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!

Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.

If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.

Having a problem logging in? Please visit this page to clear all LQ-related cookies.

Introduction to Linux - A Hands on Guide

This guide was created as an overview of the Linux Operating System, geared toward new users as an exploration tour and getting started guide, with exercises at the end of each chapter.
For more advanced trainees it can be a desktop reference, and a collection of the base knowledge needed to proceed with system and network administration. This book contains many real life examples derived from the author's experience as a Linux system and network administrator, trainer and consultant. They hope these examples will help you to get a better understanding of the Linux system and that you feel encouraged to try out things on your own.

I am wanting to implement a stable DNS solution at work to get away from nasty hosts files. I have tested with Open SuSE DNS and while it's easy to get up and running, I have concerns about high availability and failover.

Does the built in SuSE DNS solution allow you to have two servers that communicate with eachother and where updates to one will update the other?

Take a look through your logs (not sure where BIND logs on SuSE but /var/log/daemon or /var/log/syslog may be in the right area. You are looking for 'denied' entries against the process 'named'. I suspect his will be acl/view/permission based and would concentrate my search around the allow-query { } options in named.conf

One thing to mention is that this is running on a hosted partition on an IBM server and within its own subnet with mask 255.255.255.248. The clients are in the same address range but with a 255.255.255.0 mask. They server is set to allow any requests...but could this be making a difference?

Also I couldn't find the logs so I told it to go to /home/myaccount/dns.log and log everything...but I can't see anything.

Also in YaST it says bind stats will write to /var/log/named.stats...but there is nothing in /var/log with that name

OK, there are some 'if's' and 'buts' there with the networking and hosting and your original question about running dual name servers may be clouding things here. I'm sure you know that a single IP can only host one BIND listening on port 53. but let's go back to basics.

If your run NSLOOKUP {or 'dig' if it's installed} from the command line of the SuSE where you are trying to run this instance of Bind, will it resolve? Let's not try and query it from another machine or OS, query it from itself just to troubleshoot this. Say the IP address of SuSE is 1.2.3.4, from it's own command line do:

nslookup bbc.co.uk 1.2.3.4

and see if it gives you anything back. If not check the logs to see what went wrong.

It's also worth a quick check to rule out any basic failures by running a test against the google public DNS servers at 8.8.8.8 and compare the results:
nslookup bbc.co.uk 8.8.8.8
Server: 8.8.8.8
Address: 8.8.8.8#53

Non-authoritative answer:
Name: bbc.co.uk
Address: 212.58.224.138

I'm not that familiar with SuSE and I'm not sure what you have running that is overwriting your named.conf. The gist of what you have should be good as long as you have something like this within your options {} section:

recursion yes;
allow-query {any; };

In reality 'any' may be bad in production, depending on your application, but I'd be inclined to get it working first.
HTH

Thanks for your reply Dave. I agree that the thread title isn't really relevant anymore. I am just trying to get this single nameserver working for now (and then all I do is set up the second one as a slave).

I agree any isn't going to be good practice - at the minute it's just a case of learning the ropes and then locking it down. Thanks for pointing that out though. I think that when using BIND via YaST, there is something you need to do in order to manually edit named.conf and have it save the changes. However, the idea is that you shouldn't really need to in the first place.

Certainly appreciate the help

PS - If a mod happens to read this, can you please change the thread title to "Problem with BIND - Query Refused"

But other clients are not able to query it. We know that BIND is getting those queries from your Syslog, it's just refusing them:
client 192.168.1.224#1067: query (cache) 'google.com/A/IN' denied

So something in the config of your BIND is refusing those lookups. It may be helpful to post the entire output of your named.conf here {munging any sensitive bits} as I suspect there is some kind of Access Control in place.

At a wild outside guess I wonder if it is something to do with the 'localnets' directive? If that server has a netmask of .248 I make that:
Network: 192.168.1.96
HostMin: 192.168.1.97
HostMax: 192.168.1.102
Broadcast: 192.168.1.103

And this client: client 192.168.1.224 would not fall within that. It should *not* matter with 'any', but I suspect there is something else at work going on. Perhaps you could try a query from a client in the range of 192.168.1.97-102 just to rule that out?

Getting a client up in that range is possible but not easy...it's a transparent subnet on an IBM Power System for use with virtual interfaces with proxy arp, so I will have to set up another partition on the Power system and then give it an IP in the range. I will try if I get no further though.

Here is named.conf (changed company name to "acme"):

The ACL statements were added via yast as a test. Not fully sure if the syntax is correct. Lots of stuff seems to be commented out...

suse:/var/lib/named/etc # cat named.conf
# Copyright (c) 2001-2004 SuSE Linux AG, Nuernberg, Germany.
# All rights reserved.
#
# Author: Frank Bodammer, Lars Mueller <lmuelle@suse.de>
#
# /etc/named.conf
#
# This is a sample configuration file for the name server BIND 9. It works as
# a caching only name server without modification.
#
# A sample configuration for setting up your own domain can be found in
# /usr/share/doc/packages/bind/sample-config.
#
# A description of all available options can be found in
# /usr/share/doc/packages/bind/misc/options.

options {

# The directory statement defines the name server's working directory

directory "/var/lib/named";

# Write dump and statistics file to the log subdirectory. The
# pathenames are relative to the chroot jail.

# The forwarders record contains a list of servers to which queries
# should be forwarded. Enable this line and modify the IP address to
# your provider's name server. Up to three servers may be listed.

#forwarders { 192.0.2.1; 192.0.2.2; };

# Enable the next entry to prefer usage of the name server declared in
# the forwarders section.

#forward first;

# The listen-on record contains a list of local network interfaces to
# listen on. Optionally the port can be specified. Default is to
# listen on all interfaces found on your system. The default port is
# 53.

#listen-on port 53 { 127.0.0.1; };

# The listen-on-v6 record enables or disables listening on IPv6
# interfaces. Allowed values are 'any' and 'none' or a list of
# addresses.

listen-on-v6 { any; };

# The next three statements may be needed if a firewall stands between
# the local server and the internet.

# The allow-query record contains a list of networks or IP addresses
# to accept and deny queries from. The default is to allow queries
# from all hosts.

#allow-query { 127.0.0.1; };

# If notify is set to yes (default), notify messages are sent to other
# name servers when the the zone data is changed. Instead of setting
# a global 'notify' statement in the 'options' section, a separate
# 'notify' can be added to each zone definition.

# The following zone definitions don't need any modification. The first one
# is the definition of the root name servers. The second one defines
# localhost while the third defines the reverse lookup for localhost.

zone "." in {
type hint;
file "root.hint";
};

zone "localhost" in {
type master;
file "localhost.zone";
};

zone "0.0.127.in-addr.arpa" in {
type master;
file "127.0.0.zone";
};

# Include the meta include file generated by createNamedConfInclude. This
# includes all files as configured in NAMED_CONF_INCLUDE_FILES from
# /etc/sysconfig/named

# You can insert further zone records for your own domains below or create
# single files in /etc/named.d/ and add the file names to
# NAMED_CONF_INCLUDE_FILES.
# See /usr/share/doc/packages/bind/README.SUSE for more details.

A couple of things. I'm not sure if what is in this file: "/etc/named.conf.include" is relevant, but it's been included into your named.conf.

The big one, unless I'm mistaken, is within your options {} directive, you have not given permission to anything for queries, recursion or transfer. I guess that the default is to allow localhost or localnets {just a guess} which is why local queries work.

I note you have created three acl's at the foot of your config {Personally I would have had them at the top} but at no point are they being referenced. For now, comment out or remove:

Just above the line reading "options {" insert "recursion yes;" and pop this in below it's matching closing brace: "allow-query {any; };" as per below. I've removed the IP6, forwarders, ACL's and include - see if this works for lookups.

Let's narrow this down too. If you make the changes to your named.conf and *don't* restart bind, if you less or cat it, have the changes really been made? What I'm getting at is do the changes really get saved at all, or is it they are definitely being wiped out when you restart it?