Это вполне может быть успешной атакой на резолвер НСДИ, в частности если схема работы в части кеширующего рекурсивного сервиса построена на иерархии: несколько резолверов и кучка форвардинг кешей, которые в них смотрят.
В теории это может быть и компроментация одного из авторитетных серверов на которых делегирован домен smotrim.ru. Внутри РФ задержка до обоих авторитетных серверов этого домена одинакова и маловероятно, что DNS кеши указанных провайдеров обращались только к одному из них. Гораздо более вероятно, что эти провайдеры в регионах, где они пострадали, все рекурсивные запросы отправляют в НСДИ.
Такая централизация управления убивает саму идею Интернет, который всегда управлялся децентрализовано. И складывает все яйца в одну корзину, давая слишком много власти ограниченному списку людей. Это плохо выглядит и так же закончится.
В Москве будет также, без пробок, если жить в паре остановок на трамвае от офиса.
А в Петербурге пробки перманентное явление.
Поменяете работу — если она будет в другой части города, например на другом берегу, то либо пробки, либо менять квартиру )
Let’s Encrypt при авторизации через DNS всегда проверяет запись непосредственно через непосредственное обращение к авторитативным DNS серверам домена. Запись должна быть опубликована к тому моменту, когда Let’s Encrypt придет ее проверять. TTL тут никакой роли не играет.
Bare-metal инфраструктура Packet: цена плавающего IP: $0.005/час ($3,6 в месяц) в пределах одного ДЦ, $0,15/час ($108 в месяц) между ДЦ. По мне, если это дорого для Бизнеса, но это наверное не Бизнес на котором зарабатывают деньги, а попытки экономить на спичках и на End User Experience.
Современный кеширующий резолвер при обработке запроса от Клиента смотрит сколько от оригинального TTL осталось. И если осталось меньше чем время N, то асинхронно запрашивает авторитативные сервера, обновляя запись в фоне. Таким образом популярные запросы всегда находятся в Кеше. Стандартов на сколько я знаю на это не существует в природе и каждый разработчик кэширующих DNS серверов делает это по собственным алгоритмам.
По проблематике коротких TTL — текущая температура по больнице:
1) Маленькие TTL на популярных доменах не вредят телеком-провайдерам с большим количеством Абонентов. При условии того, что эти телеком-провайдеры агрегируют трафик 400+ тысяч Абонентов на сервер. Давление на кеш на таком сервере позволяет держать все популярные домены в кеше. Сервер может отвечать на запросы к популярным доменам 100% из кеша, если используются проактивное кеширование.
У телеком-провайдеров с небольшой нагрузкой на кешируюшие DNS сервера популярные домены часто вымываются из кеша, вследствии небольшого на него давления от клиентов. И проактивное кеширование при небольшом давлении на кеш уже не помогает.
2) В среднем TTL все время снижается, так как все больше ресурсов переезжает в «облака», в которых короткие TTL используются по умолчанию.
В среднем никогда не стоит делать TTL меньше 15 секунд, иначе и проактивное кеширование на стороне резолвера ISP может не успевать обновлять кеш, до того как запись умрет по TTL.
Возможно это прозвучит странно, но есть серьезные сомнения в квалификации сотрудников Google, которые занимаются Google Public DNS. Яркий пример — они делали общий, разделяемый несколькими нодами кеш для разных инстансов сервиса. При том, что при их (большой) нагрузке это не могло привести к улучшению наполненности и актуальности кеша, если каждый инстанс обслуживает от 50,000 QPS и выше. Давление на кеш при такой нагрузке уже нормальное и он вполне себе наполнен актуальной информацией. Выигрыша от разделяемого кеша DNS между нодами в таком случае нет совсем или, даже если он и есть, то мизерный и смысла бороться за него серьезным увеличением сложности не стоило.
Теперь DoH, который ну совсем никак ни про производительность, ни про задержки, а только слом концепции, что DNS это «Control Plane» Интернет.
DoH ломает концепцию, что DNS является «Control Plane» Интернет. Внезапно DNS оказывается на «Data Plane». Это не мои слова, это Paul Vixie.
Скорости работы ни от DoT ни от DoH ждать не приходится.
По скорости, среднем в РФ у провайдеров DNS сервера медленнее гуглового сервиса, иногда в разы.
За исключением Ростелекома Северо-Западного макро филиала, DNS сервера которого работают быстрее чем Google Public DNS уже несколько лет.
Бывают еще ситуации, когда клиент может обидеться на слишком быстрое и корректное решение его вопроса.
У меня был такой случай, когда пришлось отвечать на звонок клиента и я не проявив такта и не дослушав его, не потряс бубном с пол часа, не рассказал ему насколько у него серьезная и трудно решаемая проблема сразу выдал результат.
Потом меня песочил мой на тот момент директор, объясняя, что бедный клиент мучился три месяца с проблемой, ему не смогли помочь его (клиента) три инженера, а я выставил их всех, включая его самого не очень умными людьми.
Сильно сомневаюсь, что причиной наезда стали именно эти обрывки схем.
А потому мне представляется более правильным такой вариант: адвокаты Эппла нашли повод «наехать» на человека за то, что он показывает возможность дешевого неавторизованного ремонта.
То, что Вы назвали наездом вполне могло быть творчеством конкретного сотрудника одного из юридических подразделений в Apple. Он увидел возможность и сразу же ей воспользовался. Никто не отменял желание конкретного сотрудника получить бонус от работодателя за хорошую на его (сотрудника) взгляд работу.
А могло быть (и тут Вы правы) попыткой как то зацепиться за блоггера, который по тем или иным причинам раздражает.
Но я бы не отдал тому или другому варианту явное преимущество.
После того как Apple продал свой продукт, он перестал быть ее продуктом и стал вещью принадлежащей покупателю.
Покупатель вправе поступать со своей вещью как ему будет угодно, Apple же теряет возможность и право диктовать свои условия.
Это с одной стороны. А с другой у Apple есть патенты на интеллектуальную собственность. И она может и должна ее защищать, так как именно интеллектуальная собственность является основой благополучия Apple.
Адвокаты Apple предъявили претензии к инженеру именно за распространения сведений, в которых как они считают защищены патентами на ее интеллектуальную собственность. Поэтому инженеру и понадобился юрист, который видимо порекомендовал этот ролик удалить как спорный.
Инженер воспользовался этой ситуацией, создав ее специально или случайно, чтобы получить еще бОльшую известность для своего блога. Ему стоит поблагодарить компанию Apple за столь прекрасный шанс.
Внутренние тесты показали, что быстродействие массива SC9000 превышает 360 тыс. IOPS
Мне одному кажется, что вообщем что это не так чтобы совсем много?
Возможно я ошибаюсь, но у производителей СХД обозвалась своеобразная менопауза.
С одной стороны без общей (централизованной) СХД для конкретного приложения с относительно большими объемами данных трудно стандартными средствами обеспечить HA. С другой стороны меняются подходы и часто это уже не является препятствием. А ничего (относительно) нового производители СХД предложить не могут и следствии этого мы чаще видим статьи не о новой могучей функциональности, которую может предложить данный вендор, а просто о том, что флэша и IOPS у него больше.
Или может быть в какой конкретной фиче в этой статье есть действительно новые инновации, которые влияют глобальным (просчитываемым экономическим) образом на хранение данных в СХД?
Почему то мне кажется, что программировали данный ботнет вполне себе успешные инженеры если бы не… экономический коллапс, который часть изначально приличных людей заставляет заниматься…
Это вполне может быть успешной атакой на резолвер НСДИ, в частности если схема работы в части кеширующего рекурсивного сервиса построена на иерархии: несколько резолверов и кучка форвардинг кешей, которые в них смотрят.
В теории это может быть и компроментация одного из авторитетных серверов на которых делегирован домен smotrim.ru. Внутри РФ задержка до обоих авторитетных серверов этого домена одинакова и маловероятно, что DNS кеши указанных провайдеров обращались только к одному из них. Гораздо более вероятно, что эти провайдеры в регионах, где они пострадали, все рекурсивные запросы отправляют в НСДИ.
А в Петербурге пробки перманентное явление.
Поменяете работу — если она будет в другой части города, например на другом берегу, то либо пробки, либо менять квартиру )
1) Маленькие TTL на популярных доменах не вредят телеком-провайдерам с большим количеством Абонентов. При условии того, что эти телеком-провайдеры агрегируют трафик 400+ тысяч Абонентов на сервер. Давление на кеш на таком сервере позволяет держать все популярные домены в кеше. Сервер может отвечать на запросы к популярным доменам 100% из кеша, если используются проактивное кеширование.
У телеком-провайдеров с небольшой нагрузкой на кешируюшие DNS сервера популярные домены часто вымываются из кеша, вследствии небольшого на него давления от клиентов. И проактивное кеширование при небольшом давлении на кеш уже не помогает.
2) В среднем TTL все время снижается, так как все больше ресурсов переезжает в «облака», в которых короткие TTL используются по умолчанию.
В среднем никогда не стоит делать TTL меньше 15 секунд, иначе и проактивное кеширование на стороне резолвера ISP может не успевать обновлять кеш, до того как запись умрет по TTL.
Теперь хозяин в глазах кота стал на порядок глупее! )
Теперь DoH, который ну совсем никак ни про производительность, ни про задержки, а только слом концепции, что DNS это «Control Plane» Интернет.
Скорости работы ни от DoT ни от DoH ждать не приходится.
По скорости, среднем в РФ у провайдеров DNS сервера медленнее гуглового сервиса, иногда в разы.
За исключением Ростелекома Северо-Западного макро филиала, DNS сервера которого работают быстрее чем Google Public DNS уже несколько лет.
У меня был такой случай, когда пришлось отвечать на звонок клиента и я не проявив такта и не дослушав его, не потряс бубном с пол часа, не рассказал ему насколько у него серьезная и трудно решаемая проблема сразу выдал результат.
Потом меня песочил мой на тот момент директор, объясняя, что бедный клиент мучился три месяца с проблемой, ему не смогли помочь его (клиента) три инженера, а я выставил их всех, включая его самого не очень умными людьми.
То, что Вы назвали наездом вполне могло быть творчеством конкретного сотрудника одного из юридических подразделений в Apple. Он увидел возможность и сразу же ей воспользовался. Никто не отменял желание конкретного сотрудника получить бонус от работодателя за хорошую на его (сотрудника) взгляд работу.
А могло быть (и тут Вы правы) попыткой как то зацепиться за блоггера, который по тем или иным причинам раздражает.
Но я бы не отдал тому или другому варианту явное преимущество.
Покупатель вправе поступать со своей вещью как ему будет угодно, Apple же теряет возможность и право диктовать свои условия.
Это с одной стороны. А с другой у Apple есть патенты на интеллектуальную собственность. И она может и должна ее защищать, так как именно интеллектуальная собственность является основой благополучия Apple.
Адвокаты Apple предъявили претензии к инженеру именно за распространения сведений, в которых как они считают защищены патентами на ее интеллектуальную собственность. Поэтому инженеру и понадобился юрист, который видимо порекомендовал этот ролик удалить как спорный.
Инженер воспользовался этой ситуацией, создав ее специально или случайно, чтобы получить еще бОльшую известность для своего блога. Ему стоит поблагодарить компанию Apple за столь прекрасный шанс.
Мне одному кажется, что вообщем что это не так чтобы совсем много?
Возможно я ошибаюсь, но у производителей СХД обозвалась своеобразная менопауза.
С одной стороны без общей (централизованной) СХД для конкретного приложения с относительно большими объемами данных трудно стандартными средствами обеспечить HA. С другой стороны меняются подходы и часто это уже не является препятствием. А ничего (относительно) нового производители СХД предложить не могут и следствии этого мы чаще видим статьи не о новой могучей функциональности, которую может предложить данный вендор, а просто о том, что флэша и IOPS у него больше.
Или может быть в какой конкретной фиче в этой статье есть действительно новые инновации, которые влияют глобальным (просчитываемым экономическим) образом на хранение данных в СХД?
Эммм…
Речь точно о flash-накопителях?!