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

Дошла очередь до переезда host-correct.ru, теперь на связке PowerDNS dnsdist и pdns_recursor. Lighttpd оставил по большей части для другого, но оставил как прокси. За всё время перепробовал, если помните, и Unbound, и Knot, и Bind, и почему-то незаслуженно проходил мимо PowerDNS. Очень продуктивное решение в стиле unix way, разделить собственно DNS и формы доступа к нему: DoT, DoH, DoQ и остальные - вынести в другой инструмент. Отдельное личное большое спасибо за эту наводку Андрею Пазычеву, обязательно смотрим его доклады на Linkmeetup. Это лучшее решение из всех которые я использовал.
Для Munin не нашёл готового плагина DNSdist, но это я допишу. IPv6-only для DNS резолвера тоже не летит, многие не имеют IPv6 NS записей, поэтому добавил ещё IPv4. Это немного отрезвляет, при всём моём оптимизме, попробовать развернуть что-то IPv6-only.
host-correct.ru свободно доступен для использования DoH и DoT, логирование запросов выключено, гарантий по надёжности и производительности никаких. Я вижу что никто им не пользуется, кроме меня, даже боты брезгуют по TLS заходить, но если вдруг понадобиться и нет своего, а другие не хочется, то пожалуйста.

Не написал, напишу, если что-то заметили что не работает как должно - пишите, в меру своих сил и средств и оперативности всё поправлю. Я рад, что внимательный подписчик, спасибо за это, уже нашёл проблемы в цепочке сертификатов для DoT, и теперь работает как надо.

Отчёт Backblaze (Cloud Storage) за первый квартал этого года по трафику. Интересно смотреть, в разрезе США особенно, какой тип трафика куда притягивается. Калифорния побеждает по CDN, облакам, облакам для ИИ (Neocloud). За рамками США, Neocloud больше всего в Финляндии, CDN в Нидерландах, а хостинга в Германии. И вся эта картина достаточно подвижная, в рамках США точно, за исключением трафика провайдеров, где всё стабильно.

Использование веб инструмента IHR для мониторинга BGP, на примере разбора инцидента с ROA Северной Кореи. Доступность исторических данных делает этот ресурс удобным для анализа. Внутри, знакомые RIPE Atlas, RIS, PeeringDB. Проект живёт достаточно давно и присутствует на GitHub.

Свежее изменение в RIPE DB, теперь в объектах организаций видно регистрационный номер в своей стране - атрибут reg-nr. Для России это ОГРН и теперь проще сопоставить объекты в RIPE DB со списком лицензий РКН, например.

А Cloudflare сделали просмотрщик MRT файлов (дампов BGP) прямо в браузере radar.cloudflare.com/routing/mrt-explorer

Жизнь сетевика be like.
Энтерпрайз: Таскаешь виланы между Hub и Spoke
Датацентр: Таскаешь виланы между Spine и Leaf
Провайдер: Таскаешь виланы между PoP и PE
Интегратор: Таскаешь не свои виланы
Netops: Таскаешь виланы на Python
Облако: Таскаешь виланы между Pod
Neocloud: "Действуй как CCIE, протащи виланы, не ошибайся, объясни результат понятно ребёнку"
Вендор: Наши виланы самые лучшие
IEEE и IETF: Мы придумали новый способ таскать виланы

Получаем код V-SOL OLT через гугление, в забытом, но открытом web каталоге, а дальше анализируем его и находим много уязвимостей и причин бояться за своё оборудование. В конце, автор даёт несколько очевидных советов по ограничению доступа, смене паролей, отключению неиспользуемых функций и других, а также говорит, что ещё много чего можно накопать. Не так эпично как с RedBack, случился неожиданный open source аудит.

Поиск проблем с прохождением трафика между двумя Juniper маршрутизаторами, без подробностей, но с упоминанием терминов и задействованных механизмов. Виной всему оказался фильтр трафика, но не сам по себе, а из-за своего большого размера, на прохождения которого тратилось слишком много времени.

Свежий RFC 9972 определяет больше параметров которые можно получать с помощью BMP и короткий обзор где это пригодится.

А как с BMP справляются в Akvorado. С версии 2.2 - лучше, а в будущей 2.4 - гораздо лучше.

