proNovell

Доброе время суток!
Внутри локальной сети 192.168.1.0 поднят DNS и DHCP (192.168.1.2) На шлюзе (192.168.1.1) маршрутизация выключена, но работает DNS proxy (BM3.5). Адреса DNS провайдерa указаны в списке Forvarding локальной DNS - но помогает это весьма плохо: ни одно имя в Инете локальный DNS не разрешает. Что я не так делаю?

Вероятно на локальном ДНС поднята корневая зона (которая точка - "."). Этого быть не должно.

А можно чуть-чуть подробнее ?

Мещеряков Андрей писал(а):Доброе время суток!
Внутри локальной сети 192.168.1.0 поднят DNS и DHCP (192.168.1.2) На шлюзе (192.168.1.1) маршрутизация выключена, но работает DNS proxy (BM3.5). Адреса DNS провайдерa указаны в списке Forvarding локальной DNS - но помогает это весьма плохо: ни одно имя в Инете локальный DNS не разрешает. Что я не так делаю?

Возможно 2 варианта
1. На сервере где DNS proxy (BM3.5) в resolv.cfg оставь только адрес DNS провайдерa, а на 192.168.1.2 в качестве DNS укажи 192.168.1.1.
2. На 192.168.1.1 открой 53 порт для 192.168.1.2(через транспарент телнет напр) на 192.168.1.2 в качестве DNS укажи дрес DNS провайдерa.
В обоих случаях клиентам указать что DNS - 192.168.1.2

Владимир Горяев писал(а): Возможно 2 варианта
1. На сервере где DNS proxy (BM3.5) в resolv.cfg оставь только адрес DNS провайдерa, а на 192.168.1.2 в качестве DNS укажи 192.168.1.1.
2. На 192.168.1.1 открой 53 порт для 192.168.1.2(через транспарент телнет напр) на 192.168.1.2 в качестве DNS укажи дрес DNS провайдерa.
В обоих случаях клиентам указать что DNS - 192.168.1.2

1. На 192.168.1.1 в качестве DNS всегда был адрес провайдера.
2. Тогда как 192.168.1.2 будет ресолвить адреса локального домена?

Дополнительная подробность:
имя домена - gou_lmc.
Это может как-то повлиять?
Лог с экрана:
QH_ns_req: Query for (pop.inbox.ru.gou_lmc) of type a
Это получается: к имени разрешаемого адреса дописывается (?) суффикс локального домена ? И потом такая абракадабра разрешается...

У нас так:

1. На проксе поднят ДНС-прокси. Прописаны правила, разрешающие проксёвым адресам лазить в Инет по порту 53.
2. На внутреннем ДНС-е в качестве форвардера указан внутренний интерфейс прокси.
3. На проксе в списке ДНС-серверов первым идёт внешний ДНС (он на отдельной машине), затем внутренний.

Всё работает.

ЗЫ - можно сделать "сплит-ДНС" и без внешнего ДНС-а. На сайте Крейга про это рассказано. В двух словах идея такова: на проксе поднимается ДНС сервер для нужной зоны, например внутренней (он должен грузиться _после_ загрузки прокси), а внешние адреса прописываются в файле hosts. Или наоборот. Порядок разрешения имён задаётся порядком следования адресов в resolv.cfg

Мещеряков Андрей писал(а):
Дополнительная подробность:
имя домена - gou_lmc.
Это может как-то повлиять?
Лог с экрана:
QH_ns_req: Query for (pop.inbox.ru.gou_lmc) of type a
Это получается: к имени разрешаемого адреса дописывается (?) суффикс локального домена ? И потом такая абракадабра разрешается...

вообще-то underscore это не совсем стандартный символ для обозначения хостов/зон в DNS - может в этом дело?

Мещеряков Андрей писал(а):1. На 192.168.1.1 в качестве DNS всегда был адрес провайдера.
2. Тогда как 192.168.1.2 будет ресолвить адреса локального домена?

Из своей базы Или у вас еще есть DNS-сервер(ы)? В resolv.cfg На 192.168.1.1 или инетовский адрес ему прописываешь и не нужно списка Forvarding.
Вариант без DNS-прокси мне как-то больше нравиться(не помню правда причину... был какой-то глюк), разрешить 53 UDP для 192.168.1.1.. и см. выше.

Однако, заработало После того, как прописал в форвардерах адрес DNS прокси вместо серверов имен провайдера. Даже стремно, как сразу в голову не пришло. К стати, каков смысл рулей типа "port", если IPX/IP Gateway не загружен? По-моему, никакого... Спасибо ответившим!

Мещеряков Андрей писал(а):...Кстати, каков смысл рулей типа "port", если IPX/IP Gateway не загружен?...

Правила на всех действуют. HTTP Proxy правилами "port" тоже спокойно прикрывается/разрешается. IPXIPGW здесь не ключевое слово.

и DNS сервер Netware это две разные и взаимоисключающие вещи в том смысле, что нужен только один из них. Причем DNS сервер предпочтительнее, поскольку обслужит и внутреннюю сеть и инет.
Тогда в Forwarding List ему мы пишем адреса внешних DNS, в resolv.cfg - внутренний DNS, а на интерфейсе смотрящем в инет либо подымаем NAT, либо в дополнительных настройках DNS сервера говорим ему, чтобы он пользовался только внешним интерфейсом (но это или в 6.5 или в 6.0 с какой-то версии). А прописка в Forwarding list адреса DNS Proxy конечно проблему решит, но это я считаю извращением, зачем нужен двойной DNS кеш в локальной сети.

