Description:
The Problem
Currently, plain text DNS queries (port 53) sent by the client suffer from significant and unnecessary latency. The existing flow forces these queries to travel the entire distance to the tunnel node:
Client (Port 53) > mhrv-rs TLS > GAS > Tunnel Node > Resolver > Tunnel Node > GAS > Client
For a simple DNS resolution, waiting for the packet to "sail across the Atlantic" to the tunnel node and back introduces a massive latency margin that degrades the initial connection experience.
Proposed Solution
We can build a lightweight, edge-based DNS resolver system directly within the Google Apps Script (GAS) deployment, utilizing a Google Spreadsheet as a caching database for DNS records.
Instead of routing DNS traffic to the tunnel node, GAS will intercept the query and handle it locally based on respected query TTLs.
The New Proposed Flow:
Client sends a plaintext DNS query via mhrv-rs TLS to the GAS deployment.
GAS checks the connected Google Spreadsheet (which acts as a DNS cache).
Cache Hit: If the requested domain exists in the sheet and the TTL is still valid, GAS immediately picks the answer and returns it to the client.
Cache Miss: If the record is missing or expired, GAS resolves the query directly using public resolvers (e.g., 1.1.1.2 or 8.8.8.8), stores the new record and its TTL in the spreadsheet for future access, and returns the answer to the client.
Advantages
Massive Latency Reduction: DNS queries are resolved much closer to the user, completely bypassing the geographical distance to the tunnel node.
Reduced Tunnel Load: Offloads repetitive DNS traffic from the main tunnel node, saving bandwidth and processing power.
Faster Browsing: The initial time-to-first-byte (TTFB) for users will drop significantly due to near-instant DNS resolution for cached domains.
Implementation Considerations
TTL Management: A cleanup function or simple logic is needed to ignore or overwrite rows in the spreadsheet where the TTL has expired.
Quota Management: We must be mindful of Google Apps Script execution times and UrlFetch/Sheets API daily quotas. Since GAS daily quotas reset at exactly 10:30 AM Tehran time, we should consider batching write requests or only caching highly requested domains to prevent hitting the daily write limit during peak usage hours before the reset.
Description:
The Problem
Currently, plain text DNS queries (port 53) sent by the client suffer from significant and unnecessary latency. The existing flow forces these queries to travel the entire distance to the tunnel node:
Client (Port 53) > mhrv-rs TLS > GAS > Tunnel Node > Resolver > Tunnel Node > GAS > Client
For a simple DNS resolution, waiting for the packet to "sail across the Atlantic" to the tunnel node and back introduces a massive latency margin that degrades the initial connection experience.
Proposed Solution
We can build a lightweight, edge-based DNS resolver system directly within the Google Apps Script (GAS) deployment, utilizing a Google Spreadsheet as a caching database for DNS records.
Instead of routing DNS traffic to the tunnel node, GAS will intercept the query and handle it locally based on respected query TTLs.
The New Proposed Flow:
Client sends a plaintext DNS query via mhrv-rs TLS to the GAS deployment.
GAS checks the connected Google Spreadsheet (which acts as a DNS cache).
Cache Hit: If the requested domain exists in the sheet and the TTL is still valid, GAS immediately picks the answer and returns it to the client.
Cache Miss: If the record is missing or expired, GAS resolves the query directly using public resolvers (e.g., 1.1.1.2 or 8.8.8.8), stores the new record and its TTL in the spreadsheet for future access, and returns the answer to the client.
Advantages
Massive Latency Reduction: DNS queries are resolved much closer to the user, completely bypassing the geographical distance to the tunnel node.
Reduced Tunnel Load: Offloads repetitive DNS traffic from the main tunnel node, saving bandwidth and processing power.
Faster Browsing: The initial time-to-first-byte (TTFB) for users will drop significantly due to near-instant DNS resolution for cached domains.
Implementation Considerations
TTL Management: A cleanup function or simple logic is needed to ignore or overwrite rows in the spreadsheet where the TTL has expired.
Quota Management: We must be mindful of Google Apps Script execution times and UrlFetch/Sheets API daily quotas. Since GAS daily quotas reset at exactly 10:30 AM Tehran time, we should consider batching write requests or only caching highly requested domains to prevent hitting the daily write limit during peak usage hours before the reset.