📬 ISN 215: 60 Minut RTO, Wireshark Sanitizer i Granice Kubernetes

60-minutowy RTO dla DNS

Amazon Route 53 launches Accelerated recovery for managing public DNS records | Amazon Web Services

Amazon Route 53 now offers Accelerated recovery for managing public DNS records, a new business continuity feature designed to provide a 60-minute recovery time objective (RTO) during service disruptions in the US East (N. Virginia) Region. This enhancement enables customers to continue making critical DNS changes and provisioning infrastructure even during regional outages, ensuring greater resilience for mission-critical applications.

Amazon Web Services

AWS wprowadził funkcję, która rozwiązuje realny problem biznesowej ciągłości: możliwość zarządzania rekordami DNS nawet gdy region US East (N. Virginia) jest niedostępny. Accelerated Recovery gwarantuje 60-minutowy RTO dla operacji na publicznych strefach DNS.

Dla organizacji z regulaowanych branży (bankowość, FinTech) brak możliwości zmiany rekordów DNS podczas awarii regionu to showstopper dla planów DR. Nie możesz przekierować ruchu, nie możesz aktywować standby resources. Accelerated Recovery adresuje ten problem – podczas problemów w us-east-1 nadal masz dostęp do kluczowych operacji API: ChangeResourceRecordSets, GetChange, ListHostedZones, ListResourceRecordSets.

Zero zmian w istniejącym setupie. Używasz tych samych endpointów API, tego samego kodu, tych samych skryptów. Włączasz feature per hosted zone przez Console, CLI, SDK lub IaC (CloudFormation/CDK). Aktywacja trwa kilka minut. W momencie awarii Route 53 automatycznie failuje do redundantnych systemów, które obsługują te cztery kluczowe operacje.

Kluczowa różnica: to nie jest replikacja całego control plane. AWS wybrał minimalny, krytyczny subset funkcjonalności, który pozwala wykonać DR playbook – zmienić rekordy, przekierować ruch, zweryfikować zmiany.

Co musisz wiedzieć?

Bez dodatkowych kosztów – włączasz per hosted zone. Działa tylko dla public hosted zones – private zones nie są objęte (logiczne, skoro to o external DNS resolution). Nie wymaga zmian w runbookach – istniejące procedury failover działają identycznie.

Nowy proces w ekosystemie Teams

MC1189656 - Upcoming Change to Teams Desktop Client on Windows | Microsoft 365 Message Center Archive

Microsoft Teams Desktop Client for Windows will introduce a new process, ms-teams_modulehost.exe, to handle calling features separately, improving performance and startup time. Rollout begins January 2026. Admins should allowlist the new process in security software and inform helpdesk staff; no user workflow changes expected.

Microsoft 365 Message Center Archive

Microsoft wprowadza ms-teams_modulehost.exe jako proces potomny głównej aplikacji. Oddziela on całkowicie stos wywołań (calling stack) od ms-teams.exe, co ma poprawić wydajność i czas startu klienta. Proces będzie widoczny w Task Manager jako element podrzędny głównej aplikacji Teams.

Rollout rozpocznie się na początku stycznia 2026 i potrwa do końca miesiąca (wszystkie chmury: Worldwide, GCC, GCC High, DoD). Użytkownicy nie zobaczą żadnych zmian w interfejsie ani workflow – ale twoja infrastruktura musi być gotowa.

Kluczowa kwestia: polityki QoS. Jeśli masz skonfigurowane Quality of Service dla ms-teams.exe, te same reguły muszą objąć ms-teams_modulehost.exe. Bez tego połączenia mogą tracić na jakości, mimo że Microsoft obiecuje poprawę wydajności.

Kolejny punkt: security software i endpoint management. Dodaj nowy proces do allowlist wszędzie tam, gdzie obecnie masz ms-teams.exe. Dotyczy to firewalli, EDR/XDR, application control i monitoring tools. Sprawdź także DLP policies – jeśli weryfikują procesy po nazwie, wymagają aktualizacji.

Praktyczny checklist na teraz:

• Zweryfikuj reguły QoS i rozszerz je na nowy proces
• Dodaj ms-teams_modulehost.exe do allowlist w security tools
• Sprawdź monitoring i alerty związane z procesami Teams
• Brief dla helpdesku i dokumentacja wewnętrzna

Microsoft nie identyfikuje compliance considerations, ale zweryfikuj samodzielnie w kontekście swoich polityk – szczególnie jeśli macie restrykcyjne podejście do nowych procesów w środowisku.

Zmiana wchodzi szybko – masz maksymalnie miesiąc na przygotowania. Brak akcji może skutkować degradacją jakości połączeń lub blokowaniem funkcji calling przez security policies.

Cheat Sheets dla Network Engineerów

GitHub - yuriskinfo/cheat-sheets: Cheat sheets to help you in daily hands-on tasks of trouble shooting, configuration, and diagnostics with Fortinet, HP/Aruba, Cisco, Checkpoint and others’ gear.

Cheat sheets to help you in daily hands-on tasks of trouble shooting, configuration, and diagnostics with Fortinet, HP/Aruba, Cisco, Checkpoint and others' gear. - GitHub - yuriskinfo/cheat-sh…

GitHubyuriskinfo

Repozytorium zawiera cheat sheety ułatwiające codzienne zadania związane z rozwiązywaniem problemów, konfiguracją i diagnostyką sprzętu sieciowego i systemów Linux. Znajdziesz tu zestawy poleceń i przykładów dla urządzeń Fortinet, HP/Aruba, Cisco, Checkpoint oraz innych.

Sanityzacja pakietów w Wireshark

GitHub - netwho/PacketSanitizer: Quic and Dirty Packet Sanitizer (Change IP Addresses / Scrub Payload)

Quic and Dirty Packet Sanitizer (Change IP Addresses / Scrub Payload) - GitHub - netwho/PacketSanitizer: Quic and Dirty Packet Sanitizer (Change IP Addresses / Scrub Payload)

GitHubnetwho

PacketSanitizer to wtyczka do Wireshark, która pozwala bezpiecznie udostępniać pliki PCAP/PCAPNG poza organizacją. Umożliwia trzy tryby sanitizacji: usunięcie wszystkich danych w payload, usunięcie tylko danych z protokołów tekstowych (HTTP, FTP, Telnet, SMTP i innych) oraz pełną anonimizację – łącznie z IP i MAC. Wtyczka zachowuje strukturę pakietów i czas ich przesyłania, by umożliwić dalszą analizę bez ujawniania wrażliwych informacji.

Gdzie leży limit klastrów Kubernetes?