Владимир Скубриев -> [email protected] @ 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 тут может и использоваться, и не использоваться, второе вероятнее. В типичном случае (когда в момент перезагрузки зоны слейв доступен) срабатывает первое, т.е. слейв получает изменения практически мгновенно. -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: http://lists.debian.org/[email protected]
