HowtoForge Forums | HowtoForge - Linux Howtos and Tutorials

HowtoForge Forums | HowtoForge - Linux Howtos and Tutorials (http://www.howtoforge.com/forums/index.php)
-   Tips/Tricks/Mods (http://www.howtoforge.com/forums/forumdisplay.php?f=19)
-   -   BIND version 9.5.0, under chroot /var/named/chroot (http://www.howtoforge.com/forums/showthread.php?t=25215)

terranet 17th July 2008 18:29

BIND version 9.5.0, under chroot /var/named/chroot
 
For all,ho was upgrade bind on 9.5 ,litle help if your mail is not work or you get this message:

(Name service error for name=mydomain.com.au type=A: Host found but no data record of requested type)

Than..read this...

There has been some confusion surrounding the changes to the "allow-recursion" and "allow-query-cache" options made with BIND 9.4.1-P1.

This document will attempt to clarify the change and the impact that it makes on BIND servers.

In BIND 9.3, there was no segregation of queries between cache and authoritative data.

The release of BIND 9.4 added fine-grained differentiation between queries against authoritative data ("allow-query") and cached data ("allow-query-cache"). This allows more precise control, particularly if you do not want your clients to use any cached data, for example, in an authoritative-only nameserver. (The "allow-query-cache" option was introduced in BIND 9.4.)

Prior to the release of BIND 9.4.1-P1, the default action of "allow-recursion" and "allow-query-cache" was to permit the query. The P1 patch to BIND 9.4.1 caused two changes in this behavior:

1) If not explicitly set, the ACLs for "allow-query-cache" and "allow-recursion" were set to "localnets; localhost;".

2) If either "allow-query-cache" or "allow-recursion" was set, the other would be set the same value.

Upgrading from the BIND 9.3 branch to BIND 9.4.1-P1 will significantly restrict those servers that were previously recursive servers for more than "localhost; localnets;" unless configuration changes are made.

To retain the behavior prior to BIND 9.4.1-P1, the following entries should be created in your named.conf file:
options {
...
allow-recursion { any; };
allow-query { any; };
allow-query-cache { any; };
...
};
We strongly advise against this configuration because clients spoofing queries can use your servers to launch distributed denial-of-service attacks.

The recommended method is to create ACLs that match hosts that should be allowed access to cache and recursion on the servers. For example, if you wanted to provided recursion and access to the cache to clients you trusted, you could list them in an ACL such as the following:
acl "trusted" {
192.168.0.0/16;
10.153.154.0/24;
localhost;
localnets;
};

options {
...
allow-query { any; };
allow-recursion { trusted; };
allow-query-cache { trusted; };
...
};
This example ACL includes 192.168.0.0/16 and 10.153.154.0/24 as sample networks that would require access. You must replace these sample networks with networks that correctly reflect your environment. This will allow anyone to query your server for authoritative data, but only those hosts within the "trusted" ACL access to your cache and recursion.

I do like this:

options {
pid-file "/var/named/chroot/var/run/named/named.pid";
directory "/var/named/chroot/var/named";
auth-nxdomain no;
/*
* If there is a firewall between you and nameservers you want
* to talk to, you might need to uncomment the query-source
* directive below. Previous versions of BIND always asked
* questions using port 53, but BIND 8.1 uses an unprivileged
* port by default.
*/
// query-source address * port 53;
allow-recursion { our-nets; };
allow-query { any; };
allow-query-cache { our-nets; };
};

and...

//// MAKE MANUAL ENTRIES BELOW THIS LINE! ////
acl bogusnet {
0.0.0.0/8;
1.0.0.0/8;
224.0.0.0/3;
192.0.2.0/24;
};

acl our-nets {
10.1.28.0/22;
10.1.40.0/22;
**.***.***.0/20;
172.16.0.0/19;
192.168.200.0/24;
**.***.***.0/23;
**.***.***.0/24;
localhost;
localnets;
};

And mail is gone back again.

best regards


All times are GMT +2. The time now is 11:50.

Powered by vBulletin® Version 3.8.7
Copyright ©2000 - 2014, vBulletin Solutions, Inc.