Derivative works — US Patent 7490151

Defensive Disclosure: Derivatives of US Patent 7490151

Current Date: April 26, 2026

This document outlines derivative variations of the core inventive concepts within US Patent 7,490,151, "Establishment of a secure communication link based on a domain name service (DNS) request." The objective is to create comprehensive prior art disclosures, rendering future incremental improvements in this domain obvious or non-novel to a person having ordinary skill in the art. The analysis focuses on the central mechanism of a DNS proxy server intercepting a DNS request to transparently establish a secure communication link between a client and a target server.

Derivative 1: Material & Component Substitution - Specialized Hardware Proxy

Enabling Description:
The DNS proxy server functionality for intercepting client DNS requests and initiating secure communication links is implemented on a dedicated hardware security module (HSM) or a Field-Programmable Gate Array (FPGA) based network appliance. For an HSM implementation, cryptographic key generation, secure storage, and accelerated encryption/decryption operations (e.g., for TLS, DTLS, or IPsec tunnel establishment) are performed within the HSM's tamper-resistant cryptographic module, ensuring hardware-level protection for session keys and certificates. The HSM interfaces with standard network interfaces for packet I/O. For an FPGA implementation, the entire DNS interception logic, packet parsing, secure tunnel negotiation state machines (e.g., IKEv2 or TLS handshake protocols), and high-speed symmetric encryption/decryption data paths are synthesized into custom logic on the FPGA fabric. This allows for wire-speed processing of DNS requests and secure tunnel initiation with minimal latency, bypassing CPU-intensive software stacks. The FPGA's reconfigurable nature allows for dynamic updates to cryptographic algorithms or secure link policies. Both implementations serve to offload critical security functions from general-purpose CPUs and enhance resistance to software-based attacks.

graph TD
    A[Client] -->|DNS Request (for Server)| B(Network Interface Card with FPGA)
    B --> C{DNS Proxy (FPGA/HSM Appliance)}
    C -- Intercept DNS Request --> D[Secure Link Establishment Module (on FPGA/HSM)]
    D -->|Initiate Secure Tunnel (e.g., IPsec SA)| E[Server]
    D -- Key Exchange, Parameters --> A
    C -->|Forward DNS Request| F(Domain Name Server)
    F -->|IP Address| C
    C -->|IP Address via Secure Link| A
    A <-->|Secure Communication via Tunnel| E

Derivative 2: Operational Parameter Expansion - Extreme Scale & Latency

