feat(core): complete draft-02 flat-FQDN migration across all surfaces

Ships the full draft-mozleywilliams-dnsop-dnsaid-02 wire-format
migration as a single 0.24.0 release.

The bulk of this work was authored by Nick Williams (@nicknacnic) and
is consolidated here from his draft-02 stack so the migration lands as
one reviewable, releasable unit instead of a five-deep PR chain. Full
credit to Nick for the underlying implementation -- see the
Co-authored-by trailer.

## Wire format (-01 -> -02)

- Flat primary owner record at {name}.{domain} -- a valid x.509 SAN
  dNSName. The agent protocol no longer travels in the FQDN; it lives
  in the SVCB bap SvcParamKey (or alpn when single-protocol). SVCB and
  companion TXT are written at the flat owner on every publish.
- Optional walkable AliasMode at {name}._agents.{domain} pointing at
  the flat owner. Off by default under -02 to avoid an enumeration
  handle (see docs/privacy-considerations.md); opt in per-publish via
  publish_walkable_alias=True, the CLI --walkable flag, or the MCP
  kwarg.
- Per-call legacy -01 fallback via allow_legacy on discover() /
  discover_at_fqdn(); results stamped legacy_resolved=True. The
  process-wide DNS_AID_LEGACY_01_FALLBACK=1 env form is preserved and
  now logs on each use.
- Single FQDN parser dns_aid.core.fqdn.parse_dnsaid_fqdn recognising
  flat, walkable, and legacy shapes; discoverer and telemetry parse
  paths are thin projections over it.

## SvcParamKeys

- New well-known SvcParamKey at the project's interim private-use code
  point key65409 (final IANA assignment deferred per draft 7.1).
  Reconstructed as https://<svcb-target>/.well-known/<value> and
  fetched as the capability descriptor; absolute-path values per
  Figure 3 are honoured without double-prefixing. validate_well_known_path
  constrains the value to a traversal- and injection-safe class on
  both publish and discover.
- Scalar bap per draft 5.1: bare (mcp, a2a) or =-versioned (mcp=1.0).
  A field validator on both models closes a SvcParam quoting break-out
  (a crafted value such as mcp" key65500="x used to inject a sibling
  key through to_params()). normalize_bap collapses legacy comma/list
  inputs onto the canonical scalar across discoverer, SDK, and indexer.

## Trust path

- JWS record signature binds to (fqdn, target, port, alpn). A valid
  signature lifted off one record and pasted onto a spoofed SVCB is
  rejected at the binding check. The binding comparison is
  DNS-normalized (case-insensitive, trailing-dot-insensitive) so a
  legitimately-signed dotted or mixed-case endpoint is not falsely
  rejected.
- cap-sha256 mismatch refuses the record (CapDigestMismatchError)
  instead of silently downgrading to TXT; cap_sha256_verified marks
  when the pin was actually applied.
- DANE score gates on DNSSEC (RFC 6698 10.1): a TLSA record without a
  DNSSEC chain no longer credits +15 to security_score.
- TargetName underscore validator rejects underscored endpoint labels
  by default (CA/Browser-Forum BR + RFC 5280 dNSName conformance),
  with an operator-only bypass requiring both DNS_AID_ALLOW_UNDERSCORE_TARGET=1
  and the per-call flag.

## Completion fixes (this consolidation)

- validate_fqdn accepts the flat owner {name}.{domain}. It previously
  required a literal _agents label and rejected every flat FQDN, so
  the MCP verify_agent_dns tool could not verify a draft-02 agent. It
  now validates a well-formed multi-label DNS name (flat, walkable,
  legacy, and index shapes all pass) and remains the sole input guard
  at the MCP boundary.
- CLI and MCP surfaces emit the flat owner name -- delete/search
  output, the MCP unpublish result, and list_agent_index now show
  {name}.{domain} instead of the legacy nested name.
- index sync enumerates flat primary owners. It previously discovered
  agents only via the walkable AliasMode or legacy shape, so a flat-only
  agent (the draft-02 default publish shape) was silently dropped from
  the index. It now detects flat owners by their companion TXT record,
  reads the protocol off the SVCB SvcParams, and dedups against any
  walkable alias for the same agent.
