dns; split views; named.conf: "view" unknown option
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. |
most recent bind from fedora core 2
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. |
thanks
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.
|
couldn't add command channel
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? Quote:
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? Quote:
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; }; |
thanks / fedora core special dns configuration issues?
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. |
Quote:
|
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).
|
Quote:
|
Is there someplace we can post this issue
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: Code:
[root@excelsior dev]# rpm -ql bind-chroot Code:
Sep 29 12:31:57 excelsior named[26362]: client 69.2.200.182#1209: query 'version.bind/CH' denied Code:
options { |
named.conf / unkown option 'controls'
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"; |
All times are GMT -5. The time now is 11:43 AM. |