Пока обсуждали в чатике аварию с DE, добрались до проблемы стандартных ограничений BIND в 50 итеративных запросов, которых катастрофически не хватает уже ни для чего, с учётом А, АААА, и DNSSEC записей. Даже если забрать копию корневой зоны себе, а не перебирать серверы, всё равно не будет хватать, до тех пор когда всё нужное не окажется в кеше. Уже закрытое issue в BIND GitLab.
К вопросу о простоте DNS, как и BGP, которая позволила добавить в них столько много дополнительных вещей, что они уже вываливаются наружу.

Как изменилось соотношение количества префиксов в BGP по слепкам из моего @FullViewBGPbot, в основном по данным коллектора RRC0, за последние четыре года. Доля /24 IPv4 растёт с 59% до 63%, соотношения между префиксами сохраняются. Но последнее время стало заметно, что доля /23 тоже стала расти, и может быть, в ближайшее время /22 лишаться своего второго места. Предположу, что /22 стали разагрегировать на продажу или для использования на нескольких площадках.

В IPv6 картина с /48 стабильно крутится около 45-46%. Но куда заметнее чем в IPv4 виден рост долей /40 и /44 префиксов, которые, вероятно, тоже скоро вытеснят /32 со своего места. Это не может быть связано с дефицитом адресов, возможно, с более широким использованием механизмов управления трафиком и ростом популярности IPv6. А ещё можно увидеть как /47 префикс сменяет /29, который мы больше не видим среди первой шестёрки, хотя стоит отменить, что сумма долей всех других префиксов вместе взятых занимает второе место. В IPv6 куда больше вариантов делить своё адресное пространство.

Пятничное. Ошибки при работе с ИИ, заголовочный файл. Там же по ссылке аналогичный, но для людей, написанный 10 лет назад.

TTL (Hop Limit в IPv6) важная штука, решающая проблему колец маршрутизации и позволяющая понимать пути следования пакета при решении проблем. Правда, как и всему в Интернет, не стоит слепо доверять тому что вы видите, потому что многие TTL перезаписывают, что мешает исследователям. Поэтому они всех посчитали, а с AT&T разобрались отдельно. В причинах - MPLS, баги, желание скрыть внутреннюю структуру.

Я почему-то думал что уже давно никто не доверяет ни IP адресам ни MAC адресам как средству идентификации устройства, поэтому проблема случайных MAC адресов, внедрённая разработчиками ОС, должна была пройти незаметно. Но до RADIUS такое поведение докатилось только сейчас и в качестве выходы из ситуации предлагается новый атрибут Persistent-Device-Id, который не требует модификации протокола, а только корректного заполнения из сертификата выданному устройству. Наличие сертификата устройства подразумевает корпоративную среду и централизованное управление, где проблему можно решать многими уже доступными способами, начиная от запрета смены MAC адресов, заканчивая агентом установленным в систему.
Кстати, домашние провайдеры, если не используют PON, где привязка идёт к ONT, или PPPoE где у нас логин с паролем, перекладывают ответственность привязки и не смены MAC адреса на абонента, заставляя его каждый раз подтверждать доступ логином паролем на веб портале при смене устройства подключенного к сети. Некоторые и этого не делают, идентифицируя абонента привязкой к интерфейсу своего оборудования, если уверены, что он не может внезапно смениться. Сертификаты, впрочем, здесь тоже применимы, если провайдер выдаёт и привязывается только к своим устройствам, но пока у нас не так.

Статистика Google по использованию IPv6 больше 50% дала повод многим написать очень много восторженных отзывов, действительность куда более приземлённее. Статья из этой серии, что ваш сайт станет быстрее с IPv6, если надо повлиять на человека не вполне погружённого в тему. Но даже в этой статье видно что только 30% сайтов имеют поддержку IPv6, среди популярных больше, но это все те же 50%. Не забываем что Интернет это не только сайты. В любом случае, процесс уже не остановить, поэтому внедряем, но быстрее от этого ваш сайт, скорее всего, не станет.

В большинстве стран, большинство пользователей использует DNS резолверы предоставленные провайдером или другие локальные. А если не используют их, то скорее всего Google или Cloudflare. А вот с точки зрения авторитетных DNS, картина уже другая и многие, вероятно, используют DNS предоставленные хостером, а это чаще всего Amazon, Google и Cloudflare - на троих больше 40%.