DNS Resolver Mixed-Mode Security Validation

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

In mixed DNS environments where some DNS servers support DNSSEC and others do not, there is a lack of reliable methods to securely handle interactions between DNS resolvers and DNS servers, leading to vulnerabilities such as spoofing attacks, especially when dealing with both public and private domains.

Innovation Solution

A method where a DNS resolver generates queries to both external and internal DNS servers, verifying digital signatures and chain of trust to determine the security state of DNS answers, treating sub-trees as either fully or not DNSSEC-protected, and disabling DNSSEC validation for insecure domains to ensure secure resolution of domain names.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Reliability

If DNSSEC validation is enabled in a mixed-mode environment, then security against spoofing attacks is improved, but compatibility with non-DNSSEC DNS servers deteriorates

Engineering Contradiction:
Improvesecurity against spoofing attacksVSAvoidcompatibility with non-DNSSEC DNS servers
Core Design Contradiction:
ReliabilityVSAdaptability or versatility

Solution Approach 1:

The DNS resolver dynamically adjusts its validation behavior based on the response from DNS servers. When a DNS server does not provide DNSSEC validation, the resolver switches to a non-validating mode for that specific server, allowing it to continue functioning while maintaining security where possible. This dynamic adaptation resolves the contradiction by enabling the system to operate securely with DNSSEC servers while maintaining compatibility with non-DNSSEC servers.

Inventive Principle:
Principle #15Dynamics

Solution Approach 2:

The system applies different validation strategies to different DNS servers based on their individual capabilities. Each DNS server interaction is evaluated independently, and the resolver applies DNSSEC validation only when the server supports it, while using alternative methods when the server does not support DNSSEC. This local differentiation allows simultaneous support for both secure and non-secure servers without compromising overall system reliability.

Inventive Principle:
Principle #3Local quality

2Reliability

If DNSSEC validation is strictly enforced, then authentication of DNS answers is improved, but resolution time for domains in insecure zones deteriorates

Engineering Contradiction:
Improveauthentication of DNS answersVSAvoidresolution time
Core Design Contradiction:
ReliabilityVSLoss of time

Solution Approach 1:

The validation state of the DNS resolver is dynamically changed based on the security status of the DNS zone. When a zone is determined to be insecure (missing DNSSEC validation), the resolver transitions to a non-validating state for that zone, allowing faster resolution without the overhead of cryptographic verification. This dynamic state change enables the system to maintain strict authentication where possible while reducing resolution time when security cannot be established.

Inventive Principle:
Principle #15Dynamics

Solution Approach 2:

The system changes the validation parameter based on the security status of the DNS zone. When DNSSEC validation fails or is unavailable, the system modifies the validation parameter to allow non-validated responses, thereby reducing the time required for resolution while maintaining authentication where the security parameter can be satisfied.

Inventive Principle:
Principle #35Parameter changes

3Ease of operation

If pre-configured exceptions or DHCP authentication are used, then ease of operation is improved, but security against phishing attacks deteriorates

Engineering Contradiction:
Improveease of configurationVSAvoidphishing attack vulnerability
Core Design Contradiction:
Ease of operationVSObject-affected harmful factors

Solution Approach 1:

The DNS resolver performs self-validation by independently verifying the security status of DNS zones through DNSSEC validation. Rather than relying on pre-configured exceptions or DHCP authentication, the system autonomously determines whether a zone is secure and adjusts its behavior accordingly. This self-service approach eliminates the need for manual configuration while providing robust security against phishing attacks by directly verifying the authenticity of DNS responses.

Inventive Principle:
Principle #25Self-service

Solution Approach 2:

The system uses feedback from DNSSEC validation results to automatically adjust its operation. When validation succeeds, the system trusts the DNS response; when validation fails or is unavailable, the system switches to alternative validation methods or rejects the response. This feedback mechanism provides secure operation without requiring pre-configured exceptions, as the system adapts its behavior based on real-time validation results.

Inventive Principle:
Principle #23Feedback

Data Source

PatentUS9544278B2Using domain name system security extensions in a mixed-mode environment
Publication Date: 2017.01.10 RED HAT INC
  • US9544278B2 patent drawing
  • US9544278B2 patent drawing
  • US9544278B2 patent drawing

AI summary

A method relates to generating, by a processing device executing a DNS resolver, a first domain name system (DNS) query comprising a DNS request generated from an application executing on the processing device to query a first DNS server serving a first DNS zone connected to the processing device via a public network, receiving, from the first DNS server, a first resource record comprising a DNS answer to the DNS query, a second resource record comprising a digital signature generated by signing the DNS answer with a first private key of the first DNS zone, a third resource record comprising a first public key for verifying the digital signature, and one or more files for validating a chain of trust of the first public key, determining, by the processing device in view of the one or more files, that the chain of trust of the first public key misses at least one of a trust anchor or a link in the chain of trust, and generating a second DNS query comprising the DNS request to query a second DNS server residing in a private network of the processing device.