Здраствуйте! Существует шлюз freebsd 7.0, дающий интернет людям по pptp с помощью mpd4, на нем так же стоит кеширующий днс bind9.4 в chroot'е, который ведет себя достаточно странно: по утрам, а точнее будет сказать, после определенного количества времени проведенного сервером в "простое", то есть когда ни один пользователь к нему не подключен, он перестает отвечать на днс запросы вновь подключившихся клиентов, однако, продолжает исправно обслуживать себя самого (на lo0), какой эгоист... Не работает только днс, так как все, что не задействует днс, работает... В чем может быть проблема? вот конфиг bind...------------------------------------------
// ACL
acl "users" { 192.168.2.0/24; };
// OPTIONS
options {
directory "/etc/namedb";
pid-file "/var/run/named/pid";
dump-file "/var/dump/named_dump.db";
statistics-file "/var/stats/named.stats";
listen-on { 127.0.0.1; 192.168.2.1; };
// These zones are already covered by the empty zones listed below.
// If you remove the related empty zones below, comment these lines out.
disable-empty-zone "255.255.255.255.IN-ADDR.ARPA";
disable-empty-zone "0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.IP6.ARPA";
disable-empty-zone "1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.IP6.ARPA";
forwarders { 80.70.224.2; 80.70.224.4; };
allow-query { 127.0.0.1; users; };
allow-transfer { none; };
// recursion 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 versions 8 and later
* use a pseudo-random unprivileged UDP port by default.
*/
query-source address * port 53;
};
// CONTROLS
controls {
inet 127.0.0.1 port 953 allow { 127.0.0.1; } keys { dnsadmin; };
};
// KEY
key "dnsadmin" {
algorithm hmac-md5;
secret "xxxxxxxxxxxxxxxxx";
};
// LOGGING
logging {
channel systemlog {
file "/var/log/named.log";
severity debug;
print-time yes;
};
channel audit_log {
file "/var/log/security.log";
severity debug;
print-time yes;
};
channel xfer_log {
file "/var/log/xfer.log";
severity debug;
print-time yes;
};
category default { systemlog; };
category security { audit_log; systemlog; };
category config { systemlog; };
category xfer-in { xfer_log; };
category xfer-out { xfer_log; };
category notify { audit_log; };
category update { audit_log; };
category queries { audit_log; };
category lame-servers { audit_log; };
};
// The traditional root hints mechanism. Use this, OR the slave zones below.
zone "." { type hint; file "named.root"; };
/* Serving the following zones locally will prevent any queries
for these zones leaving your network and going to the root
name servers. This has two significant advantages:
1. Faster local resolution for your users
2. No spurious traffic will be sent from your network to the roots
*/
// RFC 1912
zone "localhost" { type master; file "master/localhost-forward.db"; };
zone "127.in-addr.arpa" { type master; file "master/localhost-reverse.db"; };
zone "255.in-addr.arpa" { type master; file "master/empty.db"; };
// RFC 1912-style zone for IPv6 localhost address
zone "0.ip6.arpa" { type master; file "master/localhost-reverse.db"; };
// "This" Network (RFCs 1912 and 3330)
zone "0.in-addr.arpa" { type master; file "master/empty.db"; };
дальше блабла про зоны серых адресов
---------------------------------------------
ifconfig, таков:
---------------------------------------------
rl0: flags=88843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST,STATICARP> metric 0 mtu 1500
options=8<VLAN_MTU>
ether 00:05:5d:35:16:81
inet 192.168.1.90 netmask 0xffffff00 broadcast 192.168.1.255
media: Ethernet autoselect (100baseTX <full-duplex>)
status: active
vr0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
options=8<VLAN_MTU>
ether 00:19:5b:7c:9c:60
inet 10.x.x.x netmask 0xffff0000 broadcast 10.x.255.255
media: Ethernet autoselect (100baseTX <full-duplex>)
status: active
plip0: flags=108810<POINTOPOINT,SIMPLEX,MULTICAST,NEEDSGIANT> metric 0 mtu 1500
lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> metric 0 mtu 16384
inet6 fe80::1%lo0 prefixlen 64 scopeid 0x4
inet6 ::1 prefixlen 128
inet 127.0.0.1 netmask 0xff000000
ng0: flags=88d1<UP,POINTOPOINT,RUNNING,NOARP,SIMPLEX,MULTICAST> metric 0 mtu 1460
inet y.y.y.y --> 80.70.225.45 netmask 0xffffffff
ng1: flags=88d1<UP,POINTOPOINT,RUNNING,NOARP,SIMPLEX,MULTICAST> metric 0 mtu 1396
inet 192.168.2.1 --> 192.168.2.11 netmask 0xffffffff
ng2: flags=88d1<UP,POINTOPOINT,RUNNING,NOARP,SIMPLEX,MULTICAST> metric 0 mtu 1396
inet 192.168.2.1 --> 192.168.2.12 netmask 0xffffffff
ng3: flags=8890<POINTOPOINT,NOARP,SIMPLEX,MULTICAST> metric 0 mtu 1500
и тд...
----------------------------------------------
в логах заметил появление таких надписей:
----------------------------------------------
04-May-2008 08:16:17.978 listening on IPv4 interface ng4, 192.168.2.1#53
04-May-2008 08:16:17.978 creating IPv4 interface ng4 failed; interface ignored
04-May-2008 09:16:17.958 listening on IPv4 interface ng4, 192.168.2.1#53
04-May-2008 09:16:17.958 creating IPv4 interface ng4 failed; interface ignored
и тд...
----------------------------------------------
убрав listen-on и изменив allow-query на { any; } попробывал найти подобное для lo0 rl0 vr0, но оказалось bind проявляет агрессию только к ngX, причем постоянно поднятый ng0 дающий интернет уже самому серверу, любит он ни чуть не больше:
----------------------------------------------
04-May-2008 15:43:01.426 listening on IPv4 interface ng0, y.y.y.y#53
04-May-2008 15:43:01.426 creating IPv4 interface ng0 failed; interface ignored
04-May-2008 16:43:01.427 listening on IPv4 interface ng0, y.y.y.y#53
04-May-2008 16:43:01.428 creating IPv4 interface ng0 failed; interface ignored
----------------------------------------------
вот такая проблема...