Firefox собирается включить DNS over HTTPS по умолчанию. И всё бы ничего, но этим DNS будет Cloudflare. Новость отсылает нас к дискуссии по безопасности и приватности DNS которая была на FOSDEM в феврале и которая подробно разбирается в блоге Powerdns. Суть та же, что и во многих других случаях, когда мы имеем один сервис на всех - риски потерь или злоупотреблений сосредоточенными в одних руках данными слишком высоки. DoH позволяет скрыть запросы к DNS, но не от того кто держит этот сервис, поэтому децентрализованность терять не много кому хочется.
Firefox, кстати, предлагает решение как отключить DoH совсем, в случаях когда оператору или в корпоративной среде, внутрь DNS стоит заглядывать, как раз для той самой безопасности. Но это вернёт нас в состояние - как сейчас, а хочется избежать подглядывания и одновременно не дарить все свои данные какому-нибудь облачному провайдеру.

У RIPE NCC совсем скоро будет своя сертификация, сейчас пилотный вариант с RIPE Database Associate. Записываться - тут, если знаете зачем. Всё онлайн, но под строгим присмотром.

"Количество префиксов в «выгрузке» превысило количество их в Full View". Это если брать в чистую, но на самом деле такая ситуация уже достаточно давно, ввиду того что приходится подставлять несколько адресов на один ресурс (потому что DNS) и число это уже сильно больше 900 000. Это проблема.
Такое количество префиксов уже в ближайшее время сведёт на нет некоторые относительно дешёвые системы блокировки на основе маршрутизации в систему фильтрации только нужного трафика, потому что два или три миллиона адресов, а может и пять просто не влезут в таблицы маршрутизации. Так что волей не волей, а придётся искать такие которые через себя будут пропускать весь трафик или большую его часть, в разрыве или зеркале, но это уже не важно. Отсрочить конечно можно попытаться экономя на реальной таблице маршрутизации и выключив настоящий Full View или сократив его, но это лишь отсрочка.

​Все же знают что в серверной можно прятать пиво, прохладно и посторонние не ходят. А можно постараться и сделать целый автомат для смешивания коктейлей из Cisco. Собственно от Cisco, сильно похожей на WS-2950G-24, там остался только корпус и питание, но выглядит вполне неплохо. Можно конечно поработать над внешним видом и стилизовать трубки под патчкорды, тогда точно в серверную очередь выстроится на частные экскурсии ;)

P.S. Большие порты справа - гигабитные под GBIC, мы такие даже в паре мест ещё используем. Так что и такие агрегаты могут работать в 2019 по прямому назначению.

Ubiquiti сделала свой speedtest, есть серверы в Москве и Петербурге. Показывает адекватно, выглядит минималистично.

Плюс минус так и есть, при этом большую часть трафика можно забрать с ближайшего крупного IX где есть Google и Mail, которые охотно отдают трафик в общий пиринг. Онлайн видео делает погоду, торрентов скоро совсем не видно будет.

Драйвера можно писать на многих языках программирования, на всех популярных - точно. Всё зависит от поставленной задачи. Но по скорости всех побеждает Си, как минимум при написании драйвера для сетевой карты. На пятки наступает Rust и Go не очень далеко. Все исходники можно посмотреть на GitHub, включая сами драйвера и инструменты тестирования.

Любимый многими Protonmail включили у себя DANE. Написали сейчас, но сделали ещё в августе.

Лонгрид от ARIN для программистов (и всех кто себя ими считает) на тему разработки приложений с поддержкой IPv6. Охвачено много тем, примеры не забыты.

https://www.arin.net/resources/guide/ipv6/preparing_apps_for_v6.pdf

Это фундаментально, можно включить конспиролога и предположить что вскрыли закладку. Но скорее всего количество исследователей симкарт, на порядки меньше чем например, Windows, поэтому и пропустили (никто не искал). Симкарта - процессор, как и тысячи других процессоров вокруг, скоро в каждой вещи. Вопрос только сколько в них уязвимостей ещё не найдено.

