Не доверяйте никому в Интернете, даже если это ваш собственный роутер. TP-Link перехватывает DNS запросы из благих побуждений, конечно, и для этого ему даже не надо быть роутером, достаточно выступать в роли точки доступа, главное чтобы трафик проходил сквозь него. Проверил у себя в домашней сети, отвечает достаточно невинно - при запросе tplinkap.net локальным адресом устройства, но сам факт перехвата всего DNS трафика напрягает и ещё как.

Введение в настройку Firewall в Junos. На самом деле это очень понятный и логичный инструмент и при возможности практики изучаемый самостоятельно достаточно быстро, тем более если был опыт с другими вендорами. Сравнение с ACL не совсем правильно, хотя и понятно как устоявшийся синоним механизма фильтрации трафика. Но ACL в контексте Cisco это не более чем список IP, протоколов, портов, флагов с привязанным к ним признаком разрешения или запрета. Удобное обобщение уже с которым делается сопоставление во многих возможных механизмах - политиках, route-map, access-group.
Поэтому Junos firewall по сравнению с ACL это космический корабль, где можно практически всё, а не жалкие no <line number>, remark <bla bla bla> , <line number> acl rule, для того чтобы просто поправить ошибку в комментарии. Именованные правила, вставка, переименование, удаление в любом месте, временное отключение, масса возможных сравнений и действий, несколько наборов фильтров одновременно списком для одного интерфейса. И многословность тут только в плюс, совместно с иерархическим конфигом позволяет меньше ошибаться, а следовательно реже ездить поднимать доступ напрямую с консоли у нечаянно заблокированных устройств.

Сравнение DNS over UDP, TCP, TLS, HTTPS и QUIC. Без шифрования сейчас не жизнь, поэтому лучший - DNS over QUIC, за счёт более быстрой установки сессии, без этого обычный DNS по UDP побеждает. В остальном всё плюс минус одинаковое. Поэтому сравнили ещё скорость загрузки страниц различных сайтов, там уже есть варианты что DoQ побеждает и UDP за счёт количества запросов, что нивелирует начальную задержку нужную для установки сессии. Впрочем, в этих случаях и DoH неплох - при 100500 DNS запросах на одной странице, вероятно, разницы не будет совсем. В среднем же DoQ немного медленнее UDP в этом тесте, но в итоге всё зависит от сайта.

Будьте последовательны в поиске и не спешите (если это возможно), тогда результат обязательно будет. Статья про поиск и решение проблемы с медленной передачей через Интернет, где в конечном итоге проблема была в Интернет, там определяется конкретное место, но это место далеко за зоной ответственности автора. Дампы, мониторинг и понимание принципов работы протоколов - рулят.

Раз уж несколько раз на глаза попалось, да и коллеги скинули ссылку на Хабр, вспомню как мы Cisco SCE «чинили». Всё как в статье - работала, перестала. При загрузке в консоли попадаем в U-Boot, видим что с ФС проблема на SD карте. Ну и потыкав немногочисленные кнопочки которые там были я затираю кусок памяти с этим самым U-Boot. Из того что осталось команды копирования и записи в память и диагностические тесты.
Благо в нашем дружном коллективе были люди которые лучше меня понимают в embedded, спасшие ситуацию написав код который копировал кусок памяти побайтово из рабочей железки, тут нам тоже повезло что она была, сохранив его в файл. И потом из этого файла также побайтово используя встроенный набор команд из того интерфейса что был доступен записывая кусок памяти в нерабочую. Про скорость копирования я говорить не буду. После того как мой косяк был поправлен, дальше перенесли образ флешки с рабочей на нерабочую, новую флешку мы купили. Но тут уже было сильно проще, на ней Linux и все можно было делать с обычных компов. А уже потом выдохнули и расслабились. Нам очень сильно повезло, тыкаться в слепую методом обезьянки и решить проблему. Впоследствии наши образцы помогли ещё некоторому количеству пострадавших от таких же проблем с флешками.

А теперь самое главное к чему я все это, у нас практически никогда не было никакой внятной поддержки даже для железок цену которых страшно называть. И такая ситуация не считалась критичной и мы далеко не одни так считали. То что могли чинили самостоятельно, ни для кого никогда не было никаких запретов вскрыть и перепаять блоки питания или память поменять на побольше. То что сейчас в такой ситуации оказались все - печально, я начал привыкать к поддержке 24/7 по любой мелочи. Но это не смертельно и для многих совершенно обычно. А уровень локальной поддержки подтянется, уровень инженеров которые смогут на месте чинить всё не обращаясь в ТП тоже.

Эмулятор x86 из браузера с WebAssembly с несколькими готовыми образами операционок, свои тоже можно использовать. Исходники доступны.
Напомню ещё про PCjs, там набор железа и софта побольше будет.

Если вы владели и использовали каким-то ресурсом в Интернет: доменным именем, IP адресом - то можете быть уверенным что освободив его, запросы на него будут приходить ещё очень и очень долго. Как, например, у Dataplane, новость "DNS Query Anomalies". Они конечно написали куда надо и даже заверили что никак этой ситуацией не воспользовались, но на такое поведение полагаться нельзя. Напротив, стоит предполагать что каждый утраченный вами ресурс будет использован, как минимум для сбора чувствительной для вас информации. Не теряйте свои ресурсы, а освободившиеся попридержите и помониторьте что на них прилетает.

