bind9 не пересылается на поддомен NS
Я запускаю bind9 в Ubuntu 10.04, управляю доменом (LAN) lan.group04.org - см. Следующий файл зоны
lan.group04.org. IN SOA dns.lan.group04.org. admin.lan.group04.org. (
2006081401
28800
3600
604800
38400
)
lan.group04.org. IN NS dns.lan.group04.org.
gateway IN A 10.10.1.1
wlan-access IN A 10.10.1.2
dns IN A 10.10.1.3
payment IN A 10.10.1.4
iodine IN A 10.10.1.5
tunnel IN NS iodine.lan.group04.org.
Как вы уже догадались по этим умно выбранным именам, я пробую йод (это курсовая работа, а не пытаться взломать Гибсона здесь:P).
Моя проблема сейчас в том, что мой DNS-сервер никогда не отправляет DNS-запросы на 10.10.1.5. Чтобы йод работал, мне нужно, чтобы DNS перенаправил любой запрос на что-либо из tunnel.lan.group04.org на этот IP; например, запрос на hello.tunnel.lan.group04.org должен быть перенаправлен на йод-машину.
Я пробовал несколько вариантов вышеупомянутых, которые я мог бы придумать, которые кажутся семантически идентичными и синтаксически допустимыми, но не смог передать запросы субдоменов на машину йода. Я знаю, что они не перенаправлены туда из-за перегрузки провода на обеих машинах.
О сети: все это в 10.10.1.0/17, нет маршрутизаторов / межсетевых экранов / коммутаторов между 10.10.1.4 (локальный DNS) и 10.10.1.5 (йод), порты открыты, ping, http,.... работает. iodine.lan.group04.org разрешается правильно.
Нужно ли устанавливать йодный сервер в качестве главного для этого субдомена в named.conf.local? Я уже пробовал это однажды, но, возможно, испортил это, поэтому я собираюсь попробовать это снова сразу после публикации этого вопроса.
Кто-нибудь есть идеи, что я здесь делаю не так?
РЕДАКТИРОВАНИЕ решено; увидеть мой собственный ответ. Принятым ответом была благодарность AndreasM за помощь в решении этой проблемы.
2 ответа
Отвечая в ответе за апвот;) . Я не знаю из рук, как это делает bind9, обычно он должен сначала проверить свои представления (в настроенном порядке), чтобы решить, должен ли он действовать как распознаватель или как автор. Я согласен с вами, что в вашем случае он должен был действовать в режиме решателя (при условии, что другие запросы (например, www.google.com) работали), а затем отвечал из режима аутентификации, но, по-видимому, это не так. Вот почему я всегда использую специальный распознаватель при тестировании этого материала.
Ваше решение является только частичным, вы никогда не проверяете, работает ли оно также извне. Это "сокращение" для ваших тестов, говорящее "также спросите этого, если вы не получите ответ".
Хорошо, проблема решена; Я не настроил 10.10.1.5 в качестве сервера пересылки для моего локального DNS-сервера; в named.conf.options моего локального DNS это должно быть:
forwarders {
...
10.10.1.5;
...
}
Это (и, конечно, последующий перезапуск привязки) решило мою проблему.