Вопросы по DNS серверам

1. не вижу смысла в этом

2. использую поддержку dns у мастерхоста (услуга бесплатная) - всё устраивает и проблем пока не было. правда панелька не очень удобная, но привыкнуть можно

так же можно первичный нс разместить на своём сервере, а вторичный взять в другом месте для надёжности (например здесь ispserver.com). такая схема мне кажется не совсем удобной :)

1. Правило - 2 ns-а в разных подсетях не просто так придумали. Если нужна надежность, то это неправильное решение. Могут быть проблемы с тестированием ns-ов в ру-центер. Тестирование не пройдет.

2. Если я правильно понял вопрос, то список ns-ов для вашего домена с услугой ру-центра будет выглядеть так:

ns1.ваш_домен

ns2.ваш_домен

ns4.nic.ru

ns8.nic.ru

Причем я бы выкинул ns2.ваш_домен так как смысла в нем нет, а

ру-центер дает на самом деле два secondary для вашего домена,

один из которых находится в амстердаме. Т.е. с точки зрения надежности

лучше не придумаешь. Даже если ляжет канал забугор домен будет резолвится.

Оксиген,

1) Если иметь свои НС-ы, значит их надо поддерживать, что конечно напрягает. С другой стороны, свои сервера - свой контроль и независимость от бесплатных NS-ов регистраторов, хостеров (которые по причине большого числа клиентов могут "глючить"). А если большинство полезных доменов у регистраторов, где нет бесплатных NS-ов (например, РуЦентр), то конечно лучше сделать свои и разместить там домены. Если покупать независимые NS-сервисы под каждый домен, то накладно будет.

BIND реализация NS-сервера мало-ресурсоемка, поэтому можно прикупить простенькие VDS-ы и там все поднять. Некоторые хостеры выдают несколько IP из разных сеток С-класса. И есть соблазн, на одном серваке сымитировать два NS-а (и тем самым сэкономить на втором VDS-е). Технически это реально (я видел такое), но я настоятельно не рекомендую. Ибо если ляжет VDS/Хостер/Провайдер, то лягут все эти DNS-ы со всеми вытекающими последствиями.

2) Для более стабильной работы желательно не просто из разных подсеток взять IP, а с разной (и качественной) "физикой", а то сетки то могут быть разные, но от одного провайдера и по тем же проводам. Услуга РуЦентра Secondary при большом числе доменов - дорогое удовольствие.

П.С.

Если DNS-ы записи для всех доменов идентичны, то можно настроить, чтобы любые запросы выдавали идентичные DNS-записи. (Как это обычно сделано на ряде парковкок) .