И Radius тоже через TLS, черновик предложения стандарта протокола уже реализованного автором во FreeRADIUS.

Концепция систем - "Всё это X", с примерами и выводами. Ещё больше примеров, без выводов, показывающих насколько данная концепция популярна.

Лаба Segment Routing на Nokia SR OS с возможностью не только разобраться с SR и Nokia, но и с инструментом для запуска всего этого добра containerlab.

Ограничивайте доступ к консоли контролируемых вами устройств настолько насколько можете, пусть даже это будет не очень удобно. Автор сосредоточился на WEB интерфейсах и WEB API, с конкретными примерами CVE, как более сложных системах которые сами по себе могут иметь уязвимости. Но в целом дело конечно не в этом. В текстовой консоли тоже можно наворотить дел если получишь к ней доступ.

Список лучших конференций для сетевиков из которого я узнал про ONUG, AWS re:Invent и WLPC (почти случайный отзыв о мероприятии). Наши Yandex.NextHop и Пиринговый форум уже совсем скоро в очном формате после долгого перерыва, хоть и не попали в список 7 лучших, достойны посещения. Программы представлены, регистрация открыта.

Russ White в 7 небольших заметках (1, 2, 3, 4, 5, 6, 7) растянутых на полгода, которые можно было объединить в одну, рассказывает про основы приватности с точки зрения сети - вас могут вычислить по IP. Поэтому сетевым инженерам стоит относиться к IP адресу и к любой собираемой технической информации как к персональным данным клиента/абонента, утечка которых не сильно отличается от утечки паспортных данных и ничем хорошим не кончится. Вас взломают, это дело времени, готовьтесь к этому.
А вот с точки зрения нашего государства у вас нет конфиденциальности в Интернете, сессии с вашим IP регистрируются и хранятся, а с приходом закона Яровой ещё и куча метаданных сверху. Интернет по паспорту уже давно с нами.

Как работает Wine - попытка объяснить это просто, но куски кода, элементарные, на ассемблере и Си увидеть придётся. На самом деле, то что вообще у нас есть Wine при всей сложности современных ОС и Windows особенно, можно только поражаться.

Хороший обыгрыш известной шутки - это наша страшная тайна, static route ещё и NAT. Не знаю как у вас с твиттером, поэтому картинкой, стащил отсюда.

Подарок доставлен и теперь я тоже в деле. Это не с Kickstarter, там я поддерживал лишь морально. Пока не включал стараясь максимально растянуть удовольствие. Надеюсь, что смогу поковырять поглубже готового функционала и что мой SOC отнесётся с пониманием ;). А ещё я очень рад что у @zhovner_hub и всей команды всё получилось.

Интересное исследование степени централизации DNS: https://www.potaroo.net/ispcol/2022-11/dns-ctl.html

TL/DR: рекурсивный DNS в целом не централизован, но открытые рекурсивные DNS высоко централизованы и Google имеет больше двух третей в этом сегменте (на картинке - централизация публичных рекурсивных DNS по экономикам). Сервис авторитетных DNS серверов умеренно централизован, четыре крупнейших провайдера (Amazon, Google, Cloudflare и Akamai) контролируют около 57.3% доли.

Всякий раз, ну почти, когда приходится обращаться в тех.поддержку вас попросят перезагрузить роутер. И в общем, совсем не имеет значения, что ваш роутер это вовсе не мыльница с WiFi и даже не Микротик, а вы вовсе не пользователь домашнего Интернета. Такое встречается не только между провайдером и клиентом, но и между провайдерами тоже. Причины просты, исключить ошибку той самой мыльницы с другого конца кабеля и это работает в случае усреднённого массового сервиса, но даже в этом случае может сыграть против. Когда выученный пользователь при любых проблемах перезагружает роутер провоцируя, например, массовое обращение к системе авторизации и загоняя аварийную ситуацию в ещё больший тупик.
Не берусь судить, но, наверное, в среднем массовый корпоративный клиент такой же пользователь с мыльницей, но кому как ни провайдеру об этом должно быть известно, чтобы отделять мух от котлет и не просить перезагружать маршрутизатор на 100500 подключений, ради проверки одного своего упавшего канала.

А как бы вы убивали Интернет? Вот один из способов, комментарий тоже прочитайте. И я бы не рассматривал это с точки зрения только IPv6, где проблему можно сделать потому что каждый обладает очень большим адресным пространством. В IPv4 - массовый и легитимный анонс всего своего адресного пространства в префиксах по /24 может привести даже к более плачевным результатам, потому что размер BGP таблицы маршрутизации уже очень большой и лишние 100К могут сделать дело намного эффективнее, чем лишние 500К в IPv6. Сейчас префиксов /24 в IPv4 таблице чуть меньше 60%, а /48 в IPv6 чуть больше 45% так что есть что деагрегировать. Смотрим за статистикой @FullViewBGPbot или @bgp_table_bot и не забываем поставить лимиты и триггеры там где это необходимо.

Про только файрволлы могу подтвердить, собственно, как ни странно, это наверно самый из понятных для условного ибшника механизмов - доступ открыть/закрыть и для чего. И больше всего раздражающий сетевика, кстати. Могу предположить, что если в организации и есть процесс проверки конфигурации сетевых устройств, то он базируется на каких-то из требований сертификации, тех же ISO 27000 или PCI DSS, где много про доступы и ограничения, отсюда и файрволлы.