Pull to refresh

Comments 25

Бровсер - так себе словечко.. Но в целом статья хорошая, спасибо.

Спасибо на добром слове! Я старался.

Слово браузер мне нравится еще меньше - очень уж не-русская у него фонетика.

Может, "сетевое бродило?" ;)

Да тут почти вся фонетика нерусская, что поделать, так получилось..:) А если уж сильно не нравится, можно писать browser, как вариант.

Не, ну вот слово "сокет", например, хорошее. Звучит, как родное, хоть само и импортное. А бровсеру не повезло.

«Может собственных Платонов и быстрых разумом Невтонов российская земля рождать». М. Ломоносов.
:)

Во! Невтонов, а не Неутонов!

Тогда уж логичнее - соцкет. :)

Я только что понял откуда пошло кул хаЦкер

>Анатомия Интернета ...

Александр, спасибо за статью хорошего уровня, imho не хуже первой, но хочу обратить Ваше внимание, что служба DNS это не совсем анатомия сети, потому что касается в основном разрешения имен в ip адреса, и только косвенно движения самих пакетов в сети, т.е. routing, и global connectivity,

поэтому может быть стоит Вам именно про это тоже написать, типа как connectivity обеспечивается, в том числе на логическом уровне, потому что сеть это не просто hw соединенное волокном, а также иерархическая логическая структура фиксированная в конфигурации routers разного уровня, в свою очередь созданной на основе контрактов между isp, и разделения функций по уровням между isp tier 1, 2, 3,

это вероятно имело бы практический интерес для читателей habr, типа лучшего понимания, что именно может происходить в сети при фильтрации vpn, dpi и пр.

поэтому может быть стоит Вам именно про это тоже написать

Я так и планирую. Тема-то, как Вы понимаете, очень широкая. Пытаюсь найти то смысловое ядро, которое будет интересно и понятно многим, не скатываясь в банальности и не погрязая в чрезмерно низкоуровневых деталях.

Я сам-то разработчик с большим сетевым опытом, а не админ. Поэтому смотрю на это дело больше с технической стороны, чем со стороны использования (а заодно, прорабатывая материал для статьи, подтягиваю пробелы в собственных знаниях).

Спасибо вам за отзыв и за обратную связь!

> разработчик с большим сетевым опытом

может напишете пару строк в личку, просто интересно

Чисто перед именем сервера

Чисто конкретно задвинул, брателло!

ситуация аналогочная

Чисто конкретно поправил. Аналогочно и со второй опечаткой. Спасибо!

А есть ли у вас, уважаемые коллеги, реальный опыт эксплуатации dnssec в больших проектах? На сколько я вижу, особо никто из гигантов его не использует, из-за проблем с реальной совместимостью

Не очень понятно, в чем могли бы заключаться эти проблемы с совместимостью.
Вот habr.com, например, подписан DNSSEC-ом. Вроде никто не жалуется.

Я вижу тут следующие соображения:

  1. Если доступ к сайту осуществляется только через TLS (и не только HTTPS, SMTP/TLS тоже считается), проверка домена в любом случае заложена в TLS, и DNSSEC ничего особо полезного не добавляет

  2. С DNSSEC много возни (хотя, казалось бы, Google мог бы справиться)

  3. DNSSEC не очень-то совместим с CDN. Если посмотреть, тот же google.com по-разному резолвится из разных мест - на выходе адрес их ближайшего к пользователю CDN-сервера.

Наверное, об этом стоило упомянуть в статье. Но вот, упустил...

Добавлю ещё несколько причин, почему его не используют:

  • Почти нет (либо они не на слуху) реальных кейсов эксплуатации подмены DNS запросов

  • Наличие или отсутствие DNSSEC не влияет на поисковый рейтинг веб-сайта (в отличие от наличия SSL)

  • Мало какие shared хостинг-площадки предоставляют функцию подписания зоны из коробки. У Plesk, например, это платное расширение, в CPanel для работы DNSSEC нужно использовать PowerDNS. Остальным нужно либо ставить ПО для подписания зоны, либо вручную подписывать через dnssec-signzone или другие инструменты, а также самостоятельно сделить за ротацией ключей. Приятное исключение - ISPConfig, из коробки предоставляет DNSSEC бесплатно и без регистрации.

  • При смене хостинга необходимо заранее подписать зону на новом хостинге и заранее публиковать новые DS-записи в родительской зоне. Если своевременно не обновить DS-записи при переносе хостинга, домен перестанет работать, и на возобновление работы могут понадобиться многие часы.

  • Не все регистраторы предоставляют услугу публикации DS-записей

Подмену DNS-ответов можно использовать, чтобы отравить кеш (крупного) DNS-резолвера. В эпоху повсеместного использования TLS на чужой сайт пользователей так не заведешь, но отказ в обслуживании устроить можно.

Гугль активно двигает DoH. Причем в варианте, встроенном в Chrome и с терминацией на Гугловских серверах. Им, я бы даже сказал, не выгодно чинить проблемы в DNS.

Разное пишут в интернете. Например такие ужастики: https://ianix.com/pub/dnssec-outages.html

  1. TLS сертификат можно подделать, если получается каким-то образом получить управление надо доменом

  2. Возможно, у гугла были какие-то еще соображения, и они шире, чему у админов хабра, по этому и спрашиваю мнения компетентных коллег

Вряд ли мы здесь встретим людей, принимающих техническое решение о использовании DNSSEC в доменах масштаба google.com или intel.com. Таких людей просто физически очень мало, не думаю, что они тут стаями ходят

Но можем попробовать сами разобраться. Я потом обновлю статью.

История по вашей ссылке интересная. Там говорится, что если сломать TLD, DNSSEC сломается у кучи поддоменов. И еще там говорится, что такие случаи 100500 раз были в истории.

Мне, вообще, пока не очень понятно. Если сломается TLD, он и NS не будет возвращать и записи, относящиеся к DNSSEC тоже не будет. Вроде и просто домены сломаются, и криптоподпись сломается в них заодно. Но последствия первого сильно хуже последствий второго, и на фоне первого второе вроде как представляет только чисто академический интерес -- поправьте меня, если я не прав.

TLS сертификат не зависит никак от домена. С точки зрения TLS, имя домена - это просто такая строка. Мы идем на google.com, запоминаем, куда шли, резолвим адрес, куда-то попадаем, там нам предъявляют TLS-сертификат, и мы сравниваем строку в сертификате с запомненным доменом.

Единственное что, надо посмотреть, как это с CNAME сочетается. Я не знаю, бровсер сам резолвит CNAME и сразу обращается по каноническому адресу, или он идет по тому адресу, который дали, рассчитывает там найти TLS-сертификат, соответствующий имени, принимает оттуда redirect на каноническое имя, и потом, зайдя уже по каноническому имени, рассчитывает там найти другой TLS-сертификат, уже соответствующий новому имени. Я разберусь, мне любопытно.

Но в общем и целом, похоже, DNSSEC - мёртвая технология (хотя ее агония может еще довольно долго продолжаться).

Мы занимались внедрением DNSSEC на уровне TLD, и подготовка заняла действительно много времени. В зоне было порядка 100тыс.доменов, и риски были достаточно высокими. Если будут вопросы, постараемся ответить тут

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

Собственно, я хочу написать серию статей, которая восполняет этот пробел. Я много чего трогал собственными руками, но много чего и не трогал - жизнь, она не бесконечна :)

Поэтому если вы поделитесь своим опытом, это может быть полезным другим людям. Буду рад вашему рассказу

Если наш ИБ одобрит, напишу тут развёрнутый комментарий )

Sign up to leave a comment.

Articles