Этим летом мы потеряли двух админов, которые ушли в программисты. Ушли в соседний отдел, но всё же мы потеряли двух хороших, настоящих админов с прокачанными телеком навыками. Таких в наших краях не сразу и найдёшь. Один теперь занимается автоматизацией и интеграцией сетевых устройств во все наши системы управления, мониторинга и анализа. Получилась модная сейчас эволюция о которой все говорят. Второй в JavaScript ударился, в провайдере этому место тоже есть, но от админства совсем далеко.

А так как сегодня праздник всех настоящих программистов, то поздравляю всех кто был, есть или хочет ими стать, особенно двух этих товарищей с праздником - удачи!

ICMP богатый протокол и имеет в своём распоряжении, например, механизм синхронизации времени. NTP победил, но то что осталось позволяет получить много чувствительной информации об узле который отвечает на запрос, включая геолокацию с точностью до часового пояса. Обо всём об этом в исследовании представленном на конференции PAM 2019.

Если подходить к безопасности комплексно и серьёзно, то типы 13 и 14 ICMP которые отвечают за запросы и ответы timestamp, можно безболезненно запретить в своём фильтре, если за вас это не сделала уже операционная система, так как рабочих вариантов их использования в настоящее время не существует. При этом, согласно приведённым данным, больше 2 миллионов узлов ответили на запрос timestamp, а это около 15% из всех опрошенных. Можно взять nmap, который широко использует данный тип запроса и убедиться.

​На Chaos Constructions 2019 меня не было, но значок с Free Software меня нашёл благодаря хорошему товарищу который всё видел собственными глазами и передал привет от Ричарда Столлмана. А в довесок ещё несколько стикеров с логотипами и страшилками про то как за нами следят.
Значок большеват на мой вкус, но обязательно буду носить пока ещё тепло, прицеплю на свой свитер.

Суть вчерашних обсуждений в очень многих тематических чатах.

Джон Гилмор (не музыкант, а ex-Sun, соавтор BOOTP, основатель EFF) сотоварищи решили, что что-то много IPv4 адресов простаивает. А именно, 0.0.0.0/8, 127.0.0.0/8 (кроме 127.0.0.0/24), 225.0.0.0/8 - 231.0.0.0/8, 240.0.0.0/4. И надо их превратить (https://netdevconf.org/0x13/session.html?talk-ipv4-unicast-expansions) в обычные global unicast.

Патчи для линукса вышли. Это некоторым образом удовлетворяет требованию running code, так что останется rough consensus от IETF.

127.0.0.0/8 мне лично кажется слишком радикальным. А 240.0.0.0/4 могут и начать раздавать, это 16 /8, плюс 225.0.0.0/8 - 231.0.0.0/8 - это ещё 7 /8. 23 префикса /8 - это по четыре префикса на один RIR. Среднее время расходования /8 одним RIR, судя по данным https://ipv4.potaroo.net/ — от 6 до 12 месяцев. То есть, если предположить, что это пройдёт IETF, будет поддржано вендорами, ICANN, RIR, это оттянет текущую ситуацию на 2-3 года.

​В Oracle сделали суперкомпьютер, тут скорее как синоним кластера, самого большого из Raspberry Pi. Чуть больше описания с фотографиями на servethehome.com. Параметры производительности не приводятся, но приводится количество затраченных материалов.

40Гбит/c по воздуху, уже можно. Точнее 4 по 10Гбит/c на расстояние в 11км. В статье не так много технических деталей, но есть история вопроса.
Лучше резерв на радиолинке чем никакого, тем более гигабиты/c можно получать достаточно легко в пределах нескольких километров. Хотя такой резерв доставляет больше мороки, особенно тем кто всё время с кабелем работает.

Проверщик на живость URL по списку из файла, говорят что быстрый.

MANRS собрали в одном месте статистику по проблемам и готовности участников интернет отвечать за свои сети, называется observatory.manrs.org. Соответствие данных IRR действительности, покрытие RPKI, фильтрация, спуфинг, количество инцидентов с маршрутизацией. Можно смотреть по странам и по RIR, есть история и сравнения. Наверное, когда все примут соглашения MANRS, то все графики будут зелёные, но пока не так. Почитать что к чему, большое спасибо за ссылку от нашего подписчика, можно на arstechnica.com.

Yandex молодцы - включили проверку по RPKI, скоро у всех. Может расскажут на Nexthop, в программе есть доклад про безопасность в BGP.