- Discovery reconciles the agent protocol from the SVCB record. The
  protocol lives in the record (bap, or alpn) under draft-02, not the
  FQDN. The discoverer now stamps the record's true protocol on every
  path (discover_at_fqdn, the zone-walk, the HTTP index), so a
  default-published a2a/https agent (alpn, no bap) is no longer
  mislabeled mcp -- which previously failed the JWS binding check and
  picked the wrong handler. The zone-walk dedups by (fqdn, protocol).
- parse_dnsaid_fqdn accepts a flat owner in a two-label zone
  (agent.internal) and normalizes case + a trailing dot up front.
- Docs, CHANGELOG, CITATION, and the package version (0.23.0 -> 0.24.0)
  updated to the flat shape.

## Production hardening

- SVCB SvcParam injection closed on every free-form field. The bap
  validator already blocked quote break-out injection; the same guard
  now applies to cap / cap-sha256 / policy / realm / sig / connect-meta /
  enroll-uri on both models, so a forged value cannot inject a sibling
  SvcParamKey into the authoritative record via the presentation-format
  backends.
- JWKS fetch is SSRF-guarded, size-capped (64 KB), redirect-free, and the
  per-process cache is bounded. JWS verification pins alg=ES256 (rejects
  none/RSA) and the key to a P-256 EC signing key with 32-byte
  coordinates -- closing algorithm/curve confusion on the attacker-
  influenceable JWKS path.
- The HTTP agent index fetch is bounded in body size (1 MB) and agent
  count (500) so a hostile index can't OOM or amplify the per-agent
  fan-out.

## Verification

Full local gate run green: ruff, ruff format, mypy (83 source files),
bandit (0 issues), and 1890 unit/integration tests. Verified end to end
across the CLI, MCP, and SDK surfaces against live Route53 and a local
BIND9/DDNS backend (publish -> discover -> verify -> delete round-trips,
flat-owner resolution, protocol reconciliation for a2a/mcp/https,
signature binding, index round-trip); NIOS WAPI lifecycle validated on
the same code paths. The JWKS hardening was validated live over real TLS
sockets and real ES256 crypto: SSRF guard blocks a loopback JWKS, the
full sign -> fetch -> verify chain succeeds, the streaming size cap
rejects an oversized document, and alg/curve confusion is refused.

Breaking changes (strict underscore TargetName validator, scalar bap,
and the -01 -> -02 default flip) are documented with migration notes
in CHANGELOG [0.24.0].

Co-authored-by: Layer8 <NWillAU900@gmail.com>
Signed-off-by: Igor Racic <iracic82@gmail.com>

Author: iracic82

CHANGELOG.md

@@ -13,8 +13,8 @@ authors:
     given-names: Ingmar
     affiliation: Infoblox
 
-version: "0.23.0"
-date-released: "2026-05-26"
+version: "0.24.0"
+date-released: "2026-06-04"
 
 keywords:
   - dns

CITATION.cff

