# Mirroring Instead of Touching the Resolver ## The design insight the product is built on DNS is the most sensitive box on a network to change. It is load-bearing, it fails loudly, and everything stops when it breaks. So the honest problem is not "can we read DNS data", it is "can we read it without anyone having to touch the resolver". TelemetriX answers by taking a copy. The resolver keeps answering queries exactly as before. A mirrored stream of the same events goes to TelemetriX, which reads the copy. ```mermaid graph LR A[Devices and apps] --> R[DNS resolver<br/>unchanged] R --> ANS[Answered, same as always] R -.mirror.-> T[TelemetriX<br/>reads the copy] T --> S[Structured intelligence<br/>stays inside the boundary] class A,R,T,S internal-link; ``` The chain the company uses to explain itself is four steps: | Problem | Challenge | Solution | Value | | --- | --- | --- | --- | | Nobody keeps what DNS reveals | You cannot touch the resolver to get it | Mirror the traffic instead | The intelligence stays yours | > [!tip] Why this matters commercially > It removes the objection that kills most DNS products before a trial starts. The buyer is not being asked to change production DNS, ==so the security review is about a read path, not a live dependency==. That shortens the path from interest to pilot. The company's own phrase for this is a resolver-preserving layer. ## Why it matters It sets what the product is and is not. TelemetriX is not a resolver and does not compete with BIND, PowerDNS, Knot, Unbound or Infoblox. It sits beside them. That keeps every resolver vendor a potential channel rather than a rival. ## Related - [[Red Onion MOC]] - [[DNSTAP and Where the Data Comes From]] - [[The Resolver as Sovereignty Chokepoint]] - [[CoreDNS]] - [[PowerDNS]]