[Feature Request] Detect DNS Spoofing Attacks by Validating OPT Record Presence and Response Consistency

### Prerequisites

- [x] I have checked the [Wiki](https://github.com/AdguardTeam/AdGuardHome/wiki) and [Discussions](https://github.com/AdguardTeam/AdGuardHome/discussions) and found no answer

- [x] I have searched other issues and found no duplicates

- [x] I want to request a feature or enhancement and not ask a question

### The problem

**1. Problem Description**
In certain network environments, DNS spoofing/poisoning attacks are prevalent. An attacker on the path can intercept plain DNS queries and immediately inject forged responses, arriving before the legitimate response from the upstream resolver. This compromises DNS reliability where DoH/DoT is not enforced.

**2. Evidence from Packet Analysis**
I conducted live packet captures in a suspected hostile network. The analysis reveals a clear and consistent pattern distinguishing forged packets from real ones.

**Key Attack Patterns Observed:**
* **For Non-Address Record Queries (MX, SOA, NS, TXT, AAAA):** The attacker **ignores the query type** and consistently returns a **single forged A record**. The response **lacks an OPT (EDNS) record** and has a short, fixed TTL (often 60 seconds).
* **For Address Record Queries (A):** The attacker returns a matching A record type but with a **false IP address**. This response also **lacks an OPT record**.
* **Legitimate Responses:** The genuine response from the upstream resolver (e.g., 8.8.8.8, 9.9.9.9) consistently arrives later. It contains **correct record types**, often **multiple answers** for load balancing, and crucially, **includes an OPT record**.

**Illustrative Examples from Captures:**
* **Query for `google.com AAAA`:** The first, faster response was a spoofed `A record (46.82.174.69, TTL 60, no OPT)`. The later, legitimate response was the correct `AAAA record (2a00:1450:400e:810::200e, TTL 175, with OPT)`.
* **Query for `pixiv.net MX`:** The first response was a spoofed `A record (75.126.33.156, no OPT)`. The legitimate response arrived later with five correct `MX records` and an `OPT record`.

The complete packet capture files, a detailed analysis article, and a proof-of-concept implementation are referenced below for full technical details.

### Proposed solution

**3. Proposed Solution: Multi-Feature Validation**
A simple yet effective heuristic within AdGuardHome would be to assign a confidence score to responses based on these identifiable features:

1. **OPT Record Check (Highest Weight):** A response lacking an OPT record is highly suspicious.
2. **Record Type Consistency:** A response whose answer type does not match the query type is invalid.
3. **Answer Count & Structure:** For known major domains, a single A-record answer is less credible than multiple answers or answers accompanied by authority/additional sections.
4. **TTL Analysis:** A very short, fixed TTL (e.g., 60s) can be a supporting indicator.

**Implementation Suggestion:**
```yaml
# Suggested configuration addition
dns:
spoofing_protection:
enabled: true
check_opt_record: true # Primary filter
check_type_match: true # Basic RFC compliance
min_answers_common_domains: 2 # Heuristic for common domains
log_only_mode: false # Start by logging, then potentially rejecting
```

**4. Benefits & Impact**
* **High Accuracy:** Based on captured attacks, OPT record absence is a near-perfect identifier.
* **Low Cost:** Checking for an OPT record is a trivial iteration over the `Extra` section.
* **Backward Compatible:** Can be an optional feature, disabled by default.
* **Incremental:** Serves as a foundation for more advanced response validation (e.g., cross-upstream consistency checks).

### Alternatives considered and additional information

**5. References for Maintainers**
* **Detailed Analysis Article:** [https://www.yangdujun.top/opus/105](https://www.yangdujun.top/opus/105) – Documents the "Multi-feature Fusion Analysis" methodology.
* **Packet Capture Files:** [https://nas.yangdujun.top/api/public/dl/i56Jq-SC/%E6%8A%93%E5%8C%85%E6%95%B0%E6%8D%AE.pcapng](https://nas.yangdujun.top/api/public/dl/i56Jq-SC/%E6%8A%93%E5%8C%85%E6%95%B0%E6%8D%AE.pcapng) – Contains the raw files supporting the above claims.
* **Proof-of-Concept Demo:** [https://github.com/yandujun363/CleanDNS](https://github.com/yandujun363/CleanDNS) – A simple DNS proxy implementing the core idea of querying multiple upstreams and filtering based on OPT records. *(Note: This is a demo; not production-ready).*

**6. Conclusion**
Implementing a validation step based on the presence of OPT records and response consistency would allow AdGuardHome to effectively filter out a large class of common DNS spoofing attacks in plaintext DNS mode, significantly enhancing user security in adversarial networks. The provided evidence demonstrates the practicality of this approach.

I would be happy to provide further details, test builds, or assist in any way.