I have set up a network firewall / router (with an external interface alias of eth0 and eth0:0 for two ip addresses corresponding to two dns servers on my home office adsl like in the diagram below). To do this I am using DNAT for all external inquires for my DMZ servers and SNAT for outgoing traffic with the local network's outgoing traffic sharing the IP of my secondary server.

Currently all external clients can access all DMZ services (http, dns, mail) but none of the internal clients on the local network can browse the internet or access the servers using their domain names. All the local clients can ping the firewall /router and the DMZ servers using both the servers' public and private addresses.

It seems that this a DNS problem and that it can best be solved by "split" views on my DNS. I am having a problem with my /etc/named.conf file (modified copy of named.conf from shorewall.net below). When I try to use this I get the error message from /var/log/messages that "view" is an unknown option. Can someone tell me what I am doing wrong? Thanks.

ADSL   ---------  Linux  ---------  DMZ segment
Modem             Server                 PUBLIC IPs (66.77.88.xx and 66.77.88.yy)
                                 |
                                +-------------  Internal net
                                                     private IPs

*************************************************************

/etc/named.conf

options {
directory "/var/named";
listen-on { 127.0.0.1 ; 192.0.2.177; };
};

logging {
channel xfer-log {
file "/var/log/named/bind-xfer.log";
print-category yes;
print-severity yes;
print-time yes;
severity info;
};

category xfer-in { xfer-log; };
category xfer-out { xfer-log; };
category notify { xfer-log; };
};

#
# This is the view presented to our internal systems
#

view "internal" {
#
# These are the clients that see this view
#
match-clients { 192.168.201.0/29;
192.168.202.0/29;
127.0.0.0/8;
192.0.2.176/32;
192.0.2.178/32;
192.0.2.179/32;
192.0.2.180/32; };
#
# If this server can't complete the request, it should use
# outside servers to do so
#
recursion yes;

zone "." in {
type hint;
file "int/root.cache";
};

zone "foobar.net" in {
type master;
notify no;
allow-update { none; };
file "int/db.foobar";
};

zone "0.0.127.in-addr.arpa" in {
type master;
notify no;
allow-update { none; };
file "int/db.127.0.0";
};

zone "201.168.192.in-addr.arpa" in {
type master;
notify no;
allow-update { none; };
file "int/db.192.168.201";
};

zone "202.168.192.in-addr.arpa" in {
type master;
notify no;
allow-update { none; };
file "int/db.192.168.202";
};

zone "176.2.0.192.in-addr.arpa" in {
type master;
notify no;
allow-update { none; };
file "db.192.0.2.176";
};

zone "177.2.0.192.in-addr.arpa" in {
type master;
notify no;
allow-update { none; };
file "db.192.0.2.177";
};

zone "178.2.0.192.in-addr.arpa" in {
type master;
notify no;
allow-update { none; };
file "db.192.0.2.178";
};

zone "179.2.0.192.in-addr.arpa" in {
type master;
notify no;
allow-update { none; };
file "db.206.124.146.179";
};

};
#
# This is the view that we present to the outside world
#
view "external" {
match-clients { any; };
#
# If we can't answer the query, we tell the client so
#
recursion no;

zone "foobar.net" in {
type master;
notify yes;
allow-update {none; };
allow-transfer { <secondary NS IP>; };
file "ext/db.foobar";
};

zone "176.2.0.192.in-addr.arpa" in {
type master;
notify yes;
allow-update { none; };
allow-transfer { <secondary NS IP>; };
file "db.192.0.2.176";
};

zone "177.2.0.192.in-addr.arpa" in {
type master;
notify yes;
allow-update { none; };
allow-transfer { <secondary NS IP>; };
file "db.192.0.2.177";
};

zone "178.2.0.192.in-addr.arpa" in {
type master;
notify yes;
allow-update { none; };
allow-transfer { <secondary NS IP>; };
file "db.192.0.2.178";
};

zone "179.2.0.192.in-addr.arpa" in {
type master;
notify yes;
allow-update { none; };
allow-transfer { <secondary NS IP>; };
file "db.192.0.2.179";
};
};

