dns-aid 1.0.0

DNS-AID Agent Discovery Check v1.0.0

Status

• version: 1.0.0
• check identifier: dns-aid
• input contract: [email protected]
• output contract: [email protected]
• scope: site-level DNS discovery records for the scanned origin hostname

Abstract

This check looks for emerging DNS-AID agent discovery records under _agents using HTTPS/SVCB DNS records. It validates the standards-backed HTTPS/SVCB shape, records DNS-AID-specific routing evidence such as alpn and endpoint, and reports DNSSEC authentication evidence when visible from the resolver.

Motivation

Agents often need an origin-level starting point before fetching richer HTTP metadata such as agents.json, A2A cards, MCP metadata, Auth.md, or Agent Skills indexes. DNS-AID moves that first hint into DNS by using compact service-binding records under _agents.

The underlying DNS record types are standardized, but DNS-AID itself is emerging. The check therefore treats HTTPS/SVCB syntax as standards-backed and treats _agents labels plus endpoint routing as DNS-AID conventions.

Normative Model

This version uses the following standards-backed model:

• RFC 9460 defines SVCB and HTTPS resource records.
• RFC 9461 defines SVCB use for DNS services.
• RFC 8552 defines the registration model for globally scoped underscored DNS node names.
• RFC 8484 defines DNS-over-HTTPS, used by this scanner to query typed records.
• RFC 4033, RFC 4034, and RFC 4035 define DNSSEC.

This version recognizes the following DNS-AID conventions:

• _index._agents.<hostname> for a general agent index route
• _a2a._agents.<hostname> for an A2A-style route
• HTTPS RR type 65
• SVCB RR type 64
• alpn as a standard SvcParam used to advertise compatible application protocols
• endpoint as an emerging DNS-AID routing parameter, not an IANA-registered SvcParamKey

As of 2026-06-12, _agents, _index, and _a2a are not registered in IANA's underscored DNS node registry, and endpoint is not registered in IANA's SVCB Service Parameter Keys registry. This check must not describe those conventions as formal RFC requirements.

Applicability

The check applies to every public scanned origin with a hostname.

If the page or headers explicitly mention DNS-AID, _agents, _index._agents, or _a2a._agents, missing DNS-AID records are treated as a failed claimed capability.

If the site does not claim DNS-AID and no DNS-AID records are found, the result is a warning because DNS-AID is an emerging recommendation for agent readiness, not a mature universal web requirement.

Pass Criteria

A passing result requires:

• at least one expected _agents label returns a HTTPS or SVCB record
• at least one record is ServiceMode, not only AliasMode
• the ServiceMode record has parseable SVCB presentation or structured resolver data
• mandatory SvcParams are known or explicitly DNS-AID-compatible
• at least one ServiceMode record contains alpn
• at least one ServiceMode record contains a parseable HTTPS endpoint
• the endpoint does not contain credentials
• the endpoint does not point at localhost or private address literals
• authenticated-data DNSSEC evidence is visible from the resolver

Warning Criteria

Warnings include:

• no DNS-AID records found and the page does not claim DNS-AID support
• only AliasMode records are visible
• DNSSEC material is visible but authenticated-data is not confirmed
• no DNSSEC authentication evidence is visible
• records use unregistered or unknown non-mandatory SvcParams
• endpoint is present as a DNS-AID convention even though it is not an IANA-registered SvcParamKey
• the resolver path cannot expose complete typed HTTPS/SVCB evidence and a fallback is used

Failure Criteria

Failures include:

• the page claims DNS-AID support but no expected _agents HTTPS/SVCB records resolve
• records exist but cannot be parsed as usable HTTPS/SVCB records
• a ServiceMode record marks unknown parameters as mandatory
• records exist but none provide both alpn and a usable HTTPS endpoint route
• endpoint evidence is not an absolute URL
• endpoint evidence uses a non-HTTPS scheme
• endpoint evidence contains credentials
• endpoint evidence points at localhost or private address literals

Evidence Model

The result emits:

• scanned hostname
• whether DNS-AID was claimed by page/header text
• labels queried
• query type per lookup: HTTPS, SVCB, or fallback ANY
• resolver path used
• DNS response code when available
• authenticated-data flag when available
• answer count
• parsed records:
• owner name
• RR type
• TTL
• SvcPriority
• AliasMode, ServiceMode, or unknown mode
• TargetName
• SvcParams
• mandatory keys
• alpn values
• endpoint value and validity
• unknown parameters
• parse warnings
• DNSSEC evidence:
• queried names
• resolver path
• authenticated-data flag
• DNSSEC material types observed

Evidence must not include provider dashboard configuration, private resolver credentials, or unrelated DNS zone data.

Validation And Scoring Steps

1. query-records - weight 0.35

Query _index._agents.<hostname> and _a2a._agents.<hostname> for HTTPS and SVCB records.

1. validate-svcb-shape - weight 0.20

Validate HTTPS/SVCB ServiceMode shape, TargetName, SvcParams, and mandatory-key compatibility.

1. validate-agent-routing - weight 0.30

Validate DNS-AID routing evidence, including alpn and the DNS-AID endpoint convention.

1. dnssec-authentication - weight 0.15

Record authenticated-data and DNSSEC material evidence.

Standard Behavior

The check is isolated. It does not consume output from agents.json, A2A Agent Card, MCP server card, Auth.md, Agent Skills, or any other check.

The check queries the public DNS names derived from the scanned origin hostname. It prefers typed DNS-over-HTTPS queries for HTTPS and SVCB records and uses resolveAny only as fallback evidence when typed records are not returned through the primary resolver path.

Non-Standard And Real-World Behavior

DNS-AID-specific endpoint is treated as an emerging routing convention. It can make a DNS-AID record usable for this scanner, but it is not treated as formal RFC 9460 conformance.

Provider behavior may affect results. Some DNS providers synthesize HTTPS records, some restrict manually authored HTTPS records, and some do not support HTTPS/SVCB records at all.

DNSSEC reporting is evidence-based. An authenticated-data flag is strong evidence from a validating resolver, but DNSSEC material alone is weaker evidence and receives a warning.

Non-Goals And Limitations

• This check does not claim DNS-AID is an IETF standard.
• This check does not claim _agents or endpoint are IANA-registered.
• This check does not infer DNS-AID from TXT records.
• This check does not query DNS provider dashboard APIs.
• This check does not require DNSSEC for basic discovery while DNS-AID remains emerging.
• This check does not fetch the advertised endpoint; endpoint fetchability belongs to the specific HTTP metadata check.
• DNSSEC validation is limited to resolver evidence and does not independently validate the chain of trust.

References

• www.rfc-editor.org/rfc/rfc9460
• www.rfc-editor.org/rfc/rfc9461
• www.rfc-editor.org/rfc/rfc8552
• www.rfc-editor.org/rfc/rfc8484
• www.rfc-editor.org/rfc/rfc4033
• www.rfc-editor.org/rfc/rfc4034
• www.rfc-editor.org/rfc/rfc4035
• www.iana.org/assignments/dns-svcb/dns-svcb.xhtml
• www.iana.org/assignments/dns-parameters/dns-parameters.xhtml

dns-aid v1.0.0 Changelog

• Added typed HTTPS/SVCB DNS-over-HTTPS querying with resolveAny fallback evidence.
• Reclassified missing DNS-AID as a warning unless the page explicitly claims support.
• Added HTTPS/SVCB ServiceMode, mandatory parameter, alpn, endpoint, and DNSSEC evidence steps.
• Rewrote versioned docs in RFC-style form with explicit pass, warning, and failure criteria.