Internal DNS as Control Plane: Why Resolvers Matter More Than They Seem
Cloudflare announced the general availability of Cloudflare Internal DNS on 20 July 2026 for corporate clients of Cloudflare Gateway. The vendor placed public and internal DNS next to a protective resolver and described the system through three objects: internal zones, views, and resolver policies. This is not a new DNS standard, yet the architectural framework proves useful because it forces separate descriptions of data, audiences, and response-selection rules.
Most hybrid infrastructures run five simultaneous DNS layers. Public authoritative DNS serves the internet, internal DNS lives in directory services, cloud DNS holds private zones in multiple consoles, protective DNS applies gateway policies, and platform DNS handles container discovery. Each layer has its own management tools, TTL habits, change logs, and owners. When one layer is updated and another is forgotten, symptoms appear as balancer problems, VPN faults, or application slowdowns.
The article distinguishes the data plane from the management plane. The data plane carries the query itself through recursion, caching, and authoritative answers. The management plane answers which zones exist, which records are authoritative, which audience sees which view, which queries are blocked or logged, and how changes propagate with audit trails.
Three objects connect context to authoritative data. An internal zone stores records that must never be visible to public authoritative servers. A view groups internal zones so that resolver policy can return different answers for the same name to different audiences such as office staff, contractors, build pipelines, or test environments. Resolver policy routes the query to the correct view, an upstream server, or public recursion and can also block or log requests.
Client devices reach the corporate resolver through DHCP in offices, VPN tunnels for remote workers, local forwarders in branches, or explicit configuration on servers. Container clusters often run their own resolvers and must forward corporate zones outward. Any device that bypasses the corporate resolver breaks the management plane, leaving only documentation instead of control.
Changes must travel through a single, auditable path. Cloudflare routes console, Terraform, and API calls through one DNS Records API that validates, stores, replicates, and invalidates cache entries. The recommended pattern is infrastructure-as-code or API client to validation to durable store to replication to cache management to audit log. Manual edits on individual servers or separate consoles for network and cloud teams create independent states that later produce resolution conflicts.
Public authoritative zones remain outside internal views. Private zones must never be delegated to public name servers, and zone transfers must be restricted by strict access lists. When a record is absent, the resolver policy decides whether to return a negative answer or fall back to public recursion; sensitive internal zones should return negative answers explicitly.
In zero-trust models, DNS can limit network reconnaissance, surface anomalies earlier, and link name requests to user or device context when the platform supplies that context. Groups such as external contractors can receive views without production zones, while devices lacking disk encryption receive only update and management names. DNS logs become an inventory of user and system behavior that complements, but does not replace, application authorization and network controls.
Related articles
OpenAI Releases GPT-6.1 Terra: Cost-Effective Model Focused on Computer Control, Image Analysis and Practical Automation
OpenAI has launched GPT-6.1 Terra, a new model positioned between its high-end GPT-6 Astra and more affordable options in the GPT-6 family. The model emphasizes real-world computer interaction, visual understanding of documents and interfaces, and reduced error rates rather than raw reasoning benchmarks. It supports a 1.05 million token context window, image inputs, and tool use through the Responses API while cutting input token prices by half compared with its predecessor. Published benchmarks show substantial gains on Terminal-Bench 4.0, OSWorld 2.1 and Agents' Last Exam, with error rates dropping sharply at both low and maximum reasoning levels. OpenAI stresses that the model still requires human oversight for high-stakes actions and does not directly process audio or video. The release targets developers and enterprises seeking reliable automation of repetitive multi-step tasks at lower cost than flagship models.
Yandex Black October: How Architectural Flaws and Capacity Mismanagement Turned Data Center Losses Into a 11-Day Fintech Coma
In October 2026 three Yandex data centers in Central Russia were physically destroyed within days, triggering the collapse of Yandex Cloud and multiple core services. Between the first and third site failures engineers had 74 hours to restore quorum and rebalance workloads yet failed to do so because Control Plane components remained tied to the lost zone and spare capacity had been eliminated to cut costs. Core banking and BNPL systems entered Read-Only mode after losing quorum, forcing a complete stop-the-world reconciliation that lasted until 22 October. Backups stored inside the same regional S3 buckets proved unusable, resulting in a seven-day RPO and primary-key collisions after restoration. The incident exposed that Metro-Cluster designs had been incorrectly treated as full Disaster Recovery and that aggressive AP microservice patterns created logical split-brain conditions outside the database layer.
Astra Group Releases Low-Code Astra AI Platform for Building Corporate AI Agents in Closed Environments
Astra Group has launched the Astra AI Platform, a low-code constructor designed for creating corporate AI applications that operate entirely within closed circuits without reliance on foreign clouds. The platform targets small and medium businesses as well as large corporations, enabling rapid deployment of AI secretaries, technical support assistants, and other agents in days rather than months. It forms part of the broader Astra AI ecosystem and includes two main constructors: one for machine learning model training and deployment, and another for LLM-based language assistants, document search, and process automation. Users can assemble scenarios from visual blocks, debug them in real time, or extend functionality with custom Python code when needed. The solution supports RAG-based knowledge bases, integration with external tools such as CRM and ERP systems, and the coordination of multiple agents for distributed task handling. One demonstrated use case involves processing ten pages of engineering drawings and specifications in five minutes to prepare data for downstream systems. The product is already listed in the Russian domestic software registry and available to customers.
Multi-Tenancy Isolation in VictoriaMetrics, VictoriaLogs and Grafana: Building Client Separation in a Shared Stack
Voltir runs a single shared monitoring stack consisting of VictoriaMetrics, VictoriaLogs, Grafana and vmalert for all customers instead of deploying separate instances per tenant. Isolation relies on numeric account IDs enforced at every layer: nginx validates tokens against the platform API before proxying writes, Grafana data sources hard-code tenant accounts, and vmalert rules receive automatic account filters. The team discovered that a single malformed rule or template could break alerting for every tenant because vmalert loads the entire rules directory at once. They also found that Grafana automatically created personal organizations granting Org Admin rights, accumulating hundreds of orphaned organizations and users that consumed disk space and resources. A dedicated cleanup module plus hourly reconciliation now removes rules, organizations, series and users when a tenant is deleted, while isolation tests verify both data and API objects across tenants.