Задать вопрос
Ответы пользователя по тегу Веб-разработка
  • Не понимаю суть переноса домена (как быть с ns-ками)

    merlin-vrn
    @merlin-vrn
    Чтобы домен работал:

    1. DNS-серверы оператора должны делегировать домен на ваши DNS-севреры. Под «ваши» в данном случае имеется ввиду «на те, на которых вы разместили свою зону». Такое делегирование в зоне оператора выглядит так:

    (в зоне com)
    domain2.com. NS ns1.domain1.net.
    domain2.com. NS ns2.domain1.net.

    Если серверы так и расположены в другой зоне, этого достаточно. Если NS-серверы имеют имена в той же самой зоне, то появляются ещё специальные A-записи типа «а где этот сервер найти»:

    (в зоне com)
    domain1.net. NS ns1.domain1.net.
    domain1.net. NS ns2.domain1.net.
    ns1.domain1.net. A 192.168.0.1
    ns2.domain1.net. A 192.168.0.2

    Чтобы оператор это мог сделать, вы сообщаете ему имена, и, если потребуется, адреса DNS-серверов. Делается это через панель управления доменом у вашего регистратора, который там потом разберётся, что куда. Для домена, в котором расположены сами DNS-серверы, указываете вместе с IP-адресами, для остальных доменов, хостящихся на этих же DNS-серверах — без адресов, достаточно указать имена.

    2. Ваши DNS-серверы должны быть правильно сконфигурированы. Это значит:

    2.а: Все серверы имеют одинаковую версию зоны, т.е. один и тот же запрос ко всем серверам вернёт совершенно одинаковый ответ.
    2.б: В них есть служебные SOA-запись и NS-записи, в которых указаны все эти DNS-серверы.

    Т.е. для первого случая, в зоне domain.com будет такая информация:
    domain2.com. SOA ns1.domain1.net. dnsadmin.domain1.net. 2011100976 86400 7200 3600000 172800
    (числа в конце — это номер версии зоны и временные параметры; dnsadmin… — это служебный емейл, в котором @ заменили на .)
    domain2.com NS ns1.domain1.net.
    domain2.com NS ns2.domain1.net.

    Всё остальное здесь — записи domain2.com. A, domain2.com. MX, www.domain2.com. A и прочие — какие вам нужны, то есть, адреса ваших хостингов почты и сайта, jabber-сервер, DKIM-подпись, и тому подобное.

    Для второго случая в зоне нужно указать сами IP-адреса серверов в A-записях, т.к. они являются частью этой зоны:
    domain1.net. SOA ns1.domain1.net. dnsadmin.domain1.net. 2011100976 86400 7200 3600000 172800
    domain1.net. NS ns1.domain1.net.
    domain1.net. NS ns2.domain1.net.
    ns1.domain1.net. A 192.168.0.1
    ns2.domain1.net. A 192.168.0.2

    опять же, всё остальное здесь — записи domain1.net. A, domain1.net. MX, www.domain1.net. A и любые другие — по вашему желанию.
    Ответ написан
    Комментировать
  • Как обезопасить систему с полным клиентским доступом к HTML?

    merlin-vrn
    @merlin-vrn
    HTTPS и клиентские сертификаты. Аутентификация по сертификату (защита от кражи — можно хоть токены использовать), в результате чего получаем уникальный идентификатор пользователя — commonName из сертификата. При проверке прав (авторизации) привязывайтесь к commonName.

    Общая аутентификация будет хоть на нескольких несвязанных доменах, и им даже иметь какую-то общую базу необязательно — общим на них будет только корневой сертификат вашего ЦС, которым подписаны все сертификаты клиентов.

    Пароли в принципе тоже не обязательны, можно внедрить — тогда общая база будет нужна, а аутентификация получится двухфакторая.
    Ответ написан
  • Утилита для бекапов под linux

    merlin-vrn
    @merlin-vrn
    к предыдущему оратору: да, у нас довольно масштабная система бекапов на бакуле развёрнута. Гуи есть, но он не нужен.
    Ответ написан