- Поисковые системы
- Практика оптимизации
- Трафик для сайтов
- Монетизация сайтов
- Сайтостроение
- Социальный Маркетинг
- Общение профессионалов
- Биржа и продажа
- Финансовые объявления
- Работа на постоянной основе
- Сайты - покупка, продажа
- Соцсети: страницы, группы, приложения
- Сайты без доменов
- Трафик, тизерная и баннерная реклама
- Продажа, оценка, регистрация доменов
- Ссылки - обмен, покупка, продажа
- Программы и скрипты
- Размещение статей
- Инфопродукты
- Прочие цифровые товары
- Работа и услуги для вебмастера
- Оптимизация, продвижение и аудит
- Ведение рекламных кампаний
- Услуги в области SMM
- Программирование
- Администрирование серверов и сайтов
- Прокси, ВПН, анонимайзеры, IP
- Платное обучение, вебинары
- Регистрация в каталогах
- Копирайтинг, переводы
- Дизайн
- Usability: консультации и аудит
- Изготовление сайтов
- Наполнение сайтов
- Прочие услуги
- Не про работу
Что делать, если ваша email-рассылка попала в спам
10 распространенных причин и решений
Екатерина Ткаченко
Авторизуйтесь или зарегистрируйтесь, чтобы оставить комментарий
Всем спасибо, для меня сейчас тут слишком много незнакомых слов - пошёл изучать...
Я встречал людей, искренне верящих, что если какой-то их клиент посмотрит Whois и увидит там "чужой" домен, то он тут же побежит к этому "чужому". Бред, конечно же, но бывает...
На самом деле это бред, т.к. никто из нормальных клиентов таких слов как whois даже не знает, а для специалиста отличить реального владельца сервера от посредника труда не составит даже если будут свои ns. К тому же иногда у посредника получается дешевле и выгоднее. Но есть другие причины иметь свои ns'ы: когда твоего клиента пытаются переманить любым способом другие, технически подкованные люди. И начинают ему "раскрывать" глаза в том числе и показывая через данные в ns, например сайт с ценами (если URLы у них одинаковые). Свои ns в данном случае полностью исключают такую возможность.
...
_interceptor_
2pegs
не реально чтобы ip поменялись т.к. эти ip скорее всего прописаны на
primary клиента.
Реально в случае глобальных инфраструктурных изменений. Тот же RIPE имеет полное право "забрать" блок адресов и заменить его другим.
Такие варианты я, конечно, не рассматривал, но не спорю, возможно. :)
Но согласитесь, это достаточно уникальное событие ... из разряда а сколько еще не предусмотрено.
В конце концов можно и primary тогда у ru-центер заказать и отказаться
от брендованых ns-ов.
Такие варианты я, конечно, не рассматривал, но не спорю, возможно. :)
Но согласитесь, это достаточно уникальное событие ... из разряда а сколько еще не предусмотрено.
В конце концов можно и primary тогда у ru-центер заказать и отказаться
от брендованых ns-ов.
_interceptor_, все верно пишите, можно и primary заказать. Но если доменов много, во сколько это обойдется? Потом, чтобы прописать зону по услуге primary РуЦентра для большого числа доменов это сколько времени надо! Куда проще наладить свой BIND написать конфиги зон и запустить это хозяйство.
П.С. По услуге primary есть одна неприятная деталь, там обновление изменений регламентировано ~3 часа (если не ошибаюсь, во всяком случае долго ждал :)). А бывают ситуации (например, меняются IP-шники у веб-хостинга) когда нужно TTL понизить до минимума, срочно обновить зоны, а после смены IP вернуть TTL обратно. Когда DNS свой (BIND-вый, например) - это под вашим полным контролем.
Оксиген
Но есть другие причины иметь свои ns'ы: когда твоего клиента пытаются переманить любым способом другие, технически подкованные люди. И начинают ему "раскрывать" глаза в том числе и показывая через данные в ns, например сайт с ценами (если URLы у них одинаковые). Свои ns в данном случае полностью исключают такую возможность.
Да, если только брендирование распространяется и на обратную зону. Реальный пример:
...
Куда проще наладить свой BIND написать конфиги зон и запустить это хозяйство.
Кому как, я смогу это сделать, вы тоже, по всей видимости, а другие
талантливы в другой области. :)
П.С. По услуге primary есть одна неприятная деталь, там обновление изменений регламентировано ~3 часа (если не ошибаюсь, во всяком случае долго ждал :)). А бывают ситуации (например, меняются IP-шники у веб-хостинга) когда нужно TTL понизить до минимума, срочно обновить зоны, а после смены IP вернуть TTL обратно. Когда DNS свой (BIND-вый, например) - это под вашим полным контролем.
Ваш вариант хорош, но что нужно Оксигену, знает только он.
Я кстати хотел пойти по вашему варианту чтобы провести некоторый эксперимент с DNS и осв. доменами... но нету времени(! и это при условии, что я знаю что делать).
Хостинг провайдер предоставляет возможность использовать свой домен в качестве нейм сервера.
а какой вообще смысл в этом? зачем?...
Могут быть проблемы с тестированием ns-ов в ру-центер. Тестирование не пройдет
Да, так пока и получается. Выдаёт ошибку: Не найден IP-адрес для ns2...
если только брендирование распространяется и на обратную зону
Проверил - распространяется.
купить Managed DNS у сторонней фирмы
Купил. Вы меня не в ту сторону отправили, egorych. Managed DNS - это то же самое, что предлагает Руцентр как Primary и Secondary. Это совсем не то, что мне нужно.
Да, так пока и получается. Выдаёт ошибку: Не найден IP-адрес для ns2...
...
Я думал, что у вас будет ошибка два ns в одной подсети...
Где там могут быть не найдены ip адреса не понимаю,
т.к. ip адреса этих серверов вы должны указать еще при заказе
изменений:
ns2.мой_домен ip_адрес_ns2_провайдера
ns1.мой_домен ip_адрес_ns1_провайдера
Если ns-ы находятся внутри зоны самого домена, то указание ip адресов обязательно
Если ns-ы находятся внутри зоны самого домена, то указание ip адресов обязательно
Нет. Дело в том, что под NS'ы я специально взял отдельный домен в зоне NET на котором кроме них не будет ничего вообще. Соответственно тестируемый с ошибкой домен имеет в настройках только ns1.мойдомен и ns2.мойдомен, никаких ай-пи я там не указывал (сейчас попробую, кстати). При этом буржуйские домены работают на ура, а вот с RU вылезла такая проблема. Да ещё и выходные, блин - половина нужных контор не работает. :(
У resellerclub.com как я понял купить нужную мне услугу нельзя? Или я что-то просмотрел?
Нет. Дело в том, что под NS'ы я специально взял отдельный домен в зоне NET на котором кроме них не будет ничего вообще. Соответственно тестируемый с ошибкой домен имеет в настройках только ns1.мойдомен и ns2.мойдомен, никаких ай-пи я там не указывал (сейчас попробую, кстати). При этом буржуйские домены работают на ура, а вот с RU вылезла такая проблема. Да ещё и выходные, блин - половина нужных контор не работает. :(
Для зон RU/SU домены тестируют при делегировании. При этом у каждого регистратора своя процедура тестирования, РуЦентр например, круто проверяет на трансфер зоны для домена. При этом, для все прописанные к домену NS-ы проверяются на идентичность основных данных (SOA, NS), и только при полном их соответствии тестирование считается пройденным.
Для "буржуйских" же зон, проверяется только наличие зарегистрированного NS-а, а тестирования, как такого, нет.