After a quick cursory look at your named.conf, I don't see anything wrong. In fact, I use "views" at this end.

What version of bind are you using? If I remember correctly, bind "views" were not added until the bind 9.x series of releases.

thanks for your quick response. i am using the most up to date bind from fedora core 2 (9.2?).

Odd! I copy/pasted your named.conf file into my test FC1 system and the only error I get was...

Sep 20 16:41:00 voyager named[19531]: could not configure root hints from 'root.cache': file not found
Sep 20 16:41:00 voyager named[19531]: loading configuration: file not found

Which is correct. root.cache does not exist on my system in the directory strcuture you specifed. So to me, named is reading the "view" statement without an error.

At this point, I would start checking for errors before the the "view" statement. Like missing semi-colons, left/right brackets not closed, non printable characters at the end of a line, DOS formatted file. Something like that.

i think you must be right. i have started again with a clean file and have eliminated this problem. i still need to edit the file to make it fit my system. i suspect that am unknowingly inserting some strange characters in vi when i forget to hit the insert command and just start typing. i'll post back with results.

i have been getting another error message in /var/log/messages.
Sep 27 04:10:28 ns2 named[29498]: couldn't add command channel 127.0.0.1#953: not found
Sep 27 04:10:28 ns2 named[29498]: couldn't add command channel ::1#953: not found

I configured rndc correctly by removing /etc/rndc.conf and commenting
out the rndc key lines in /etc/named.conf. Next, I ran rndc-confgen -a, which created all the appropriate entries and then cut and paste the key generated into my named.conf (SEE BELOW).

From there, i have triedt (without success) to follow the fix suggested by another thread but i can't seem to follow a key step. Can someone explain what this passage is referring to?
EXCERPT FROM NAMED.CONF
key "rndckey" {
algorithm hmac-md5;
secret "VWP7hSbGKHTQGm+67KCIjA==";
controls {
inet 127.0.0.1 port 953
allow { 127.0.0.1; } keys { "rndc-key"; };
};
options {
directory "/var/named";
listen-on { 127.0.0.1 ; 192.168.202./24 ; 192.168.0.0/24 ; 69.17.65.161 ;};
// we varied here by using only the local IP
// because we are using DNAT / SNAT instead of
// proxy arp since we only have two public IP's
};

key "rndckey" {
algorithm hmac-md5;
secret "VWP7hSbGKHTQGm+67KCIjA==";
controls {
inet 127.0.0.1 port 953
allow { 127.0.0.1; } keys { "rndc-key"; };
};

1) Your key definition is named "rndckey", but you are referencing this key in the control statement with the key name of "rndc-key". The key names need to match. Pick one and be sure that this name is also referenced in /etc/rndc.conf

2) Your key definition does not have the closing bracket.

3) Although it will still work, there is no need to cut/paste the key into named.conf. Simply include the key file in named.conf. i.e.

include "/etc/rndc.key";

listen-on { 127.0.0.1 ; 192.168.202./24 ; 192.168.0.0/24 ; 69.17.65.161 ;};

Hopefully the above is a type-o, checkout the 192.168.202 part.

From there, i have triedt (without success) to follow the fix suggested by another thread but i can't seem to follow a key step. Can someone explain what this passage is referring to?

Named will create files at startup, through channel specific logging, or through rndc. In particular, the process ID file which should be referenced in named.conf as option pid-file. So if named is started with the "-u named" parameter (which is good), then named is started as that user, thus will not have the proper permission to create any files in the /var/run directory because the default permissions of that directory do not allow any user but root to create a file in this directory. To fix this problem, you will need to:

1) Create a /var/run/named directory which is owned by the user specifed by the -u parameter. This is usually the user named.
# cd /var/run
# mkdir named
# chown named.named named
# chmod 770

2) Add/Change the pid-file global option in named.conf to point to /var/run/named/named.pid
pid-file "/var/run/named/named.pid";

3) Repeat steps 1 & 2 for the following global named.conf options. If the directory doesn't exist (like /var/log/named), create it and change the ownership/permissions to allow the user "named" to write to the new directories.
options {
directory "/var/named";
pid-file "/var/run/named/named.pid";
statistics-file "/var/log/named/named.stats";
dump-file "/var/log/named/named.dump";
zone-statistics yes;
};