я в курсе, поэтому и сомневаюсь и хочу дополнительно обезопаситься. После того, как несколько лет назад упало полинтернета, текущий провайдер поставил 3-й ns вообще в другой сети, не то что в подсети. Меня то больше несколько другой вопрос интересует в пункте 1: поскольку я не владею техническими подробностями как это всё работает, я беспокоюсь, не будет ли это (собственные ns'ы) тормозить работу сайта? Я лишь понимаю, что эти ns'ы реально не существуют в природе, а являются лишь синонимами (в лучшем случае) уже существующих ns провайдера.

Видимо нет. Возможно я не точно изложил, попробую ещё раз: мне нужен IP из какой-то другой сетки, который бы работал в качестве 3-го ns вида ns3.мойдомен. Насколько я понял, Руцентр таких услуг не предоставляет, он предоставляет как раз то, о чём вы написали. Какой мне смысл делать 2 ns'а своих, а третий с чужим брендом? Тогда проще не заморачиваться и использовать провайдерские.

Интересует именно размещение под своим брендом, но в разных сетях/подсетях.

Хмм, ну если под своим брендом, то сделайте в зоне

мойдомен две A записи

ns3.мойдомен A {ip адрес secondary ru-центер ns4.nic.ru}

ns4.мойдомен A {ip адрес secondary ru-центер ns8.nic.ru}

И тогда список ns-ов будет

ns1.мойдомен

ns2.мойдомен

ns3.мойдомен

ns4.мойдомен

Но опять же, вы покупаете secondary у ru-центр для одного домена, который еще к тому же

нельзя будет поменять, как правильно заметил pegs это дорого, но с другой стороны для

серьезного проекта оно стоит того

Оксиген

Меня то больше несколько другой вопрос интересует в пункте 1: поскольку я не владею техническими подробностями как это всё работает, я беспокоюсь, не будет ли это (собственные ns'ы) тормозить работу сайта? Я лишь понимаю, что эти ns'ы реально не существуют в природе, а являются лишь синонимами (в лучшем случае) уже существующих ns провайдера.

Если с технической стороны всё сделано грамотно, то тормозов не будет. Если же захочется полностью перейти на DNS-решение под собственным брендом, то имеет смысл зарегистрировать какой-либо "инфраструктурный" домен в разных TLD, поддерживаемых разными операторами реестра (к примеру, OXY-DNS.RU, OXY-DNS.NET и OXY-DNS.CO.UK) и используя эти имена, создать свои NS на базе опять-таки различных провайдеров VDS-решений или как синонимы NS различных провайдеров. В последнем случае нужно предусмотреть механизм автоматической проверки изменения адреса провайдерского NS и его корректировке в собственных зонах.

Тут вопрос количества доменов. Для серьезных проектов приносящих доход можно купить и Secondary у РуЦентра. И, на мой взгляд, бренд тут ничем не пострадает, если дополнительно будут прописаны ns4.nic.ru и ns8.nic.ru. Другое дело, если доменов много (и большого дохода они не приносят), то покупать столько услуг Secondary - дорого будет. Вот об чем речь :)

Именно вероятность изменения адреса и создает ненадежность такого решения. РуЦентр (например) поменяет IP-шники для ns4.nic.ru, ns8.nic.ru и если это оперативно не сделать на своих ns-ах, то будет неприятная ситуация. Хотя конечно, такие перемены очень редко происходят.

И, кстати, такой способ просто скрывает NS-провайдера, но при этом для размещения зоны на этих NS-ах все равно придется "договариваться" с провайдером (фактически покупать услугу Secondary). Поэтому если доменов много, дешевле купить VDS и там поднять DNS. В любом случае, все надо считать (стоимость VDS, число доменов и т.п.)

проще имхо купить Managed DNS у сторонней фирмы (например тот же publicdomainregistry или множество других), если регистратор ее не предлагает, и сделать себе child ns

ns1.domain.com ip11,ip12,ip13,

ns2.domain.com ip21,ip22,ip23,

etc.

(по нескольку записей на каждый чайлд нс, ip - статичные, не меняются со временем, по три штуки на каждый nameserver - вполне достаточно имхо, да и по одному хватит, поскольку ипы нормальных сторонних сервисов не ложатся).

потом только А и CNAME записи менять при переездах.

2Оксиген

в моем варианте забыл еще добавить, что ns-ы провайдера должны давать

возможность AXFR зоны, либо это должно как-то настраиваться.

Иначе толку от secondary на сторне не будет, они просто не смогут выкачать

зону с праймари.

2pegs

не реально чтобы ip поменялись т.к. эти ip скорее всего прописаны на

primary клиента. Т.е. смена ip приведет к массовым ошибкам на

secondary и протуханием зон, если админы primary не пошевелятся

и не пустит новый ip для axfr зоны. Т.е. это реальная подстава и ру-центер на это не пойдет.

pegs

Для серьезных проектов приносящих доход можно купить и Secondary у РуЦентра. И, на мой взгляд, бренд тут ничем не пострадает, если дополнительно будут прописаны ns4.nic.ru и ns8.nic.ru.

Я встречал людей, искренне верящих, что если какой-то их клиент посмотрит Whois и увидит там "чужой" домен, то он тут же побежит к этому "чужому". Бред, конечно же, но бывает...

Именно вероятность изменения адреса и создает ненадежность такого решения. РуЦентр (например) поменяет IP-шники для ns4.nic.ru, ns8.nic.ru и если это оперативно не сделать на своих ns-ах, то будет неприятная ситуация.

Transition с одного IP на другой, тем более на NS, тем более у операторов реестра не происходит вот так вот с бухты-барахты. Обычно этому предшествует рассылка информации по клиентам. Но даже если такой рассылки не было или она не пришла, утонув в спам-фильтрах, то реализующий схему подобного "брендирования" понимает, на какие риски идёт, и соответственно должен предусмотреть скрипт, проверяющий неизменность A-записи для "брендируемого" сервера и корректирующий "свои" зоны при её изменении, а также отправляющий письмо админу.

_interceptor_

2pegs
не реально чтобы ip поменялись т.к. эти ip скорее всего прописаны на
primary клиента.

Реально в случае глобальных инфраструктурных изменений. Тот же RIPE имеет полное право "забрать" блок адресов и заменить его другим.