Чиновники замечательные люди, целое министерство с удовольствием рисует то что должно быть, но забывают о такой мелочи как это должно быть. Ну и сроки не соблюдают конечно, но это не только к чиновникам относится. http://minsvyaz.ru/ru/events/37299/

На этот год приходится много событий с связанных с большими обновлениями DNS инфраструктуры:

1. 8 сентября начинается обязательный учёт записей CAA https://habrahabr.ru/company/1cloud/blog/326734/, Хотя тип записи и достаточно старый, но он был не всегда и серверы DNS могут быть старее, поэтому придётся обновляться.

2. А чтобы ССА записи, как и вообще фальсифицировать DNS запросы было сложнее следует использовать DNSSEC. 11 октября в котором планируют заменить мастер ключ - KSK https://www.icann.org/resources/pages/ksk-rollover-2016-07-27-ru который уже установлен в DNS наравне со старым.

Безопасность всегда компромис с удобством, не пропускаем эти два важных события. Как минимум, стоит начать пользоваться :) Некоторые компании даже предупреждают своих клиентов об этом, вот такие они хорошие.

Сообщаем Вам, что на 11 октября 2017 года Интернет-корпорация ICANN запланировала изменения в параметре настройки безопасности корневой зоны системы доменных имен (далее-DNS), которые по их оценкам могут затронуть 750 миллионов пользователей сети Интернет во всем мире.
Предстоящее изменения затрагивает только провайдеров интернет-услуг и операторов, использующих протокол расширенной безопасности DNS – DNSSEC, предоставляющий способ аутентификации данных DNS и использующий криптографический ключ, известный как ключ подписи ключа корневой зоны (далее-KSK).
В целях обеспечения плавного процесса смены этого ключа Интернет-корпорация ICANN рекомендует провайдерам интернет-услуг и операторам заблаговременно настроить свои системы для использования нового KSK, а также воспользоваться специальной платформой тестирования, расположенной по адресу: https//go.icann.org/KSKtest, чтобы подтвердить готовность инфраструктуры поддерживать возможность обработки смены ключа KSK без ручного вмешательства.

У Cisco обновился VIRL https://learningnetwork.cisco.com/docs/DOC-33132 и наверное он хороший, а может даже очень хороший... однако у нас есть EVE-NG http://www.eve-ng.net/ и GNS3 https://www.gns3.com/, а свичи, всё равно, лучше в железном варианте собирать, прямо на столе.

Интернет, не смотря на свои размеры по прежнему сеть друзей. Фактически уже давно это не так, но основа осталась. Вступая в пиринговые отношения с кем-то из операторов, будь он хоть трижды хороший друг, или будь он очень большой и "надёжный" всегда остаётся риск нарваться на неприятности. И в первую очередь, проблемы скорее всего, будут с настройкой BGP, связанные с желанием отправить трафик по наиболее благоприятному для себя маршруту.

25 августа Google решил, что он самый главный и обьявил себя транзитным оператором для всей Японии. BGPmon это увидел. А всё вышло достаточно классически:

Провайдеры в Японии, да и наверное сотни других, чтобы Google AS15169 видел их сети в большем приоритете чем остальные, чтобы трафик шёл непосредственно в пиринг, а не через транзиты, анонсируют свои префиксы с длинными масками. Обычная практика и самый железный способ в BGP безаговорочно развернуть трафик в твоём направлении. Но Google являсь конечным потребителем, почему-то решил эти сети проанонсировать дальше, в Verizon AS701. В результате, из-за тотальной поломки основных маршрутов, которые были с гораздо более короткими масками - Интернет для Японии пошёл через Google. Как минимум маршруты через полмира не способствуют качеству, но наверное ещё и каналы подзабились. В итоге, министр коммуникаций решил провести расследование почему сайты не открывались у жителей поднебесной, в Google, может, пожурят ночного админа.

С такими друзьями и враги не нужны. Как говорится - доверяй, но проверяй, а community NO_EXPORT в этом поможет.

Если что, у нас свой BGPmon есть https://radar.qrator.net/as-rating#connectivity6/1 и даже лучше, подконтрольные ASn можно бесплатно мониторить и видеть статистику со всеми плюшками, точнее дырами, протечками и DDoSами. Они даже BIRD свой сделали https://radar.qrator.net/tools/route-leak-mitigation, умный.

