Agentless Service Dependency Mapping Using DNS Logs

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

The complexity of service-to-service communication in microservices architectures, particularly in public cloud environments, leads to difficulties in security, tracing, and debugging due to the exponential increase in connectivity and dynamic dependencies, which existing solutions often require intrusive agents or are not scalable.

Innovation Solution

A non-intrusive method using a security service to analyze DNS logs and service registries to dynamically infer service dependencies, generating a network graph that updates periodically, allowing for the detection of vulnerabilities and misconfigurations without requiring agents within the service plane.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Measurement precision

If agents are deployed within the service plane to trace dependencies, then measurement precision improves, but device complexity increases

Engineering Contradiction:
Improvedependency tracing accuracyVSAvoidagent deployment complexity
Core Design Contradiction:
Measurement precisionVSDevice complexity

Solution Approach 1:

The patent uses DNS logs as an intermediary data source to trace service dependencies. Instead of deploying agents within services, the system queries DNS logs which naturally record service-to-service communication patterns. This intermediary approach provides accurate dependency tracing without the complexity of agent deployment.

Inventive Principle:
Principle #24Intermediary (Mediator)

Solution Approach 2:

The system leverages existing DNS logging infrastructure that automatically records service communication without requiring additional instrumentation. The DNS logs self-document the service plane traffic, eliminating the need for external agents to trace dependencies.

Inventive Principle:
Principle #25Self-service

2Reliability

If agents are deployed within the service plane, then reliability of security monitoring improves, but ease of operation deteriorates

Engineering Contradiction:
Improvesecurity monitoring reliabilityVSAvoiddeployment ease
Core Design Contradiction:
ReliabilityVSEase of operation

Solution Approach 1:

The system uses DNS logs as a mediator to achieve reliable security monitoring without deployment complexity. By querying existing DNS log data, the system maintains reliable visibility into service dependencies while avoiding the operational burden of agent installation and maintenance.

Inventive Principle:
Principle #24Intermediary (Mediator)

3Loss of information

If comprehensive service tracing is implemented, then loss of information decreases, but device complexity increases

Engineering Contradiction:
Improvedependency information completenessVSAvoidtracing system complexity
Core Design Contradiction:
Loss of informationVSDevice complexity

Solution Approach 1:

The system leverages DNS logs that already contain comprehensive service communication information. By querying these self-documenting logs, the system achieves complete dependency information without implementing complex tracing infrastructure.

Inventive Principle:
Principle #25Self-service

Data Source

PatentUS12563078B2App security: agentless solution to identify internal service to service dependencies and routes
Publication Date: 2026.02.24 PALO ALTO NETWORKS INC
  • US12563078B2 patent drawing
  • US12563078B2 patent drawing
  • US12563078B2 patent drawing

AI summary

The present application discloses a method, system, and computer system for performing discovery of service to service communication traffic. The method includes (i) determining, based at least in part on one or more Domain Name System (DNS) logs, a source Internet Protocol (IP) address based on a resolved record for a requested service, (ii) determining a source service based at least in part on performing a lookup in a service registry based at least in part on the source IP address, and (iii) generating, based at least in part on the source service associated with the source IP, a network graph for an application service comprising the source service and the requested service.