Внутренний и внешний DNS с различных серверов, той же зоны
У Вас есть это задание в crontab пользователя (Можно ли видеть его с crontab -l?) или это в системе crontab (/etc/crontab)? Система crontab (На Linux, по крайней мере, не знайте о других системах), требует дополнительного пользовательского аргумента, что пользователь crontabs не делает.
В пользователе определенный crontab это должно быть похожим:
# crontab -l
...
5,20,35,50 * * * * /var/www/django-apps/callreport/util.py
Принимая во внимание, что та же команда в системе crontab должна быть похожей:
# cat /etc/crontab
...
5,20,35,50 * * * * www-data /var/www/django-apps/callreport/util.py
Пользователь мог бы отличаться в Вашей системе, конечно, но это - общее представление.
То, что Вы захотите сделать, создают зону DNS для testing.webdomain.com на Вашем внутреннем сервере DNS. Таким образом, DNS webdomain.com не размещается Вашим внутренним сервером, но вместо этого размещается dotster.
Когда кто-то запросит для www.webdomain.com, запрос будет передан к dotster для поиска (так как Ваш локальный сервер DNS не является авторитетным для той зоны), в то время как запросы на testing.webdomain.com будут обработаны Вашим внутренним сервером DNS.
Вам нужно представление Разделения DNS. Для Ваших машин границы используйте внешний сопоставитель. Для Вашей тестовой среды используйте отдельный, внутренний сопоставитель. Внутренний сопоставитель будет иметь Вашу запись тестирования в DNS и ответах от одного представления; но внешний мир будет видеть другое "представление" Вашей зоны, которая опускает тестовую среду.
Другие записи SF, которые могут представлять интерес:
У меня только есть время сегодня для просматривания расширенного сообщения, таким образом, вот первый взгляд:
options {
directory "/etc/bind";
listen-on { // why are these lines needed?
10.0.1.5; // the way it is set up, only your loopback
127.0.0.1; // and your LAN clients will be able to
// get answers; the outside world can't see boo
// because there's no interface/port pair
// to contact. I would just get rid of this and
}; // not worry about what interfaces are being bound to
// BTW, that listen-on line is why your outside queries are failing.
auth-nxdomain no;
allow-query { any; };
recursion no;
version "0";
};
Кроме того, внешний оператор клиентов соответствия
view "external" {
match-clients { !localnets; any; };
может быть сделан в
view "external" {
match-clients { any; };
потому что, когда Вы добавляете к клиентам соответствия, это уже предполагает, что нет ничего для соответствия для начала; отрицание ACL действительно не добавит много (потому что оно никогда не "существовало" в том представлении для начала, таким образом, нет никакой причины уравновесить его).
Я уверен, что, вероятно, пропустил некоторые вещи, но это самые очевидные преступники.
Кажется, что Ваше зональное определение не корректно. Это пропускает IP-адрес для сервера имен, объявленного как "webdomain.com".
Я предлагаю, чтобы Вы изменили зональное определение как
$TTL 604800
@ IN SOA webdomain.com. email.webdomain.com. (
4 ; Serial
604800 ; Refresh
86400 ; Retry
2419200 ; Expire
604800 ) ; Negative Cache TTL
;
@ IN NS webdomain.com.
webdomain.com. IN A 10.0.1.5
test IN A 10.0.1.20
затем перезапустите сервер (например. /etc/init.d/bind9 restart).
Так как зона не могла быть загружена, не из-за ошибки, домен не мог быть разрешен.
В Вашем Windows DNS сервер устанавливают новую ЗОНУ для testing.webdomain.com. Когда Вы добавляете, что первый хост оставляет незаполненное поле имени и вставил IP-адрес, Вы хотите, чтобы внутренние пользователи решили к.
Этот сервер будет авторитетным для той зоны, таким образом, любые запросы будут направлены к тому IP, таким образом, это не будет конфликтовать с Вашим внешним разрешением.
Я использую это на всех своих сайтах для mail.corpdns.com (потому что пользователи никогда не помнят использовать внутреннее имя сервера при попытке получить доступ к веб-почте, и т.д.).
Я подозреваю, что это может быть сделано в Linux/Связывать также, но я не знаю шаги.