Publish DNS-AID (_agents.aspire.dev) SVCB/HTTPS records + DNSSEC

[IEvangelist]

Publish DNS-AID (_agents.aspire.dev) SVCB/HTTPS records + DNSSEC

The isitagentready.com scanner currently reports checks.discoverability.dnsAid.status = "fail" for aspire.dev because no DNS for AI Discovery (DNS-AID) records are published in our zone. This issue tracks the DNS-operator work needed to flip that to "pass".

What needs to happen (DNS zone change, not a code change)

This is out of scope for the aspire.dev source tree — the repo contains no zone files or DNS IaC. Whoever administers DNS for aspire.dev (Azure DNS in the dnceng tenant, per current understanding) needs to:

1. Publish SVCB / HTTPS service-binding records under the _agents.aspire.dev namespace following the DNS-AID draft.
2. Sign the public discovery zone with DNSSEC so validating resolvers return authenticated answers.

Draft record set

The DNS operator should finalize the targets, alpn values, ports, and any DNS-AID-specific experimental keyNNNNN SvcParamKeys (the draft is not yet RFC, so registered keys are not assigned). Starting point:

; Top-level discovery anchor for aspire.dev (HTTPS web endpoint)
_index._agents.aspire.dev.  3600 IN HTTPS 1 aspire.dev. alpn="h2,http/1.1" port=443

; Add per-protocol records once aspire.dev publishes an A2A or agent endpoint, e.g.:
; _a2a._agents.aspire.dev.   3600 IN SVCB  1 agent.aspire.dev. alpn="a2a" port=443 mandatory=alpn,port

Per the DNS-AID skill: Use numeric keyNNNNN SvcParamKey names for experimental DNS-AID custom parameters until they are registered.

DNSSEC

Enable DNSSEC on the aspire.dev zone (or the subordinate zone that owns _agents.aspire.dev) so DNS-AID consumers can rely on authenticated data. In Azure DNS this is the dnssec-config feature.

Validation

After the records are live and the zone is signed:

POST https://isitagentready.com/api/scan
Content-Type: application/json

{"url": "https://aspire.dev"}

Expect checks.discoverability.dnsAid.status == "pass".

Spot-check from any host:

dig +dnssec HTTPS _index._agents.aspire.dev

Why not just fix this in the repo?

aspire.dev deploys via AddAzureFrontDoor(...) in src/apphost/Aspire.Dev.AppHost/AppHost.cs, but the repo holds no Bicep / Terraform / zone files for the public DNS zone — only the Front Door wiring. DNS-AID records and DNSSEC have to be applied by whoever owns the authoritative zone.

Related: API Catalog (RFC 9727) — intentionally NOT shipping

The same scanner also flags checks.discovery.apiCatalog.status as fail. We deliberately opted out of publishing /.well-known/api-catalog in #807 — see the pinned assertion in tests/StaticHost.Tests/LinkHeaderTests.cs:

// Confirm we are NOT advertising api-catalog (out of scope per RFC 9727).
Assert.DoesNotContain("api-catalog", link);

RFC 9727 is "for HTTPS servers that publish APIs." aspire.dev is a documentation site whose only HTTP endpoints are /healthz and the install-script redirects (/install.ps1, /install.sh). The scanner-vs-RFC mismatch is on the scanner, not on us — no action wanted here.

References

• DNS-AID draft (draft-mozleywilliams-dnsop-dnsaid)
• RFC 9460 — SVCB / HTTPS records
• isitagentready.com DNS-AID skill
• Azure DNS DNSSEC how-to