Владимир Скубриев -> debian-russian@lists.debian.org @ Tue, 26 Mar 2013 15:35:36 +0400:
ВС> On 03/26/2013 12:52 PM, Peter Pentchev wrote:
>> Так... значит, несколько вариантов:
>>
>> 1. Не использовать DNS hosting, а только Ваших серверов; запустить
>> BIND, PowerDNS, djbdns или чего-либо в режим authoritative
>> nameserver, определить locations/views для локальки и для внешнего
>> света, задать соответствующие DNS-записи. Потом запустить BIND,
>> Unbound, PowerDNS, MaraDNS, djbdns или чего-либо в режим recursive
>> resolver только для локальки и указать ему Ваши authoritative
>> сервера, так чтоб resolver попадал в дефиниции локальних
>> views/locations.
ВС> Не вариант. Наш DNS сервер не сможет обеспечить доступность 24/7/365.
>> 2. Запустить BIND, PowerDNS, MaraDNS, djbdns или чего либо в режим
>> resolving cache + authoritative nameserver. В дефиниции зон
>> authoritative nameserver-а дублировать информацию домена
>> example.com, но менять адреса на локальние. Основний недостаток:
>> когда что-либо изменится в "внешней" зоны example.com, надо будет те
>> же изменения нанести и в зонах сервера.
ВС> Как сделать так, чтобы bind забирал информацию о зоне с сервера провайдера
ВС> автоматически?
ВС> Как правильно потом менять только нужные нам записи на локальные адреса?
В связи с последним я бы попытался напрячь сервера провайдера работать
slave. То есть держать свой сервер мастером, разрешить серверам
провайдера zone transfer, вписать их (и только их) как NS в зону, и
попросить сервера провайдера таскать зону со своего. Для последнего
может потребоваться вменяемый провайдер :) Вообще говоря, в данном
случае регистратор, провайдер DNS и провайдер интернета могут быть
совершенно разными сущностями. Так, я периодически работаю у знакомых
таким вот "провайдером DNS". Правда, я обычно предоставляю только один
из secondary.
Но сам я views в бинде не настраивал, готового рецепта не дам. Тут явно
будут тонкости на тему того, что будет отдавать как zone transfer
слейвам бинд, который выдает разную информацию разным клиентам.
ВС> А если сделать так, чтобы для клиентов ЛВС первый адрес отдавался локальный а
ВС> второй публичный ?
ВС> Можно ли это реализовать
Если я правильно ошибаюсь, да, можно.
ВС> и как будет себя вести клиентское ПО: 1. Будет всегда пытаться
ВС> соединится с хостом сначала с первым IP, потом с последующими в
ВС> случае не доступности первых. или 2. Программы будут работать в
ВС> зависимости от их реализации и их принцип выбора не всегда
ВС> предсказуем.
Второе. Подозреваю, что чаще всего, если один из адресов из локальной
сети (т.е. той, в которую есть прямой роутинг), то резолвер первым в
ответе программе выдает именно его. А вот если нет, то может и
потасовать. Во всяком случае, линуксовый резолвер, насколько нам
рассказывает man resolv.conf, умеет и собственную сортировку, и round
robin. Сами программы редко что-либо делают с полученным списком
адресов, но в целом имеют право.
>> 3. Запустить BIND, PowerDNS, MaraDNS, djbdns или чего либо в режим
>> resolving cache + authoritative nameserver и определить
>> authoritative nameserver как slave/secondary для внешней зоны
>> example.com. Так он получит все изменения... только раз сейчас мне
>> не приходит в голову точно как нанести локальние записи там.
>> Конечно, если использовать djbdns
>> , можно в процессе обновления зоны
>> наносить в нее какие нужно корекции - ведь зона же machine-readable
>> (и writable) plain text file.
ВС> А как часто DNS серверы обновляют свои зоны являясь при этом slave/secondary ?
ВС> Исходя из TTL?
slave делает это по трем событиям: по пинку с мастера (мастер посылает
такой пинок, когда перегружает зону), по собственному запуску или
просьбе переконфигурации, и периодически. Часть "периодически" может
быть у разных серверов реализована по-разному. TTL тут может и
использоваться, и не использоваться, второе вероятнее.
В типичном случае (когда в момент перезагрузки зоны слейв доступен)
срабатывает первое, т.е. слейв получает изменения практически мгновенно.