DNS Name Server TEE Ledger Authentication
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Current DNS systems face integrity issues due to vulnerabilities in DNS servers, lack of widespread DNSSEC adoption, and complexities in key management for authenticity and integrity, particularly in ensuring that DNS resolution results are trustworthy and not susceptible to man-in-the-middle attacks.
Innovation Solution
Implementing a device and method where a name server operates within a Trusted Execution Environment (TEE) to authenticate DNS responses using a shared public/private key pair, ensuring the integrity of DNS records by reading them from a common ledger shared among multiple name servers, and allowing for a hybrid approach that integrates with both traditional and blockchain-based DNS systems.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Reliability
If DNSSEC is used to sign DNS records, then integrity of DNS records is improved, but coverage is limited since only a fraction of DNS zones are signed
Solution Approach 1:
The patent introduces a recursive resolver as an intermediary that performs DNSSEC validation and acts as a trusted source for unsigned zones. This mediator bridges the gap between signed and unsigned zones by validating signed records and providing authenticated responses for both types, thereby extending integrity coverage beyond just signed zones.
2Reliability
If DNSCrypt is used to authenticate DNS responses, then authenticity is improved, but key management complexity increases when multiple resolvers are used
Solution Approach 1:
The patent combines DNSSEC cryptographic validation with DNSCrypt-style authenticated responses in a unified system. The recursive resolver merges these approaches by using DNSSEC keys for validation and providing authenticated responses that work across multiple resolvers, reducing key management complexity while maintaining authenticity.
Solution Approach 2:
The recursive resolver is designed to handle both DNSSEC-signed and unsigned zones universally, providing authenticated responses for all queries. This multi-functional approach allows a single resolver to serve multiple purposes (validation and authentication) without requiring separate key management systems.
3Ease of operation
If a centralized DNS service is used, then ease of operation is improved, but vulnerability to DDoS attacks and service downtime increases
Solution Approach 1:
The patent segments the DNS system into hierarchical components (root servers, TLD servers, authoritative name servers, and recursive resolvers) where each segment maintains DNSSEC signatures independently. This segmentation allows the system to remain operational even if some segments are attacked, as other segments can still provide authenticated responses.
4Reliability
If multiple key pairs are distributed to clients for multiple resolvers, then authenticity verification is improved, but security is lowered and administration becomes more complex
Solution Approach 1:
The system enables self-service authentication where the recursive resolver automatically performs DNSSEC validation and generates authenticated responses without requiring manual key distribution to clients. The resolver serves itself by maintaining the necessary keys and cryptographic material, eliminating the need for complex key distribution administration.
Data Source
AI summary
A method for resolving domain names, where a name server is configured to receive a query for a domain name system (DNS) record from a stub resolver, where a public key or certificate held by the stub resolver matches a private key of the name server. The name server runs the query for a DNS record by executing code in a trusted execution environment. Instead of recursively resolving the query for a DNS record as is common practice, the name server reads the DNS record corresponding to the query from a ledger. At last the name server prepares an authenticated response to the stub resolver by authenticating the response comprising the read DNS record with its private key, wherein the private/public key pair or alternatively private key and matching certificate are protected and distributed with the at least another name server via the common ledger.