Недавно столкнулся с проблемой, на которую раньше как-то не обращал внимания, заключающуся в том, что сидя через VPN и в качесте NS указан сервер организации, то резолвятся только внутренние домены оной, а на все запросы для внешних доменов получаем host not found.
Первая попытка разобраться что тут не так только запутала:
host www.yandex.ru 192.168.mynet.1
Using domain server:
Name: 192.168.mynet.1
Address: 192.168.mynet.1#53
Aliases:
Host www.yandex.ru not found: 3(NXDOMAIN)
Изучение named.sec.log хоть и натолкнуло на решение, но ясности в причинах не внесло:
22-Mar-2010 12:10:33.853 security: client 192.168.vpnnet.18#65056: view int: query (cache) 'www.yandex.ru/A/IN' denied
Немного подумав изменяем исходный запрос:
host www.yandex.ru. 192.168.mynet.1
Using domain server:
Name: 192.168.mynet.1
Address: 192.168.mynet.1#53
Aliases:
Host www.yandex.ru not found: 5(REFUSED)
Вот какой оказывается был исходный код ошибки, а NXDOMAIN мы получили уже после попытки подставить к имени домен указанный в resolv.conf. При этом в named.conf явно (в упрощённом виде) указано:
acl "trusted" {
127.0.0.1;
192.168.mynet.0/24;
192.168.vpnnet.0/24;
};
view "int" in {
match-clients { trusted; };
recursion yes;
zone "tune-it.ru" in {
type master;
file "dynamic/tune-it.ru";
};
};
И у клиентов находящихся в 192.168.mynet.0/24 всё работает без проблем. И на запросы из VPN к домену tune-it.ru тоже отвечаем. При этом ситуация воспроизвелась и на bind, скомпилированном руками на Solaris, и на bind, входящий в комлект FreeBSD.
Исходя из сложившейся ситуации делаем вывод о том, что в bind 9.6.1 (и возможно более младших версий, лень читать CHANGELOG) появилился дополнительный интеллект запрещающий слать кэшируемые запросы из подстей, на которых сам named не слушает входящие пакеты. С точки зрения большей безопасности по умолчанию может оно и хорошо, а в нашем случае в named.conf понадобилось дописать:
allow-query-cache { trusted; };
Так то.