NNU DNS Domain Control Authorization Protocol Version 1.0 Revised 28 August 2026 Abstract This document specifies a DNS TXT challenge protocol by which the controller of an exact DNS domain authorizes an association between that domain and an NNU Profile. A Profile can represent a person or an organization and can be published as an NNU Public Profile. Successful verification produces public, time-bounded, and revocable official_domain evidence that relying parties can use for source attribution and domain-to-Profile relationship decisions. For an Organization Profile, the evidence is a building block for a domain-verified organization. It does not by itself verify legal identity, organizational membership, representative authority, content, or access rights. Status of This Document This document is the stable version 1.0 vendor specification implemented by nnu.us. It is not an IETF document and does not claim IETF consensus. The DNS owner name and TXT record syntax defined by the original version 1.0 publication are unchanged by this revision. A future incompatible wire-format change will use a new protocol version. Specification URL: https://nnu.us/specifications/nnu-domain-verification-1.0.txt Change controller: Grid Heap, Inc. General contact: contact@gridheap.com Security contact: security@gridheap.com 1. Introduction An Internet service can allow a Profile to state that it is associated with a DNS domain. A self-asserted statement is insufficient when a relying party needs evidence that the association was authorized through the domain's DNS publication path. The NNU DNS Domain Control Authorization Protocol supplies that evidence by combining three facts: 1. an authenticated Profile controller requested one exact association; 2. the NNU Verifier issued an unpredictable, association-specific challenge; and 3. a Domain Controller published that challenge at an application-specific DNS owner name beneath the Subject Domain. The causal relationship between challenge issuance and DNS publication allows the NNU Verifier to confirm that the association was authorized at the time of the DNS check. The resulting evidence can be exposed in an NNU Public Profile Manifest and consumed outside the nnu.us user interface by applications, security tooling, and Agents. For organizations, this protocol establishes the first link in a larger evidence chain: Subject Domain -> Organization Profile -> separately authorized resources The later links can include members, applications, Agents, public knowledge spaces, or publications. Those links require their own authorization mechanisms and are not created by the DNS record defined here. 1.1. Protocol Goals This protocol is designed to: 1. require an explicit DNS publication action by a Domain Controller; 2. bind that action to one Profile, one Subject Domain, and one fixed purpose; 3. prevent a pre-existing or guessed value from satisfying a new challenge; 4. publish a minimal result that does not disclose the Challenge Token; 5. make evidence status, freshness, expiration, and revocation visible; and 6. provide a stable, machine-readable domain association for relying parties. 1.2. Non-Goals This protocol does not: 1. determine whether a domain merely exists or resolves; 2. establish legal ownership of a domain or legal identity of a person or organization; 3. establish employment, membership, representative authority, authorship, accuracy, safety, certification, or endorsement; 4. authorize access to a private Space, API, MCP server, Agent, or other resource; 5. discover services or Agents; or 6. replace authentication, OAuth, organizational administration, or application-specific authorization. 2. Conventions The key words MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, NOT RECOMMENDED, MAY, and OPTIONAL in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals. DNS names in examples use presentation format. A trailing dot marks an absolute DNS name and is not part of the normalized Subject Domain value. 3. Terminology Subject Domain The exact, normalized DNS domain for which an association is requested. Profile The NNU Profile identified in NNU Verifier state by an immutable internal Profile identifier. A Profile has a kind of person or organization. Its canonical HTTPS Profile URI is its current public retrieval location, and its public representation is an NNU Public Profile Manifest. Organization Profile A Profile whose kind is organization. Domain Control Evidence on an Organization Profile supports the label "domain-verified organization" within the scope defined by this document. Profile Controller The authenticated NNU principal permitted to manage the Profile and request a domain association. Profile control is distinct from domain control. Domain Controller A party capable of authorizing publication at the DNS owner name defined in Section 6. The party can act directly or through a DNS administrator. NNU Verifier The verification service that authenticates the Profile Controller, issues and retains challenge state, queries DNS, and publishes Domain Control Evidence. The deployed NNU Verifier is operated by nnu.us. Challenge Token A 32-octet cryptographically random value issued for one pending Domain Association and encoded as specified in Section 7. Domain Association The tuple of Profile, Subject Domain, purpose official_domain, and current verification state maintained by the NNU Verifier. Its state is pending, confirmed, expired, or revoked as specified in Section 9.3. Domain Control Evidence The public, time-bounded result of a successful verification. In the NNU Public Profile Manifest it is represented by an Evidence object whose type is official_domain and whose source is dns. Relying Party A person, application, or Agent that uses Domain Control Evidence when making an attribution or relationship decision. Current Evidence Domain Control Evidence whose status is confirmed, whose expiration time is later than the relying party's current time, and which has not been revoked by the NNU Verifier. 4. Authorization Semantics Publishing the exact TXT value from a pending challenge at the exact owner name expresses the following limited authorization: The Domain Controller authorizes the identified NNU Profile to publish a current association with the exact Subject Domain for the official_domain purpose. The authorization applies only to the immutable Profile identity and Subject Domain retained in the NNU Verifier's challenge state. The DNS record does not contain a Profile identifier or URI because the unpredictable token is bound to the immutable Profile identifier in Verifier state. The canonical Profile URI displayed when a challenge is issued is not a separate authorization target or an issue-time identity snapshot. If the same Profile's canonical URI changes before evidence publication, the NNU Verifier MUST resolve the retained immutable Profile identifier to that Profile's current canonical URI. A URI or handle MUST NOT transfer Domain Control Evidence to a different immutable Profile identity. For a person Profile, Current Evidence means that the Domain Controller authorized the public domain-to-Profile association. It does not identify the person or establish that the person can represent an organization. For an Organization Profile, Current Evidence means that the Domain Controller authorized the public association between the Subject Domain and that Organization Profile. A conforming user interface SHOULD describe this as a "domain-verified organization" or "verified domain association" unless a separate process establishes stronger organizational identity claims. Domain Control Evidence MUST NOT be treated as evidence that a Profile member, application, or Agent can act on behalf of the organization. Membership, roles, publication authority, application ownership, and Agent delegation require separate, explicit, and revocable evidence. 5. Protocol Overview The protocol consists of the following steps: 1. The Profile Controller authenticates to the NNU Verifier. 2. The Profile Controller selects one Subject Domain. 3. The NNU Verifier normalizes the domain and creates a pending Domain Association. 4. The NNU Verifier generates a Challenge Token and returns the exact DNS owner name and TXT value once. 5. The Domain Controller reviews the scope and publishes the TXT record. 6. The Profile Controller asks the NNU Verifier to check DNS. 7. The NNU Verifier queries the exact owner name and compares complete TXT values with the retained challenge digest. 8. On success, the NNU Verifier records confirmation and can publish time-bounded Domain Control Evidence in the Profile Manifest. 9. The NNU Verifier periodically rechecks DNS or expires the evidence. 10. The Profile Controller can revoke the Domain Association at any time. 6. Subject Domain and DNS Owner Name 6.1. Subject Domain Normalization The input is a DNS host name, not a URL. The NNU Verifier performs the following normalization before issuing a challenge: 1. remove leading and trailing whitespace; 2. remove one optional trailing presentation-format dot; 3. reject URL or authority syntax in the remaining raw input; 4. parse the remaining value as a host using the WHATWG URL Standard; 5. apply that standard's domain-to-ASCII processing; and 6. lowercase the result. Input containing a URL path, query, fragment, credentials, or port MUST be rejected before host parsing. The NNU Verifier MUST NOT accept such input by wrapping it in a URL and then using only the parsed hostname after another component has been discarded or normalized away. A slash or backslash is path syntax for this purpose. As deployed nnu.us policy, a Subject Domain MUST contain at least two LDH labels. Each label MUST be no longer than 63 octets and MUST match this syntax: label = alphanum / alphanum [ *61label-char alphanum ] alphanum = ALPHA / DIGIT label-char = ALPHA / DIGIT / "-" The Subject Domain MUST NOT be an IP address; localhost; a name ending in .localhost, .local, or .internal; nnu.us; or a subordinate name of nnu.us. These exclusions state the deployed version 1.0 denylist. They do not claim that every other accepted name is delegated in the public DNS. This policy is intentionally narrower than the set of all syntactically possible DNS names. 6.2. Owner Name Construction The TXT owner name is: _nnu-verification.. The complete owner name without its final presentation-format dot MUST be no longer than 253 characters. Example owner name: _nnu-verification.example.com. The authorization applies to the exact Subject Domain. A verifier MUST NOT search parent domains for a matching record. Validation of a parent domain does not by itself validate an independently delegated child domain, and validation of a child does not validate its parent. A candidate TXT resource record MUST have the exact queried owner name after case-insensitive DNS name comparison and removal of an optional final presentation-format dot. CNAME and DNAME targets MUST NOT supply the authorization TXT value. A TXT record returned for an alias target, rather than for the exact _nnu-verification owner name, MUST be ignored even when a recursive resolver includes it in the same response. 7. TXT Record Syntax The logical TXT value has the following ABNF: record-value = "nnu-verification=" challenge-token challenge-token = 43base64url-character base64url-character = ALPHA / DIGIT / "-" / "_" The Challenge Token MUST contain 32 octets generated by a cryptographically secure random number generator. It MUST be encoded using the unpadded URL-safe Base64 alphabet from RFC 4648. The result is exactly 43 characters and contains at least 256 bits of source entropy. The logical value comparison is case-sensitive and covers the complete value, including the nnu-verification= prefix. Example record: _nnu-verification.example.com. IN TXT "nnu-verification=AAECAwQFBgcICQoLDA0ODxAREhMUFRYXGBkaGxwdHh8" A DNS TXT RDATA value can contain multiple character-strings. The NNU Verifier MUST concatenate the character-strings within one TXT resource record in wire order before comparison. When a response contains multiple TXT resource records, a match in any one complete resource record is sufficient. Unrelated TXT records at the same owner name MUST be ignored. Quotation marks displayed by DNS management or query tools are presentation syntax and are not part of the logical value. 8. Challenge Issuance and State Binding After authenticating the Profile Controller and validating the Subject Domain, the NNU Verifier MUST: 1. identify the Profile by its immutable internal identifier and resolve its current canonical Profile URI for display; 2. create a Challenge Token as specified in Section 7; 3. bind the challenge state to the immutable Profile identifier, Subject Domain, fixed official_domain purpose, and current-challenge expiration time; 4. retain a SHA-256 digest, as specified by RFC 6234, of the complete logical TXT value; 5. return the exact owner name and complete TXT value to the Profile Controller; and 6. expire the pending challenge no later than 24 hours after issuance. The current challenge's lifetime begins when its Challenge Token is generated, not when a reusable database row or an earlier Domain Association was created. An implementation need not retain or expose a separate issue-time field, but it MUST calculate the current expiration time from the current token generation. Issuing a new challenge MUST replace the retained digest, set a new expiration time, clear prior confirmation times for that challenge generation, and permanently invalidate the previous Challenge Token. Because official_domain is the only purpose defined by this protocol, the purpose binding can be implicit in a dedicated implementation path. It MUST NOT be interpreted as another verification or authorization purpose. The deployed NNU Verifier does not retain the plaintext Challenge Token after the creation response. Loss of the response before the value is published in DNS requires issuance of a new challenge. Before displaying the challenge, the NNU Verifier MUST inform the Profile Controller that successful verification creates a public association between the exact Subject Domain and Profile. The notice MUST also state that publishing the value does not grant access to private Space data. The notice MUST identify the retained Profile using its current display identity, while the challenge remains bound to the immutable Profile identifier rather than to a displayed URI snapshot. A Challenge Token MUST NOT be reused for another Profile, Subject Domain, account, purpose, permission, or authorization scope. 9. DNS Verification Procedure 9.1. Query and Matching For an unexpired pending or previously confirmed Domain Association that has not been revoked, the NNU Verifier: 1. constructs the exact owner name from Section 6; 2. queries DNS for TXT resource records at that name; 3. reconstructs each logical value as described in Section 7; 4. computes SHA-256, as specified by RFC 6234, over each complete candidate value; and 5. performs a byte-for-byte comparison with the retained digest. An unconfirmed challenge whose expiration time has passed MUST NOT be checked or confirmed. The NNU Verifier MUST test the pending challenge expiration immediately before starting the DNS query and MUST test it again after DNS processing, before recording confirmation. If the challenge expires while the DNS query is in progress, any matching answer MUST be discarded and the challenge MUST become expired without a confirmation time. Leading or trailing whitespace in a candidate value causes that candidate to fail. A match confirms that the challenge issued for the retained Domain Association appeared through the Subject Domain's DNS publication path at the time of the query. The NNU Verifier MUST NOT accept a value solely because it uses the expected prefix. It MUST match the complete challenge value retained for that Domain Association. Only TXT resource records whose owner name satisfies Section 6.2 are candidates. A TXT value found only at a CNAME or DNAME target is not a match. 9.2. DNS Responses and Errors NXDOMAIN, NODATA, or a successful DNS response without a matching complete TXT value does not confirm the Domain Association. A resolver, transport, timeout, truncation, or DNS server failure MUST NOT be treated as proof that the record is absent. It SHOULD be reported as a retryable verification error. Implementations and users MUST allow for positive and negative DNS cache propagation before repeating a check. 9.3. Confirmation, Revalidation, and Revocation A Domain Association has the following states and transitions: pending A current Challenge Token has been issued but has never been confirmed. A definitive response without a matching TXT value leaves the association pending until its challenge expiration time. When that time is reached, it becomes expired. That challenge generation is then terminal and MUST NOT be queried, matched, or confirmed. confirmed A successful check of an unexpired pending challenge records the first confirmation time, latest successful check time, and evidence expiration time. Confirmed evidence is valid for no more than 30 days without another successful DNS check. A later successful recheck of the same retained token updates checked_at and sets a new bounded expires_at without changing the first confirmation time for that challenge generation. expired Evidence that was previously confirmed becomes expired when expires_at is reached or when a definitive recheck does not contain the expected TXT value at the exact owner name. A definitive negative recheck records checked_at and sets expires_at no later than that check time. A previously confirmed association that has not been revoked MAY be rechecked with its retained token and can return to confirmed after a successful check. By contrast, a challenge that expired without ever being confirmed cannot return to confirmed; it requires a new challenge. revoked The Profile Controller can revoke a Domain Association at any time. Revocation immediately makes the retained challenge generation terminal at the NNU Verifier. Its old token MUST NOT be checked or confirmed, and its evidence MUST NOT be published as current. Restarting the association requires issuance and successful verification of a new Challenge Token. A resolver, transport, timeout, truncation, or DNS server failure is a temporary DNS error. It MUST NOT change pending, confirmed, expired, or revoked state; update checked_at as though a definitive check occurred; or extend expires_at. Time-based expiration still occurs while an error is unresolved. A temporary DNS error does not prove absence and MUST NOT be represented as a successful revocation check. Issuing a new challenge for an allowed Domain Association starts a new pending challenge generation and applies the invalidation rules in Section 8. A DNS answer for a superseded token MUST NOT revive the old generation, including when its DNS query began before replacement or revocation. Removing a TXT record does not immediately revoke cached evidence. The Profile Controller SHOULD also use the NNU revocation operation. Without that operation, a definitive recheck expires previously confirmed evidence, and in all cases it ceases to be Current Evidence no later than its published expires_at. The NNU Verifier MUST NOT publish Current Evidence for the same exact Subject Domain on more than one Profile at the same time. A domain can be associated with a different Profile only after the prior association is revoked, expired, or otherwise released under documented conflict policy, followed by a new challenge and successful verification. 10. Evidence Publication 10.1. Profile Manifest Representation After successful verification, the NNU Verifier can publish an Evidence object in the NNU Public Profile Manifest with these semantics: type "official_domain". source "dns". subject The exact normalized Subject Domain. status "confirmed" or "expired". confirmed_at RFC 3339 date-time of first confirmation. checked_at RFC 3339 date-time of the latest successful or definitive check. expires_at RFC 3339 evidence expiration date-time. url The HTTPS origin URL constructed from the Subject Domain. An official_domain Evidence object MUST contain expires_at. For confirmed evidence, expires_at MUST be later than checked_at and no more than 30 days after checked_at. For evidence expired by a definitive negative recheck, expires_at MUST be no later than checked_at. The Challenge Token, retained digest, account identifier, and DNS provider information MUST NOT appear in the public Profile Manifest. The containing Profile Manifest binds the Evidence object to its immutable Profile identity through publisher.id and presents that Profile at its current canonical URI. A detached or copied Evidence object is not independently authenticated and MUST NOT be accepted without the canonical Profile context from Section 10.2. Relying Parties MUST NOT treat an issue-time Profile URI as the challenge binding or transfer evidence between different publisher.id values that reuse a URI or handle. Example current evidence for an Organization Profile: { "type": "official_domain", "source": "dns", "subject": "example.com", "status": "confirmed", "confirmed_at": "2026-08-28T00:00:00Z", "checked_at": "2026-08-28T00:00:00Z", "expires_at": "2026-09-27T00:00:00Z", "url": "https://example.com/" } The url field is an informational origin reference. Its presence does not assert that the origin is reachable, secure beyond normal HTTPS processing, or controlled by the Profile. An expired Evidence object can remain public to communicate historical state, but it MUST have status expired and MUST NOT cause the Profile's current official trust summary to be true. A revoked Domain Association MUST NOT be published as current evidence. 10.2. Relying Party Processing A Relying Party that uses NNU Domain Control Evidence MUST: 1. retrieve the manifest from the canonical HTTPS Profile URI or another authenticated NNU endpoint; 2. require type official_domain and source dns; 3. compare the normalized evidence subject with the intended domain; 4. require status confirmed; 5. require a syntactically valid expires_at value and reject evidence when that time has passed or is not later than checked_at; 6. bind the evidence to the manifest's immutable publisher.id and current canonical Profile context; and 7. apply the authorization limits in Section 4. A Relying Party SHOULD consider checked_at freshness and the risk of domain reassignment when making a decision. A high-risk decision requires additional evidence appropriate to that decision. The random TXT value is meaningful only together with the private challenge state retained by the NNU Verifier. A Relying Party that lacks that state cannot independently validate an old TXT record merely by observing it. It MUST consume current evidence from an authenticated NNU endpoint or invoke an authorized verification operation. The NNU Verifier is the issuer of the evidence. Relying Parties decide whether to trust that issuer for their use case. IANA registration of the DNS owner name does not confer trust in the issuer. 11. Organization Verification Model 11.1. Domain-Verified Organization When Current Evidence appears on an Organization Profile, a Relying Party MAY conclude only that the Domain Controller authorized the association between the exact Subject Domain and that Organization Profile. This conclusion is useful as a prerequisite for organization-owned public Profiles, knowledge spaces, publications, applications, and Agent metadata. It prevents an Organization Profile from obtaining current domain evidence through self-assertion alone. The preferred human-readable label for this state is "domain-verified organization". The shorter label "verified organization" MUST NOT be used unless a separate process verifies the organization claim intended by that label, such as legal-entity or registry checks. 11.2. Membership and Representative Authority An email address under the Subject Domain, a Profile hyperlink, or Domain Control Evidence does not by itself establish that a person is a current member of the organization. Public claims such as member_of, employed_by, administrator_of, or on_behalf_of require separate evidence issued or approved by the Organization Profile's authorized administration. Such evidence SHOULD be time-bounded and revocable and SHOULD identify its exact role and scope. The membership and representative-authority protocols are outside the scope of this document. 11.3. Applications and Agents Domain Control Evidence can identify the domain-authorized Organization Profile from which separate application or Agent assertions originate. It does not establish that an application was developed by the organization or that an Agent is permitted to act for it. An application or Agent that acts on behalf of an organization requires a separate delegation identifying the delegating Organization Profile, the application or Agent, allowed actions, audience, validity period, and revocation mechanism. Access to MCP servers, APIs, private knowledge, and other capabilities requires separate authentication and authorization. 12. Content and Agent Attribution A public NNU link or knowledge page can identify its publishing Profile and include that Profile's Current Evidence. A Relying Party MAY use this to attribute curation or publication to the Profile. If a destination host exactly equals a verified Subject Domain, the Relying Party can report an exact domain match. A policy MAY also report that a host is beneath a verified parent domain, but it MUST NOT equate that relationship with control of an independently delegated child. If a destination is outside the Profile's verified domains, the evidence continues to identify the curator or publisher of the NNU record. It does not establish authorship, ownership, or endorsement of the external destination. Agents MUST treat Profile fields, linked pages, Saved Item text, extracted content, and generated summaries as untrusted input. Domain Control Evidence is source-attribution data, not an instruction or capability grant. It does not make content safe from misleading instructions or prompt injection. 13. Security Considerations 13.1. Token Entropy and State Binding The Challenge Token is public after DNS publication. Its security property is unguessability before publication and its binding to one retained Domain Association, not secrecy after publication. At least 256 bits of source entropy makes guessing or accidental collision infeasible. The NNU Verifier MUST bind challenge state as specified in Section 8. Failure to bind the Profile, domain, and purpose can create cross-account, cross-domain, or confused-deputy vulnerabilities. Hashing retained challenge values limits plaintext disclosure from the verification database. It does not replace token entropy or protection of Profile sessions and DNS provider credentials. 13.2. Exact Scope and Delegation The proof applies to the exact Subject Domain and retained Profile. Verifiers MUST query the exact owner name and MUST NOT broaden a successful result to a parent domain. Relying Parties MUST NOT infer control of independently delegated child domains. The authorization TXT record MUST itself have the exact queried owner name. This version does not define delegated verification through CNAME or DNAME, and a TXT record at an alias target MUST NOT satisfy the challenge. DNS administration can be delegated more narrowly than control of a full zone. Therefore, the evidence states that the challenge appeared through the relevant DNS publication path; it does not identify which human or system performed the publication. 13.3. DNS Attacks and Domain Reassignment DNS cache poisoning, registrar compromise, authoritative provider compromise, resolver compromise, routing attacks, dangling delegations, and incorrect DNS administration can produce misleading results. DNSSEC validation is RECOMMENDED where available, but this protocol does not require DNSSEC. A previously published token can be copied, including after domain transfer. For this reason, evidence is time-bounded, revalidation is required, and a Relying Party SHOULD consider domain reassignment risk. High-risk consumers MUST obtain additional evidence. 13.4. Stale DNS and Evidence DNS TTLs and negative caching delay visibility of additions and removals. Removal of a record is not an immediate revocation signal. Relying Parties MUST inspect status, checked_at, and expires_at instead of treating historical confirmation as indefinite proof. Operators SHOULD remove obsolete challenge records after revocation or expiration to reduce the chance of future confusion. 13.5. Cross-Protocol Confusion Verifiers MUST require both the _nnu-verification owner-name label and the exact nnu-verification= value prefix. They MUST compare the complete value. An unrelated TXT value at the same owner name MUST NOT satisfy a challenge. IANA has registered the TXT and _nnu-verification combination in the "Underscored and Globally Scoped DNS Node Names" registry. The unique registration prevents another registered protocol from assigning incompatible semantics to that globally scoped combination. A registration cannot correct compromised DNS, weak challenge generation, incorrect state binding, or an untrusted issuer. 13.6. Content Safety and Authorization Separation Domain Control Evidence MUST remain separate from content interpretation and resource authorization. A domain-authorized Profile can still publish unsafe, incorrect, or malicious content. OAuth tokens, MCP grants, API credentials, organization roles, and Agent delegations MUST be evaluated independently. 14. Privacy Considerations DNS TXT records are public. The Profile Controller and Domain Controller must expect the owner name and Challenge Token to be observable, cached, archived, and indexed. The NNU Verifier MUST disclose the public effect of verification before challenge publication. It MUST NOT include private account identifiers, credentials, email addresses, DNS provider details, the Challenge Token, or the retained challenge digest in public evidence. Domain Control Evidence does not authorize publication of organization membership or personal information. Those disclosures require separate user and organization controls. 15. Operational Considerations The Challenge Token SHOULD be published as one TXT character-string. DNS systems that split it into multiple character-strings remain compatible because the NNU Verifier concatenates strings within one resource record. Multiple TXT records can coexist at the owner name. Operators SHOULD retain only records needed for active challenges or revalidation and SHOULD remove obsolete values. The deployed NNU Verifier uses a pending lifetime of at most 24 hours and a confirmed evidence lifetime of at most 30 days. Implementations SHOULD keep both periods short, expose the latest check and expiration times, and provide an explicit revocation operation. Temporary DNS failures SHOULD produce retryable errors. They MUST NOT be silently converted into successful verification or definitive revocation. 16. IANA Considerations Per RFC 8552, IANA has registered the following entry in the "Underscored and Globally Scoped DNS Node Names" registry: RR TYPE: TXT _NODE NAME: _nnu-verification Reference: https://nnu.us/specifications/nnu-domain-verification-1.0.txt The global TXT and _nnu-verification combination identifies the constrained NNU domain-control authorization context defined by this document. DNS operators can publish the record beneath any eligible Subject Domain, and NNU Verifiers use the same owner-name semantics globally. This protocol has global DNS naming impact even though the deployed NNU Verifier is operated by one service: records are provisioned beneath arbitrary Subject Domains in DNS zones that nnu.us does not administer. Without a coordinated registry, unrelated applications could assign incompatible semantics to the same RR type and underscored node name in those zones. Registration is therefore necessary to prevent that collision. The stable Reference provides DNS operators, implementers, relying parties, and security reviewers with the exact syntax, processing rules, authorization scope, and change controller. Registration does not make this document an Internet Standard and does not certify nnu.us, a Profile, an organization, a domain, content, an application, an Agent, or any identity claim. Implementations MUST consult the IANA registry as the authoritative source for the current registration status. 17. References 17.1. Normative References BCP 14: RFC 2119 and RFC 8174 RFC 1034: Domain Names - Concepts and Facilities RFC 1035: Domain Names - Implementation and Specification RFC 3339: Date and Time on the Internet: Timestamps RFC 4648: The Base16, Base32, and Base64 Data Encodings RFC 5234: Augmented BNF for Syntax Specifications: ABNF RFC 6234: US Secure Hash Algorithms (SHA and SHA-based HMAC and HKDF) RFC 8552: Scoped Interpretation of DNS Resource Records through "Underscored" Naming of Attribute Leaves RFC 9499: DNS Terminology WHATWG URL Standard: https://url.spec.whatwg.org/ NNU Public Profile Manifest 1.0: https://nnu.us/specifications/nnu-profile-manifest-1.0.txt 17.2. Informative References RFC 4033: DNS Security Introduction and Requirements RFC 8126: Guidelines for Writing an IANA Considerations Section in RFCs Domain Control Validation using DNS, Work in Progress: https://datatracker.ietf.org/doc/draft-ietf-dnsop-domain-verification-techniques/