DNS Whitelist Update via Encoded Queries
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Traditional methods for maintaining whitelists to access blocked websites are slow and burdensome for users, as they require manual cache flushing or centralized updates, and do not respect the Time to Live (TTL) of DNS records, leading to issues with accessing blacklisted sites.
Innovation Solution
A computer-implemented method and system that automatically adds a blacklisted site to a whitelist by generating whitelisting queries with a unique nonce, cryptographic hash, and static domain, sent through recursive DNS servers to update the whitelist without requiring user intervention or centralized distribution, allowing for faster access to blocked sites.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Reliability
If traditional centralized whitelist updates are used, then whitelist management is centralized and controlled, but user access speed is slow
Solution Approach 1:
The centralized whitelist management system is segmented into distributed DNS servers that independently maintain and update whitelist information. Each DNS server can autonomously process whitelist updates without waiting for centralized distribution, enabling parallel processing and faster user access while maintaining control through the distributed architecture.
Solution Approach 2:
The patent combines the whitelist management function with the existing DNS infrastructure, merging two previously separate systems (centralized whitelist management and distributed DNS resolution) into a unified system where whitelist updates are propagated through the DNS server network, eliminating the need for separate update mechanisms.
2Speed
If browsers maintain their own DNS caches, then DNS lookup speed is improved, but cache invalidation becomes problematic when IP addresses change
Solution Approach 1:
The system implements feedback mechanisms where DNS servers monitor TTL expiration and actively push whitelist update notifications to clients. When a whitelist entry's TTL expires or the IP address changes, the DNS server detects this through continuous monitoring and sends feedback to invalidate the client's cache, ensuring cache validity while maintaining fast lookup speeds.
Solution Approach 2:
The system performs preliminary actions by pre-loading whitelist information into DNS server caches with associated TTL values before clients need to access the information. This allows clients to quickly retrieve whitelist data from DNS server caches without repeated full lookups, while the preliminary setting of TTL values prepares the system for automatic cache invalidation when entries expire.
3Ease of operation
If users manually flush browser caches or restart browsers, then access to unblocked sites is achieved, but user experience becomes burdensome
Solution Approach 1:
The system implements self-service by automatically detecting when clients need whitelist updates and pushing updates to them without user intervention. The DNS servers monitor for TTL expirations and actively contact clients to provide updated whitelist information, eliminating the need for users to manually flush caches or restart browsers while maintaining easy access to unblocked sites.
Data Source
AI summary
A method for adding a blacklisted site to a whitelist. At least one whitelisting query may be generated for an encoded domain in the tag format: a nonce, a hash, a blocked-domain, and a static domain, each separated by a delimiter. The nonce is a unique identifier for the at least one query. The hash is a cryptographic hash of an IP address of the user, a normalized timestamp, and the blocked domain. The static domain is a constant domain representing the at least one query. The at least one query may be sent to a first recursive DNS server. The first recursive DNS server may create a message including whitelist information. The first recursive DNS server may send the message to a second recursive DNS server.