Вчера домен kostikov.co на котором размещается это блог был наконец-то подписан с использованием технологии DNSSEC. Напомню, что ранее автор уже довольно подробно останавливался на особеностях и практическом применении DNSSEC в цикле статей. Однако, в отличии от обычного здесь разбора примеров на основе реального конфигурирования домена kostikov.co в случае с DNSSEC приходилось отходить от этой традиции. Причиной этому было отсутствие возможности передачи отпечатка ключа для домена первого уровня .co регистратору домена — компании Namecheap через панель управления.

Действительно, согласно официально опубликованной статье "Nameservers and TLDs supported/unsupported by DNSSEC" в базе знаний Namecheap домен .co пока не числится в списке поддерживающих DNSSEC у данного регистратора. Однако, не далее как вчера поддержка известила, что имеется возможность ручного добавления необходимой для включения этой технологии информации в DNS-зону в ручном режиме.

Электронная почта была и остаётся одним из основных практических применений возможностей Интернет. Для удобства работы с ней создано большое количество специализированных почтовых программ — клиентов. В целях облегчения настройки последних применяется ряд механизмов, позволяющих в автоматическом режиме получать и применять настройки подключения к обслуживающим данных адрес e-mail серверам.

К сожалению, на сегодня не существует единого стандарта для автоматизации конфигурирования клиентов электронной почты, поэтому в зависимости от разработчика может использоваться один или несколько способов получения необходимой информации. Именно описанию таких способов, а также их внедрению на примерах и посвещена эта статья.

Публичные чёрные и белые списки являются давно и широко используемой технологией в борьбе с рассылкой несанкционированной электронной почты или спамом. Наиболее распространённым вариантом таких списков являются так называемые DNSBL (они же RBL), когда доступ к информации предоставляется посредством особым способом оформленного DNS-запроса и ответа, на основании которого можно произвести оценку относится ли данный узел сети Интернет к добросовестным или, соответственно, наоборот отправителям электронной почты. Также к своего рода чёрным спискам, которые, в отличие от DNSBL, не используют систему DNS для доступа к данным, автор относит и службы оценки сообщений на основе контрольных сумм. Среди них наиболее известны Rhyolite DCC, Vipul's Razor и Pyzor. Неплохим подспорьем в оценке эффективности того или иного публичного списка может служить рейтинг Blacklist Monitor от немецкой компании Intra2net.

Вопросы безопасности в целом, и проблемы аутентификации в частности, уже давно являются главной проблемой функционирования сети Интернет. К настоящему времени разработана масса способов, протоколов и стандартов, призванных сделать работу в глобальном киберпространстве надёжной и защищённой от различного рода угроз. К примеру, одним из самых известных и широкоупотребимых механизмов обеспечения безопасности является протокол HTTPS, который предназначен для передачи данных, в основном, во Всемирной паутине на базе криптографических методов SSL / TLS. Последние же неотъемлемо связаны с инфраструктурой удостоверяющих центров (CA), которые через цепочку доверия посредством цифровых подписей призваны гарантировать подлинность того или иного ресурса в сети.

Если удостоверяющий центр включён в список доверенных для данного программного обеспечения, в частности браузера в случае с протоколом HTTPS, то узел сети использующий выданный этим CA сертификат заведомо признаётся подлинным и, следовательно, заслуживающим доверия. Однако, именно здесь и находится главная проблема данной системы. Пользователь вынужден слепо доверять всем сертификатам, которые такие доверенные удостоверяющие центры выдали стороннему по отношению к ним самим ресурсу. При этом, нет никаких гарантий что это было сделано с ведома самого владельца такого ресурса. Ставшие достоянием общественности в последние годы многочисленные прецеденты выпуска известными удостоверяющими центрами сертификатов с серьёзными нарушениями правил их выдачи, самым громким из которых явился случай с DigiNotar, вновь поставили вопрос доверия к самой системе CA со стороны пользователей и заказчиков, а также разработку и внедрение более надёжных методов аутентификации в Интернет.

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

Казалось бы, ваша корпоративная почта на Google mail получает лишь одни преимущества, к примеру, в виде стандартизированного интерфейса, качественной защиты от спама, наличие общего календаря и доступа к документам. И всё это при простом развёртывании и высокой надёжности системы.

Однако, как и во всякой бочке мёда, здесь возможно отыскать и предостаточно дёгтя. Причём дёгтя настолько горького, что под сомнение может быть поставлена сама целесообразность такого подхода. Особенно болезненным понимание проблем, ограничений и даже угроз, которое может нести использование Google mail для поддержки корпоративной почты может стать для тех, кто изначально полностью положился на такое решение.

Но, обо всё по порядку.

Вопросы обеспечения безопасности различных сервисов в сети Интернет занимают существенное место в тематике статей этого сайта. Это не случайно, поскольку именно эта проблематика с каждым годом становится всё более важной частью работы во всемирной сети являясь существенным стимулом для технологического прогресса.

Среди последних проявлений такого прогресса можно отметить и недавнее решение CA/Browser Forum о необходимости обязательного использования контроля DNS-записей типа CAA (Certification Authority Authorization) в процессе выдачи SSL-сертификатов начиная с сентября 2017 года.