Network Working Group T.R. Teppo Internet-Draft Independent Submission Intended status: Informational 29 July 2026 Expires: 30 January 2027 Authenticated DNS Resolution (ADR) for Enterprise DNS draft-teppo-corporate-authenticated-dns-00 Abstract This document defines Authenticated DNS Resolution (ADR), an enterprise query-plane model that augments DNS resolution with per- query identity, role-based authorization, and audit. ADR preserves DNSSEC and public Internet DNS behavior while enabling enterprises to publish comprehensive internal naming without exposing sensitive topology. ADR leverages existing enterprise authentication and identity systems to authorize and audit DNS queries without defining a new authentication protocol. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 30 January 2027. Copyright Notice Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Teppo Expires 30 January 2027 [Page 1] Internet-Draft Authenticated DNS Resolution July 2026 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. The Enterprise Has Already Rejected Anonymous DNS . . . . 4 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 1.3. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 5 2.1. Topology Exposure . . . . . . . . . . . . . . . . . . . . 5 2.2. Role Over-Visibility . . . . . . . . . . . . . . . . . . 6 2.3. Reconnaissance Facilitation . . . . . . . . . . . . . . . 6 2.4. Security Through Obscurity as Sole Defense . . . . . . . 6 2.5. Operational Degradation . . . . . . . . . . . . . . . . . 6 2.6. Audit Gap . . . . . . . . . . . . . . . . . . . . . . . . 6 2.7. Example of Exposure . . . . . . . . . . . . . . . . . . . 6 2.8. False Choice Created by Lack of Authorization . . . . . . 7 3. Prior Art . . . . . . . . . . . . . . . . . . . . . . . . . . 7 3.1. DNSSEC . . . . . . . . . . . . . . . . . . . . . . . . . 7 3.2. Active Directory Integrated DNS . . . . . . . . . . . . . 8 3.3. Split-Horizon DNS . . . . . . . . . . . . . . . . . . . . 8 3.4. DNS over TLS (DoT) and DNS over HTTPS (DoH) . . . . . . . 8 3.5. Multicast DNS (mDNS) . . . . . . . . . . . . . . . . . . 9 3.6. Authenticated DNS Updates (RFC2136) . . . . . . . . . . . 9 3.7. TSIG and SIG(0) . . . . . . . . . . . . . . . . . . . . . 9 3.8. DNS Cookies (RFC7873) . . . . . . . . . . . . . . . . . . 10 3.9. Response Policy Zones (RPZ) . . . . . . . . . . . . . . . 10 3.10. DNS Views and Split-Horizon DNS . . . . . . . . . . . . . 10 3.11. Network Access Control and 802.1X . . . . . . . . . . . . 11 3.12. DNS ACLs . . . . . . . . . . . . . . . . . . . . . . . . 11 4. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 5. Architecture . . . . . . . . . . . . . . . . . . . . . . . . 13 5.1. DNS Deployment Models . . . . . . . . . . . . . . . . . . 13 5.1.1. Home and Small Office Networks . . . . . . . . . . . 13 5.1.2. Public Internet DNS . . . . . . . . . . . . . . . . . 14 5.1.3. Enterprise and Corporate DNS . . . . . . . . . . . . 14 5.2. Authenticated Transport . . . . . . . . . . . . . . . . . 14 5.2.1. What Authenticated Transport Provides . . . . . . . . 15 5.3. Query Authentication Flow . . . . . . . . . . . . . . . . 16 5.4. Authorization Engine . . . . . . . . . . . . . . . . . . 16 5.5. Legacy Client Support . . . . . . . . . . . . . . . . . . 17 5.6. Compatibility . . . . . . . . . . . . . . . . . . . . . . 17 6. Identity and Authorization Model . . . . . . . . . . . . . . 17 6.1. Identity Binding . . . . . . . . . . . . . . . . . . . . 18 6.2. Permission Model . . . . . . . . . . . . . . . . . . . . 19 6.3. Example Policy . . . . . . . . . . . . . . . . . . . . . 19 6.4. Dual Identity Resolution . . . . . . . . . . . . . . . . 20 7. Resolver Behavior . . . . . . . . . . . . . . . . . . . . . . 21 7.1. Query Processing Steps . . . . . . . . . . . . . . . . . 21 7.2. Caching Behavior . . . . . . . . . . . . . . . . . . . . 21 Teppo Expires 30 January 2027 [Page 2] Internet-Draft Authenticated DNS Resolution July 2026 7.3. Forwarding and Recursion . . . . . . . . . . . . . . . . 22 7.4. NXDOMAIN Handling . . . . . . . . . . . . . . . . . . . . 22 7.5. Transport Requirements . . . . . . . . . . . . . . . . . 22 7.6. Error Handling . . . . . . . . . . . . . . . . . . . . . 22 7.7. Performance Considerations . . . . . . . . . . . . . . . 23 8. Integration with Existing Infrastructure . . . . . . . . . . 23 8.1. Identity Providers . . . . . . . . . . . . . . . . . . . 24 8.2. Identity Binding and Client Model . . . . . . . . . . . . 24 8.3. Mapping Enterprise Identity to RBAC . . . . . . . . . . . 24 8.4. Deployment Models and IP Gating . . . . . . . . . . . . . 25 8.5. Migration Strategy . . . . . . . . . . . . . . . . . . . 26 8.6. Operational Considerations, DNSSEC Preservation, and Resolver Responsibilities . . . . . . . . . . . . . . . . 26 8.7. Implementation Checklist (Operational Summary) . . . . . 27 8.8. Summary, Addressing, and Key Considerations . . . . . . . 28 9. Security Considerations . . . . . . . . . . . . . . . . . . . 28 9.1. Credential Protection . . . . . . . . . . . . . . . . . . 28 9.2. Topology Minimization via RBAC . . . . . . . . . . . . . 29 9.3. Dual Identity Evaluation . . . . . . . . . . . . . . . . 29 9.4. Authenticated NXDOMAIN Handling . . . . . . . . . . . . . 29 9.5. Resolver Compromise . . . . . . . . . . . . . . . . . . . 29 9.6. Kerberos Delegation and Token Replay . . . . . . . . . . 29 9.7. Legacy Fallback . . . . . . . . . . . . . . . . . . . . . 30 9.8. Denial of Service . . . . . . . . . . . . . . . . . . . . 30 9.9. Protocol Impact Statement . . . . . . . . . . . . . . . . 30 9.10. Deployment Scope Clarification . . . . . . . . . . . . . 31 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31 11. Future Extensions . . . . . . . . . . . . . . . . . . . . . . 32 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 32 12.1. Normative References . . . . . . . . . . . . . . . . . . 32 12.2. Informative References . . . . . . . . . . . . . . . . . 33 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 34 1. Introduction The Domain Name System (DNS) [RFC1034][RFC1035] was designed as a globally distributed, hierarchical, publicly readable database. This design is appropriate for the public Internet, where anonymous query resolution is a fundamental requirement. However, this same openness creates significant operational and security challenges when DNS is used within private corporate networks. ADR introduces query-plane RBAC - controlling who may resolve (read) DNS records at query time - which is distinct from existing management-plane RBAC that controls who may create or modify DNS data. This document is limited to enterprise and corporate deployments and does not change public DNS or DNSSEC behavior. Teppo Expires 30 January 2027 [Page 3] Internet-Draft Authenticated DNS Resolution July 2026 Corporate infrastructure administrators have long understood the operational value of comprehensive DNS naming. When every network device - routers, switches, servers, printers, storage systems, and endpoint infrastructure - carries a meaningful DNS name, operational efficiency improves dramatically. Log files become human-readable, monitoring systems reference meaningful identifiers, troubleshooting becomes tractable, and documentation remains accurate because DNS itself serves as the living record of the infrastructure. Security teams and regulatory frameworks have increasingly mandated minimal DNS records in corporate environments. A comprehensive, well-named DNS namespace provides an attacker with a complete map of the network topology, device roles, geographic distribution, and logical segmentation - often without requiring any exploitation. A simple zone transfer request or recursive enumeration can yield information equivalent to months of manual reconnaissance. The result is a false choice: operational excellence requires comprehensive naming, while security requires minimal exposure. Current practice sacrifices one for the other. This document proposes that the correct solution is neither comprehensive public naming nor minimal naming, but authenticated naming - where the right to resolve a DNS record is treated as a permission governed by existing enterprise identity and access control systems. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 1.1. The Enterprise Has Already Rejected Anonymous DNS The anonymous query model defined in [RFC1034] and [RFC1035] was designed for a globally distributed public system where resolvers cannot reasonably maintain identities for arbitrary Internet clients. This design choice was correct for its intended environment. However, enterprises have never operated anonymous DNS. Enterprise DNS resolvers sit behind firewalls that block external queries, internal zones are hidden from the public Internet, zone transfers are restricted to authorized secondaries, dynamic updates require Kerberos authentication, and domain-joined status is required before a machine may register records. What enterprises have not done is extend these constraints to query- plane authorization. Writes are controlled, transfers are controlled, external access is controlled, but reads remain open to any principal with network access to a resolver. ADR completes the model enterprises have already been building by introducing authenticated query resolution as the final missing control. ADR Teppo Expires 30 January 2027 [Page 4] Internet-Draft Authenticated DNS Resolution July 2026 does not affect Internet DNS, ISP resolvers, home networks, or any environment where anonymous resolution is required. It applies exclusively where enterprises have already decided that anonymous DNS is unacceptable. 1.2. Terminology *management-plane RBAC*: controls who may create, modify, or delete DNS zones and records. *query-plane RBAC*: controls who may resolve DNS records at query time and is enforced by ADR. *authorized principal*: an authenticated machine, user, or service account. *AUTH-NXDOMAIN*: a resolver response indicating a record exists but the principal lacks permission to resolve it. 1.3. Scope This document addresses DNS query authentication and query-plane authorization for enterprise and corporate DNS only. It does not change public Internet DNS or DNSSEC behavior. 2. Problem Statement The core problem can be stated precisely: DNS resolvers in corporate environments authenticate the source of DNS answers (partially, via DNSSEC) but never authenticate the identity of the entity making a DNS query. Any entity with network access to a corporate DNS resolver may enumerate the entire DNS namespace visible to that resolver, regardless of its operational role or authorization level. This creates several categories of concrete harm: 2.1. Topology Exposure A comprehensive DNS namespace reveals router locations, firewall clusters, WAN link endpoints, core switch identifiers, subnet assignments, geographic site distribution, and device roles. In regulated industries (pipeline infrastructure, financial services, healthcare), this exposure may violate regulatory requirements. Teppo Expires 30 January 2027 [Page 5] Internet-Draft Authenticated DNS Resolution July 2026 2.2. Role Over-Visibility Traditional DNS provides identical visibility to all authenticated machines and users. Windows administrators, Linux administrators, DBA teams, helpdesk personnel, and ordinary domain users can all resolve router names, firewall names, WAN transit addresses, and core infrastructure records - despite having no operational need for this information. This violates separation-of-duties principles and materially increases lateral-movement risk. 2.3. Reconnaissance Facilitation Penetration testing engagements consistently identify comprehensive DNS naming as a critical finding. Zone transfer vulnerabilities (AXFR via "nslookup ls -d" or "dig AXFR") provide complete network inventories with minimal effort. Even when AXFR is disabled, recursive enumeration yields similar results. 2.4. Security Through Obscurity as Sole Defense The current industry response - removing records from DNS - is security through obscurity, a practice broadly condemned in security literature. It removes the threat by eliminating the data, not by controlling access to it. 2.5. Operational Degradation Removing naming from DNS does not eliminate the operational need for naming. It displaces that need into spreadsheets, wikis, tribal knowledge, and documentation systems that are consistently less accurate and less maintained than DNS itself. 2.6. Audit Gap Current DNS implementations provide no mechanism to record which entity resolved which name, when, and from where. This audit capability is standard in file systems, databases, and application systems but absent from DNS. 2.7. Example of Exposure The following example illustrates the scope of exposure from a well- maintained corporate DNS namespace: Teppo Expires 30 January 2027 [Page 6] Internet-Draft Authenticated DNS Resolution July 2026 routera.tucson.corp.example.com A 192.0.2.1 routera-to-prescott.tucson.example.com A 198.51.100.1 routerb-to-phoenix.prescott.example.com A 198.51.100.2 routerb.prescott.corp.example.com A 192.0.2.2 sw-core-01.tucson.corp.example.com A 192.0.2.3 payroll-db-01.tucson.corp.example.com A 192.0.2.4 1.2.0.192.in-addr.arpa PTR routera.tucson.corp.example.com 2.2.0.192.in-addr.arpa PTR routerb.prescott.corp.example.com routera.tucson.corp.example.com AAAA 2001:db8::1 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa. sPTR routera.tucson.corp.example.com From the above, an unauthenticated or over-privileged querier can determine physical site locations (Tucson, Prescott, Phoenix), WAN link topology and transit addressing, subnet assignments by geography, device roles (router, switch, database), and redundancy architecture. This information is obtainable via a single zone transfer or recursive enumeration requiring no credentials and no exploitation. 2.8. False Choice Created by Lack of Authorization The absence of role-based query authorization forces organizations into a false choice: either expose the entire DNS namespace to every authenticated entity, or remove records and degrade operations. ADR resolves this dilemma by treating DNS resolution as a permissioned action governed by identity and RBAC, ensuring that only the network- team - and not Windows admins, Linux admins, DBAs, helpdesk, or ordinary users - may resolve sensitive infrastructure records. 3. Prior Art 3.1. DNSSEC DNS Security Extensions (DNSSEC) [RFC4033][RFC4034][RFC4035] provide strong, well-established cryptographic authenticity and integrity for DNS data. DNSSEC ensures that responses originate from the correct zone owner and have not been modified in transit, fulfilling its design goal for the public Internet where resolvers must validate data from untrusted sources. DNSSEC is highly effective in this role and remains the best mechanism for protecting the integrity of globally visible DNS information. DNSSEC does not, however, authenticate the entity performing the query. Any client capable of reaching a DNSSEC-enabled resolver may query any signed record. This behavior is appropriate for the public Teppo Expires 30 January 2027 [Page 7] Internet-Draft Authenticated DNS Resolution July 2026 Internet, where anonymous resolution is a fundamental requirement, but it does not address enterprise scenarios where resolver visibility must be governed by machine identity, user identity, and role-based authorization. ADR therefore complements DNSSEC rather than replacing it: DNSSEC protects the authenticity of the answer, while ADR governs who is permitted to ask the question. 3.2. Active Directory Integrated DNS Active Directory (AD) Integrated DNS authenticates machines during dynamic record registration using Kerberos [RFC4120], ensuring that only authorized principals may create or update DNS records. However, AD DNS provides no query-plane authorization: once a machine is domain-joined, it may resolve any record visible to the AD DNS zone. AD DNS therefore implements management-plane RBAC but not query-plane RBAC, leaving all domain-joined machines with identical visibility into sensitive infrastructure records. 3.3. Split-Horizon DNS Split-horizon DNS presents different views of a zone based on the source IP address of the querier. This technique is coarse-grained, unauthenticated, and trivially bypassed through VPNs, NAT traversal, or IP spoofing in environments lacking strict ingress filtering. Because split-horizon DNS does not bind queries to authenticated identities, it cannot enforce role-based visibility or separation of duties. It is therefore insufficient for enterprise authorization requirements. 3.4. DNS over TLS (DoT) and DNS over HTTPS (DoH) DNS over TLS [RFC7858] and DNS over HTTPS [RFC8484] provide confidentiality and integrity for DNS queries in transit. These mechanisms protect the wire but do not authenticate the identity of the querying principal. DoT and DoH prevent eavesdropping and tampering but do not restrict which entities may resolve which records. Without identity binding, encrypted transport alone cannot support query-time authorization. Teppo Expires 30 January 2027 [Page 8] Internet-Draft Authenticated DNS Resolution July 2026 3.5. Multicast DNS (mDNS) Multicast DNS (mDNS) [RFC6762] enables service discovery in home and small-office networks by broadcasting queries and responses on the local link. mDNS assumes a trusted local environment and provides no access control, identity binding, or authorization. Its design is explicitly scoped to unmanaged networks and is unsuitable for enterprise deployments where visibility must be restricted based on machine and user identity. 3.6. Authenticated DNS Updates ([RFC2136]) The Dynamic DNS Update protocol [RFC2136] introduced authenticated record registration, allowing only authorized principals to create or modify DNS records. In Active Directory environments this mechanism is implemented using Kerberos, ensuring that only domain-joined machines may register records in AD-integrated zones. Authenticated updates demonstrate that the DNS protocol is capable of incorporating identity and authorization controls into specific operations. However, [RFC2136] authentication applies exclusively to the write path. Record creation and modification require credentials; record resolution does not. Any principal with network access to the resolver may read any record regardless of how strictly its creation was controlled. DNS therefore has authenticated writes and unauthenticated reads. ADR introduces authenticated reads, completing the access control model that [RFC2136] began on the write side. 3.7. TSIG and SIG(0) Transaction Signatures (TSIG) [RFC2845] and SIG(0) [RFC2931] provide message-level authentication for DNS operations between servers. TSIG is widely used to authenticate zone transfers between primary and secondary nameservers and to authenticate dynamic update messages from trusted sources. SIG(0) provides public-key-based message authentication for similar purposes. Both mechanisms authenticate server-to-server and updater-to-server communications. Neither mechanism authenticates the querying principal in a client-to-resolver exchange. TSIG and SIG(0) demonstrate that DNS has long supported authenticated server operations, but this authentication has never been extended to the client query path. ADR addresses this remaining gap by introducing authenticated client-to-resolver resolution. Teppo Expires 30 January 2027 [Page 9] Internet-Draft Authenticated DNS Resolution July 2026 3.8. DNS Cookies ([RFC7873]) DNS Cookies [RFC7873] provide a lightweight anti-spoofing mechanism that allows resolvers and authoritative servers to detect forged source addresses and mitigate certain reflection and amplification attacks. A server cookie is computed from the client IP address and a server secret, allowing the server to verify that subsequent requests originate from the same source. DNS Cookies provide anti-spoofing protection, not identity. They verify that a request arrives from a consistent network source but carry no information about the machine identity, user identity, or organizational role of the querying principal. DNS Cookies cannot express authorization policy, enforce separation of duties, or restrict record visibility based on authenticated identity. They are therefore complementary to ADR but do not address the query-plane authorization problem. 3.9. Response Policy Zones (RPZ) Response Policy Zones provide a mechanism for DNS resolvers to modify or block responses based on policy rules applied to queried names, response addresses, or name server addresses. RPZ is widely deployed for threat intelligence feeds, malware blocking, and content filtering. It allows administrators to redirect, refuse, or synthesize DNS responses according to locally defined policy. RPZ operates on DNS content, not on querying identity. Policy rules apply uniformly to all clients regardless of machine identity, user identity, or group membership. RPZ cannot differentiate between a network administrator and a domain user querying the same record, and it cannot enforce role-based visibility within an enterprise namespace. RPZ is sometimes described informally as DNS access control, but it filters what is served rather than governing who may resolve it. ADR addresses the identity-based authorization requirement that RPZ does not provide. 3.10. DNS Views and Split-Horizon DNS Many DNS server implementations, including BIND, support named views that present different zone content to different clients based on source IP address, network interface, or transport characteristics. Split-horizon deployments use this mechanism to serve internal records to corporate clients while presenting a reduced record set to external clients. Teppo Expires 30 January 2027 [Page 10] Internet-Draft Authenticated DNS Resolution July 2026 DNS views and split-horizon configurations are coarse-grained, unauthenticated, and bypassable. Because authorization is based on network location rather than authenticated identity, any client that can reach the resolver from an authorized network range receives the same visibility regardless of its role or the sensitivity of the records it queries. VPN connections, NAT traversal, and network topology changes can silently alter effective visibility in ways that do not reflect intended authorization policy. ADR replaces source- IP-based visibility controls with identity-bound, per-query authorization that remains consistent regardless of network path. 3.11. Network Access Control and 802.1X IEEE 802.1X and Network Access Control (NAC) frameworks authenticate devices at the network access layer, ensuring that only authorized endpoints may connect to enterprise network segments. NAC systems verify device identity, health posture, and compliance before granting network access and are widely deployed as a first line of defense in enterprise environments. NAC authenticates network access, not DNS visibility. Once a device has been admitted to the network, it may reach DNS resolvers and query any record visible to those resolvers without further authorization. NAC does not provide per-query identity evaluation, per-record authorization, or resolver-side RBAC. Enterprises that rely on NAC as their primary access control mechanism retain the full topology exposure problem described in Section 2, because NAC admission grants unrestricted DNS visibility to all admitted devices regardless of their operational role. ADR operates after network admission and applies authorization at the DNS query layer where NAC provides no control. 3.12. DNS ACLs Many DNS server implementations support access control lists (ACLs) that restrict which clients may perform specific operations such as recursion, zone transfers, or access to particular views. DNS ACLs are effective for their intended purposes and are widely used in Internet-facing deployments to implement geographic steering, direct clients to the nearest cache server, or limit administrative operations to specific network ranges. These mechanisms operate on network attributes such as source IP address, interface, or transport characteristics and are well suited to environments where coarse segmentation is sufficient. However, DNS ACLs do not authenticate the identity of the querying principal and cannot express role-based authorization. ACLs cannot differentiate between machines operated by different administrative Teppo Expires 30 January 2027 [Page 11] Internet-Draft Authenticated DNS Resolution July 2026 groups, enforce separation of duties, or restrict visibility based on user or service identity. Because ACLs authorize based on network location rather than authenticated identity, they are not capable of providing per-record or per-zone RBAC within an enterprise namespace. ADR complements existing ACL mechanisms by introducing identity- aware, per-query authorization without altering DNS protocol behavior. 4. Goals The Authenticated DNS Resolution (ADR) model seeks to restore the operational benefits of comprehensive DNS naming while eliminating the security risks associated with unauthenticated DNS queries. ADR introduces identity and authorization controls into DNS resolution, allowing organizations to publish complete and meaningful DNS records without exposing sensitive infrastructure information to unauthorized entities. The goals of ADR are as follows: 1. Restore comprehensive DNS naming in corporate environments without exposing network topology to unauthorized users or machines. 2. Treat DNS resolution as a permissioned action, governed by identity and role-based access control (RBAC), similar to file access, database queries, and API calls. 3. Authenticate the entity performing a DNS query using existing corporate identity systems, including Kerberos, X.509 client certificates, and OAuth/OIDC tokens. 4. Authorize DNS queries based on machine identity, user identity (when present), and group membership, ensuring that only principals with a legitimate operational need may resolve sensitive records. 5. Provide auditability for DNS queries, including identity, source IP, timestamp, record requested, and resolution result. 6. Preserve compatibility with existing DNS infrastructure and protocols, including recursive resolution, caching, and DNSSEC. 7. Support gradual deployment, allowing legacy clients to continue performing unauthenticated DNS queries for non-sensitive namespaces. Teppo Expires 30 January 2027 [Page 12] Internet-Draft Authenticated DNS Resolution July 2026 8. Reduce reliance on security-through-obscurity practices such as removing records from DNS or using non-descriptive naming conventions. 9. Ensure consistent authorization and audit behavior across IPv4 and IPv6, including reverse DNS (in-addr.arpa and ip6.arpa). ADR does not seek to replace DNSSEC, recursive caching, or existing DNS transport mechanisms. Instead, ADR augments DNS with identity and authorization controls that have long been standard in other corporate systems but absent from DNS itself. 5. Architecture Authenticated DNS Resolution (ADR) introduces identity and authorization controls into DNS query processing while preserving compatibility with existing DNS protocols and infrastructure. ADR does not replace DNS; it augments it with authentication, authorization, and audit capabilities that have long been standard in other corporate systems. ADR consists of the following architectural components: 5.1. DNS Deployment Models This document treats Internet DNS and DNSSEC as the public integrity layer for globally visible names, and treats ADR as an enterprise query-plane layer that enforces per-query identity, RBAC, and audit for internal names. The DNS ecosystem consists of distinct operational environments with different security and administrative requirements. No single authentication or authorization model is appropriate for all deployments. ADR applies equally to IPv4 and IPv6 environments. Resolver identity, per-query authorization, and audit mechanisms operate independently of IP address family; policy and RBAC decisions must be applied consistently for both IPv4 and IPv6 records and reverse mappings (in-addr.arpa and ip6.arpa). 5.1.1. Home and Small Office Networks Home and small office networks typically consist of trusted devices under common administrative control. Service discovery protocols such as mDNS are generally sufficient, and user- or machine-level authorization of DNS queries provides little operational benefit. Teppo Expires 30 January 2027 [Page 13] Internet-Draft Authenticated DNS Resolution July 2026 5.1.2. Public Internet DNS The public Internet requires anonymous, globally accessible name resolution. Internet DNS prioritizes authenticity and integrity of DNS data through mechanisms such as DNSSEC. Because public authoritative servers cannot reasonably maintain identities or authorization policies for arbitrary Internet clients, identity-based query authorization is outside the scope of Internet DNS. 5.1.3. Enterprise and Corporate DNS Enterprise networks operate under centralized administrative control and already maintain identity, authentication, and authorization infrastructures. Directory services, identity providers, public key infrastructures, and RBAC systems are commonly deployed to control access to enterprise resources. ADR applies only to this environment. Rather than introducing a new authentication mechanism, ADR leverages existing enterprise identity systems to authorize DNS query resolution according to organizational policy. This approach aligns DNS with the authorization models already used for filesystems, databases, applications, and network infrastructure. ADR does not change public DNS or DNSSEC behavior; public zones remain anonymous and integrity-protected as today. In enterprise deployments ADR enforces per-query authentication and RBAC so that sensitive records (for example, router and firewall names) are resolvable only by authorized principals while ordinary service names remain available to business clients. 5.2. Authenticated Transport ADR resolvers accept DNS queries over authenticated transports. These transports may include: 1. Kerberos-authenticated DNS over TCP [RFC7766] or TLS [RFC8446]. 2. DNS over TLS (DoT) [RFC7858] with client certificates. 3. DNS over HTTPS (DoH) with OAuth/OIDC bearer tokens. 4. Mutual TLS (mTLS) [RFC8705] using X.509 client certificates. Teppo Expires 30 January 2027 [Page 14] Internet-Draft Authenticated DNS Resolution July 2026 Implementations MUST ensure that authentication, authorization, and audit are applied consistently across IPv4 and IPv6 transports. Reverse DNS handling for IPv6 (ip6.arpa) MUST be treated with the same sensitivity and RBAC controls as IPv4 reverse zones to avoid topology leakage via PTR records. Unauthenticated UDP and TCP DNS MAY be supported for non-sensitive namespaces, but ADR resolvers MUST require authenticated transport for any namespace containing infrastructure records, administrative records, or other sensitive information. 5.2.1. What Authenticated Transport Provides Authenticated transport enables ADR to enforce identity-based authorization without modifying the DNS protocol. ADR does not introduce new DNS header fields, opcodes, EDNS options, resource record types, or message formats. DNS queries and responses remain wire-compatible with existing clients, resolvers, and DNSSEC validators. By carrying identity in the transport layer (Kerberos, mTLS, DoH with OIDC), ADR gains: 1. *Identity Without Protocol Changes* - DNS packets remain unchanged. ADR resolvers extract identity from the transport, not from DNS messages. 2. *Full Compatibility With Existing DNS Infrastructure* - Recursive resolution, caching, DNSSEC validation, and authoritative behavior operate exactly as defined in existing RFCs. 3. *Incremental Deployment* - Clients capable of authenticated transport require no changes to DNS stub resolver logic. Legacy clients continue using unauthenticated DNS for non-sensitive zones. 4. *Authorization at Query Time* - Authenticated transport binds each DNS query to a principal, enabling ADR resolvers to apply RBAC policies without altering DNS semantics. 5. *No New Record Types or Header Fields* - ADR does not define new DNS resource records, flags, or protocol extensions. All DNS behavior remains unchanged for authorized principals. Authenticated transport therefore provides the identity substrate required for ADR while preserving the DNS protocol exactly as it exists today. Teppo Expires 30 January 2027 [Page 15] Internet-Draft Authenticated DNS Resolution July 2026 5.3. Query Authentication Flow When a DNS query arrives over an authenticated transport, the ADR resolver performs the following steps: 1. Extract machine identity from the transport layer (Kerberos principal, client certificate, or workload token). 2. Extract user identity if present (Kerberos PAC attributes, certificate SAN fields, or OIDC claims). 3. Merge machine and user group memberships to form the effective identity. 4. Evaluate RBAC policy for the requested record, record type, or zone. 5. Return one of the following: RESOLVED (authorized), NXDOMAIN (record does not exist), AUTH-NXDOMAIN (record exists but the principal lacks permission). This flow ensures that DNS resolution reflects operational responsibility rather than mere network access. 5.4. Authorization Engine The ADR authorization engine evaluates RBAC policies defined by administrators. Policies may apply at the zone level, record-type level, or individual record level. Policies may reference machine identities, user identities, and group memberships. Examples of authorization boundaries include: * Only network-team may resolve router, firewall, core switch, WAN link, and transit infrastructure records. * Windows administrators may resolve Windows server records only. * Linux administrators may resolve Linux server records only. * Helpdesk may resolve workstation and printer records. * DBA teams may resolve specific database servers. * Domain computers may resolve workstation A and PTR records required for normal operation. Teppo Expires 30 January 2027 [Page 16] Internet-Draft Authenticated DNS Resolution July 2026 5.5. Legacy Client Support ADR deployments may include legacy clients that cannot perform authenticated DNS queries. ADR resolvers MAY permit unauthenticated queries for non-sensitive namespaces. Sensitive namespaces MUST require authenticated transport. Legacy support allows gradual migration without disrupting existing systems. 5.6. Compatibility ADR is fully compatible with: * DNSSEC * Recursive resolution * Caching resolvers * Forwarders * Split-horizon DNS * Existing zone files * Existing naming conventions ADR does not modify DNS record formats or DNSSEC validation. It adds identity and authorization controls to the query path while preserving all existing DNS behavior for authorized principals. 6. Identity and Authorization Model ADR introduces identity and authorization controls into DNS resolution. DNS queries in corporate environments are overwhelmingly machine-initiated, but authorization boundaries are determined by the roles of the human operators and service accounts associated with those machines. ADR therefore evaluates both machine identity and user identity (when present), merging group memberships to form the effective identity used for authorization. Top technical review concerns include per-principal cache keying to prevent leakage, token protection and replay controls, recommended fail modes (fail-closed for sensitive zones), audit retention and privacy, and migration guidance for legacy clients. See the detailed mitigations below. Teppo Expires 30 January 2027 [Page 17] Internet-Draft Authenticated DNS Resolution July 2026 6.1. Identity Binding ADR resolvers MUST support identity binding for both machine principals and human principals. Identity binding requires evaluation of all relevant principal types: *Machine Identity:* The computer account or workload identity performing the DNS query. Examples include Kerberos computer accounts, X.509 client certificates, or OAuth/OIDC workload tokens. Machine identity establishes where the query originates and provides baseline authorization for system-level operations. *User Identity (if present):* The human principal currently authenticated to the machine or session. User identity determines who is operating the machine and provides role-based authorization for administrative tasks. ADR resolvers MUST extract user identity from Kerberos PAC attributes, X.509 SAN fields, or OIDC claims when available. *Group Membership:* The effective identity of a querying entity is the union of machine group memberships, user group memberships, and service account group memberships. Group membership determines what the principal is allowed to see within the DNS namespace. ADR deployments MUST enforce strict separation of duties through group-based RBAC. In particular: * network-team is the only group permitted to resolve router, firewall, core switch, WAN link, and transit-infrastructure records. This prevents Windows, Linux, and application administrators from obtaining network topology information they do not require. * windows-admins, linux-admins, helpdesk, dba-team, and domain-users MUST NOT inherit network-infrastructure visibility unless explicitly granted. * domain-computers MAY receive limited workstation-level permissions required for normal system operation. Identity binding ensures that DNS resolution reflects operational responsibility rather than mere network access. Machines perform DNS queries automatically, but authorization is governed by the roles of the humans and service accounts associated with those machines. Teppo Expires 30 January 2027 [Page 18] Internet-Draft Authenticated DNS Resolution July 2026 6.2. Permission Model ADR uses a role-based access control (RBAC) model to determine whether a principal may resolve a DNS record. Permissions may be granted at the following levels: *Zone-Level:* Permissions applying to an entire DNS zone. *Record-Type-Level:* Permissions applying to specific DNS record types (A, AAAA, PTR, SRV, TXT). *Record-Level:* Permissions applying to individual DNS records. Policies may reference machine identities, user identities, and group memberships. ADR resolvers evaluate the effective identity of the principal performing the query and apply the most specific matching policy. 6.3. Example Policy zone "corp.example.com" { default-permission: DENY; grant { identity: group:network-team; scope: record; name-pattern: [ "router*.corp.example.com", "fw-*.corp.example.com", "sw-core-*.corp.example.com", "wan-link-*.corp.example.com", "transit-*.corp.example.com" ]; permission: RESOLVE; }; grant { identity: group:windows-admins; scope: record-type:A, record-type:PTR; name-pattern: "*.winserver.corp.example.com"; permission: RESOLVE; }; grant { identity: group:linux-admins; scope: record-type:A, record-type:PTR; name-pattern: "*.linux.corp.example.com"; permission: RESOLVE; Teppo Expires 30 January 2027 [Page 19] Internet-Draft Authenticated DNS Resolution July 2026 }; grant { identity: group:helpdesk; scope: record-type:A, record-type:PTR; name-pattern: [ "*.workstation.corp.example.com", "*.print.corp.example.com" ]; permission: RESOLVE; }; grant { identity: group:dba-team; scope: record; names: [ "payroll-db-01.corp.example.com", "payroll-db-02.corp.example.com", "hr-db-01.corp.example.com" ]; permission: RESOLVE; }; grant { identity: group:domain-computers; scope: record-type:A, record-type:PTR; name-pattern: "*.workstation.corp.example.com"; permission: RESOLVE; }; } 6.4. Dual Identity Resolution DNS queries are machine-driven, but authorization boundaries are human-driven. ADR resolvers MUST evaluate both machine identity and user identity (when present). The union of machine and user group memberships forms the effective identity used for authorization. This ensures that: * A machine operated by a network administrator may resolve router names. * The same machine operated by a normal user may not. * A machine operated by a DBA may resolve database servers. * A machine operated by helpdesk may resolve workstations only. Teppo Expires 30 January 2027 [Page 20] Internet-Draft Authenticated DNS Resolution July 2026 Dual identity resolution aligns DNS authorization with operational responsibility and prevents accidental or malicious over-visibility. 7. Resolver Behavior ADR resolvers extend traditional DNS resolver behavior by adding identity extraction, authorization evaluation, and audit logging. All other aspects of DNS resolution remain unchanged. ADR resolvers continue to support recursive queries, caching, DNSSEC validation, and standard DNS transport mechanisms. 7.1. Query Processing Steps An ADR resolver processes a DNS query using the following steps: 1. Receive the DNS query over an authenticated or unauthenticated transport. 2. If the transport is authenticated, extract machine identity, user identity (if present), and group memberships. 3. Construct the effective identity by merging machine and user group memberships. 4. Evaluate RBAC policy for the requested record, record type, or zone. 5. If authorized, perform normal DNS resolution using local zone data, forwarding, recursion, or caching. 6. If unauthorized, return NXDOMAIN or AUTH-NXDOMAIN depending on policy. 7. Generate an audit log entry for authenticated queries. 7.2. Caching Behavior ADR resolvers MAY cache DNS responses normally. Authorization decisions MUST NOT be cached across principals. A cached DNS answer may be reused only if the principal requesting the cached answer is authorized to receive it. Authorization caching MAY be used for short durations (for example, the lifetime of a Kerberos service ticket or an OAuth token) to reduce repeated identity evaluation overhead. Teppo Expires 30 January 2027 [Page 21] Internet-Draft Authenticated DNS Resolution July 2026 7.3. Forwarding and Recursion ADR resolvers MAY forward queries to upstream resolvers or perform recursive resolution. Authorization MUST be evaluated before forwarding or recursion. If a principal is not authorized to resolve a record, the resolver MUST NOT forward the query. 7.4. NXDOMAIN Handling ADR resolvers support two forms of NXDOMAIN: *NXDOMAIN:* Returned when the record does not exist or when the resolver is configured to hide authorization failures. *AUTH-NXDOMAIN:* Returned when the record exists but the principal lacks permission to resolve it. This mode provides stronger audit signal but may reveal the existence of records to unauthorized principals. Administrators MAY choose either mode depending on security requirements. 7.5. Transport Requirements ADR resolvers MUST support at least one authenticated transport. Supported transports MAY include: * Kerberos-authenticated DNS over TCP or TLS * DNS over TLS (DoT) with client certificates * DNS over HTTPS (DoH) with OAuth/OIDC tokens * Mutual TLS (mTLS) with X.509 client certificates Unauthenticated UDP/TCP DNS MAY be supported for non-sensitive namespaces. 7.6. Error Handling ADR resolvers MUST handle the following error conditions: * Invalid or expired authentication tokens * Missing or malformed client certificates * Kerberos authentication failures Teppo Expires 30 January 2027 [Page 22] Internet-Draft Authenticated DNS Resolution July 2026 * Authorization failures * Transport negotiation failures Resolvers SHOULD provide clear audit entries for all authentication and authorization errors. 7.7. Performance Considerations Authentication and authorization introduce additional processing overhead. Resolvers SHOULD: * Cache validated tokens and PAC attributes * Reuse TLS sessions * Minimize repeated group membership lookups * Use efficient RBAC policy evaluation structures These optimizations ensure ADR resolvers remain performant under typical corporate DNS query loads. 8. Integration with Existing Infrastructure ADR is an authorization architecture for DNS that augments resolver behavior with per-query identity, role-based authorization, and audit. ADR does not define a new identity protocol, identity provider, or credential format; instead, ADR integrates with existing enterprise identity and authentication infrastructures to establish the identity of the querying principal before evaluating authorization policy. ADR does not require changes to DNS resource records, zone signing, DNSSEC, recursive resolution, or zone management. ADR extends resolver behavior by introducing identity- aware authorization into the DNS query path. ADR is scoped to enterprise private namespaces and private address spaces; it does not change public Internet DNS behavior. Operators MAY restrict which hosts may reach ADR resolver endpoints by private address ranges (IPv4 [RFC1918]: 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16; IPv6 ULA: fc00::/7 per [RFC4193]). These network controls are useful for segmentation, bootstrapping, and limiting legacy or unmanaged clients, but they are coarse-grained and MUST NOT replace identity-bound authentication and per-query RBAC. Clients outside the enterprise private address space (for example, remote or cloud hosts) MUST authenticate to ADR endpoints via VPN, managed tunnels, or authenticated DoH/DoT before being permitted to resolve sensitive zones. Teppo Expires 30 January 2027 [Page 23] Internet-Draft Authenticated DNS Resolution July 2026 8.1. Identity Providers Any authentication mechanism capable of establishing a verifiable identity for a querying principal MAY be used with ADR. Implementations MAY integrate with one or more enterprise identity providers capable of establishing authenticated identities for users, machines, workloads, service accounts, or other principals. Examples include Kerberos, X.509 client certificates, OAuth 2.0 [RFC6749] / OpenID Connect, SAML, hardware-backed device identities, enterprise PKI, and federated identity services. ADR places no architectural preference on any identity provider. 8.2. Identity Binding and Client Model A principal MAY represent a machine, a human user, a service account, an application or workload, or another authenticated enterprise identity. When multiple identities are available (for example, a user operating an authenticated workstation), implementations MAY evaluate machine identity, user identity, or both according to local policy. Managed endpoints are typically provisioned to act as stub resolvers that authenticate to ADR resolver endpoints; ADR resolvers are the enforcement point that authenticate the principal, evaluate authorization, validate DNSSEC, and emit audit records. Clients SHOULD be treated as non-validating stubs unless explicitly configured and verified to perform DNSSEC validation locally. 8.3. Mapping Enterprise Identity to RBAC Authenticated identities are mapped to locally defined authorization policies. Examples of role mappings include: * Network Administrators: resolve router, firewall, core switch, WAN, transit, and other network infrastructure records. * Windows Administrators: resolve Windows server records required for system administration. * Linux Administrators: resolve Linux server records required for system administration. * Database Administrators: resolve database infrastructure records. * Helpdesk Personnel: resolve workstation, printer, and end-user support records. * Ordinary Users: resolve workstation and non-sensitive service records required for normal business operations. Teppo Expires 30 January 2027 [Page 24] Internet-Draft Authenticated DNS Resolution July 2026 * Machine Identities: resolve only those records required for automated system operation and service discovery. Organizations MAY define additional roles appropriate to their operational and security requirements. Authorization decisions are made per-query by evaluating the principal against RBAC policy for the requested name and qtype. 8.4. Deployment Models and IP Gating ADR may be deployed in several architectural models: * Centralized Resolver: a single ADR resolver or resolver cluster authorizes all authenticated DNS queries. * Distributed Resolver: multiple ADR resolvers operate across sites or network segments while enforcing a common authorization policy. * Split-Horizon Deployment: authenticated queries are processed by ADR resolvers while traditional DNS continues serving non- sensitive namespaces. * Hybrid Deployment: authenticated and traditional DNS services coexist during migration or for legacy client support. Operators commonly use network controls (IP ACLs, VLANs, DHCP scopes) to limit which hosts can reach ADR resolver endpoints as a bootstrap and segmentation measure. Recommended operational patterns: * Defense in depth: use IP ACLs, VLANs, and DHCP scopes to reduce the initial attack surface and to isolate legacy or unmanaged devices. * Authenticated transport for sensitive zones: require Kerberos, mTLS, or DoT/DoH+OIDC for any zone marked sensitive; treat IP ACLs as a secondary control. * Provisioning: provision managed endpoints (DHCP, MDM, Group Policy) to point to ADR resolver endpoints and to obtain required credentials or certificates automatically. * Remote and cloud hosts: require VPN, managed client tunnels, or explicit authentication to ADR endpoints for clients that are not within the enterprise private address space. * Behavior options for non-private clients: administrators MAY choose to deny resolver access unless the client authenticates, redirect unauthenticated clients to a public/non-sensitive Teppo Expires 30 January 2027 [Page 25] Internet-Draft Authenticated DNS Resolution July 2026 resolver or captive ADR endpoint, require VPN/managed tunnel before ADR access, or apply per-zone policy permitting unauthenticated queries only for non-sensitive zones. 8.5. Migration Strategy Organizations MAY deploy ADR incrementally. A typical migration consists of: 1. Deploy ADR resolvers alongside existing DNS infrastructure. 2. Configure one or more trusted identity providers and provisioning mechanisms. 3. Define RBAC policies for sensitive namespaces. 4. Enable authenticated DNS for administrative systems and critical services. 5. Gradually expand ADR coverage as clients become capable of authenticated resolution. 6. Restrict unauthenticated DNS to approved public or non-sensitive records. This phased approach minimizes operational disruption while permitting gradual policy refinement. 8.6. Operational Considerations, DNSSEC Preservation, and Resolver Responsibilities Organizations deploying ADR SHOULD: * Maintain accurate identity and role assignments. * Review authorization policies regularly. * Monitor audit logs for unauthorized resolution attempts. * Protect identity-provider trust relationships. * Secure ADR resolvers to the same standard as other critical identity-aware infrastructure. * Minimize privileges using least-privilege RBAC principles. Teppo Expires 30 January 2027 [Page 26] Internet-Draft Authenticated DNS Resolution July 2026 *DNSSEC preservation:* ADR does not change DNSSEC or the DNSSEC trust model. ADR resolvers MUST perform DNSSEC validation on any answers they return and MUST NOT alter zone RRs, RRSIGs, or signed denial records; ADR is an authorization layer applied after cryptographic validation. ADR resolvers validate responses using standard DNSSEC mechanisms (see [RFC4033], [RFC4034], [RFC4035] and RFC 5155) and may rely on compact/online denial optimizations where applicable (see [RFC9824]), but they do not require changes to zone signing or the chain of trust. Network controls used to gate access to ADR endpoints (for example, IPv4 [RFC1918]: 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16; IPv6 ULA: fc00::/7 per [RFC4193]) are operational segmentation measures only and do not substitute for cryptographic validation or identity-bound authorization. Operators MUST NOT disable DNSSEC validation to accommodate ADR deployment or network interception; DNSSEC validation failures and all denied queries MUST be logged with principal id, source IP, name, qtype, and timestamp for monitoring and incident response. *Resolver responsibilities:* ADR resolvers are the enforcement point for authenticated resolution. They MUST authenticate the querying principal, evaluate RBAC policy, validate DNSSEC for any answers they return, and emit tamper-protected audit records. When forwarding authorized queries to upstream resolvers that do not implement ADR, ADR resolvers MUST NOT forward principal credentials or identifying tokens; the upstream will see only the ADR resolver as the client. ADR resolvers remain responsible for the final disclosure decision and for preserving DNSSEC validation and integrity before returning answers to the original principal. 8.7. Implementation Checklist (Operational Summary) * Enforce authenticated transport for sensitive zones. * Key caches by principal: cache entries SHOULD be keyed by (name, qtype, effective-principal-id). * Authz cache lifetime: authz cache entries SHOULD expire at the shorter of the authentication token lifetime and an operator- configured authz-cache-max (recommended default 300 seconds). * Provision clients centrally to obtain credentials and resolver configuration. * Log and monitor unauthenticated queries by source IP and escalate anomalies. Teppo Expires 30 January 2027 [Page 27] Internet-Draft Authenticated DNS Resolution July 2026 * Per-zone fail modes: configure fail-closed for critical infrastructure and allow fail-open for low-sensitivity service discovery where availability is paramount. 8.8. Summary, Addressing, and Key Considerations *Standards background:* [RFC1918] defines the IPv4 private address blocks 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16. [RFC4193] defines IPv6 Unique Local Addresses (ULA) with prefix fc00::/7 (commonly used fd00::/8 for locally assigned ULA). *Key considerations:* * *Scope:* ADR is scoped to private namespaces and private address spaces; do not attempt to gate or authorize arbitrary public Internet addresses. * *Bootstrapping:* Use IP ACLs keyed to [RFC1918] / ULA ranges to limit who can reach ADR endpoints during rollout. This is operational segmentation, not proof of identity. * *Authentication:* Require identity-bound transports (mTLS, Kerberos, DoH+OIDC) for sensitive zones; private IP presence alone is insufficient. * *Risks:* IP controls are brittle - private addresses can be NATed, reused in cloud VPCs, or assigned to unmanaged devices; they cannot replace per-query authentication. Relying on IP-only gating risks accidental exposure when networks merge or when remote/cloud hosts use the same private ranges. * *Recommendation:* Use IP ACLs for segmentation and migration only; make identity the primary enforcement mechanism. Log and monitor unauthenticated queries by source IP and principal mapping. 9. Security Considerations This document is primarily concerned with security. The following considerations apply to the ADR architecture proposed herein. 9.1. Credential Protection Kerberos service tickets, X.509 client certificates, and OAuth/OIDC tokens used for DNS query authentication MUST be protected in transit. ADR resolvers MUST require TLS for all authenticated query sessions. Unauthenticated (cleartext UDP or TCP DNS) MAY be supported only for a restricted, default-deny namespace permitting resolution of non-sensitive records. Teppo Expires 30 January 2027 [Page 28] Internet-Draft Authenticated DNS Resolution July 2026 9.2. Topology Minimization via RBAC ADR MUST enforce strict separation of duties through role-based visibility controls. Only the network-team may resolve router, firewall, core switch, WAN link, and transit-infrastructure records. Windows administrators, Linux administrators, DBA teams, helpdesk personnel, and ordinary domain users MUST NOT inherit network- infrastructure visibility unless explicitly granted. This prevents unnecessary exposure of network topology and significantly reduces lateral-movement reconnaissance opportunities. 9.3. Dual Identity Evaluation DNS queries are machine-initiated, but authorization boundaries are determined by the roles of the human operators and service accounts associated with those machines. ADR resolvers MUST evaluate both machine identity and user identity (when present), merging group memberships to determine effective permissions. This prevents machines operated by non-network personnel from resolving sensitive infrastructure records. 9.4. Authenticated NXDOMAIN Handling The distinction between "record does not exist" and "record exists but you lack permission" must be carefully considered. Implementations MAY return standard NXDOMAIN in both cases to prevent information leakage about namespace contents, accepting reduced audit signal as a tradeoff. Alternatively, authenticated NXDOMAIN MAY be used to detect unauthorized enumeration attempts without revealing record existence. 9.5. Resolver Compromise A compromised ADR resolver has access to the complete DNS namespace and the audit log of all queries. Resolver security is therefore critical. ADR resolvers SHOULD be hardened, monitored, and subject to privileged access controls consistent with domain controller security standards. 9.6. Kerberos Delegation and Token Replay Implementations MUST carefully control Kerberos delegation settings on the DNS service principal and MUST validate OAuth/OIDC tokens using proof-of-possession mechanisms (mTLS or DPoP) to prevent credential forwarding or token replay attacks. Teppo Expires 30 January 2027 [Page 29] Internet-Draft Authenticated DNS Resolution July 2026 9.7. Legacy Fallback Environments transitioning to ADR will need to support legacy clients incapable of authenticated DNS. A phased approach with monitoring of unauthenticated query sources is recommended during transition. Legacy clients SHOULD be restricted to non-sensitive namespaces. 9.8. Denial of Service Authentication overhead introduces additional latency and computational cost per query. ADR resolvers MUST implement rate limiting and SHOULD cache authenticated session state to minimize per-query overhead. Token validation SHOULD be optimized through JWKS caching and PAC attribute caching where applicable. 9.9. Protocol Impact Statement ADR has no impact on the DNS protocol itself. ADR does not modify DNS message format, DNS header fields, opcodes, EDNS options, resource record types, DNSSEC validation behavior, or wire-format semantics. All DNS queries and responses remain fully compatible with existing DNS clients, stub resolvers, recursive resolvers, authoritative servers, and DNSSEC validators. ADR applies exclusively to DNS resolvers operating inside enterprise and corporate networks. ADR is not intended for public Internet DNS, ISP recursive resolvers, home networks, or globally visible authoritative servers. ADR relies on identity systems (Kerberos, X.509, OAuth/OIDC) and authenticated transports (DoT, DoH, mTLS) that exist only in managed enterprise environments. ADR may be used with enterprise-managed consumer-grade devices such as cameras, badge readers, access control panels, point-of-sale terminals, scanners, and corporate laptops or mobile devices. These devices participate in enterprise identity infrastructure and therefore can authenticate to ADR resolvers. ADR does not apply to unmanaged home devices or consumer DNS environments. Because ADR operates entirely at the resolver authorization layer and carries identity in the transport rather than the DNS packet, ADR introduces no protocol-level changes and has no effect on Internet DNS or home DNS behavior. Teppo Expires 30 January 2027 [Page 30] Internet-Draft Authenticated DNS Resolution July 2026 9.10. Deployment Scope Clarification ADR applies exclusively to DNS resolvers operating inside enterprise and corporate networks. ADR is not intended for public Internet DNS, ISP recursive resolvers, home networks, or globally visible authoritative servers. ADR may be used with enterprise-managed consumer-grade devices, including: * enterprise cameras * badge readers * access control panels * point-of-sale terminals * industrial scanners * corporate laptops and mobile devices These devices are often consumer-grade hardware, but they participate in the organization's identity infrastructure (Kerberos, X.509, OAuth/OIDC) and authenticated transports (DoT, DoH, mTLS). ADR applies whenever the enterprise controls the identity of the device. ADR does not apply to unmanaged consumer devices such as home routers, home laptops, personal phones, smart TVs, or IoT devices operating outside enterprise identity systems. ADR therefore operates strictly within private enterprise namespaces and has no impact on Internet DNS, home DNS, or consumer DNS infrastructure. 10. IANA Considerations This document does not define any new DNS record types, DNS classes, protocol parameters, or registry entries. ADR operates entirely within existing DNS protocol structures and does not require changes to IANA-managed registries. ADR introduces no new RR TYPEs, no new RR CLASSes, and no new opcode or rcode values. All ADR functionality is implemented at the resolver level using authentication, authorization, and audit mechanisms external to DNS record formats. No IANA actions are required. Teppo Expires 30 January 2027 [Page 31] Internet-Draft Authenticated DNS Resolution July 2026 11. Future Extensions Possible future work includes: * Standardized ADR policy language * DNS message extensions for authenticated transports * Integration with DoQ (DNS over QUIC) * Resolver-to-resolver identity propagation * Standard audit log schema 12. References 12.1. Normative References [RFC1034] Mockapetris, P., "Domain Names - Concepts and Facilities", RFC 1034, November 1987, . [RFC1035] Mockapetris, P., "Domain Names - Implementation and Specification", RFC 1035, November 1987, . [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "DNS Security Introduction and Requirements", RFC 4033, March 2005, . [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Resource Records for the DNS Security Extensions", RFC 4034, March 2005, . [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Protocol Modifications for the DNS Security Extensions", RFC 4035, March 2005, . [RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The Kerberos Network Authentication Service (V5)", RFC 4120, July 2005, . [RFC6749] Hardt, D., "The OAuth 2.0 Authorization Framework", RFC 6749, October 2012, . Teppo Expires 30 January 2027 [Page 32] Internet-Draft Authenticated DNS Resolution July 2026 [RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D., and P. Hoffman, "Specification for DNS over Transport Layer Security (TLS)", RFC 7858, May 2016, . [RFC7766] Dickinson, J., Dickinson, S., Bellis, R., Mankin, A., and D. Wessels, "DNS Transport over TCP - Implementation Requirements", RFC 7766, March 2016, . [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 8446, August 2018, . [RFC8484] Hoffman, P. and P. McManus, "DNS Queries over HTTPS (DoH)", RFC 8484, October 2018, . [RFC8705] Campbell, B., Bradley, J., Sakimura, N., and T. Lodderstedt, "OAuth 2.0 Mutual-TLS Client Authentication and Certificate-Bound Access Tokens", RFC 8705, February 2020, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997, . 12.2. Informative References [RFC2136] Vixie, P., Thomson, S. S., Rekhter, Y., and J. Bound, "Dynamic Updates in the Domain Name System (DNS UPDATE)", RFC 2136, April 1997, . [RFC2845] 3rd, D. M. E., Gudmundsson, O., Vixie, P., and B. Wellington, "Secret Key Transaction Authentication for DNS (TSIG)", RFC 2845, May 2000, . [RFC2931] 3rd, D. M. E., "DNS Request and Transaction Signatures (SIG(0)s)", RFC 2931, September 2000, . [RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762, February 2013, . Teppo Expires 30 January 2027 [Page 33] Internet-Draft Authenticated DNS Resolution July 2026 [RFC7873] 3rd, D. M. E. and M. Andrews, "Domain Name System (DNS) Cookies", RFC 7873, May 2016, . [RFC9824] Huque, S., Elmerot, C., and O. Gudmundsson, "Compact Denial of Existence in DNSSEC", RFC 9824, September 2025, . [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast Addresses", RFC 4193, October 2005, . [RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., Groot, G. J. D., and E. Lear, "Address Allocation for Private Internets", RFC 1918, February 1996, . Author's Address Terry Teppo Independent Submission Iron River, WI United States of America Email: TerryTeppo.RFC@outlook.com Teppo Expires 30 January 2027 [Page 34]