AntiMalware•July 14, 2026•🇷🇺Translated from Russian

t.me Domain Restored in DNS After Sudden Outage, But Full Recovery for Telegram Links May Take Up to 24 Hours

The short domain t.me has been successfully restored in the DNS after the .me registry removed the restrictive serverHold status that had rendered it unreachable for users worldwide.

According to the registry, DNS records for the domain have been reinstated, which means links in the format t.me should once again resolve correctly in web browsers. However, because DNS information is cached by internet service providers, corporate networks, and public resolvers, the change will not appear instantly for every user. Full propagation may take as long as 24 hours depending on individual cache lifetimes.

The incident began when the domain was abruptly removed from DNS at the registry level. A serverHold status appeared in the WHOIS record—an action that can only be taken by the registry operator itself rather than a regular registrar. As a direct result, short Telegram links stopped working globally, even though the messaging service itself continued to function without interruption.

In anticipation of a prolonged outage, Telegram proactively began replacing t.me links with the longer telegram.me format inside its own applications. While older t.me addresses still opened correctly when tapped within the messenger, any attempt to access them through an external browser led to a resolution failure.

The precise reason for the sudden application of the serverHold status has not been disclosed. It remains unclear whether the event was caused by a technical malfunction, a legal or regulatory request, or a deliberate manual decision by the registry operator.

With the domain now formally returned to active status, the only remaining step is for DNS servers across the internet to refresh their caches and begin serving the restored records to end users.

Related articles

Habr•Other

Secure Boot on Arch Linux: Enabling Protection for UKI Without Replacing Factory Keys

A detailed guide explains how to configure Secure Boot on Arch Linux for Unified Kernel Images without replacing the motherboard's factory keys or relying on Microsoft certificates. The author chose the minimal-intervention approach of adding a custom key to the existing DB section via the UEFI interface instead of using sbctl enroll-keys or shim. The process begins with backing up existing keys to a FAT-formatted USB drive directly from the BIOS menu. New keys are then generated using sbsigntools and openssl, converted to DER format, and enrolled through the ASUS Prime 790-P UEFI interface. A post-hook script for mkinitcpio automatically signs the UKI after every kernel update, ensuring the entire unified image remains protected. The method preserves the original Microsoft and vendor certificates while adding only the user's own signing key.

Habr•Other

What Server Logs Reveal About Attackers: Analyzing Suspicious Requests on Linux

Server logs provide critical insights into potential intrusions by recording events from the operating system, SSH authentication, and web applications. The guide explains how to examine Linux system journals with journalctl, review authentication logs on Debian and RHEL systems, and inspect Nginx access logs for unusual HTTP requests. Analysts learn to identify patterns such as rapid failed login attempts using multiple usernames from a single IP address, which may indicate brute-force or automated scanning activity. The article also covers counting the most active IP addresses with awk and sort commands while stressing the need to compare findings against normal traffic baselines. Additional recommendations include logging structured security events in JSON format with fields for timestamp, user ID, resource, and outcome, following OWASP guidelines. The text warns against storing sensitive data like passwords in logs and highlights limitations such as possible log tampering or unsynchronized server clocks. A practical seven-step investigation plan helps responders preserve evidence and verify hypotheses before taking action.

Habr•Other

UserGate Details FPGA Acceleration to Turbocharge Next-Generation Firewalls

UserGate product manager Pavel Molodan explains why adding security features like IDS/IPS, SSL/TLS inspection, and application control turns a high-performance NGFW into a bottleneck. The company outlines four groups of acceleration methods, with a focus on FPGA-based hardware offloading for packet parsing, firewall rules, NAT, and encryption tasks. Research from 254 respondents shows strong demand for these functions in data center B2E segments at 50-200 Gbit/s. Experimental platforms including Katun-2 PCIe cards and the FG system demonstrate concrete gains, such as scaling IDPS from 5 to 90 Gbit/s and achieving 85 Gbit/s firewall throughput on EMIX profiles. FPGA delivers microsecond latency and better energy efficiency compared with CPU-only designs while preserving full NGFW functionality for elephant flows.

Habr•Other

Curator Reveals Detailed Architecture of Its Network Filtering System After October 2026 Outage

Curator published a technical post-mortem analyzing the 38-minute outage that affected its entire traffic filtering network on October 8, 2026. The company operates nine filtering sites across Russia, each containing multiple nodes connected via high-performance switches to upstream providers. Traffic is isolated using two VRF contexts—external for inbound dirty traffic and internal for cleaned traffic—ensuring sequential processing through the protection system. Each node runs a custom Linux kernel firewall and a watchdog service that monitors BGP sessions to detect failures and remove unhealthy nodes from rotation. Centralized configuration management via CControl allows rapid rollout of rules but also introduces systemic risk when faulty changes propagate across all nodes. The post-mortem emphasizes the need for isolation, staged deployments, and independent recovery mechanisms in large-scale filtering infrastructures.