Enabling Description:
The DNS proxy server is engineered to operate at two extreme scales: (1) ultra-low latency for high-frequency trading (HFT) environments and (2) massive concurrency for large-scale Internet of Things (IoT) deployments.
For HFT, the DNS proxy is an in-line network appliance utilizing kernel-bypass networking frameworks (e.g., Data Plane Development Kit (DPDK) or Solarflare's OpenOnload) for direct access to network interface controllers, achieving sub-microsecond processing latencies. DNS packet inspection and modification are performed by specialized hardware offload engines or tightly optimized byte-code filters. Secure link establishment (e.g., IPsec or TLS) leverages hardware cryptographic accelerators with pre-computed ephemeral key pools and "zero-round-trip time" (0-RTT) session resumption mechanisms to minimize negotiation overhead. The plurality of IP addresses for the secure link are pre-provisioned or derived from rapidly changing, high-entropy pseudo-random sequences for maximal agility.
For massive IoT networks, the DNS proxy is designed for distributed, horizontally scalable deployment across edge computing nodes. It handles millions of concurrent DNS requests from constrained, low-power IoT devices. Secure link establishment uses lightweight cryptographic protocols (e.g., DTLS for UDP-based IoT, or TLS 1.3 with PSK mode) and leverages Constrained Application Protocol (CoAP) extensions for secure provisioning and identity management. DNS proxy responses are batched, pushed, or multi-cast to device groups for efficiency. IP address hopping sequences are centrally managed by the proxy but synchronized and executed locally by IoT devices using minimal CPU cycles and power. Secure tunnels are established and torn down rapidly on-demand to conserve device battery life.

sequenceDiagram
    participant C as HFT Client / IoT Device
    participant DP as Ultra-Low Latency DNS Proxy
    participant DNS as Authoritative DNS
    participant S as HFT Exchange / IoT Server

    C->>DP: DNS Query (domain.hft / iot.example.com)
    activate DP
    DP->>DP: Intercept & Packet Inspect (Kernel-bypass)
    DP->>DP: Check Secure Link Status
    alt No Existing Secure Link
        DP-->>C: Initiate Secure Link Setup (e.g., IPsec/DTLS)
        C->>DP: Secure Link Negotiation (Hardware-accelerated)
        DP->>C: Secure Link Established
    end
    DP->>DNS: Forward DNS Query
    DNS->>DP: DNS Response (Server IP)
    DP->>DP: Encapsulate DNS Response
    DP->>C: Secure DNS Response (Server IP via Tunnel)
    deactivate DP
    C->>S: Secure Communication (via tunnel, ultra-low latency)

Derivative 3: Cross-Domain Application - Aerospace (Drone Swarm Management)

Enabling Description:
In an Aerospace application, specifically for secure command and control of autonomous drone swarms, a ground control station (client) sends a DNS-like query for a drone's mission-specific identifier (e.g., drone-id-007.mission-recon.aero). A specialized "Aero-DNS" proxy, operating on a hardened, redundant airborne or ground-based network appliance, intercepts this query. Upon successful cryptographic authentication of the ground station (e.g., using secure element-based certificates and mutual TLS), the Aero-DNS proxy establishes a highly resilient and encrypted communication link with the target drone or a designated lead drone within a swarm. This link utilizes a plurality of dynamically assigned network identifiers (e.g., dynamically assigned IPv6 addresses, or proprietary link-layer identifiers for specialized aviation protocols) from a pre-allocated, secure address block. The communication link employs rapid frequency-hopping spread spectrum (FHSS) techniques at the physical layer combined with IP-level address hopping to resist jamming, spoofing, and interception in contested environments. The Aero-DNS proxy then forwards the original identifier query to a central mission control registry, which returns the drone's current operational parameters, health status, and precise network routing information. All subsequent command-and-control, telemetry, and payload data (e.g., high-resolution imagery) are transmitted over this secure, agile, and robust communication link.

flowchart TD
    A[Ground Control Station (Client)] -- DNS Query (e.g., drone-id-007.aero) --> B(Aero-DNS Proxy)
    B -- Intercept & Authenticate (Secure Element, mTLS) --> C{Establish Secure Link}
    C -- Dynamic ID Allocation & FHSS/IP Hopping --> D[Target Drone / Lead Drone]
    C -- Link Established --> A
    B -- Forward Query --> F(Mission Control Registry)
    F -- Drone Operational Data & Network Addresses --> B
    B -- Secure Response (over established link) --> A
    A <-->|Secure C2, Telemetry, Payload Data| D

Derivative 4: Cross-Domain Application - AgTech (Autonomous Farm Equipment)

Enabling Description:
For an AgTech application managing autonomous farm equipment, a centralized farm management system (client) requests connectivity to a specific autonomous tractor or harvester (server) identified by its unique asset tag and operational role (e.g., tractor-X500.field-alpha.farmOS.com). A "Farm-DNS" proxy, running on a ruggedized edge gateway or a mobile command unit within the agricultural field, intercepts this request. The proxy performs robust authentication of the farm management system (e.g., using digital certificates and attribute-based access control policies derived from the farm's operational database). In response, it initiates a secure communication tunnel to the target autonomous equipment. This tunnel dynamically assigns a plurality of IP addresses from a local subnet pool, selected and hopped to optimize for varying wireless signal strength, interference, and network coverage across the farm's heterogeneous wireless infrastructure (e.g., private 5G, LoRaWAN, Wi-Fi mesh, satellite backhaul). The secure link is established using protocols adapted for intermittent connectivity and harsh environmental conditions, with forward error correction and retransmission mechanisms. After establishing the secure link, the Farm-DNS proxy queries a central farm asset registry or cloud-based telematics platform for the equipment's real-time precise GPS coordinates, operational status, and task assignments. This information is returned to the farm management system via the secure channel. All subsequent telematics data, remote control commands, and sensor data from attached implements (e.g., soil moisture, nutrient application rates, crop yield metrics) flow through this resilient, multi-path secure link.

graph LR
    A[Farm Management System (Client)] -->|DNS Query (tractor-X500.farmOS.com)| B(Farm-DNS Proxy / Edge Gateway)
    B -- Intercept & Authenticate (Certificates, ABAC) --> C{Secure Link Initiation}
    C -- Dynamic IP Allocation (Multi-path: 5G, LoRa, Wi-Fi, Satellite) --> D[Autonomous Tractor (Server)]
    C -- Establish Secure Tunnel --> A
    B -- Forward Query --> E(Farm Asset Registry / Telematics Platform)
    E -- Real-time GPS, Status, Tasks --> B
    B -- Secure Response (via tunnel) --> A
    A <-->|Secure Telematics, Control, Sensor Data| D

Derivative 5: Cross-Domain Application - Smart City Infrastructure (Traffic Control)

Enabling Description:
In the context of Smart City Infrastructure, a municipal traffic control center (client) aims to establish a secure connection with a specific smart traffic intersection controller (server) identified by a hierarchical naming scheme (e.g., controller-zone-alpha.int-main-elm.citygrid.io). A "City-DNS" proxy, deployed as a redundant appliance within the city's critical municipal network infrastructure, intercepts this request. Following successful multi-factor authentication and authorization of the control center operator (e.g., using digital identities and role-based access control), the City-DNS proxy initiates a secure communication link with the target traffic controller. This link utilizes a pool of dynamically assigned IP addresses from a dedicated, isolated block within the smart city subnet. Traffic is multiplexed over redundant physical links (e.g., dedicated fiber optic lines, licensed fixed wireless spectrum, cellular VPNs) to ensure ultra-high availability and resilience against physical link failures or cyber-attacks. The secure connection employs cryptographic protocols tailored for industrial control systems (e.g., IEC 62351-5 for authenticated message exchanges, or DNP3 with secure authentication extensions). The City-DNS proxy then forwards the original query to a centralized traffic management and data analytics platform, which returns real-time traffic flow data, sensor readings (e.g., vehicle presence, pedestrian counts), and the controller's precise network configurations, transmitted securely back to the control center. Subsequent commands for dynamic signal timing adjustments, emergency vehicle preemption, and public safety camera feeds are conveyed exclusively over this established secure, fault-tolerant link.

sequenceDiagram
    participant CCS as City Control Center (Client)
    participant CDP as City-DNS Proxy
    participant TMS as Traffic Management Platform
    participant STC as Smart Traffic Controller (Server)

    CCS->>CDP: DNS Query (controller-zone-alpha.citygrid.io)
    activate CDP
    CDP->>CDP: Intercept & Authenticate Client (MFA, RBAC)
    CDP->>CDP: Initiate Secure Link Setup (e.g., IEC 62351-5, DNP3 Secure)
    CDP->>STC: Negotiate Secure Tunnel (Dynamic IP Assignment, Redundant Physical Links)
    STC->>CDP: Secure Tunnel Established
    CDP->>CCS: Secure Link Established
    CDP->>TMS: Forward DNS Query
    TMS->>CDP: Traffic Data, Sensor Readings, Config (STC IP)
    CDP->>CCS: Secure DNS Response (via Tunnel)
    deactivate CDP
    CCS->>STC: Secure Commands & Camera Feeds (via Tunnel)

Derivative 6: Integration with AI-driven Optimization (Secure Link Parameters)

Enabling Description:
The DNS proxy server incorporates an AI-driven optimization engine that dynamically adjusts secure link establishment and operational parameters in real-time. When a client sends a DNS request, the AI engine performs a multi-dimensional threat assessment by analyzing source IP reputation, historical attack patterns, behavioral anomalies of the client or requested server, and current network topology vulnerabilities. Based on this continuous assessment, a machine learning model within the AI engine determines the optimal secure communication protocol (e.g., strongest encryption suite, quantum-safe key exchange mechanisms), the required number and randomness of IP addresses to utilize for hopping, the frequency and timing of IP address changes (agility), and the selection of preferred routing paths for the secure link. For instance, if a high-confidence zero-day threat is detected, the AI might mandate a multi-hop, maximally agile secure link using a maximally randomized IP address block and post-quantum cryptography. Conversely, for routine, low-risk internal communications, it might select a more performant but less computationally intensive secure link. The AI continuously monitors established link quality, cryptographic entropy, and detected attack vectors post-establishment, dynamically adapting parameters (e.g., increasing hop frequency, switching encryption algorithms, or re-routing traffic) to maintain an optimal balance of security, performance, and resource utilization. This decision-making process is transparently logged and auditable.

graph TD
    A[Client] -- DNS Request (domain.com) --> B(DNS Proxy with AI Engine)
    B -- Intercept DNS Request --> C{AI-Driven Threat Assessment Module}
    C -- Analyze Client/Request (IP Rep, Behavior, Topology) --> D[AI Optimization Engine]
    D -- Determine Optimal Security Params (Protocol, IPs, Hopping Freq, Routes) --> E[Secure Link Establishment Module]
    E -- Establish Secure Link (AI-optimized) --> F[Server]
    E -- Secure Link Established --> A
    B -- Forward DNS Request --> G(Domain Name Server)
    G -- Server IP --> B
    B -- Secure Response (AI-optimized) --> A
    A <-->|AI-Optimized Secure Communication| F
    F --> H[Real-time Link Metrics]
    H --> C

Derivative 7: Integration with IoT Sensors for Real-time Physical Monitoring

Enabling Description:
The DNS proxy server's secure link management system is tightly integrated with a pervasive network of IoT physical environmental and infrastructure sensors. These sensors, strategically deployed throughout the network's physical layer (e.g., data centers, edge gateways, fiber routes, wireless access points), continuously monitor parameters such as electromagnetic interference (EMI), radio frequency (RF) signal strength, optical fiber integrity, physical tampering attempts on network hardware, server rack temperatures, power supply fluctuations, and localized seismic activity. When a client sends a DNS request, the DNS proxy initiates secure link establishment. During this process, and continuously throughout the lifespan of the secure link, real-time IoT sensor data is streamed to the secure link management system. If, for example, IoT RF sensors detect a sudden increase in localized jamming or interference on a specific wireless network segment, the system dynamically adjusts the IP address hopping sequence, shifts traffic to alternative frequency bands, or re-routes the secure link entirely to different physical paths to mitigate the threat and maintain link integrity. Similarly, if physical tampering is detected near a router or cable splice point, the proxy can immediately trigger a rapid IP address change on affected network devices, reroute all traffic to hardened, monitored paths, or even initiate an automatic failover to a geographically separated backup infrastructure. This provides a proactive, physical-layer security response capability.

stateDiagram
    [*] --> ClientDNSRequest
    ClientDNSRequest --> ProxyIntercept: DNS Request Received
    ProxyIntercept --> ThreatAssessment: Validate Client & Request
    ThreatAssessment --> MonitorIoT: Integrate IoT Sensor Data (EMI, Signal, Tamper, Temperature)
    MonitorIoT --> SelectLinkParams: Choose Security Protocol & IPs based on Sensor Data
    SelectLinkParams --> EstablishSecureLink: Initiate Secure Tunnel
    EstablishSecureLink --> DNSResolution: Forward DNS Request to Authoritative DNS
    DNSResolution --> MonitorIoT: Receive Server IP, Continue Monitoring
    MonitorIoT --> SecureCommunication: Client-Server Communication via Secure Link
    SecureCommunication --> DynamicAdjustment: (Loop) Continuously adapt link parameters based on real-time IoT data, re-route if needed
    DynamicAdjustment --> SecureCommunication

Derivative 8: Integration with Blockchain for Component and Identity Verification

Enabling Description:
The DNS proxy server utilizes a blockchain-based identity and supply chain verification system to establish a higher degree of trust for secure communication links. Before establishing any secure link in response to a DNS request, the DNS proxy queries an immutable, permissioned blockchain ledger. This ledger contains verified, tamper-evident records of the digital identities of both the client device/user and the target server (e.g., device certificates, cryptographic hashes of boot firmware, signed software manifests). Crucially, the blockchain also stores attestations regarding the manufacturing, distribution, and patching history (supply chain integrity) of critical network hardware components (e.g., Network Interface Cards (NICs), routers, DNS proxy appliances, servers) and their associated software images. If the blockchain reveals any unauthorized modifications, suspicious firmware versions, unverified component provenance, or a lapse in patching records for either the client or server in the proposed communication path, the DNS proxy can: (a) refuse to establish a secure link; (b) establish a highly restricted, read-only, or sandboxed link; (c) flag the connection for deep packet inspection by a separate security appliance; or (d) enforce the use of stronger, more resource-intensive cryptographic algorithms. The secure link establishment process itself can also record metadata (e.g., session identifiers, public key hashes exchanged, policy decisions) on a private blockchain to provide an auditable, non-repudiable log of secure connection events, enhancing forensic capabilities.

sequenceDiagram
    participant C as Client
    participant DP as DNS Proxy (Blockchain-Enabled)
    participant B as Blockchain Ledger (Identity/Supply Chain)
    participant DNS as Authoritative DNS
    participant S as Server

    C->>DP: DNS Query (domain.com)
    activate DP
    DP->>B: Query Client Identity & Supply Chain Verif.
    B-->>DP: Client Verification Status (e.g., firmware hash valid)
    DP->>B: Query Server Identity & Supply Chain Verif.
    B-->>DP: Server Verification Status (e.g., component provenance)
    alt Verification Failed
        DP-->>C: Reject Secure Link / Flag for Inspection
    else Verification Successful
        DP->>DP: Establish Secure Link (based on verified trust)
        DP-->>C: Secure Link Established
        DP->>DNS: Forward DNS Query
        DNS->>DP: Server IP
        DP->>B: Record Secure Link Metadata (Session ID, Key Hashes, Policies)
        DP->>C: Secure DNS Response (Server IP)
        deactivate DP
        C->>S: Secure Communication (via blockchain-verified link)
    end

Derivative 9: The "Inverse" or Failure Mode - Safe-Fail Degradation

Enabling Description:
The DNS proxy server is architected for "safe-fail" degradation of secure communication links. Upon intercepting a DNS request and attempting to establish a secure link, the proxy continuously monitors its internal state and external network conditions. If it detects critical resource constraints (e.g., CPU overload exceeding 90% for 5 seconds, memory exhaustion, critical network path congestion) preventing the establishment of a full, high-grade secure link, or if it identifies a potential cryptographic key compromise or protocol negotiation failure during the secure link setup, the proxy automatically initiates a controlled degradation. Instead of a full VPN-like secure tunnel with multi-path IP hopping and strong encryption, it might establish only a pre-defined, minimal-security "failsafe" mode connection (e.g., basic TLS 1.2 with limited cipher suites, or a single static IP route without hopping). In extreme cases of detected compromise or resource unavailability, the DNS proxy can redirect all traffic for that client/server pair to a "quarantine network" (a separate, isolated VLAN with restricted access) or block it entirely, preventing potential data leakage or active exploitation. All such degradation or blocking events are immediately logged to a secure, immutable log and trigger an automated security alert to network administrators, ensuring no inadvertent fallback to insecure cleartext communication or silent failure.

stateDiagram
    [*] --> ClientDNSRequest
    ClientDNSRequest --> ProxyIntercept: DNS Request Received
    ProxyIntercept --> DetectConditions: Check Internal Resources & Security Status
    DetectConditions --> CompromiseDetected: IF Cryptographic Failure OR Key Compromise OR High Threat
    DetectConditions --> ResourceConstraint: ELSE IF CPU/Memory Overload OR Network Congestion
    CompromiseDetected --> QuarantineNetwork: Redirect to Isolated Network / Block Traffic
    ResourceConstraint --> MinimalSecureLink: Downgrade to Basic TLS / Static Route (Failsafe)
    MinimalSecureLink --> LimitedFunctionality: Client Communicates in Limited Mode
    DetectConditions --> FullSecureLink: ELSE (Normal Conditions)
    FullSecureLink --> NormalFunctionality: Client Communicates Normally
    QuarantineNetwork --> AlertAdmin: Generate Critical Security Alert
    MinimalSecureLink --> AlertAdmin: Generate Warning/Info Alert
    FullSecureLink --> Monitor: Continuously Monitor Link Health
    Monitor --> DetectConditions: IF Degradation/Compromise Detected

Derivative 10: The "Inverse" or Failure Mode - Low-Power / Intermittent-Connectivity Optimization

Enabling Description:
For battery-constrained client devices (e.g., deep-sleep IoT sensors, remote environmental monitors, mobile autonomous agents) or in environments characterized by intermittent network connectivity, the DNS proxy server operates in a "low-power/limited-functionality" secure link establishment mode. The "identification of the first computer" within the DNS request includes a specific flag or metadata indicating the client's low-power status and/or expected connectivity profile. Upon intercepting such a request, the proxy establishes a secure link using lightweight cryptographic algorithms (e.g., Elliptic Curve Cryptography (ECC) for key exchange to minimize computational load, AES-GCM with reduced key sizes for data encryption, or pre-shared key (PSK) modes for rapid session establishment). IP address hopping is either minimized to a small, pre-negotiated pool, or a static, energy-optimized secure channel is provisioned for the duration of a short, burst transmission. The proxy prioritizes rapid establishment and teardown of the secure link, minimizing active radio time and CPU wake cycles for the client. The DNS response might also be optimized to return only essential IP addresses, with non-critical DNS records cached or deferred. If the low-power client attempts to access a resource requiring a higher security profile (e.g., real-time video streaming), the proxy might refuse the connection, prompt the client to enter a temporary "full-power" mode, or redirect it to a low-bandwidth proxy service. The secure link also supports asynchronous communication patterns and opportunistic data transfer windows to further conserve client energy during periods of sleep.

sequenceDiagram
    participant LC as Low-Power Client (IoT)
    participant DP as DNS Proxy (Low-Power Mode)
    participant DNS as Authoritative DNS
    participant S as Server

    LC->>DP: DNS Query (low_power_sensor.data, includes Low-Power Flag)
    activate DP
    DP->>DP: Intercept, Recognize Low-Power Flag
    DP->>DP: Select Lightweight Crypto (ECC, AES-GCM, PSK), Minimal IP Hopping/Static Channel
    DP->>LC: Initiate Lightweight Secure Link Setup
    LC->>DP: Lightweight Secure Link Established
    DP->>DNS: Forward DNS Query
    DNS->>DP: Server IP
    DP->>LC: Secure DNS Response (Server IP, optimized)
    deactivate DP
    LC->>S: Burst Secure Communication (low-power, via lightweight link)
    Note over LC,S: Link quickly torn down or kept minimally active; supports async communication

Combination Prior Art Scenarios

US7490151 + DNSCrypt:
- Description: The DNS proxy server of US7490151 integrates the DNSCrypt protocol to secure the initial DNS request itself. When a client sends a DNS request for a target server, this request is first encrypted and cryptographically signed using the DNSCrypt protocol, establishing a secure channel between the client and the DNS proxy (acting as a DNSCrypt resolver). The DNS proxy intercepts this DNSCrypt-encrypted request, decrypts it, validates its authenticity, and then, in response, proceeds with the standard US7490151 process of establishing a broader secure communication link (e.g., a VPN tunnel) between the client and the target server. The proxy then forwards the original, now-verified DNS query to the authoritative DNS server, potentially over a DNSCrypt connection as well, to maintain end-to-end privacy and integrity. The target server's IP address is returned to the client over the newly established secure communication link.
- Prior Art Value: This combination renders obvious any claims relating to securing the initial DNS request itself using existing DNS encryption and authentication protocols (like DNSCrypt) as part of a system that then uses a DNS proxy to trigger and establish a broader secure communication link.
US7490151 + WireGuard (for VPN Tunnel Establishment):
- Description: The "secure communication link" established by the DNS proxy server in response to a DNS request is specifically implemented using the WireGuard VPN protocol. Upon intercepting a client's DNS request, the DNS proxy, acting as a WireGuard endpoint, initiates a WireGuard key exchange and tunnel establishment process with the client. The proxy leverages WireGuard's efficient cryptographic primitives and simple protocol design for rapid and lightweight VPN setup. Once the WireGuard tunnel is established, the DNS proxy forwards the original DNS request to the authoritative domain name server. The resulting IP address of the target server is then delivered back to the client encrypted within the WireGuard tunnel. All subsequent client-to-server application data flows through this high-performance, WireGuard-secured communication link, benefiting from its speed and modern cryptographic assurances.
- Prior Art Value: This combination renders obvious the application of specific modern, lightweight, and high-performance VPN protocols (such as WireGuard) for the "secure communication link" that is transparently established by a DNS proxy in response to a DNS request.
US7490151 + DNSSEC (for DNS Response Integrity):
- Description: The DNS proxy server, as described in US7490151, enhances the security of the overall process by integrating DNSSEC (Domain Name System Security Extensions) validation. After intercepting a client's DNS request and before establishing the secure communication link, the DNS proxy forwards the request to an authoritative name server. When the DNS response (containing the target server's IP address) is received by the DNS proxy, the proxy cryptographically validates the authenticity and integrity of this DNS response using DNSSEC records. This step ensures that the resolved IP address has not been spoofed or tampered with by an intermediate attacker. Only after successful DNSSEC validation does the DNS proxy proceed to establish the secure communication link between the client and the verified target server. The validated IP address is then securely transmitted to the client over the newly established secure link, ensuring both the integrity of the resolution and the confidentiality of the subsequent communication.
- Prior Art Value: This combination renders obvious the incorporation of DNSSEC validation by a DNS proxy to cryptographically verify the integrity and authenticity of DNS resolution results when that resolution triggers the establishment of a secure communication link. This preempts claims attempting to secure the DNS resolution aspect of the process.