Comments 25
Бровсер - так себе словечко.. Но в целом статья хорошая, спасибо.
Спасибо на добром слове! Я старался.
Слово браузер мне нравится еще меньше - очень уж не-русская у него фонетика.
Может, "сетевое бродило?" ;)
Да тут почти вся фонетика нерусская, что поделать, так получилось..:) А если уж сильно не нравится, можно писать browser, как вариант.
Не, ну вот слово "сокет", например, хорошее. Звучит, как родное, хоть само и импортное. А бровсеру не повезло.
>Анатомия Интернета ...
Александр, спасибо за статью хорошего уровня, imho не хуже первой, но хочу обратить Ваше внимание, что служба DNS это не совсем анатомия сети, потому что касается в основном разрешения имен в ip адреса, и только косвенно движения самих пакетов в сети, т.е. routing, и global connectivity,
поэтому может быть стоит Вам именно про это тоже написать, типа как connectivity обеспечивается, в том числе на логическом уровне, потому что сеть это не просто hw соединенное волокном, а также иерархическая логическая структура фиксированная в конфигурации routers разного уровня, в свою очередь созданной на основе контрактов между isp, и разделения функций по уровням между isp tier 1, 2, 3,
это вероятно имело бы практический интерес для читателей habr, типа лучшего понимания, что именно может происходить в сети при фильтрации vpn, dpi и пр.
поэтому может быть стоит Вам именно про это тоже написать
Я так и планирую. Тема-то, как Вы понимаете, очень широкая. Пытаюсь найти то смысловое ядро, которое будет интересно и понятно многим, не скатываясь в банальности и не погрязая в чрезмерно низкоуровневых деталях.
Я сам-то разработчик с большим сетевым опытом, а не админ. Поэтому смотрю на это дело больше с технической стороны, чем со стороны использования (а заодно, прорабатывая материал для статьи, подтягиваю пробелы в собственных знаниях).
Спасибо вам за отзыв и за обратную связь!
Просто бро.
Я делаю так: h + end + enter
Чисто перед именем сервера
Чисто конкретно задвинул, брателло!
ситуация аналогочная
А есть ли у вас, уважаемые коллеги, реальный опыт эксплуатации dnssec в больших проектах? На сколько я вижу, особо никто из гигантов его не использует, из-за проблем с реальной совместимостью
Не очень понятно, в чем могли бы заключаться эти проблемы с совместимостью.
Вот habr.com, например, подписан DNSSEC-ом. Вроде никто не жалуется.
Я вижу тут следующие соображения:
Если доступ к сайту осуществляется только через TLS (и не только HTTPS, SMTP/TLS тоже считается), проверка домена в любом случае заложена в TLS, и DNSSEC ничего особо полезного не добавляет
С DNSSEC много возни (хотя, казалось бы, Google мог бы справиться)
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
TLS сертификат можно подделать, если получается каким-то образом получить управление надо доменом
Возможно, у гугла были какие-то еще соображения, и они шире, чему у админов хабра, по этому и спрашиваю мнения компетентных коллег
Вряд ли мы здесь встретим людей, принимающих техническое решение о использовании 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тыс.доменов, и риски были достаточно высокими. Если будут вопросы, постараемся ответить тут
Интернет - штука сложная, и в ней много неочевидных нюансов. Даже в протоколах, которые кажутся на первый взгляд простыми. И когда начинаешь решать какую-то практическую проблему, в начале пути даже не знаешь объем того, что не знаешь, не говоря уж о том, по каким ключевым словам искать недостающее
Собственно, я хочу написать серию статей, которая восполняет этот пробел. Я много чего трогал собственными руками, но много чего и не трогал - жизнь, она не бесконечна :)
Поэтому если вы поделитесь своим опытом, это может быть полезным другим людям. Буду рад вашему рассказу
Анатомия Интернета: что в имени тебе моём? (DNS)