Thank you for your help. I am still working through your solution. I wonder if this solution will affect some of the chroot features of DNS under fedora. In persuing your solution, I have read several postings suggesting that Fedora chroots the named user. This limits the files that the named user can see outside of the directory /var/named/chroot. Fedora puts the named.conf and named.ca files in the standard /etc directory (where the chrooted named user can't read them). A possible solution might be something like this from the root terminal: (1) cp -f /etc/named.conf /var/named/chroot/etc/ ; and (2) cp -f /etc/rndc.* /var/named/chroot/etc/

Note: files formerly found in /var/named now belong in /var/named/chroot/var/named.

Thats correct! Fedora sets named to start as user named and start in a chroot'd jail. So the above is the correct procedure to follow. You would still need to set the proper permissions on the chrooted directories as noted in my previous reply though.

Right, the above is what OpenBSD does by default. It's mystifying why the Fedora develoers chroot'd named but forgot to make the config files available to it after it's there (and I've seen this problem several times now, so it's not like it's not a known problem).

Maybe I'm misunderstanding your reply, but if the "bind-chroot" rpm is installed (which is a dependency against the bind rpm), all the chrooted files are available. Only problem is the permissions are still wrong (based on the options in the supplied named.conf). Plus, it would be nice if the rpm post-install script would copy /etc/localtime to the chroot'd environment so that the dates are not logged in UTC.

chort and scowles thanks both for your help.

I'm not a linux guru but this seems like a really core issue for Fedora.

When I upgraded to Fedora, two really bad things happened.

1. My DNS stopped working.

2. DNS failing hammered my mail server immediately.