Ого, GnuPG обновился http://www.opennet.ru/opennews/art.shtml?num=47090.

RIPE NCC запускает новый хелпдеск - Zendesk, всё онлайн и в облаках https://labs.ripe.net/Members/AlexBand/ticketing-and-document-management-at-the-ripe-ncc. E-mail - всё. Актуально для LIRов, станет удобнее. Хотя и так последние пару лет интерфейс круто поменялся, подстраховки в каждом поле.

https://habrahabr.ru/post/336696/ писать операционки тяжело, а реального времени ещё тяжелее. Но таки пишут и успешно.

Статья для тех кто немного разбирается, чтобы смочь оценить. Основы это всегда основы, популярную теорию на эту тему хорошо Таненбаум пишет с его "Современными операционными системами".

Миллион примеров в сети как работать с IPSEC в strongswan, а всё равно примеры на самом strongswan лучше всех. И даже если что-то не получается, включаем логи в файл, которые выключены обычно, с уровнем детализации 2 и всё становится понятно.

Сетевым инженерам достаточно уметь думать https://twitter.com/burneeed/status/902975250534514690 и telnet я бы ещё добавил. Правда, его уже и Windows выпилила, может и в самом деле не нужен.

Cisco это не только коммутаторы, но и игрушки. Сегодня всех приглашают поиграть в марсианскую жизнь айтишника, с командиром Верой.

Есть и другие. Гораздо больше их доступно членам сетевой академии.

У RIPE NCC есть замечательная возможность - получить доступ к истории объектов, включая первую или почти первую (часть данных не сохранилась) и все промежуточные версии.

Для этого придётся обратиться к whois серверу напрямую, а не через веб. Уникальный способ как заглянуть в историю, так и наблюдать в динамике за изменениями интересующих объектов, без самостоятельной обработки данных с ftp.ripe.net

Всего три команды:
--list-versions <объект>,
--show-version <номер> <объект> и
--diff-versions <номер>:<номер> <объект>

Например, посмотреть всех членов MSK-IX в октябре 2002 года:
whois -h whois.ripe.net -- --show-version 1 AS-MSKROUTESERVER

Wikileaks и Tadviser делают сенсацию из ничего. Загрузочные и резидентные вирусы, полиморфизм, сверху, наверное, ещё виртуализацией приправлено. Вполне себе массовые и обкатанные технологии. Если бы не ЦРУ в заголовке, то прямо будни вирусолога-надомника описаны.

Хотя ЦРУ надо отдать должное, оформили "Руководство пользователя" и "Руководство программиста", в лучших традициях ЕСПД. Где бы ещё ТЗ и ТП посмотреть?

Оооочень длинная статья о Juniper и как его дружить с зеркалированием трафика. Классический подход этого вендора - всё instance, работает и в этом случае.

RIPE NCC радует, по старинке в почту, что ему отсыпали /20 IPv4:

Dear colleagues,

On 1 September 2017, the RIPE NCC and other Regional Internet Registries (RIRs) were each allocated the equivalent of a /20 of IPv4 address space from the Internet Assigned Numbers Authority (IANA). The RIPE NCC received the following IPv4 address ranges:

160.20.214.0/23
160.20.248.0/23
160.238.60.0/23
160.238.96.0/22
192.145.224.0/22
204.48.32.0/23

Капля в море, но однако до сих пор LIR могут получить последние /22, в том числе и все новые LIR.

https://twitter.com/kmcnam1/status/904557942568919040 - горячий кофе и салфетки, чтобы суровые будни CCIE не были такими суровыми :)

Помимо всем знакомых RFC IETF поддерживает базу документов под общим названием BEST CURRENT PRACTICE - BCP. Их всего 210 на данный момент. Документы призваны раскрыть вопрос как же применять RFC лучшим образом.

Например, что обязательно надо фильтровать входящий с границы сети трафик BCP38, BCP84, или как использовать синонимы в DNS BCP17, или сколько же IPv6 отсыпать в одни руки BCP157 и BCP198.

Многое уже сидит в подкорке и воспринимается как заявления капитана очевидность, но конечно же это всё не берётся из ниоткуда.