Skip to content

Add optional DNS validation to filter out fake SNI targets#43

Open
noleston wants to merge 1 commit into
XTLS:mainfrom
noleston:dns-resolve
Open

Add optional DNS validation to filter out fake SNI targets#43
noleston wants to merge 1 commit into
XTLS:mainfrom
noleston:dns-resolve

Conversation

@noleston

Copy link
Copy Markdown

Add optional DNS validation to filter out fake SNI targets

*Note: This PR is a redesigned and fully explained version of the closed #27

Problem & Background

RealiTLScanner is used to find suitable destination (dest) and SNI (serverNames) pairs for VLESS Reality. The goal is to find legitimate websites hosted on the same hosting provider/subnet as the user's VPS to masquerade under them.

Why this feature is needed now:

  1. Shifting to smaller hosters: In censored environments (like Russia with their TSPU system), large hosting providers such as Hetzner or OVH suffer from severe traffic filtering and connection degradation (e.g., the 16KB connection limit). This forces users to deploy their VPS on smaller, budget, or less popular hosting providers.
  2. Subnets flooded with fake SNIs: When scanning these smaller VPS subnets, the scanner returns dozens of "feasible" targets presenting certificates for popular domains (like google.com, microsoft.com, apple.com, vk.com).
  3. Existing Reality servers as false positives: Since these large companies do not host their infrastructure on cheap VPS providers, these IPs are actually other users existing VLESS + Reality servers masquerading under stolen/cloned certificates. When RealiTLScanner handshakes with them, they forward the handshake to the real domain, tricking the scanner into returning them as valid destinations.

Addressing the doubts in #27

In #27, the question was raised: "Even if the IP doesn't match the DNS record, you can still use it as a fallback target. What is the practical benefit of filtering this?"

While connecting to such a target technically "works" (the handshake succeeds), using them as a Reality destination is highly counterproductive for two reasons:

  1. Eliminating False Positives: Returning other people's temporary proxies defeats the purpose of the scanner. The goal is to find stable, legitimate, local websites, not "nested" proxy servers that can disappear at any moment.
  2. Reducing Detection & Subnet Risks: Big websites (like Google, Microsoft, or Apple) do not host their infrastructure on cheap VPS subnets. Using a cheap VPS IP while pretending to be Google is a glaring anomaly that censors easily detect, leading to immediate blocking. Furthermore, having multiple users set up masquerading under these popular domains on the same small subnet draws censor attention and risks a subnet-wide ban, ruining the hoster for everyone.

The Solution

This PR adds a -resolve-domains flag (disabled by default).

When enabled, the scanner:

  1. Extracts the certificate domain name (preferring DNSNames[0], falling back to Subject.CommonName).
  2. DNS-resolves the domain to its actual A/AAAA records.
  3. Discards the target if the scanned IP is not present in those records.

Implementation Details

  • Caching: DNS resolutions are cached thread-safely using sync.RWMutex. Only successful resolutions are stored to prevent permanent domain filtering caused by temporary network timeouts.
  • Resolver Protection: We use golang.org/x/sync/singleflight to prevent duplicate concurrent DNS requests for the same domain, protecting the local resolver from overload during high-thread scans.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant