Add optional DNS validation to filter out fake SNI targets

[noleston]

Add optional DNS validation to filter out fake SNI targets

Note

• This PR is a redesigned and fully explained version of the closed Checking the IP and CN address match #27.
• It directly addresses and implements the features requested by the community in Add options to resolve IP-addresses of cert-domains and filter by their IP-subnet #21 (DNS resolution of cert-domains) and Please add DNS probing for skip other reality servers #34 (skipping other Reality servers via DNS probing).

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:

• Shifting to smaller hosters: In censored environments (like Russia with their TSPU DPI 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 ASNs.
• 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, apple.com, yahoo.com, vk.com).
• 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, it receives a forwarded handshake, tricking the scanner into returning them as valid destinations. (This behavior and the need to filter them has been highlighted by users in Add options to resolve IP-addresses of cert-domains and filter by their IP-subnet #21 and Please add DNS probing for skip other reality servers #34).

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 and currently dangerous for the entire hoster, for the following reasons:

1. Eliminating False Positives (Unstable Targets): 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 be reconfigured or shut down by their owners at any moment.
2. Active DPI Triggers (The SNI Marker Issue): Using popular domains (google.com, icloud.com, etc.) on a cheap VPS IP is no longer just an "anomaly" — it is a known circumvention marker for DPI systems (like TSPU). Censors now actively identify VLESS+Reality specifically by checking these "exposed" popular SNIs mismatching their ASNs.
3. Subnet-wide Bans & TOS Violations: DPI systems often respond to these glaring anomalies not by blocking a single IP, but by blocking the entire /24 subnet. Because of this, hosting providers have started sending TOS Violation notices and suspending accounts of users who use large public domains for SNI masking, as one user's configuration ruins network accessibility for the entire subnet.

Filtering out these fake targets is now a necessity for stealth and server survival.

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.

[Puskagruz2010]

Great write-up, this matches something I ran into today running RealiTLScanner against a Timeweb Frankfurt /24 — the scan returned several *.yandex.tr and *.beeline.ru results that were obviously other Reality servers impersonating those brands, not real infrastructure. The -resolve-domains approach here would've caught that automatically instead of a manual dig check.
One related thing I hit that's a bit different from target selection — after picking a legitimate, correctly-resolving small site as target, repeatedly testing the Reality fallback path with curl/openssl s_client during debugging got our server's IP temporarily rate-limited by the target site's own WAF/anti-abuse — nothing to do with censorship, just the site reacting to an unusual TLS pattern from one IP. Looked identical to "Reality is down" from the outside while real client connections kept working the whole time. Might be worth a one-line note in the README (once this merges) warning not to hammer the fallback target directly when debugging.