DNS Resolver Cache Sharing via Multicast Communication

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

Current DNS record cache management across multiple DNS servers is inefficient due to reliance on centralized caching solutions, which introduce single points of failure and increase recursive lookup times when cache misses occur.

Innovation Solution

Implementing multicast communication among DNS resolver nodes within the same data center to share cache updates, allowing each node to maintain its own cache and reduce the need for outbound queries to authoritative nameservers, thereby distributing cache updates and eliminating single points of failure.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Ease of operation

If a centralized caching solution is used to manage DNS records across multiple DNS servers, then cache management is simplified, but single points of failure are introduced and query response times increase when cache misses occur

Engineering Contradiction:
Improvecache managementVSAvoidsingle point of failure
Core Design Contradiction:
Ease of operationVSReliability

Solution Approach 1:

The patent divides the centralized cache into distributed caches across multiple DNS resolver nodes. Each node maintains its own cache independently, eliminating the single point of failure associated with centralized caching. The segmentation is achieved through multicast group membership where each resolver node can independently store and retrieve DNS records without relying on a central authority.

Inventive Principle:
Principle #1Segmentation

Solution Approach 2:

The patent introduces multicast communication as an intermediary mechanism to enable cache sharing among distributed resolver nodes. Instead of direct peer-to-peer communication or centralized coordination, multicast messages serve as the mediator that allows efficient propagation of DNS records across the network, maintaining simplicity while achieving distribution.

Inventive Principle:
Principle #24Intermediary (Mediator)

2Reliability

If each DNS resolver node maintains its own local cache, then reliability is improved by eliminating single points of failure, but cache hit ratios decrease due to lack of cache sharing

Engineering Contradiction:
Improvesingle point of failureVSAvoidcache hit ratio
Core Design Contradiction:
ReliabilityVSProductivity

Solution Approach 1:

The patent merges the functionality of multiple independent caches into a unified distributed cache system. Through multicast communication, DNS records cached by one resolver node are automatically propagated to other nodes in the group, effectively combining the cache capacities of all nodes while maintaining individual node autonomy and reliability.

Inventive Principle:
Principle #5Merging (Combining)

Solution Approach 2:

The patent implements a feedback mechanism where resolver nodes publish DNS records they acquire to the multicast group. Other nodes receive these publications and update their local caches accordingly, creating a continuous feedback loop that maintains cache synchronization across the distributed system without central coordination.

Inventive Principle:
Principle #23Feedback

3Stability of the object's composition

If outbound queries are sent to authoritative nameservers for every cache miss, then cache consistency is maintained, but query response times increase and network traffic increases

Engineering Contradiction:
Improvecache consistencyVSAvoidquery response time
Core Design Contradiction:
Stability of the object's compositionVSLoss of time

Solution Approach 1:

The patent performs preliminary action by having resolver nodes proactively publish DNS records to the multicast group as soon as they are acquired from authoritative nameservers. This allows other nodes to obtain records before they would need to query authoritative nameservers themselves, reducing response times while maintaining consistency through the publish-subscribe model.

Inventive Principle:
Principle #10Preliminary action

Solution Approach 2:

The patent uses copying to propagate DNS records across the distributed cache system. When one resolver node obtains a DNS record, it creates copies and distributes them to other nodes via multicast communication. This copying mechanism maintains cache consistency across all nodes without requiring each node to independently query authoritative nameservers.

Inventive Principle:
Principle #26Copying

4Productivity

If multicast communication is implemented among DNS resolver nodes, then cache sharing is achieved and response times are reduced, but network complexity increases

Engineering Contradiction:
Improvequery response timeVSAvoidnetwork complexity
Core Design Contradiction:
ProductivityVSDevice complexity

Solution Approach 1:

The patent leverages the universality of multicast communication, which is already a standard network protocol supported by most modern networks. By using this existing infrastructure, the patent achieves complex distributed cache sharing functionality without adding significant network complexity, as multicast is handled natively by network devices rather than requiring custom protocols or infrastructure.

Inventive Principle:
Principle #6Universality (Multi-functionality)

Data Source

PatentUS11323414B2Managing domain name system (DNS) record cache across multiple DNS servers using multicast communication
Publication Date: 2022.05.03 CLOUDFLARE INC
  • US11323414B2 patent drawing
  • US11323414B2 patent drawing
  • US11323414B2 patent drawing

AI summary

A Domain Name System (DNS) resolver node receives a first DNS query from a first client device. The resolver node determines that it cannot answer the query using its local cache so it performs a recursive query to obtain the answer. The answer is sent to the first client and stored in its local cache. The resolver node further transmits the answer to multiple other resolver nodes that are part of the same cluster so they can update their respective local cache with the information. Upon receiving a message from another resolver node that includes a set of resource record(s) not in its local cache, the resolver node stores that set of resource record(s) in its local cache so that it can locally answer subsequent requests for those resource record(s) locally.