| Internet-Draft | Authenticated DNS Resolution | July 2026 |
| Teppo | Expires 30 January 2027 | [Page] |
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.¶
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 (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.¶
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.¶
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].¶
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 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.¶
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.¶
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:¶
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.¶
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.¶
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.¶
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.¶
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.¶
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.¶
The following example illustrates the scope of exposure from a well-maintained corporate DNS namespace:¶
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.¶
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.¶
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 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.¶
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.¶
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.¶
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.¶
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.¶
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.¶
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.¶
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.¶
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.¶
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.¶
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.¶
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 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.¶
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:¶
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.¶
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:¶
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).¶
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.¶
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.¶
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.¶
ADR resolvers accept DNS queries over authenticated transports. These transports may include:¶
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.¶
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:¶
Authenticated transport therefore provides the identity substrate required for ADR while preserving the DNS protocol exactly as it exists today.¶
When a DNS query arrives over an authenticated transport, the ADR resolver performs the following steps:¶
This flow ensures that DNS resolution reflects operational responsibility rather than mere network access.¶
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:¶
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.¶
ADR is fully compatible with:¶
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.¶
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.¶
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:¶
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.¶
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.¶
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;
};
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;
};
}
¶
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:¶
Dual identity resolution aligns DNS authorization with operational responsibility and prevents accidental or malicious over-visibility.¶
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.¶
An ADR resolver processes a DNS query using the following steps:¶
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.¶
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.¶
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.¶
ADR resolvers MUST support at least one authenticated transport. Supported transports MAY include:¶
Unauthenticated UDP/TCP DNS MAY be supported for non-sensitive namespaces.¶
ADR resolvers MUST handle the following error conditions:¶
Resolvers SHOULD provide clear audit entries for all authentication and authorization errors.¶
Authentication and authorization introduce additional processing overhead. Resolvers SHOULD:¶
These optimizations ensure ADR resolvers remain performant under typical corporate DNS query loads.¶
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.¶
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.¶
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.¶
Authenticated identities are mapped to locally defined authorization policies. Examples of role mappings include:¶
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.¶
ADR may be deployed in several architectural models:¶
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:¶
Organizations MAY deploy ADR incrementally. A typical migration consists of:¶
This phased approach minimizes operational disruption while permitting gradual policy refinement.¶
Organizations deploying ADR SHOULD:¶
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.¶
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:¶
This document is primarily concerned with security. The following considerations apply to the ADR architecture proposed herein.¶
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.¶
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.¶
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.¶
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.¶
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.¶
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.¶
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.¶
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.¶
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.¶
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:¶
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.¶
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.¶
Possible future work includes:¶