Add docs/RFC-conformance.md: Level 1 authoritative UDP subset

[Copilot]

Adds a precise, implementation-grounded conformance document mapping every DNS query scenario handled by the server to the relevant RFC sections, explicitly distinguishing correct behavior from known gaps.

New file: docs/RFC-conformance.md

• §2 Scope — IN class only, UDP only, authoritative-only, configured zones only; explicit non-goals list (TCP, recursion, EDNS0, AXFR, AAAA, dynamic update)
• §3 Level 1 subset — transport, zone matching logic, header flag contract (QR=1, AA=1, RA=0), and health-driven NXDOMAIN semantics
• §4 Behavior matrix — one row per scenario (wire parse failure, QDCOUNT=0, QDCOUNT>1, non-QUERY opcode, non-IN class, outside-zone, NXDOMAIN, NODATA, positive A/NS/SOA, health-removed name) with RCODE, authority section content, and exact RFC section citations
• §5 RFC mapping — per-RFC cross-reference table (RFC 1034 §3.7/§4.3.1; RFC 1035 §3.2.1, §3.2.2, §3.3.11, §3.3.13, §4.1, §4.1.1, §4.1.2, §4.3.1, §4.3.2; RFC 2181 §5; RFC 2308 §2, §2.1, §3; RFC 7766 §5)
• §6 Known gaps — each deviation from RFC guidance tracked with code location and a concrete future-extension statement:
  • Outside-zone → NXDOMAIN instead of REFUSED (RFC 1035 §4.3.1) — dns_server_udp_handler.py:32-37
  • SOA absent from authority on all negative responses (RFC 2308 §3) — dns_server_udp_handler.py:32-54
  • QDCOUNT > 1 silently answered instead of FORMERR — :81-84
  • Non-QUERY opcodes not rejected with NOTIMP — :81
  • Non-IN class not explicitly rejected — :46
  • No TC-bit / truncation handling

Updated: docs/table-of-contents.md

Registers docs/RFC-conformance.md in the Reference section.

Original prompt

You are working inside an existing Pull Request on this repository.

First, review:

• the current PR diff
• AGENTS.md
• existing docs structure and indexing/navigation conventions
• the DNS server documentation already present in README/docs

Task:
Add the initial RFC conformance document at:

• docs/RFC-conformance.md

Goal:
Create a precise, implementation-oriented, extensible conformance document for the project’s current “Level 1 authoritative UDP subset”.

This document must:

• define the current supported behavior without claiming full DNS conformance
• explicitly map each behavioral rule to the relevant RFCs and RFC section numbers
• clearly distinguish:
  • implemented behavior
  • intentional limitations
  • project choices within RFC bounds
  • non-goals / known scope limits

Cover at least:

• supported transport: UDP only
• authoritative scope: configured primary zones and alias zones only
• supported class: IN only
• supported opcode: QUERY only
• positive answer types served: A, SOA, NS
• behavior for unsupported-but-valid QTYPEs on existing names
• behavior for in-zone nonexistent names
• behavior for names outside served zones
• behavior for malformed queries
• behavior for multi-question queries
• high-level header-bit expectations
• health-driven semantics when all A records for a configured name disappear from the live zone

Use this Level 1 policy:

• outside served zones: REFUSED
• in-zone missing owner name: NXDOMAIN
• existing owner but queried type absent: NOERROR with empty answer and SOA in authority
• malformed or unsupported query structure: FORMERR where appropriate
• unsupported opcode: NOTIMP
• only IN class is supported
• QDCOUNT must be exactly 1
• negative in-zone responses include apex SOA in authority

RFC requirements:

• For every behavioral rule, cite the relevant RFC section number(s), not just RFC numbers.
• If a rule is a project choice within RFC bounds, state that explicitly.
• If the project is intentionally limited in scope, state that explicitly.
• Avoid vague citations when exact section references can be given.

At minimum, evaluate relevance of:

• RFC 1034
• RFC 1035
• RFC 2181
• RFC 2308
• RFC 7766

Use only RFCs actually relevant to the documented behaviors.

Preferred structure:

• Purpose and scope
• Conformance scope and non-goals
• Level 1 authoritative UDP subset
• Behavior matrix
• RFC mapping by behavior
• Known limitations / future extensions

Preferred format:
Use a main behavior matrix table with columns similar to:

• Area
• Query/scenario
• Implemented behavior
• RCODE / section expectations
• Driving RFC(s) and section(s)
• Notes

Scope:

• documentation only
• no production code changes in this task

Deliver:

1. docs/RFC-conformance.md
2. any required docs indexing/navigation updates
3. a short PR-style summary:
   • files changed
   • documented Level 1 behavior set
   • RFCs and section numbers referenced
   • any ambiguities intentionally left open

---

✨ Let Copilot coding agent set things up for you — coding agent works faster and does higher quality work when set up for your repo.