View Single Post
  #1   (View Single Post)  
Old 5th March 2010
J65nko J65nko is offline
Administrator
 
Join Date: May 2008
Location: Budel - the Netherlands
Posts: 3,779
Default BIND 9 : Caching and forward-only named.conf

A simple named.conf which forwards all DNS queries to another nameserver, and caches the answers for possible reuse.
Tested under OpenBSD 4.7 BETA with
Code:
$ named -v
BIND 9.4.2-P2
This type of configuration is useful to minimize the repeating nameserver queries issued when surfing the web.
Not only for your notebook or laptop using wireless connections, but also for a department that wishes to make use of a LAN/WAN link efficiently.
  • The Access Control List (acl) limits useage of this forward-only nameserver to my local 192.168.222.0/24 subnet.
  • The queries are forwarded to a dnscache namerver running on my OpenBSD firewall at 192.168.222.10.
  • The cache size is limited to two MB, which probably is too much for a notebook or laptop. The comments show how to calculate this amount in bytes using bc(1), the unlimited precision calculator.

Code:
// Caching and forward only configuration

// Access Control List

acl  clients    {
    192.168.222.0/24  ;
};

options {
    forward only ;
    forwarders { 192.168.222.10 ; } ; 
    allow-query { clients ; } ;
    // max-cache-size is in bytes : echo '2 * 1024^2' | bc
    max-cache-size 2097152 ; 
    empty-zones-enable yes;
} ;

# After editing this file please use 'named-checkconf' to validate!
To enable this under OpenBSD, assuming the above configuration has been saved as /var/naned/etc/caching-forward-only.conf, you have to add the following to /etc/rc.conf.local:

Code:
named_flags='-4 -c /etc/caching-forward-only.conf'
Note that applications use the /etc/resolv.conf to find out which name server they should use. So for a departmental nameserver, all clients should have the iP address of that name server in /etc/resolv.conf

For my small department in the garage, the clients have the following in /etc/resolv.conf

Code:
nameserver 192.168.222.25
A test query shows that dig indeed selects the 192.168.222.25 nameserver:

Code:
dig www.kpn.com

; <<>> DiG 9.4.2-P2 <<>> www.kpn.com
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 34979
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;www.kpn.com.                   IN      A

;; ANSWER SECTION:
www.kpn.com.            3600    IN      A       145.7.192.133

;; Query time: 96 msec
;; SERVER: 192.168.222.25#53(192.168.222.25)
;; WHEN: Fri Mar  5 04:11:47 2010
;; MSG SIZE  rcvd: 45
The nameserver received this answer after 96 msec, and will cache this data for 3600 seconds, A repeat query showing a 1 msec query time and a decreased TTL (Ttime to live) of 3219.

Code:
dig www.kpn.com 

; <<>> DiG 9.4.2-P2 <<>> www.kpn.com
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 24059
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;www.kpn.com.                   IN      A

;; ANSWER SECTION:
www.kpn.com.            3219    IN      A       145.7.192.133

;; Query time: 1 msec
;; SERVER: 192.168.222.25#53(192.168.222.25)
;; WHEN: Fri Mar  5 04:18:08 2010
;; MSG SIZE  rcvd: 45
__________________
You don't need to be a genius to debug a pf.conf firewall ruleset, you just need the guts to run tcpdump
Reply With Quote