[SOLVED] bind caching nameserver: views/firewalling (RHEL5/CentOS5)

deadeyes · 10-15-2009, 04:56 AM

Hi all,

1:

I have following config for my bind service:

Code:

options {
        listen-on port 53 { 127.0.0.1; 192.168.14.78; };
        listen-on-v6 port 53 { ::1; };
        directory       "/var/named";
        dump-file       "/var/named/data/cache_dump.db";
        statistics-file "/var/named/data/named_stats.txt";
        memstatistics-file "/var/named/data/named_mem_stats.txt";

        // Those options should be used carefully because they disable port
        // randomization
        query-source    port 53;
        // query-source-v6 port 53;

        allow-query     { localhost; 10.10.240.0/24; };
};
logging {
        channel default_debug {
                file "data/named.run";
                severity dynamic;
        };
};
//view localhost_resolver {
//      match-clients      { localhost; };
//      match-destinations { localhost; };
//      recursion yes;
//      include "/etc/named.rfc1912.zones";
//};
//view localnet_resolver {
//      match-clients      { 10.10.240.0/24; };
//      match-destinations { 10.10.240.0/24; };
//      recursion yes;
//      include "/etc/named.rfc1912.zones";
//;

The server has the ip 192.168.14.78.
The machines who use this server are in 10.10.240.0/24.
When the view part is commented, then I can resolve domain names correctly using this nameserver.
However when I put it in the config again (which I think should work as I expect, that 10.10.240.x can resolve using this server) I get this from dig at the remote host:

Code:

dig @192.168.14.78 google.be

; <<>> DiG 9.4.3-P3 <<>> @192.168.14.78 google.be
; (1 server found)
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: REFUSED, id: 21016
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0
;; WARNING: recursion requested but not available

;; QUESTION SECTION:
;google.be.                     IN      A

;; Query time: 37 msec
;; SERVER: 192.168.14.78#53(192.168.14.78)
;; WHEN: Thu Oct 15 11:53:58 2009
;; MSG SIZE  rcvd: 27

I wonder what I am doing wrong.

2: Same bind configuration. This is about the query-source directive.
If I put it in the config I can use port 53 in my firewall configuration.
However, if I disable it (enabling port randomization) will my firewall then see that this is related traffic and let it pass through?

If you need any more information... please let me know

bathory · 10-15-2009, 07:31 AM

1.

Quote:

;; WARNING: recursion requested but not available

Either remove, or comment out, or use {any;} for the "match-destinations ..." line, because I cannot see any other reason why you denied recursion

2. If you're behind a firewall allowing only port 53 traffic, you need that statement

deadeyes · 10-15-2009, 07:58 AM

Quote:

Originally Posted by bathory

1.
Either remove, or comment out, or use {any;} for the "match-destinations ..." line, because I cannot see any other reason why you denied recursion

2. If you're behind a firewall allowing only port 53 traffic, you need that statement

Thanks for your reply bathory.
Maybe I have a wrong understanding of what the match-destinations directive means.
I did searched on google but explanations are not very clear.
This destination, is it the destination where the response from a request should be sent? Is it the IP of the interface on the bind server itself? Is it an (DNS)IP range that the bind server should respond for.

From your explanation I would think the second one(an IP on an interface on the bind server).

bathory · 10-15-2009, 08:54 AM

I also don't understand the match-destinations statement: If that's for the server ip, you should use the 192.168.14.78.
Do what I've told you and see if it works.

deadeyes · 10-15-2009, 09:52 AM

Quote:

Originally Posted by bathory

I also don't understand the match-destinations statement: If that's for the server ip, you should use the 192.168.14.78.
Do what I've told you and see if it works.

I did what you said before I posted my previous post and it worked... I was just wondering