Boris Morozov писал(а):Тогда в Forwarding List ему мы пишем адреса внешних DNS, в resolv.cfg - внутренний DNS, а на интерфейсе смотрящем в инет либо подымаем NAT, либо в дополнительных настройках DNS сервера говорим ему, чтобы он пользовался только внешним интерфейсом (но это или в 6.5 или в 6.0 с какой-то версии). А прописка в Forwarding list адреса DNS Proxy конечно проблему решит, но это я считаю извращением, зачем нужен двойной DNS кеш в локальной сети.

Ваш вариант рассчитан (как я понимаю) на работу DNS-сервера на том же сервере, что и прокси. Но так бывает далеко не всегда и прежде всего тогда, когда нужен т.н. "split-DNS", т.е. одни и те же имена должны разрешаться в разные адреса внутри и снаружи. Кроме того, не всегда удобно (да и не всегда хочется) поднимать НАТ, т.к. при этом сразу падает информативность логов и контролируемость периметра. Ну и наконец, внутри могут использоваться приватные адреса...
Можно использовать DNS-proxy как сервер, прописывая аналоги записей типа "А" в файле hosts, однако сей вариант зело ущербен, т.к. не поддерживаются остальные типы DNS-записей (прежде всего NS и MX, а также CNAME в достаточном количестве). Кроме того, не всегда корректно работает обратное разрешение адреса в имя.
Поэтому, самый корректный вариант "split-DNS" - сделать два DNS-сервера, внутренний и внешний (один из них может быть на иной платформе, например Linux или в ином дереве - в случае NW-платформы), а DNS-proxy использовать для контролируемого форвардинга запросов изнутри наружу (особенно, когда внутри приватные адреса, но есть сервера - например Lotus Notes, как SMTP-сервер - для которых обязательно наличие возможности прямого контакта (и прямого разрешения имени) удалённого сервера).
Можно сделать вариант Крейга, но при этом будут вышеупомянутые ограничения на одну из зон (ту, которая будет разрешаться через файл hosts).

К сожалению, Нетваревский ДНС (в отличие от BIND-а) не позволяет поднять две зоны с одним именем, но с разными адресными пространствами на одном сервере - прежде всего из-за наличия всего одного объекта "DNS locator" в дереве. Если было бы можно создавать несколько таких объектов (пусть даже в разных контейнерах - тем лучше) - можно было бы к ним привязывать разные зоны-контейнеры.

на другом сервере именно по этой схеме. Если чего надо ограничить, то там фильтры стоят. А вот по схеме с двумя зонами я думаю, что можно с разных интерфейсов раздавать по DHCP разное имя домена. И в обоих доменах сделать одинаковые имена хостов, тогда по короткому имени хоста и будем получать разные адреса. А вообще расскажите, для чего конкретно нужны две зоны с одним доменным именем. И по какому принципу должен происходить выбор.

Boris Morozov писал(а):...А вообще расскажите, для чего конкретно нужны две зоны с одним доменным именем. И по какому принципу должен происходить выбор...

Для того чтобы (например) во внутренней сети, хост www.domain.com отображался на 192.168.254.254, а извне - 213.76.193.50. Выбор - очевидно по IP запрашивающего или по интерфесу, с которого пришел запрос.

Boris Morozov писал(а):А вот по схеме с двумя зонами я думаю, что можно с разных интерфейсов раздавать по DHCP разное имя домена. И в обоих доменах сделать одинаковые имена хостов, тогда по короткому имени хоста и будем получать разные адреса. А вообще расскажите, для чего конкретно нужны две зоны с одним доменным именем. И по какому принципу должен происходить выбор.

Этот вариант работать не будет, ибо раздача domain-name через DHCP в общем-то фикция, не влияющая ни на что, кроме возможности станции разрешать short-names путём автоприписывания DNS-суффикса. Ну не по стандарту это. По крайней мере - в реализации MS.
Нормальный иерархический резолвинг начинается с поиска SOA-записи для нужного домена. А это никаким DHCP не раздашь.
И потом - как Вы это себе представляете конкретно? Я же писал, что в пределах одного дерева невозможно реализовать один домен, пусть даже и с разными адресными пространствами. А нужен именно один домен изнутри и снаружи.
"split-DNS", как уже верно сказал предыдущий товарищ, нужен для: а) сокрытия внутренней структуры имён и б) одновременного сохранения единого именования домена внутри/снаружи. Выбор никакой не происходит - просто при обращении к хосту www.aaa.com снаружи он разрешается в 193.86.0.12 (к примеру), а при обращении к тому же www.aaa.com изнутри - разрешается в 192.168.21.4.
Это две разные зоны, пусть и с одинаковыми именами домена/некоторых хостов. Работают они на разных интерфейсах межсетевого экрана/прокси (в случае работы DNS-сервера на той же машине, что и МЭ) или на разных серверах, расположенных по разные стороны МЭ/прокси. Вот и всё.
"Правильные" DNS-сервера (BIND в частности) позволяют иметь хоть 10 зон с одним именем, но работающих на разных интерфейсах. Либо - запускать несколько копий задачи DNS - с разными конфиг-файлами (и соответственно - разными файлами зон).
Нетварь такого, к сожалению, не умеет. Почему я тоже писал - из-за наличия в дереве всего одного объекта типа "DNS locator". Если бы их можно было делать несколько - то можно было бы их привязвать к разным объектам "DNS-server" и создавать одноимённые зоны (пусть даже и в разных контейнерах).