Ответы пользователя по тегу Система доменных имен
  • Почему на западе любят поддомен www в адресе сайте, а у нас корень домена?

    HeadOnFire
    @HeadOnFire
    PHP, Laravel & WordPress Evangelist
    Технически можно и так, и сяк. Но, как всегда, есть нюансы, на которых и сыпется большинство советчиков (в том числе в этом треде).

    Если у вас только сайт на домене, максимум почта на других портах, и даже CDN не используется - можете спокойно использовать основной домен без www. Если у вас сайт многоязычный, и языки размещены на поддоменах - тогда тоже без www. Если же у вас есть и другие ресурсы в домене, например:

    www.example.com - публичный сайт
    developers.example.com - публичный сайт инструментов для разработчиков
    api.example.com - какой-нибудь публичный АПИ
    cdn.example.com - поддомен content delivery network (можно много - cdn1, cdn2 итд)
    docs.example.com - публичная документация
    help.example.com - публичная справка
    support.example.com - публичная служба поддержки
    dev.example.com - закрытая, непубличная копия сайта, стейджинг
    hr.example.com - закрытая, непубличная часть, внутренние ресурсы компании для сотрудников
    mail.example.com - технический субдомен для почты
    webmail.example.com - веб-морда для почты (может быть как публичной, так и открытой для отдельных IP, доступ по VPN и тд)
    vpn.example.com - чисто технический поддомен для проксирования трафика через VPN компании
    ns1.example.com - поддомен для своего сервера имен (ns1/ns2/ns3 или primary/secondary и тд)

    ... и так далее. Таких поддоменов может быть очень много, и у каждого своя, совершенно изолированная кухня. Так вот, если использовать для публичного сайта домен без www, то все его куки будут распространяться на все поддомены. А это плохо. На современном сайте этих кук штук 10 минимум, большая часть из них совершенно не нужна, или даже откровенно лишняя на всех других поддоменах. В это же время, если вы используете www и хотите поделиться куками с него с другим поддоменом - это вполне возможно сделать, осознанно.

    Кроме этого - с www намного удобнее работать на уровне DNS, если это CNAME. Записи типа А лучше ставить долгий TTL, а вот CNAME может иметь короткий и его можно перебрасывать в любой момент. Пошла DDoS-атака - в считанные минуты пустили трафик через гейт сервиса защиты от DDoS или выделенный файрвол (у который другие IP-адреса). Или балансировку нагрузки делать. При этом основной домен (origin) и его IP не меняется, почта не слетает, внутренние сервисы не слетают, АПИшки не падают и тд.

    Вот тут можно немного почитать про вопросы безопасности, связанные с принудительным транслированием всех кук на все поддомены.

    В общем, мое мнение - если у вас свой личный сайт или маленький сайтик маленького личного бизнеса, и рост до уровня когда понадобится куча поддоменов не планируется - тогда можете смело использовать без www. Если же продукт или сервис, бизнес который может вырости в что-то относительно крупное - стартуйте с www с самого начала, потом спасибо скажете.
    Ответ написан
    2 комментария
  • Как правильно разместить девелоперскую копию сайта на втором сервере?

    HeadOnFire
    @HeadOnFire
    PHP, Laravel & WordPress Evangelist
    Ну, раз по-человечески сделать dev / staging / production не вариант, то в голову приходят такие варианты:

    1. Если сайты на разных серверах - поставить перед ними load balancer. Весь трафик слать на продакшн, а девелоперов по IP - на копию. SSL-сертификат нужно будет перенести на балансировщик, разумеется.

    2. Если сайты физически на одном сервере - настроить Nginx / Apache или что там у вас для разных IP смотреть в разный docment root. Всех слать в папку прода, а свои IP - в клон.
    Ответ написан
    Комментировать
  • Как правильно связать хостинг провайдера cacloud с купленным доменом imena.ua?

    HeadOnFire
    @HeadOnFire
    PHP, Laravel & WordPress Evangelist
    Если в контрольной панели на cacloud.com есть возможность настройки DNS, тогда надо создавать зону в нем (привязывать доменное имя к IP-адресу вашего сервера), в ней же будут указаны NS-сервера, которые нужно указать в настройках домена на imena.ua. При такой схеме вы в imena.ua единожды указали NS-сервера, и вся дальнейшая работа с зонами (создание поддоменов и т.д.) идет уже на стороне cacloud.com

    Если же подобной настройки на caacloud.com нет (что, в принципе, вряд ли) - тогда в настройках imena.ua нужно будет создать все зоны (A, CNAME, MX и т.д.) и указывать везде IP-адрес сервера.

    В любом из этих вариантов потребуется некоторое время на пропагацию зоны и обновление DNS-информации. Учитывая, что регистратор в Украине, а хостинг в Канаде, время обновления DNS-информации может занять и сутки - тут многое зависит от настроек TTL и пр. на обеих концах.

    На данный момент запрос в базу whois возращает корректную информацию, прописаны NS-сервера cacloud.com (ns*.caclouddns.com). Значит вам нужно на стороне cacloud.com в контрольной панели своей настроить (см. первый абзац). По сути, обращение к домену сейчас корректно отправляет на NS-сервера cacloud.com, но придя туда запрос теряется, так на на стороне этих самых NS-серверов нет созданной зоны (или некорректно настроена), соответственно, дальше непонятно на какой сервер (IP-адрес) направлять запрос.
    Ответ написан
    2 комментария