Re: problems with system-config-bind

Alexander Dalloz wrote:

Am Fr, den 25.06.2004 schrieb Timothy Stone um 18:46:

Is it me, or is it the tool, but system-config-bind really just doesn't seem to make the cut.

I'm moving a bind 9.2.1 config (from RHL8) to FC2 bind (installed via rpm) and the system-config-bind tool either:

1. doesn't launch

or

2. writes nonsensical zone files

I can't speak about the system-config-bind tool as my servers have no X.
Did you check bugzilla.redhat.com for bug reports regarding that
specific tool?

No, I have not. I will do so.

My caching only server config from RHL8 worked, I would say flawlessly, but the config doesn't like it. Now, I'm worried that a) my config was always broken and system-config-bind is trying to tell me something or b) the tool is hosed.

In case it matters, I host multiple domains.

Either you have a caching only nameserver or you have an authorized DNS
for your domains.

Hmmm... well, I might best describe my DNS setup as a way to resolve
names on the internal network. You see, our network admin is clueless
and does not, and has never, worked with DNS outside of what our ISP
dictates. So, as an example, www.harrisburgpa.gov, will resolve just
fine outside of our network. However, a couple of things are working
against us on the inside, network admin cluelessness aside. 1) we host
www.harrisburgpa.gov internally. 2) we do not have official internal DNS
running on the Windoze domain. This combination, I'm told result in a
name lookup "loop" (for lack of a better description). Requests go out
but come back saying, that server is on your network and die.

So I began running a instance of BIND on my RHL 8 staging server.

With the excellent advice of users on the RHL list, I got it running and
now, I and a few others that like to be able to view internally hosted
websites, use the DNS server on the staging box.

The BIND instance I run does not communicate with the outside (via
notify no; ) and it forwards all requests it doesn't to our ISP nameservers.

So that being said... here's the requested sample work:

It might be helpful if you post representative lines from your
named.conf and corresponding old zone files, to see where there might be
an error with the old now not accepted zones.

#### /etc/named.conf

// config for caching only name server

options {
	directory "/var/named";
	recursion yes;
	allow-query {
		127.0.0/8;
		10.4.100/24;
		10.4.104/24;
		10.4.103/24;
	};
	// uncomment to help with firewall
	query-source port 53;
	forward only;
	forwarders {
		4.2.2.1;
		4.2.2.2;
		4.2.2.3;
	};
};

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

zone "0.0.127.in-addr.arpa" {
	type master;
	file "named.local";
	notify no;
};

zone "americanmusicfest.com" {
	type master;
	file "americanmusicfest.com.db";
	notify no;
};

zone "harrisburgpa.gov" {
	type master;
	file "harrisburgpa.gov.db";
	notify no;
};
... continue with more zones

### zone example, nearly all zones have following format

$TTL 86400
@		IN 	SOA	americanmusicfest.com. webmaster.americanmusicfest.com. (
				2004041204	;serial, yearMonthHour
				28800		;refresh (8H)
				7200		;retry (2H)
				2419200		;expire (4W)
				86400		;minimum (1D)
				)
		IN	NS	ns.harrisburgpa.gov.
		IN	NS	dnsauth1.xx.xx.xxx.
		IN	NS	dnsauth2.xx.xx.xxx.
		IN	NS	dnsauth3.xx.xx.xxx.
www		IN	A	10.0.1.4	; www1
www		IN	A	10.0.1.5	; www2

Alexander

--

/**
 * Timothy Stone  . www.petmystone.com
 * Harrisburg PA  . javafueled at petmystone.com
 * USA            . coffee fueled macintosh zealot
 *
 * "This Satan's drink [coffee] is so
 *  delicious, we shall cheat Satan and
 *  baptize it."
 *  --Pope Clement VIII
 */