@@ -9,28 +9,12 @@
 [![Python](https://img.shields.io/badge/python-3.11%20%7C%203.12%20%7C%203.13-blue)](https://www.python.org/)
 [![PyPI](https://img.shields.io/pypi/v/dns-aid)](https://pypi.org/project/dns-aid/)
 
-<!-- mcp-name: io.github.dns-aid/dns-aid -->
-
 **DNS-based Agent Identification and Discovery**
 
-Reference implementation of the DNS-AID specification, developed at the IETF: https://datatracker.ietf.org/doc/draft-mozleywilliams-dnsop-dnsaid/.
+Reference implementation for [IETF draft-mozleywilliams-dnsop-dnsaid-02](https://datatracker.ietf.org/doc/draft-mozleywilliams-dnsop-dnsaid/).
 
 DNS-AID enables AI agents to discover each other via DNS, using the internet's existing naming infrastructure instead of centralized registries or hardcoded URLs.
 
-## Relationship to IETF
-
-The DNS-AID specification is being developed within the IETF: https://datatracker.ietf.org/doc/draft-mozleywilliams-dnsop-dnsaid/.
-
-This repository provides a reference implementation.
-
-This project does not define the specification. The IETF draft is authoritative.
-
-## Scope of this Repository
-
-This project focuses on implementation, tooling, and ecosystem activities.
-
-Changes to protocol behavior should be discussed within the IETF.
-
 > **New to DNS-AID?** Start with the [Getting Started Guide](docs/getting-started.md) for install, first agent publication, and backend setup.
 
 ## Documentation
@@ -97,7 +81,7 @@ result = await dns_aid.discover(
 )
 
 # Verify an agent's DNS records
-result = await dns_aid.verify("_my-agent._mcp._agents.example.com")
+result = await dns_aid.verify("my-agent.example.com")
 print(f"Security Score: {result.security_score}/100")
 ```
 
@@ -278,7 +262,7 @@ dns-aid discover example.com --use-http-index
 dns-aid discover example.com --json
 
 # Verify DNS records
-dns-aid verify _my-agent._mcp._agents.example.com
+dns-aid verify my-agent.example.com
 
 # List DNS-AID records in a zone
 dns-aid list example.com
@@ -397,7 +381,7 @@ agents = await dns_aid.discover("example.com", use_http_index=True)
 | **DNS (default)** | Maximum decentralization, offline caching, minimal round trips |
 | **HTTP Index** | Rich metadata upfront, ANS compatibility, model cards, capabilities, direct endpoints |
 
-**FQDN as Source of Truth (v0.4.7):** The HTTP index only needs to provide each agent's FQDN (e.g., `_booking._mcp._agents.example.com`). Agent name and protocol are extracted from the FQDN — no separate `protocols` field needed. DNS SVCB lookup then resolves the authoritative endpoint.
+**FQDN as Source of Truth (v0.4.7):** The HTTP index only needs to provide each agent's FQDN (e.g., `booking.example.com`). Agent name and protocol are extracted from the FQDN — no separate `protocols` field needed. DNS SVCB lookup then resolves the authoritative endpoint.
 
 **Discovery Transparency (v0.4.6+):** Each discovered agent includes source fields showing how data was resolved:
 
@@ -491,14 +475,14 @@ Claude will:
 DNS-AID uses SVCB records (RFC 9460) to advertise AI agents:
 
 ```
-_chat._a2a._agents.example.com. 3600 IN SVCB 1 chat.example.com. alpn="a2a" port=443 mandatory="alpn,port"
-_chat._a2a._agents.example.com. 3600 IN TXT "capabilities=chat,assistant" "version=1.0.0"
+chat.example.com. 3600 IN SVCB 1 chat.example.com. alpn="a2a" port=443 mandatory="alpn,port"
+chat.example.com. 3600 IN TXT "capabilities=chat,assistant" "version=1.0.0"
 ```
 
 **DNS-AID Custom SVCB Parameters (v0.4.8+):** Per the IETF draft, SVCB records can carry additional custom parameters for richer agent metadata:
 
 ```
-_booking._mcp._agents.example.com. SVCB 1 mcp.example.com. alpn="mcp" port=443 \
+booking.example.com. SVCB 1 mcp.example.com. alpn="mcp" port=443 \
     cap="https://mcp.example.com/.well-known/agent-cap.json" \
     cap-sha256="dGVzdGhhc2g" bap="mcp/1,a2a/1" \
     policy="https://example.com/agent-policy" realm="production"
@@ -526,7 +510,7 @@ This allows any DNS client to discover agents without proprietary protocols or c
   │  Step 1: Fetch HTTP Index (primary)                             │
   │  ──────────────────────────────────                             │
   │  GET https://index.aiagents.salesforce.com/index-wellknown      │
-  │  Response: [{"fqdn":"_chat._a2a._agents.salesforce.com",...}]   │
+  │  Response: [{"fqdn":"chat.salesforce.com",...}]   │
   │                                                                 │
   │  Fallback: Query TXT Index via DNS                              │
   │  Query: _index._agents.salesforce.com TXT                       │
@@ -536,7 +520,7 @@ This allows any DNS client to discover agents without proprietary protocols or c
   ┌──┴──────────────────────────────────────────────────────────────┐
   │  Step 2: Query SVCB per agent                                   │
   │  ────────────────────────────                                   │
-  │  Query: _chat._a2a._agents.salesforce.com SVCB                  │
+  │  Query: chat.salesforce.com SVCB                  │
   │  Response: SVCB 1 chat.salesforce.com. alpn="a2a" port=443      │
   │            cap="https://chat.salesforce.com/.well-known/cap.json"│
   │  (DNSSEC validated)                                             │
@@ -553,7 +537,7 @@ This allows any DNS client to discover agents without proprietary protocols or c
   ┌──┴──────────────────────────────────────────────────────────────┐
   │  Step 3: TXT Capabilities (fallback if no cap document)         │
   │  ──────────────────────────────────────────────────             │
-  │  Query: _chat._a2a._agents.salesforce.com TXT                   │
+  │  Query: chat.salesforce.com TXT                   │
   │  Response: "capabilities=chat,support" "version=1.0.0"          │
   └──┬──────────────────────────────────────────────────────────────┘
      │                            │                               │
@@ -1025,9 +1009,81 @@ Cloudflare DNS is ideal for demos, workshops, and quick prototyping thanks to it
 - **Simple API**: Well-documented REST API v4
 - **Full DNS-AID compliance**: Supports ServiceMode SVCB with all parameters
 
-## Background and Comparison
+## Why DNS-AID?
+
+### vs Competing Proposals
+
+| Approach | Problem | DNS-AID Advantage |
+|----------|---------|-------------------|
+| **ANS (GoDaddy)** | Centralized registry, KYC required, single gatekeeper | Federated — you control your domain, publish instantly |
+| **Google (A2A + UCP)** | Discovery via Gemini/Search, payments via UCP | Neutral discovery — no platform lock-in or transaction fees |
+| **.agent gTLD** | Requires ICANN approval, ongoing domain fees | Works NOW with domains you already own |
+| **AgentDNS (China Telecom)** | Requires 6G infrastructure, carrier control | Works NOW on existing DNS infrastructure |
+| **NANDA (MIT)** | New P2P overlay network, new ops paradigm | Uses infrastructure your DNS team already operates |
+| **Web3 (ERC-8004)** | Gas fees, crypto wallets, enterprise-hostile | Free DNS queries, no blockchain complexity |
+| **ai.txt / llms.txt** | No integrity verification, free-form JSON | DNSSEC cryptographic verification, structured SVCB |
+
+### Feature Comparison
+
+| Feature | DNS-AID | Central Registry | ai.txt |
+|---------|---------|------------------|--------|
+| **Decentralized** | ✅ | ❌ | ✅ |
+| **Secure (DNSSEC)** | ✅ | Varies | ❌ |
+| **Sovereign** | ✅ | ❌ | ✅ |
+| **Standards-based** | ✅ (IETF) | ❌ | ❌ |
+| **Works with existing infra** | ✅ | ❌ | ✅ |
+
+### The Sovereignty Question
+
+> **Who controls agent discovery?**
+> - ANS: GoDaddy (US company as gatekeeper)
+> - AgentDNS: China Telecom (state-owned carrier)
+> - Web3: Ethereum Foundation
+> - **DNS-AID: You control your own domain**
+>
+> DNS-AID preserves sovereignty. Organizations and nations maintain control over their own agent namespaces with no central authority that can block, censor, or surveil agent discovery.
+
+### Google's Agent Ecosystem
+
+Google is building a full-stack agent platform: **A2A** (communication), **UCP** (payments), and **Gemini/Search** (discovery). While A2A is an open protocol, discovery through Google surfaces means:
+- Google controls visibility (pay-to-rank)
+- Transaction fees via [UCP](https://developers.google.com/merchant/ucp)
+- Platform dependency for reach
+
+**DNS-AID complements A2A** by providing neutral, decentralized discovery — find agents anywhere, not just through Google.
+
+### Understanding the .agent Domain Approach
+
+The [Agent Community](https://agentcommunity.org/) is pursuing a `.agent` top-level domain through ICANN's [new gTLD program](https://newgtlds.icann.org/). Here's how the two approaches compare:
+
+**How .agent Domains Would Work:**
+1. Apply to ICANN for `.agent` gTLD (~$185,000 application fee)
+2. Wait 9-20 months for ICANN approval process
+3. Build registry infrastructure (Open Agent Registry, Inc.)
+4. Sell `.agent` domains through accredited registrars
+5. Users pay annual registration fees (~$15-50/year per domain)
+
+**How DNS-AID Works:**
+1. Use your existing domain (you already own `yourcompany.com`)
+2. Add DNS-AID records to your zone (`myagent.yourcompany.com`)
+3. Start discovering and being discovered immediately
+
+| Factor | .agent gTLD | DNS-AID |
+|--------|-------------|---------|
+| **Cost to publish** | ~$15-50/year domain fee | Free (use existing domain) |
+| **Time to start** | Months (gTLD launch + registration) | Minutes |
+| **Who controls discovery** | Registry operator | You (your domain) |
+| **Works today** | ❌ Pending ICANN approval | ✅ Works now |
+| **Requires new infrastructure** | ✅ Registry, registrars | ❌ Uses existing DNS |
+| **Memorable names** | ✅ `myagent.agent` | `myagent.example.com` |
+
+**The Friendly Take:**
+
+Both approaches share the goal of making AI agents discoverable. The `.agent` gTLD creates a dedicated namespace that's easy to remember (`mycompany.agent`), while DNS-AID leverages existing infrastructure so you can start publishing agents today.
+
+DNS-AID doesn't require waiting for ICANN approval or paying for new domains—it works with the DNS infrastructure your organization already operates. If you own `example.com`, you can publish agents to `myagent.example.com` right now.
 
-For background on how DNS-AID compares to other agent-discovery approaches (ANS, Google A2A+UCP, `.agent` gTLD, AgentDNS, NANDA, Web3, `ai.txt`) and "The Sovereignty Question", see [docs/positioning.md](docs/positioning.md). That content is non-normative — protocol positioning is determined at the IETF.
+*Fun fact: When `.agent` domains become available, DNS-AID records will work on them too! The approaches are complementary.*
 
 ## Examples
 
@@ -1076,6 +1132,6 @@ Apache 2.0
 
 ## Contributing
 
-Contributions welcome! This project supports an implementation ecosystem with planned hosting in the Linux Foundation. The DNS-AID specification is developed in the IETF.
+Contributions welcome! This project is intended for contribution to the Linux Foundation Agent AI Foundation.
 
 See [CONTRIBUTING.md](CONTRIBUTING.md) for guidelines.

README.md

@@ -84,7 +84,7 @@ async def main():
     discovery = await discover("example.com", protocol=Protocol.MCP)
 
     # Verify an agent's DNS records
-    verification = await verify("_my-agent._mcp._agents.example.com")
+    verification = await verify("my-agent.example.com")
 
 asyncio.run(main())
 ```
@@ -168,8 +168,9 @@ else:
 
 #### DNS Records Created
 
-- **SVCB**: `_{name}._{protocol}._agents.{domain}` → Service binding record
-- **TXT**: `_{name}._{protocol}._agents.{domain}` → Capabilities and metadata
+- **SVCB**: `{name}.{domain}` (draft-02 flat primary owner) → Service binding record
+- **SVCB (AliasMode, optional)**: `{name}._agents.{domain}` → walkable AliasMode pointer at the flat primary owner (suppressible via `publish_walkable_alias=False`)
+- **TXT**: `{name}.{domain}` → Capabilities and metadata (alongside the primary SVCB)
 
 ---
 
@@ -305,7 +306,7 @@ async def verify(fqdn: str) -> VerifyResult
 
 | Parameter | Type | Required | Description |
 |-----------|------|----------|-------------|
-| `fqdn` | `str` | Yes | Fully qualified domain name (e.g., "_chat._mcp._agents.example.com") |
+| `fqdn` | `str` | Yes | Fully qualified domain name (e.g., "chat.example.com") |
 
 #### Returns
 
@@ -316,7 +317,7 @@ async def verify(fqdn: str) -> VerifyResult
 ```python
 from dns_aid import verify
 
-result = await verify("_chat._mcp._agents.example.com")
+result = await verify("chat.example.com")
 
 print(f"Record exists: {result.record_exists}")
 print(f"DNSSEC valid: {result.dnssec_valid}")
@@ -332,7 +333,7 @@ DCV is a stateless challenge/verify primitive that lets one party prove control
 domain to another using a short-lived TXT record at `_agents-challenge.{domain}`.
 It implements [draft-ietf-dnsop-domain-verification-techniques-12](https://datatracker.ietf.org/doc/draft-ietf-dnsop-domain-verification-techniques/)
 plus the `bnd-req` binding extension from
-[draft-mozleywilliams-dnsop-dnsaid-01](https://datatracker.ietf.org/doc/draft-mozleywilliams-dnsop-dnsaid/).
+[draft-mozleywilliams-dnsop-dnsaid-02](https://datatracker.ietf.org/doc/draft-mozleywilliams-dnsop-dnsaid/).
 
 **Role split:**
 - *Challenger* — calls `issue()` and `verify()`; no DNS write credentials required.
@@ -580,7 +581,9 @@ agent = AgentRecord(
 
 | Property | Type | Description |
 |----------|------|-------------|
-| `fqdn` | `str` | Full DNS-AID record name: `_{name}._{protocol}._agents.{domain}` |
+| `fqdn` | `str` | Full DNS-AID record name (draft-02 flat primary owner): `{name}.{domain}` |
+| `walkable_fqdn` | `str` | Optional walkable AliasMode form: `{name}._agents.{domain}` |
+| `legacy_fqdn` | `str` | Legacy -01 form: `_{name}._{protocol}._agents.{domain}` (used only by the back-compat discovery path) |
 | `endpoint_url` | `str` | Full URL: `https://{target_host}:{port}` |
 | `svcb_target` | `str` | SVCB target with trailing dot |
 
@@ -767,7 +770,7 @@ async with InfobloxBloxOneBackend() as backend:
 | `INFOBLOX_DNS_VIEW` | No | `default` | DNS view name |
 | `INFOBLOX_BASE_URL` | No | `https://csp.infoblox.com` | API URL |
 
-**DNS-AID Compliance**: Infoblox UDDI is **not fully compliant** with the [DNS-AID draft](https://datatracker.ietf.org/doc/draft-mozleywilliams-dnsop-dnsaid-01/). It only supports alias mode SVCB (priority 0) and lacks `alpn`, `port`, and `mandatory` parameters. For full compliance, use Route53Backend, InfobloxNIOSBackend, NS1Backend, or DDNSBackend.
+**DNS-AID Compliance**: Infoblox UDDI is **not fully compliant** with the [DNS-AID draft](https://datatracker.ietf.org/doc/draft-mozleywilliams-dnsop-dnsaid-02/). It only supports alias mode SVCB (priority 0) and lacks `alpn`, `port`, and `mandatory` parameters. For full compliance, use Route53Backend, InfobloxNIOSBackend, NS1Backend, or DDNSBackend.
 
 ### InfobloxNIOSBackend
 
@@ -933,7 +936,7 @@ Sign a DNS record payload with a private key.
 from dns_aid.core.jwks import sign_record, RecordPayload
 
 payload = RecordPayload(
-    fqdn="_payment._mcp._agents.example.com",
+    fqdn="payment.example.com",
     target="payment.example.com",
     port=443,
     alpn="mcp",
@@ -1052,7 +1055,7 @@ dns-aid discover example.com --protocol mcp
 dns-aid discover example.com --use-http-index
 
 # Verify an agent
-dns-aid verify _my-agent._mcp._agents.example.com
+dns-aid verify my-agent.example.com
 
 # List all agents in a zone
 dns-aid list example.com
@@ -1076,7 +1079,7 @@ dns-aid index sync example.com           # Sync index with actual DNS records
 ```bash
 # Send a message to an A2A agent (discover-first: DNS → agent card → invoke)
 dns-aid message --domain ai.infoblox.com --name security-analyzer \
-    "Analyze security of _marketing._a2a._agents.ai.infoblox.com"
+    "Analyze security of marketing.ai.infoblox.com"
 
 # Send a message to an A2A agent (direct endpoint)
 dns-aid message --endpoint https://security-analyzer.ai.infoblox.com \
@@ -1521,7 +1524,7 @@ async with AgentClient(config) as client:
 
     # Get rankings for specific agents only
     rankings = await client.fetch_rankings(
-        fqdns=["_booking._mcp._agents.example.com"],
+        fqdns=["booking.example.com"],
         limit=10
     )
 
@@ -1843,6 +1846,6 @@ print(dns_aid.__version__)  # "0.6.0"
 ## See Also
 
 - [Getting Started Guide](getting-started.md)
-- [IETF Draft: DNS-AID](https://datatracker.ietf.org/doc/draft-mozleywilliams-dnsop-dnsaid-01/)
+- [IETF Draft: DNS-AID](https://datatracker.ietf.org/doc/draft-mozleywilliams-dnsop-dnsaid-02/)
 - [RFC 9460: SVCB Records](https://www.rfc-editor.org/rfc/rfc9460.html)
 - [GitHub Repository](https://github.com/infobloxopen/dns-aid-core)