Живой, независимый мониторинг глобальных систем позиционирования - Galileo, GPS, BeiDou и GLONASS. Есть данные по доступности спутников, ошибки позиционирования, мощности сигнала. Проект в самой начальной стадии, отзывы приветствуются, код можно найти на GitHub.

У Juniper на борту есть вполне полноценная справочная система. Не знаю насколько это практически полезная вещь в мире с повсеместным интернетом, а учиться в боевом режиме на таких железках не самое удачное решение. Но это должно быть лучше чем простые однострочные подсказки, которые неплохо помогают забывчивым админам вроде меня. На сайте Juniper подробное описание что к чему.

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 по списку из файла, говорят что быстрый.