I'd be happy to do what is necessary to help because I saw a lot of postings on this and a lot of varying solutions. I am sure they probably represent valid approaches to solving the problem but I suspect that they all affect the security of DNS in differing ways that the DNS developers might not have anticipated. Since DNS is essential to the internet's correct functioning, this probably deserves some attention in a larger forum (i'd do it myself but doubt that i have the knowledge necessary to conduct that conversation).

scowles, are you sure that creating properly owned files outside /var/named will actually work? On OpenBSD /var/named has it's own dev/log device in order to write to syslog when in chroot.

The redhat bind-chroot rpm creates a similar directory structure as well, but I don't see anything regarding /dev/log (which does seem strange) and I don't have any problem logging (via syslog) at this end. I do define other channel specific logging mechanisms in named.conf, but these are done without the syslog facility.

For reference, here is what bind-chroot loads:
and here is an actual syslog entry via syslog. My version of bind is started with the "-u named" command line argument and in a chroot'd jail. Which I think is the default in FC2.
Also, for reference, the following are the relavent parts of my named.conf file. It's the pid-file option that I was referring to in my previous post.

i still can't make this file load
/etc/named.conf:12: unknown option 'controls'
/etc/named.conf:17: unknown option 'view'
/etc/named.conf:145: unknown option 'view'
/etc/named.conf:249: '}' expected near end of file
[root@testy root]#
:


/ generated by named-bootconf.pl
options {
directory "/var/named";
};
acl "mylan" {
127.0.0.1; 192.168.0.1/24; 192.168.202/24; 69.17.65.105/32; 69.17.65.161/32; 69.17.65.22/32;
};

key "rndckey" {
algorithm hmac-md5;
secret "VWP7hSbGKHTQGm+67KCIjA==";
controls {
inet 127.0.0.1 port 953
allow { 127.0.0.1; } keys { "rndc-key"; };
};

view "internal" {
match-clients { "mylan" ; };
recursion yes;

zone "." in {
type hint;
file "named.ca";
};

zone "localhost" IN {
type master;
file "localhost.zone";
allow-update { none; };
};

zone "0.0.127.in-addr.arpa" IN {
type master;
file "named.local";
allow-update { none; };
};

// local subnet for the pc's
zone "0.168.192.in-addr.arpa" in {
type master;
notify no;
allow-update { none; };
file "db.192.168.0";
};

// dmz subnet for the servers
zone "202.168.192.in-addr.arpa" in {
type master;
notify no;
allow-update { none; };
file "db.192.168.202";
};

// firewall
zone "105.65.17.69.in-addr.arpa" in {
type master;
notify no;
allow-update { none; };
file "db.69.17.65.105";
};

// number 1 server http, dns, imap
zone "22.65.17.69.in-addr.arpa" in {
type master;
notify no;
allow-update { none; };

file "db.69.17.65.22";
};

// number 2 server http, dns, imap
zone "161.65.17.69.in-addr.arpa" in {
type master;
notify no;
allow-update { none; };
file "db.69.17.65.161";
};

// our first primary zone
zone "substantis.com" {
type master;
file "db.substantis";
allow-update {none;};
notify no;
};
// our second primary zone
zone "lubuto.org" {
type master;
file "db.lubuto";
allow-update {none;};
notify no;
};
// our third primary zone
zone "danielleworden.com" {
type master;
file "db.danielleworden";
allow-update {none;};
notify no;

};
//our fourth primary zone
zone "familynetpix.com" {
type master;
file "db.familynetpix";
allow-update {none;};
notify no;
};
//our fifth primary zone
zone "mrcstudio.com" {
type master;
file "db.mrcstudio";
allow-update {none;};
notify no;
};

// our sixth primary zone
zone "doldaycare.com" {
type master;
file "db.doldaycare";
allow-update {none;};
notify yes;
};

//our seventh primary zone
zone "dexter1976.com" {
type master;
file "db.dexter1976";
allow-update {none;};
notify no;
};

//our eighth primary zone
zone "nelsonbeaudoin.com" {
type master;
file "db.nelsonbeaudoin";
allow-update {none;};
notify no;
};

};

//
//This is the view that we present to the outside world
//
view "external" {
match-clients { any; };
// version "[I don't respond to version queries]";
query-source address * port 53;
allow-query { any; };
allow-transfer { 216.231.41.19; 216.254.0.9; 69.17.65.161; };

//
// If we can't answer the query, we tell the client so
//

recursion yes;

// our first primary zone
zone "substantis.com" {
type master;
file "named.substantis.com";
allow-update {none;};
notify yes;
};

// our second primary zone
zone "lubuto.org" {
type master;
file "named.lubuto.org";
allow-update {none;};
notify yes;
};

// our third primary zone
zone "danielleworden.com" {
type master;
file "named.danielleworden.com";
allow-update {none;};
notify yes;

};

//our fourth primary zone
zone "familynetpix.com" {
type master;
file "named.familynetpix.com";
allow-update {none;};
notify yes;
};

//our fifth primary zone
zone "mrcstudio.com" {
type master;
file "named.mrcstudio.com";
allow-update {none;};
notify yes;

};

//our sixth primary
zone "doldaycare.com" {
type master;
file "named.doldaycare.com";
allow-update {none;};
notify yes;
};

//our seventh
zone "dexter1976.com" {
type master;
file "named.dexter1976.com";
allow-update {none;};
notify yes;
};

//our eighth
zone "nelsonbeaudoin.com" {
type master;
file "named.nelsonbeaudoin.com";
allow-update {none;};
notify yes;
};


zone "161.65.17.69.in-addr.arpa" in {
type master;
notify yes;
allow-update { none; };
allow-transfer { 69.17.65.161 ; };
file "db.69.17.65.161";
};

zone "22.65.17.69.in-addr.arpa" in {
type master;
notify yes;
allow-update { none; };
allow-transfer { 69.17.65.161 ; };
file "db.69.17.65.22";
};
zone "105.65.17.69.in-addr.arpa" in {
type master;
notify yes;
allow-update { none; };
allow-transfer { 69.17.65.161 ; };
file "db.69.17.65.105";
};
};
//
//
//controls {
// inet 127.0.0.1 allow { localhost; } keys { rndckey; };

//
//zone "localhost" IN {
// type master;
// file "localhost.zone";
// allow-update { none; };
//};
//
//zone "0.0.127.in-addr.arpa" IN {
// type master;
// file "named.local";
// allow-update { none; };
//};
//
// include "/etc/rndc.key";