This is not an official U.S. federal government website. The Federal Modernization Workbook is independent technical analysis. It does not represent the position of, and has not been reviewed or endorsed by, any federal agency.

Evaluation · In review

Cloud DNS on AWS, Azure and Oracle Cloud: Native Resolvers, Infoblox and BIND

For FedRAMP Moderate civilian agencies: the Route 53 VPC Resolver, the Azure DNS Private Resolver and the Oracle Cloud VCN resolver in depth, when to run your own DNS servers in a cloud, how to run BIND there so it stays inside Book 08’s single policy plane, and an alignment checklist for an agency adding BIND servers in AWS

Research under review: the Route 53 VPC Resolver (endpoints, forwarding and system rules, rule sharing through AWS RAM, DNS Firewall, query logging, private hosted zones, Profiles) the Azure DNS Private Resolver (endpoints, rulesets, DNS resolver policy) and the Oracle Cloud Infrastructure VCN resolver (views, endpoints, rules), with GovCloud (US), Azure Government, Oracle US Government Cloud and FedRAMP scope as the providers state it; when to run Infoblox vNIOS or BIND in a cloud instead of, or beside, the native resolver; BIND roles, placement, forwarding, DNSSEC, response policy zones and CISA Protective DNS, logging, patching and configuration from Git; an alignment checklist; and the NIST SP 800-53 mapping.

Status — In review

This page is under review and is not yet part of the workbook's production guidance. Its claims are sourced, but its analysis and any recommendation are the program's working view; they may change before review is complete, and they are not endorsed by any federal agency. Last reviewed 2026-10-31.

Book 08 — DNS, DHCP & IPAM asks for one authoritative policy and state plane that every other DNS system consumes. Zones, forwarding rules, IPAM data and security policy live in one place, and cloud DNS services are “synchronized targets or forwarding destinations rather than independently authored sources” (Chapter 08). The warning is about authoring copies in every silo, which produces split-brain answers, names that work in one cloud but not another, and uneven Protective DNS and logging.

This page fills gaps in how the workbook covers that design in the clouds:

• Infoblox with Azure and AWS is covered. Book 08 Chapter 07 covers Azure private endpoints, the Azure DNS Private Resolver in a hub-and-spoke network, the hybrid resolution patterns and AWS VPC IPAM. Chapter 08 sets the per-cloud conditional forwarding (Decision 3) and the order of the forwarding chain (Decision 2). The evaluation Trinzic Alone, or Trinzic Plus Cloud DDI? sets out the three Infoblox options: vNIOS in each cloud (A), Universal DDI writing to the cloud DNS services (B), and the Grid alongside native cloud DNS with two-way forwarding (C).
• The Route 53 Resolver is covered more thinly than Azure’s. Book 08 names its endpoints, rules and rule sharing, but doesn’t lay out how they work or what differs in AWS GovCloud (US), service by service. Part 1 does.
• Oracle Cloud is covered at the comparison level. Book 08 Chapter 07 compares Oracle Cloud Infrastructure’s private DNS with the other platforms, and notes that the HR platform runs on Oracle Cloud. Part 1 adds its resolver in the same depth as the other two, with the US Government Cloud and FedRAMP scope.
• BIND in AWS or Azure isn’t covered. The books touch it only briefly: Book 08, Chapter 08 holds self-managed DNS servers in a cloud, such as BIND, to the single-plane rule, and Chapter 07 points here for running BIND beside the native resolvers; Book 12, Chapter 05 mentions it because Microsoft’s ASIM DNS parser for Infoblox NIOS also handles BIND logs. Design depth is what the books lack, and Parts 2 to 4 supply it.

NoteSources, labels and scope

Every provider, product and policy fact was checked against primary sources (AWS, Microsoft Learn, Oracle, ISC, NIST, CISA, CIS and the FedRAMP Marketplace) on October 29, 2026, with the Oracle Cloud material added on October 31, 2026, and is footnoted; the verification log lists each claim. Statements marked (design guidance) are the program’s recommendations; statements marked (inference) are conclusions the sources support but don’t state; confirm marks a point the providers don’t document and the agency should settle with them. The page is agency-neutral. It targets FedRAMP Moderate civilian agencies, so the configuration authority is CISA, NIST SP 800-53 at Moderate and CIS benchmarks or NIST National Checklist Program content; DISA STIGs appear only for context and are labeled (High only). AWS GovCloud (US) and AWS commercial Regions, Azure and Azure Government, and Oracle’s commercial and US Government realms are all candidate places to run Moderate workloads; authorization is checked per service and per region, as Part 1 does.

Watch or download

The page has a narrated deck in two parts, about 16 minutes each live and 17 narrated, built only from this page and the workbook pages it links, with its labels kept. Each part has a deck for presenting live, a narrated self-running deck with captions, a video and its narration script.

The narrated deck

Part	Covers	Deck, narrated deck and video	Narration script
Part 1: The native resolvers (about 16 minutes)	The answer in brief and Part 1: the Route 53 VPC Resolver, the Azure DNS Private Resolver and the Oracle Cloud VCN resolver; endpoints, rules, query logging and DNS-layer filters; GovCloud, Azure Government and Oracle US Government Cloud as the providers state them; how the three meet on-premises DNS	Deck · Narrated deck (about 17 minutes, captions) · ▶ Watch · MP4	Script · Captions
Part 2: BIND and the federal fit (about 16 minutes)	Parts 2 to 5: when to run your own DNS servers, vNIOS or BIND, BIND’s roles, forwarding, DNSSEC, response policy zones and Protective DNS, logging, patching and configuration from Git, the alignment checklist and the federal mapping	Deck · Narrated deck (about 17 minutes, captions) · ▶ Watch · MP4	Script · Captions

The answer in brief

Use the native resolver as the forwarding bridge in each cloud, and keep the policy in the DDI plane. The Route 53 VPC Resolver and the Azure DNS Private Resolver are managed, zone-redundant forwarding services that both providers recommend over DNS servers on virtual machines.¹² Oracle Cloud gives every VCN a dedicated resolver with listening and forwarding endpoints that does the same job.³ None of the three is an authority for the agency’s own namespaces, and neither AWS nor Azure signs private zones.⁴⁵ Oracle Cloud is the one with no native DNS-layer filter for private DNS, so in a VCN the agency’s policy applies only if queries are forwarded to agency resolvers.⁶ Book 08’s Decision 3 already treats their inbound endpoints as forwarding destinations.

Run your own DNS servers in a cloud only for a stated reason (design guidance): the native resolver can’t do something the agency needs, such as answering an NS delegation, holding the agency’s response policy zones, logging at the agency resolver as M-22-09 expects, or serving as a bridge during AD DNS retirement. Infoblox vNIOS is the choice when the Grid already runs the agency’s DNS, because it joins the same Grid and gets its policy from the Grid Master. BIND is the choice when there is no Grid member to place there, or a tool needs BIND itself. Either way it consumes the policy plane; it doesn’t become a second one.

Additional BIND servers in AWS align with Book 08 when they are forwarders or resolvers under central configuration, logged to the SOC, owned and with a reason. Separately authored zones, or servers edited by hand, are the pattern Book 08 tells agencies to move away from.

BIND in AWS aligns when it is…	BIND in AWS creates a silo when it…
A resolver or forwarder whose configuration comes from the policy plane: cloud names to Route 53 Resolver inbound endpoints, on-premises names back through outbound rules, its addresses in IPAM, its queries logged to the SOC (Decision 3 expects the same forwarding rules on every resolver)	Hosts zones authored separately from the DDI platform: a new source of truth and a new split-brain
A deliberate bridge with an owner and an end date, for example during AD DNS retirement, or for a need the Route 53 Resolver can’t meet	Is edited by hand: no baseline, no change record, drift
Configured from Git and applied by automation, so the repository is the CM-2 baseline and the pull request is the CM-3 change record (Ansible guide)	Skips the shared policy (Protective DNS, DNSSEC validation, query logging), so resolution in AWS is less protected than on premises
Hardened, patched, inventoried and owned like any other DNS server	Duplicates the Route 53 Resolver with no stated reason: more servers to harden and patch (CM-6, SI-2) for nothing

What it covers

Part	Content
1. The native resolvers	The Route 53 VPC Resolver, the Azure DNS Private Resolver and the Oracle Cloud VCN resolver in depth; GovCloud, Azure Government, Oracle US Government Cloud and FedRAMP scope as the providers state it; how each meets on-premises DNS and the policy plane
2. When to run your own	Decision criteria for vNIOS or BIND instead of, or beside, the native resolver
3. BIND on AWS, Azure and Oracle Cloud	Roles, placement and HA; forwarding to and from the native resolver; DNSSEC; response policy zones and CISA Protective DNS; logging; patching; hardening; configuration from Git
4. Alignment checklist	Seven questions for an agency deploying self-managed BIND in AWS, and how to read the answers
5. Federal mapping	SP 800-53 controls, M-22-09, CISA guidance and directives

Part 1 — The native resolvers

AWS: the Route 53 VPC Resolver

The name. AWS renamed the Route 53 Resolver the Route 53 VPC Resolver when it introduced Route 53 Global Resolver.⁷ The VPC User Guide, the API, the GovCloud User Guide and AWS’s FedRAMP page still use the older name, so both appear in runbooks. This page says “VPC Resolver” except where it quotes.

What it is. Every VPC reaches the VPC Resolver at the VPC’s base address plus two (VPC+2), and at 169.254.169.253. It answers the VPC’s own EC2 names and records in private hosted zones associated with the VPC, and recurses for public names.⁸⁹ It only answers recursive queries, and network ACLs and security groups can’t filter traffic to it.¹⁰ Each network interface may send 1,024 packets per second to link-local services, a total that covers DNS, instance metadata, time and Windows licensing; the quota can’t be raised, and traffic over it is rejected.¹¹ That quota matters to any DNS server on EC2 that forwards to VPC+2 (Part 3).

Component	What it does	Limits and points to know
Inbound endpoint	Lets resolvers on the agency network, or in other clouds, forward queries into a VPC; they get the answers that VPC sees, private hosted zones included. A second type, the delegation inbound endpoint, answers NS delegations12	At least two IP addresses in different Availability Zones (six by default); each address handles up to 10,000 UDP queries per second, but as few as 1,500 for inbound queries under connection tracking or behind a Network Load Balancer; Do53, DoH and DoH-FIPS (FIPS 140-2), the last for inbound forward endpoints only1314
Outbound endpoint	Sends queries that match a forwarding rule from the VPC to the agency’s resolvers15	Do53 and DoH only, so no FIPS option outbound; needs Direct Connect, VPN or a NAT gateway; sharing a rule shares its outbound endpoint too16
Forwarding rules (conditional forwarding)	One rule per domain, with target IP addresses; the most specific matching rule wins, and a rule overrides a private hosted zone of the same name1718	1,000 rules per Region; 6 target addresses per rule; a “.” rule forwards almost everything1920
System rules	Carve a subdomain back out of a forwarding rule, so it resolves locally (forward example.com, keep acme.example.com in the VPC); AWS also creates autodefined system rules, including reverse DNS21	The recursive “Internet Resolver” rule handles everything else and can’t be deleted22
Delegation rules	Forward queries whose answers carry NS records for a delegated subdomain to the agency’s resolvers23	In GovCloud, see the availability table below
Rule sharing	AWS Resource Access Manager (RAM) shares rules with accounts, organizational units or the whole organization; the receiving account associates them with its VPCs but can’t change or delete them24	Moving an account between OUs removes its associations unless the rule is also shared with the new OU25
DNS Firewall	Rule groups of allow, alert and block rules (block answers NODATA, NXDOMAIN or a custom override), against custom or AWS managed domain lists; the Advanced tier detects domain generation algorithms (DGA) and DNS tunneling262728	Filters only queries that pass through the VPC Resolver, including those arriving through inbound endpoints; fails closed (SERVFAIL) by default; AWS managed lists can’t be downloaded or browsed293031
Query logging	Logs queries from the VPC, queries through inbound and outbound endpoints, and DNS Firewall actions, to CloudWatch Logs, S3 or Firehose; fields include query name and type, response code, answer, source address and the source instance or endpoint3233	Logs only queries that reach the VPC Resolver, and not answers from its cache; configurations can be shared through RAM3435
Private hosted zones	Zones answered only inside associated VPCs; same-name public and private zones give split-view DNS36	Need enableDnsHostnames and enableDnsSupport; 300 VPCs per zone; cross-account association is by API only (authorize, then associate); an empty match returns NXDOMAIN, with no fallback to public DNS373839
Profiles	Bundle private hosted zones, rules, DNS Firewall rule groups, interface endpoints and query log configurations, and share them with many VPCs and accounts through RAM40	One Profile per VPC; local VPC settings win on an exact-name tie41
DNSSEC	Validation of public signed names, enabled per VPC; signing of public hosted zones only, with the key-signing key in AWS KMS4243	No signing for private hosted zones; the VPC Resolver ignores the DO and CD bits and returns no DNSSEC records and no AD bit, so a resolver behind it can’t validate for itself; AWS warns enabling validation “could result in an outage”4445

Route 53 Global Resolver, generally available since March 2026, is a different thing: an internet-reachable anycast resolver (Do53, DoT and DoH) for authorized clients in branches and on-premises sites, which resolves private hosted zones and filters malicious domains.⁴⁶ It is listed in 30 commercial Regions and not in GovCloud.⁴⁷

GovCloud (US) and commercial Regions, as AWS states it

AWS’s GovCloud page for Route 53 says public and private DNS and health checks are available in GovCloud (US-West) and (US-East), that the Route 53 control plane for GovCloud is in US-West, and that public hosted zone queries “will be answered from within FedRAMP boundary.” It says private hosted zones work as in commercial Regions, except that latency, geolocation, geoproximity and IP-based routing aren’t available.⁴⁸ The page doesn’t mention Resolver endpoints, DNS Firewall, query logging or Profiles; other AWS pages do.

Capability (checked Oct 29, 2026)	Commercial Regions	AWS GovCloud (US)	Source
VPC Resolver, inbound and outbound endpoints, forwarding and system rules	Yes	Yes: the Resolver API has endpoints in us-gov-east-1 and us-gov-west-1	49
Resolver delegation (rules and delegation inbound endpoints)	Yes	Conflicting: the GovCloud User Guide says “Route 53 Resolver delegation is not available”; an AWS announcement of April 8, 2026 says Resolver endpoints now support delegation for private hosted zones in GovCloud. Confirm	5051
DNS Firewall and AWS managed domain lists	Yes	Yes	5253
DNS Firewall Advanced	Yes	The dictionary DGA protection was announced for GovCloud in November 2025; confirm the other Advanced protections	54
Resolver query logging	Yes	Yes, since September 2020 (the GovCloud User Guide doesn’t list it)	55
Route 53 Profiles	Yes	Yes, since June 2024	56
DNSSEC signing of public hosted zones	Yes	Yes; the KMS key must be in GovCloud (US-West)	57
DNSSEC validation in the VPC Resolver	Yes	Not stated on the GovCloud page; confirm	—
Public hosted zone query logging	Yes	Yes; the CloudWatch log group must be in GovCloud (US-West)	58
Route 53 Global Resolver	30 Regions	Not listed	59
VPC IPAM allocation from Infoblox	Yes	No (Book 08, Chapter 07)	60

FedRAMP scope. AWS’s services-in-scope page (updated October 15, 2026) lists one row, Amazon Route 53, as in scope for “FedRAMP Class C (formerly Moderate baseline)” in US East/West and “FedRAMP Class D (formerly High baseline)” in GovCloud. There are no separate rows for the VPC Resolver, DNS Firewall or Profiles; AWS’s general rule is that “generally available features of each of the services are considered in scope” unless specifically excluded.⁶¹ The FedRAMP Marketplace lists AWS US East/West at Moderate and AWS GovCloud at High.⁶² For a Moderate civilian workload, both locations therefore cover the DNS service. The Resolver features are covered by AWS’s general statement, not by a row of their own, which is worth noting in the system security plan (inference).

Azure: the DNS Private Resolver and DNS resolver policy

Book 08 Chapter 07 covers the Private Resolver’s hub-and-spoke design, its subnets, limits, loop rules and an illustrative deployment. In summary, with today’s limits:

Component	What it does	Limits and points to know
Inbound endpoint	Receives queries from on-premises or other clouds and answers from private DNS zones linked to its virtual network	Its own delegated subnet; static address recommended; 5 per resolver; 10,000 queries per second each6364
Outbound endpoint and forwarding ruleset	Sends queries for named domains to target servers; rulesets are linked to virtual networks	1,000 rules per ruleset, 500 virtual network links, 6 targets per rule; one ruleset linked per virtual network; same region only6566
Platform constraints	—	No virtual networks with encryption enabled, no IPv6-enabled subnets; one region per resolver, zone-redundant inside it6768
DNS resolver policy (formerly “DNS security policy”)	Filters and logs every query in a linked virtual network, public and private, with allow, block and alert rules; includes a Microsoft-managed threat intelligence list from MSRC	One policy per virtual network, same region only; logs to Log Analytics (DNSQueryLogs), storage or Event Hubs through diagnostic settings6970
Monitoring	Resolver and ruleset metrics (endpoint counts, queries per second)	Microsoft lists resource logs only for resolver policies, so per-query logs come from a resolver policy (or Azure Firewall’s DNS proxy), not from the resolver itself (inference from the complete list)7172
DNSSEC	Public zones can be signed	The Azure-provided resolver doesn’t validate DNSSEC; no Microsoft page describes signing private zones or whether the Private Resolver validates; confirm73
Zone transfers	—	“Azure DNS doesn’t currently support zone transfers (AXFR/IXFR),” so a BIND server can’t be a secondary of an Azure private zone, or the reverse74

Microsoft renamed DNS security policy to DNS resolver policy; the URL, the price meters and the Architecture Center still use the old name.⁷⁵

Azure Government and FedRAMP scope. Microsoft’s audit-scope page (updated February 2026) has one DNS row, in scope for FedRAMP High in Azure commercial and for FedRAMP High and DoD levels in Azure Government; there is no separate row for the Private Resolver or resolver policy.⁷⁶ The products-by-region page doesn’t show Azure Government regions in its public table, and no Learn page states the Private Resolver’s or resolver policy’s Azure Government availability.⁷⁷ Azure’s retail price list does carry Private Resolver meters in the US Gov billing zones (effective October 1, 2024) and DNS resolver policy meters there (effective June 1, 2026).⁷⁸ A meter is a strong signal that the service is offered, but not an availability statement; confirm in the target region before design (inference). The Trinzic explainer left the same point open.

Oracle Cloud: the VCN resolver

Oracle Cloud Infrastructure (OCI) matters here because the HR platform runs on Oracle Cloud. Book 08 Chapter 07 compares OCI’s private DNS with the other platforms; in summary, with what this page adds:

Component	What it does	Limits and points to know
VCN resolver	Created with each VCN and listening on 169.254.169.254; answers from the private views attached to it, in order, then its default view, then resolver rules, then the internet; it “performs recursion to the internet and DNSSEC validation for DNSSEC-signed zones”79	A match in the sequence ends resolution, even an NXDOMAIN, so a private zone for example.com hides a forwarding rule for onprem.example.com80
Private zones and views	Private zones are grouped into views; a view can be attached to any number of resolvers, sharing private DNS data across VCNs in the same region; same-name private and public zones give split-horizon DNS81	Resolution between VCNs, in the same or another region, uses resolver endpoints over a local or remote peering gateway82
Listening endpoint	Receives queries from on-premises or other VCNs	One IP address in the subnet; security rules for UDP and TCP port 5383
Forwarding endpoint and resolver rules	Sends queries that no view answers to target servers	Two IP addresses; up to 50 rules per resolver; a rule matches a client address block, a domain (up to 10 each) or None, which matches any query; forward is the only action; first match wins, and an unreachable target ends processing8485
Custom resolver (DHCP option)	Sends a subnet’s instances to up to three DNS servers of the agency’s choosing, in the VCN, on premises or on the internet, instead of the VCN resolver86	Instances on a custom resolver reach private views and rules through 169.254.169.254 only if it is in the DHCP nameserver list; otherwise it answers internet names only87
DNS-layer policy	None native: Oracle’s traffic management steering policies apply only to public DNS, and no Oracle page describes a DNS firewall or response policy for the VCN resolver88	—
Logging	Private resolver query and response logs through OCI Logging, with the resolution path of each query89	Oracle documents them for the commercial realms only90
Resilience	May answer from stale cache (RFC 8767) with a 30-second TTL, for up to 24 hours, when it can’t resolve a name it resolved before91	No published query rate for 169.254.169.254

Oracle US Government Cloud and FedRAMP scope. Oracle’s US Government Cloud (realm OC2: US Gov East in Ashburn and US Gov West in Phoenix) has a FedRAMP High authorization and DISA Impact Level 4. Its tenancies “can’t subscribe to the commercial regions.” Its DNS API is “for private DNS only”; public DNS isn’t available in the government realms.⁹² The FedRAMP Marketplace lists Oracle Cloud Infrastructure-Government Cloud as FedRAMP Certified at High (JAB, October 2020); it lists no commercial OCI infrastructure offering. Oracle’s SaaS has its own listings, such as Fusion Cloud at Moderate.⁹³ So (inference):

• A Moderate system on OCI infrastructure inherits from the Government Cloud’s High authorization. Commercial OCI regions have no FedRAMP listing of their own, so a federal system placed there needs its own authorization basis, which the agency must settle before design.
• Whether private resolver logging is available in the government realm isn’t documented; confirm with Oracle.
• An agency that holds only the HR platform’s SaaS service has no VCN: the HR platform is a public name, as Book 08 Chapter 07 explains, and the work is keeping agency resolvers’ path to it consistent.

How each meets on-premises DNS and the policy plane

The three resolvers meet on-premises DNS the same way, and Book 08’s Decision 3 already holds the rules (design guidance):

• Into the cloud. On-premises and other clouds’ resolvers conditionally forward each cloud namespace (and, for Azure, each private endpoint service’s public zone) to the inbound endpoints, using static addresses written once. On OCI the entry point is a listening endpoint. Neither the AWS nor the Azure inbound endpoint accepts an ordinary NS delegation of a private zone; AWS’s delegation inbound endpoint is the exception and is new.⁹⁴⁹⁵
• Out of the cloud. Each cloud forwards the agency’s on-premises namespaces to the agency resolvers through outbound endpoints and rules (AWS), rulesets (Azure) or a forwarding endpoint and resolver rules (OCI). On AWS, the rules are created once in a network account and shared through RAM or a Profile, so spokes associate them and can’t edit them, which is the cloud form of “one policy object” (design guidance).⁹⁶⁹⁷
• Internet-bound queries. CISA requires Protective DNS for all egress DNS resolution, and says agency cloud deployments should use it upstream “either directly or via a SASE/SSE solution,” or use agency internal DNS infrastructure as their upstream.⁹⁸ None of the native resolvers forwards the default path to Protective DNS on its own; that takes a “.” rule (AWS, Azure) or a rule whose condition is None (OCI) pointing at the agency resolvers or a resolver that forwards there.⁹⁹ Whether a given estate’s cloud egress already reaches Protective DNS some other way is for the agency to establish with CISA (confirm).
• Policy. DNS Firewall and DNS resolver policy are each cloud’s own DNS-layer filter; OCI has none for private DNS, so its catch-all rule to the agency resolvers is the only way agency policy reaches a VCN (inference). They’re useful, but they’re a second policy surface beside the agency’s response policy zones. Feed them from the same indicator decisions, or use them as a backstop, so a block on premises is also a block in each cloud (design guidance).
• Logs. Route 53 query logs, Azure resolver policy logs and OCI private resolver logs go to the SIEM beside the agency resolvers’ logs, parsed through ASIM’s DNS schema as Book 12 does for every DNS source.

Part 2 — When to run your own DNS servers in the cloud

Microsoft’s guidance is direct: “Use DNS Private Resolver instead of custom DNS server software like BIND when possible.” It names one case where VM-hosted DNS is needed: on-premises needs an authoritative answer for an NS-delegated subdomain, “because neither DNS Private Resolver nor Azure private DNS zones expose authoritative name servers for name server (NS) delegation.”¹⁰⁰ AWS’s current guidance steers hybrid DNS to Resolver endpoints and rules; its older whitepaper, now marked for historical reference only, described running custom resolvers on EC2 for control, or when the 1,024-packet quota limits scale.¹⁰¹¹⁰²

The criteria (design guidance):

Run your own (vNIOS or BIND) when…	Stay with the native resolver when…
A zone must be authoritative in the cloud and reached by NS delegation, and AWS’s delegation features don’t fit or aren’t available in the Region	The need is forwarding in and out of the cloud; the inbound and outbound endpoints do that, managed and zone-redundant
The agency’s response policy zones, or its encrypted-DNS logging at the agency resolver (M-22-09), must apply in the cloud exactly as on premises, and the native filter can’t carry them, or, as on OCI, there is no native filter	The cloud’s own filter (DNS Firewall, resolver policy) plus forwarding “.” to the agency resolvers gives the same policy; on OCI, a catch-all rule to agency resolvers reachable over FastConnect or VPN does
Workloads need a resolver they can reach over DoT or DoH from inside the cloud, and the native endpoints’ protocols don’t fit (AWS outbound endpoints: Do53 or DoH, no DoH-FIPS; Azure ruleset targets: plain DNS over UDP or TCP)	Clients use Do53 to the VPC or VNet resolver, and encryption starts at the agency resolver
A bridge is needed during a migration, such as AD DNS retirement or a datacenter exit, with an end date	The bridge has no end date, or no one owns its removal
Load would exceed the per-instance quotas of forwarding everything to the native resolver (1,024 packets per second per ENI on AWS; 1,000 queries per second per VM on Azure), and a caching tier helps103104	Volume fits within the endpoint quotas (10,000 queries per second per endpoint address)

vNIOS or BIND. Where the agency’s DNS runs on an Infoblox Grid, vNIOS is the natural choice: it joins the same Grid, takes its zones, response policy zones and DNSSEC from the Grid Master, and is managed in the same console (option A in the Trinzic explainer). The NIOS implementation guide notes that Infoblox’s cloud HA documentation lists only commercial endpoints, so vNIOS failover in GovCloud and Azure Government is a point to confirm. BIND is the choice when there is no Grid, when a vNIOS license or member isn’t justified for a small footprint, or when a tool or application expects BIND itself. BIND has no policy plane of its own: its policy has to come from somewhere, and for Book 08 that is the DDI platform and Git (Part 3).

Part 3 — BIND on AWS, Azure and Oracle Cloud

Version and support

ISC supports each even-numbered BIND 9 branch for four years. As of October 29, 2026, 9.20 (9.20.30, October 2026) is the supported production branch, shown as current stable and Extended Support, with end of life in the second quarter of 2028; 9.18 reached end of life in June 2026, and odd-numbered branches (9.21) are development.¹⁰⁵¹⁰⁶ ISC’s vulnerability policy covers only “the most recent monthly releases” of supported branches.¹⁰⁷ Operating-system packages follow their vendor’s support instead: Ubuntu 24.04’s archive, for example, carries 9.18.39 as of this check, so support for that package comes from Ubuntu, not ISC. An agency must decide which it relies on and record it (design guidance).

Roles, placement and high availability

BIND does three jobs; NIST and ISC both say to keep them apart. NIST SP 800-81r3 says DNS hosts “should be dedicated to that task and hardened,” that recursion should be off on authoritative servers, and that an internet-facing instance “should not be configured to serve in both roles”; combining roles is acceptable on internal-only servers.¹⁰⁸ ISC says “Do not combine authoritative and recursive nameserver functions.”¹⁰⁹

Role	When it fits in a cloud	Book 08 condition (design guidance)
Forwarder (no zones; forwards by domain)	The common case: a cloud-side hop that applies agency policy and logging, then forwards cloud names to the native resolver and everything else to the agency resolvers or Protective DNS	Its forward zones are the Decision 3 rules, generated from the policy plane
Recursive resolver (caches, validates, applies response policy zones)	Where agency policy and logging must apply at the first hop in the cloud	Same response policy zones, validation and logging as on premises
Authoritative (hosts zones)	Only for an NS-delegated zone the native services can’t answer, or a secondary of a zone mastered on the DDI platform	A secondary, never a separately authored primary; the zone’s one writable owner stays on the DDI platform

Placement. Put cloud DNS servers in the shared-services or network hub VPC or VNet that already holds the native resolver’s endpoints, never in workload accounts (design guidance). On AWS, a BIND server can forward only to its own VPC’s +2 address: AWS says forwarding to “any VPC CIDR + 2 address from on-premises or other VPC DNS servers is not supported.”¹¹⁰ Private hosted zones it needs must therefore be associated with its VPC, or reached through an inbound endpoint. On Azure, a custom DNS server must sit in the same virtual network as the VMs whose hostnames it resolves, and forward those to 168.63.129.16.¹¹¹ On OCI, a BIND server in a VCN forwards the VCN’s names (oraclevcn.com) and private views to 169.254.169.254, and the subnets that use it get it through the custom resolver DHCP option, which takes at most three servers.¹¹²¹¹³

High availability. NIST asks for at least two servers on different network segments, dispersed geographically, and a hidden primary for authoritative service.¹¹⁴ Microsoft asks for at least two DNS VMs across availability zones.¹¹⁵ In practice: two or more servers per Region in different Availability Zones, a second Region for a Region-wide failure, and every client and forwarder configured with all of them (design guidance). The 2022 AWS whitepaper describes EC2 auto-recovery and movable secondary addresses for failover.¹¹⁶

Forwarding to and from the native resolver

The native resolver stays the only path to the cloud’s own names; BIND forwards those to it, and forwards everything else up the governed chain (Book 08 Decision 2). AWS says a custom DNS server must “route your private DNS queries to the IP address of the Amazon-provided DNS servers for your VPC.”¹¹⁷ BIND’s forward default is first, which falls back to its own recursion when forwarders fail;¹¹⁸ for private names, that fallback can return the public answer or NXDOMAIN, so the AWS whitepaper says “it is critical to specify the forward only option.”¹¹⁹

Four quotas and behaviors shape the design:

• Per-instance limits. On AWS, the 1,024-packet-per-second link-local quota covers all DNS queries a BIND server sends to VPC+2.¹²⁰ On Azure, a VM may send 1,000 queries per second to 168.63.129.16 with 200 pending; queries over the limit “are dropped,” per VM.¹²¹ BIND’s cache absorbs repeats; size the fleet so no one server forwards near the limit (design guidance).
• Timeouts. Microsoft says a forwarder’s timeout should be more than four seconds, or Private DNS records may resolve to public addresses.¹²²
• Visibility. The VPC Resolver logs and filters only queries it receives, so it sees BIND as the source, not the client, and never sees BIND’s cache hits (inference).¹²³¹²⁴ BIND’s own logs carry the client.
• Loops. Don’t forward a domain to an inbound endpoint from inside the VPC or VNet that holds that endpoint, and don’t associate a VPC with both a rule and that rule’s inbound endpoint.¹²⁵¹²⁶

The configuration below is the forwarder role on AWS. It is illustrative: names and addresses are examples, it passed named-checkconf from BIND 9.18.39 (the Ubuntu 24.04 package) but hasn’t run against a VPC or been checked on 9.20, and in practice it is rendered from the policy plane and Git, not typed.

// Illustrative only: forwarder in a shared-services VPC (10.20.0.0/16).
// Generated from the DDI policy plane and Git; never edited on the host.
acl "clients" { 10.0.0.0/8; };

options {
    directory "/var/cache/bind";
    version none;                       // don't disclose the version
    recursion yes;
    allow-query { clients; };
    allow-recursion { clients; };
    allow-transfer { none; };
    dnssec-validation auto;
    // Private namespaces have no DNSSEC chain, and the VPC Resolver strips DNSSEC data
    validate-except { "aws.corp.agency.gov"; "corp.agency.gov"; "internal"; };
    // Internet-bound: the governed upstream (agency resolvers, then Protective DNS)
    forward only;
    forwarders { 10.1.0.10; 10.1.0.11; };
};

// Cloud names to the VPC Resolver of this VPC (VPC+2); private hosted zones are associated here
zone "aws.corp.agency.gov" { type forward; forward only; forwarders { 10.20.0.2; }; };
zone "compute.internal"    { type forward; forward only; forwarders { 10.20.0.2; }; };

// On-premises names to the agency resolvers
zone "corp.agency.gov"     { type forward; forward only; forwarders { 10.1.0.10; 10.1.0.11; }; };

On OCI, the same file forwards oraclevcn.com, the agency’s OCI private zones and Oracle private endpoint names, such as <prefix>.adb.<region>.oraclecloud.com for an Autonomous Database, to 169.254.169.254, or to a listening endpoint from another VCN.¹²⁷¹²⁸ On Azure, the same file forwards the agency’s Azure namespaces and each private endpoint service’s public zone (for example blob.core.usgovcloudapi.net in Azure Government) to 168.63.129.16, or to the Private Resolver’s inbound endpoint when the BIND server is in a different virtual network.¹²⁹¹³⁰

DNSSEC signing and validation

Validation. BIND validates by default: dnssec-validation defaults to auto, with the root trust anchor built in.¹³¹¹³² SP 800-81r3 asks for validation, the root key as trust anchor and automated trust anchor rollover.¹³³ Three cloud specifics:

• Behind the VPC Resolver, BIND can’t validate. The VPC Resolver “ignores the DO (DNSSEC OK) EDNS header bit,” returns no DNSSEC records and sets no AD bit, so “performing your own DNSSEC validation is not currently supported by the VPC Resolver.”¹³⁴ Validation of public names happens either in the VPC Resolver (enabled per VPC) or in BIND when it forwards to an upstream that returns DNSSEC data.
• The OCI resolver validates. Oracle says the VCN resolver performs DNSSEC validation for signed zones.¹³⁵ Whether it passes DNSSEC records and the AD bit back to a resolver behind it, so that BIND could validate for itself, isn’t documented; confirm.
• Private namespaces need exceptions. A private zone under a signed public parent, such as a private hosted zone for a name under the agency’s signed .gov domain, has no secure delegation, so a validator treats its answers as bogus. BIND’s validate-except lists the names “at and beneath which DNSSEC validation should not be performed.”¹³⁶ Hold that list in the policy plane with the forwarding rules, because it is part of the same split-horizon decision (Book 08 Chapter 06) (design guidance).

Whether CISA’s Protective DNS returns DNSSEC records to forwarders, so that BIND can validate behind it, isn’t stated on CISA’s public pages; confirm with CISA.

Signing. SC-20 asks for signed authoritative data, and M-08-23 required DNSSEC on federal systems.¹³⁷¹³⁸ Neither AWS nor Azure signs private zones, and no Oracle page describes signing private zones.^139140141 SP 800-81r3 §3.8.6 says signing internal zones “is not recommended” except where it is required, and notes that government agencies may require it.¹⁴² Where an agency signs, BIND’s dnssec-policy default is ISC’s “recommended, fully automated way to sign and maintain DNS zones” (inline signing, automatic ZSK rollover; KSK rollover needs the parent’s DS updated).¹⁴³ The program’s position is that the zone’s one writable owner signs it, and the program’s design guidance, set out in Trinzic Alone, or Trinzic Plus Cloud DDI?, keeps DNSSEC keys on the Grid Master or an HSM (Book 08 reports NIST’s recommendation of an HSM for important keys), so a cloud BIND secondary serves signed data and holds no keys (design guidance).

Response policy zones as Protective DNS

BIND’s mechanism. Response policy zones (RPZ) are “ordinary DNS zones containing RRsets that can be queried normally if allowed.” A response-policy statement takes up to 64 of them. Five triggers (client IP, query name, response IP, name server name, name server IP) map to actions: NXDOMAIN, NODATA, PASSTHRU, DROP, TCP-only or local data. Because a policy zone is an ordinary zone, it is kept in sync with zone transfers and NOTIFY.¹⁴⁴ SP 800-81r3 describes protective DNS as “generally implemented by using DNS firewalls or RPZs,” with name servers acting as secondaries for RPZ feeds.¹⁴⁵

How CISA’s Protective DNS fits. For civilian agencies, CISA’s Protective DNS Resolver is mandatory, sits “upstream from agency networks,” and “does not interfere with internal DNS architecture”; traffic from “mobile, roaming and cloud assets” can flow to it directly.¹⁴⁶ CISA’s implementation guidance says agency DNS infrastructure “should use only Protective DNS as its upstream provider” except when it’s unavailable, that the service supports DoH and DoT over IPv4 and IPv6 and plain DNS “for authorized FCEB DNS infrastructure,” and that IaaS deployments should use “Protective DNS or agency internal DNS infrastructure as their upstream DNS provider.”¹⁴⁷ NIST notes that its own “protective DNS” is the general class, “not the CISA program of the same name.”¹⁴⁸ So (design guidance):

• Agency RPZs on a cloud BIND server are the agency’s own protective DNS, in front of CISA’s: the same RPZs, from the same feed, as the agency’s on-premises resolvers, transferred from the DDI platform.
• Internet-bound queries leave the BIND server only toward Protective DNS, directly or through the agency resolvers.
• RPZ hits and blocks are logged and sent to the SOC, with the same alerting as on premises.

CISA’s public pages don’t mention RPZ, so the layering is NIST’s and the program’s, not CISA’s.

Encrypted upstream. BIND 9.20 can serve DoT and DoH, and its forwarders statement takes a tls configuration, so it can forward to Protective DNS over DoT.¹⁴⁹ CISA’s guidance (April 2024) says BIND “does not currently support communicating with upstream DNS servers using encrypted DNS protocols” and recommends a co-located proxy. That was true of 9.18 and is no longer true of 9.20.¹⁵⁰ The same appendix suggests setting recursion no to keep BIND from using root hints. In BIND that turns off recursive service to clients; the usual way is forward only; with forwarders, as above.¹⁵¹ Follow the current ARM where the two differ (inference).

Query and response logging into the SOC

SP 800-81r3 asks government agencies for “robust DNS traffic logging,” names dnstap as an efficient method, says blocked or malicious queries “should always be logged,” and asks for integration with the SIEM.¹⁵² M-22-09 expects agencies to keep visibility by logging at their designated resolvers, and M-26-14 sets the retention: searchable for six months and retrievable for a year.¹⁵³¹⁵⁴

BIND offers two mechanisms.¹⁵⁵

• The logging statement writes the queries, responses, query-errors, security, dnssec, rpz, rpz-passthru and xfer-out categories to files or syslog. The querylog option, or rndc querylog, turns query logging on.
• dnstap records client, resolver, auth, forwarder and update messages, queries and responses, to a file or a Unix socket. It needs a BIND build configured with --enable-dnstap, and dnstap-output can’t be changed by a reload.

ISC warns that query logging adds heavy overhead and needs planning.¹⁵⁶ Send the logs to the SIEM through the Azure Monitor Agent’s syslog path or the agency’s collector, and write detections against ASIM’s _Im_Dns, which already parses BIND (Book 12, Chapter 05). Because the native resolver sees BIND rather than the client (Part 3, forwarding), BIND’s log is the record of who asked; without it, cloud DNS is a blind spot (inference).

Patching and configuration settings (SI-2, CM-6)

SP 800-81r3 has no section on patching DNS software; it asks for hardened, dedicated hosts and a secured platform and stack.¹⁵⁷ The patching sources are ISC’s, and the clock is CISA’s:

• Subscribe to bind-announce, which ISC’s best-practice pages tell operators to do, and check ISC’s BIND 9 Software Vulnerability Matrix for each version in use.¹⁵⁸¹⁵⁹
• Stay on a supported branch. 9.18 is end of life at ISC (above). ISC gives support customers advance notice of serious vulnerabilities, three to five business days before disclosure.¹⁶⁰
• Patch to CISA’s clock. BOD 26-04 (June 10, 2026) replaced BOD 22-01 and BOD 19-02 with risk-based remediation timelines. Its shortest window, three days, applies to the highest-risk vulnerabilities in publicly exposed assets (SI-2).¹⁶¹ BOD 23-01 requires asset discovery every 7 days and vulnerability enumeration every 14, including cloud deployments, so cloud BIND servers are in its scope.¹⁶²

Settings (CM-6, CM-7). Every setting below is in the BIND ARM:¹⁶³¹⁶⁴

• Disclose and accept less. version none stops BIND answering version queries. allow-query defaults to all hosts, so set it, and set allow-recursion to the agency’s clients.
• Protect transfers. allow-transfer restricts zone transfers, and TSIG keys authenticate them. SP 800-81r3 adds TLS for their confidentiality.¹⁶⁵
• Run unprivileged. Run named as an unprivileged user, chrooted where practical (ARM chapter 7).
• Keep the host to DNS. No other services on it, as NIST and ISC both say.

Hardening baselines: what exists

• NIST SP 800-81r3 (March 2026) is the deployment guide, and the source for this page’s hardening points.¹⁶⁶
• ISC’s documentation: the ARM’s Security Configurations chapter, and the BIND Best Practices pages for authoritative and recursive servers. ISC marks the recursive page as stale.^167168169
• CIS no longer lists a BIND benchmark of its own. On October 29, 2026 it listed two, ISC BIND DNS Server 9.11 v1.0.0 and ISC BIND DNS Server 9.9 v3.0.1; by November 9, 2026 its BIND benchmark page returned “not found”, and its benchmark list showed only a CIS-formatted BIND 9.x STIG (1.0.0) among the DISA STIGs. CIS says benchmarks it no longer supports aren’t listed, and points to CIS WorkBench for them.¹⁷⁰ There is no CIS benchmark for the supported branch (9.20) or for 9.18. The retired 9.11 benchmark can still be read for its intent, but its settings must be checked against the 9.20 ARM before use. The National Checklist Program’s dates for the two benchmarks (about 2020 and 2016) couldn’t be loaded from NIST and aren’t relied on here.
• DISA publishes a BIND 9.x STIG (High only). Its current release couldn’t be read from DISA’s site on October 29, 2026. It isn’t this page’s configuration authority.

The baseline an agency states is therefore its own profile: the 9.20 ARM settings, SP 800-81r3, and the CIS 9.11 benchmark’s intent, recorded as the CM-6 configuration settings and approved by the CISO (design guidance).

Configuration from Git, applied by Ansible

The Ansible guide treats Linux hosts outside Intune and Arc as tier 2, managed by a playbook from a reviewed repository. A BIND server is exactly that case (design guidance):

• Rendered, not typed. named.conf and its forward zones are templates rendered from data exported by the DDI policy plane: the forwarding rules, the validate-except list, the RPZ primaries and the TSIG key references. Book 08’s single source therefore drives BIND too.
• Checked before it lands. Every change reaches the main branch only by pull request with a required reviewer. CI runs named-checkconf and named-checkzone, and the playbook validates again before it reloads.
• Git is the evidence. The commit and tag are the CM-2 baseline, the pull request is the CM-3 change record, and check-mode runs report drift (Ansible guide, evidence).
• One owning tool. Ansible owns named.conf on these hosts, and nothing else writes it (one owning tool per setting). A hand edit is drift, to be reverted.
• Secrets stay out of Git. TSIG keys and DoT certificates come from the agency’s secrets store at run time.

Part 4 — Alignment checklist for self-managed BIND in AWS

These are the questions that decide whether an agency deploying additional BIND servers in AWS fits Book 08’s single policy plane or creates a silo. The usual form is BIND on virtual machines, which in AWS means EC2 instances in a VPC: everything in Part 3 applies to them directly, including the per-interface quota to VPC+2 and the VPC Resolver’s view of BIND as the client. If the VMs are instead guests in a VMware environment that runs on AWS, they sit on NSX segments, and their resolution path follows the NSX row of Book 08 Chapter 07 until it reaches a VPC; establish which case applies before reading the answers. Ask the questions of each server, or each class of server, and record the answers in the CMDB entry; the same questions apply to BIND in Azure or Oracle Cloud, with that cloud’s resolver in place of the VPC Resolver (design guidance).

#	Question	Aligns when the answer is…	Silo signal
1	Role. Is it authoritative for any zones, a recursive resolver, or a forwarder?	A forwarder or resolver, or an authoritative secondary of a zone mastered on the DDI platform; roles separated as SP 800-81r3 §2.3.1 asks	A primary for zones, or authoritative and recursive combined on an internet-facing server
2	Source of truth. Which zones and records does it hold, and who creates them?	None, or zones transferred from the DDI platform, its one writable owner	Records created on the BIND server, or zones that also exist, separately edited, in Route 53 or on premises
3	Why BIND. Why not the Route 53 VPC Resolver, or Infoblox vNIOS? Permanent, or a bridge?	A stated need from Part 2 that the native resolver can’t meet; for a bridge, an end date and the change that retires it	“We’ve always run BIND,” or no end date for a bridge
4	Configuration. Is it in Git, applied by Ansible or another tool, with changes reviewed?	Rendered from policy-plane data, merged by reviewed pull request, applied by automation, checked for drift	Edited on the host; no repository; no change records
5	Placement. EC2 instances or VMware guests? GovCloud or commercial Regions? Which VPCs? Shared Resolver rules?	In the network or shared-services VPC of each Region it serves, at least two per Region across Availability Zones; the VPC Resolver rules that point at it created once and shared through RAM or a Profile; both GovCloud and commercial placements recorded, each checked against the Part 1 table	Servers in workload accounts; rules created per account; one Region’s design copied to the other without checking what differs
6	Shared policy. Are its queries logged to the SOC, with the same Protective DNS and DNSSEC validation as on premises?	Query and response logs (or dnstap) in the SIEM with M-26-14 retention; the agency’s RPZs from the same feed; internet-bound queries only to Protective DNS; validation on, with validate-except from the policy plane	No logs, or logs only in CloudWatch from the VPC Resolver (which shows BIND, not the client); no RPZs; its own upstream
7	Hardening, inventory, owner. Hardened to SP 800-81r3, in the CMDB, with a named owner?	A supported BIND branch on ISC’s or the OS vendor’s security feed; the agency’s stated baseline (CM-6); a CMDB record (CM-8) and IPAM entry for each server; a named owner and backup	An end-of-life branch, an unstated baseline, missing from the CMDB, or “the cloud team” as owner

How to read the answers. Yes to every row means the servers are one more surface the policy plane governs, which is what Book 08 asks for. A silo signal on rows 2 or 4 is the serious one: the servers have become an independently authored source, and the fix is to move their zones to the DDI platform and their configuration into Git before adding more. A silo signal on row 3 alone means the servers may not be needed; compare them with the VPC Resolver’s endpoints and rules, and retire them if nothing is lost.

Part 5 — Federal mapping

The controls and citations below are the ones Book 08 has already verified (Chapter 03, Chapter 11), applied to DNS servers that an agency runs in a cloud. Control titles are from SP 800-53 Rev. 5.¹⁷¹ The mapping is illustrative; validate it against the system’s own authorization boundary.

Requirement	What it asks of cloud DNS	Evidence for a self-managed BIND or vNIOS server
CM-2 Baseline Configuration	A current, documented baseline	The Git commit and tag of the rendered configuration
CM-3 Configuration Change Control	Reviewed, approved, recorded changes	Pull requests with required review; the policy-plane change that produced them
CM-6 Configuration Settings	Settings set to a stated baseline	The agency profile (9.20 ARM, SP 800-81r3, CIS benchmark intent), and drift reports in check mode
CM-7 Least Functionality	Only the functions needed	Dedicated DNS host; one role per server; version none; recursion and transfers limited
CM-8 System Component Inventory	Every component inventoried	CMDB record per server and IPAM entry per address, with owner; BOD 23-01 discovery covers cloud assets172
SC-20 Secure Name/Address Resolution Service (Authoritative Source)	Signed authoritative data	Signing by the zone’s one owner; cloud secondaries serve signed data and hold no keys
SC-21 Secure Name/Address Resolution Service (Recursive or Caching Resolver)	Validation of answers	dnssec-validation auto; the validate-except list from the policy plane; VPC Resolver validation enabled where BIND forwards to it
SC-22 Architecture and Provisioning for Name/Address Resolution Service	Fault-tolerant, role-separated service	At least two servers per Region across zones; roles separated (SP 800-81r3 §2.3)
SI-2 Flaw Remediation	Flaws fixed on time	Supported BIND branch; bind-announce and the vulnerability matrix; remediation inside BOD 26-04’s timelines173
SI-4 System Monitoring	DNS as a detection source	RPZ hits and blocks, DNS Firewall or resolver policy actions, OCI resolution paths, all in the SIEM
AU-2 Event Logging / AU-12 Audit Record Generation	DNS events selected and generated	Query, response, security and RPZ categories or dnstap; Route 53 query logs, Azure resolver policy logs and OCI private resolver logs beside them; M-26-14 retention174
OMB M-22-09	Encrypted DNS wherever technically supported; logging at agency-designated resolvers	DoT or DoH to clients where they support it; DoT upstream from BIND 9.20; logs at the BIND server175
CISA Protective DNS and Encrypted DNS Implementation Guidance	Protective DNS for all egress resolution; cloud deployments upstream to Protective DNS or agency DNS; unauthorized DNS blocked	Internet-bound forwarding only to Protective DNS or the agency resolvers; egress port 53, DoT and DoH to anything else blocked176177
CISA ED 19-01 (sunset)	Audit DNS records, change passwords and add MFA on DNS accounts, monitor Certificate Transparency	Sunset on January 8, 2026; its four actions remain sound practice for anyone who can change records, in the cloud consoles as on the DDI platform178

Status and review

In review. Every claim was checked against AWS, Microsoft Learn, ISC, NIST, CISA, CIS and FedRAMP Marketplace sources on October 29, 2026, and the Oracle Cloud material against Oracle’s documentation and the Marketplace on October 31, 2026, and is logged in the verification log. The illustrative named.conf passed named-checkconf (BIND 9.18.39) but hasn’t run in a VPC. Open points to confirm:

• AWS. Resolver delegation in GovCloud, where AWS’s own pages conflict; DNSSEC validation in GovCloud, which no AWS page states.
• Azure. The DNS Private Resolver’s and DNS resolver policy’s availability in each Azure Government region, where the price list is the only evidence; whether the Private Resolver validates DNSSEC.
• Oracle. Private resolver logging in the government realm; whether the VCN resolver passes DNSSEC data to a resolver behind it.
• CISA. Whether Protective DNS returns DNSSEC data to agency forwarders.
• Hardening sources. The current DISA BIND STIG release (High only), and the National Checklist Program dates for the CIS BIND benchmarks.

To move this page to Proved, build the forwarder pattern in a test account in each target Region and realm, run the Book 08 Chapter 10 validation matrix from every origin, and record the evidence here.

Comments and corrections are welcome as issues on GitHub.

Related research: Trinzic Alone, or Trinzic Plus Cloud DDI?, Infoblox DDI for Federal Agencies, the Infoblox NIOS implementation guide and What a Federal DDI Platform Must Do. The architecture all of them build on is Book 08 — DNS, DHCP & IPAM.

Footnotes

1. Microsoft Learn, Azure Architecture Center, “Design a hybrid Domain Name System (DNS) solution by using Azure” (custom DNS software like BIND as an alternative with “management overhead”; “Use DNS Private Resolver instead of custom DNS server software like BIND when possible”; VM-hosted authoritative DNS for NS-delegated subdomains; at least two DNS VMs across availability zones; logging through Azure Firewall or DNS security policy), https://learn.microsoft.com/azure/architecture/hybrid/hybrid-dns-infra (accessed Oct 29, 2026).

2. AWS, Amazon Route 53 Developer Guide, “What is Route 53 VPC Resolver?” (renamed from Route 53 Resolver when Route 53 Global Resolver was introduced; VPC+2; what it answers), https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/resolver.html (accessed Oct 29, 2026).

3. Oracle, Oracle Cloud Infrastructure Documentation, “Private DNS” (dedicated VCN resolver on 169.254.169.254; “performs recursion to the internet and DNSSEC validation for DNSSEC-signed zones”; views shared by any number of resolvers across VCNs in the same region; split horizon; listening endpoint one address, forwarding endpoint two; security rules; resolution between VCNs over LPG or RPG; “Traffic Management is only available for public DNS”), https://docs.oracle.com/en-us/iaas/Content/DNS/Tasks/privatedns.htm (accessed Oct 31, 2026).

4. AWS, Amazon Route 53 Developer Guide, “Configuring DNSSEC signing in Amazon Route 53” (“DNSSEC signing is supported only for public hosted zones”; KSK from a customer managed key in AWS KMS), https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/dns-configuring-dnssec.html (accessed Oct 29, 2026).

5. Microsoft Learn, “DNSSEC overview” (Azure DNS) (“DNSSEC response validation is not performed by the default Azure-provided resolver”; signing of Azure Public DNS zones), https://learn.microsoft.com/azure/dns/dnssec (accessed Oct 29, 2026).

6. Oracle, Oracle Cloud Infrastructure Documentation, “Traffic Management Steering Policies” (available only for public DNS), https://docs.oracle.com/iaas/Content/TrafficManagement/Concepts/overview.htm (accessed Oct 31, 2026). No Oracle page describes a DNS firewall or response policy for the VCN resolver (Book 08, Chapter 07 verification).

7. AWS, Amazon Route 53 Developer Guide, “What is Route 53 VPC Resolver?” (renamed from Route 53 Resolver when Route 53 Global Resolver was introduced; VPC+2; what it answers), https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/resolver.html (accessed Oct 29, 2026).

8. AWS, Amazon Route 53 Developer Guide, “What is Route 53 VPC Resolver?” (renamed from Route 53 Resolver when Route 53 Global Resolver was introduced; VPC+2; what it answers), https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/resolver.html (accessed Oct 29, 2026).

9. AWS, Amazon VPC User Guide, “Understanding Amazon DNS” (169.254.169.253 and VPC+2; recursive queries only; not filtered by network ACLs or security groups; “There is a 1024 packet per second (PPS) limit to services that use link-local addresses,” covering DNS, IMDS, NTP and Windows licensing; “This quota cannot be increased”), https://docs.aws.amazon.com/vpc/latest/userguide/AmazonDNS-concepts.html (accessed Oct 29, 2026).

10. AWS, Amazon VPC User Guide, “Understanding Amazon DNS” (169.254.169.253 and VPC+2; recursive queries only; not filtered by network ACLs or security groups; “There is a 1024 packet per second (PPS) limit to services that use link-local addresses,” covering DNS, IMDS, NTP and Windows licensing; “This quota cannot be increased”), https://docs.aws.amazon.com/vpc/latest/userguide/AmazonDNS-concepts.html (accessed Oct 29, 2026).

11. AWS, Amazon VPC User Guide, “Understanding Amazon DNS” (169.254.169.253 and VPC+2; recursive queries only; not filtered by network ACLs or security groups; “There is a 1024 packet per second (PPS) limit to services that use link-local addresses,” covering DNS, IMDS, NTP and Windows licensing; “This quota cannot be increased”), https://docs.aws.amazon.com/vpc/latest/userguide/AmazonDNS-concepts.html (accessed Oct 29, 2026).

12. AWS, Amazon Route 53 Developer Guide, “Resolving DNS queries between VPCs and your network” (inbound and delegation inbound endpoints; outbound endpoints; most specific rule wins; “Forwarding private DNS queries to any VPC CIDR + 2 address from on-premises or other VPC DNS servers is not supported, and can cause unstable results”), https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/resolver-overview-DSN-queries-to-vpc.html (accessed Oct 29, 2026).

13. AWS, Amazon Route 53 Developer Guide, “Considerations when creating inbound and outbound endpoints” (two or more IP addresses in different Availability Zones; Do53, DoH and DoH-FIPS, the last “Supported for inbound endpoints only”; outbound Do53 and DoH; sharing a rule indirectly shares its outbound endpoint), https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/resolver-choose-vpc.html (accessed Oct 29, 2026).

14. AWS, Amazon Route 53 Developer Guide, “Quotas” (IP addresses per endpoint 6; rules per Region 1,000; IP addresses per rule 6; “Each IP address in an endpoint can process up to 10,000 UDP DNS queries per second”; as low as 1,500 for inbound with connection tracking or behind a Network Load Balancer; 300 VPCs per private hosted zone), https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/DNSLimitations.html (accessed Oct 29, 2026).

15. AWS, Amazon Route 53 Developer Guide, “Resolving DNS queries between VPCs and your network” (inbound and delegation inbound endpoints; outbound endpoints; most specific rule wins; “Forwarding private DNS queries to any VPC CIDR + 2 address from on-premises or other VPC DNS servers is not supported, and can cause unstable results”), https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/resolver-overview-DSN-queries-to-vpc.html (accessed Oct 29, 2026).

16. AWS, Amazon Route 53 Developer Guide, “Considerations when creating inbound and outbound endpoints” (two or more IP addresses in different Availability Zones; Do53, DoH and DoH-FIPS, the last “Supported for inbound endpoints only”; outbound Do53 and DoH; sharing a rule indirectly shares its outbound endpoint), https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/resolver-choose-vpc.html (accessed Oct 29, 2026).

17. AWS, Amazon Route 53 Developer Guide, “Using rules to control which queries are forwarded to your network” (autodefined, forwarding, system and delegation rules; most specific match; “.” rule), https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/resolver-overview-forward-vpc-to-network-using-rules.html (accessed Oct 29, 2026).

18. AWS, Amazon Route 53 Developer Guide, “Working with private hosted zones,” https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/hosted-zones-private.html, and “Considerations when working with a private hosted zone” (enableDnsHostnames and enableDnsSupport; split-view DNS; most specific match and NXDOMAIN; a Resolver rule for the same name takes precedence), https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/hosted-zone-private-considerations.html (both accessed Oct 29, 2026).

19. AWS, Amazon Route 53 Developer Guide, “Quotas” (IP addresses per endpoint 6; rules per Region 1,000; IP addresses per rule 6; “Each IP address in an endpoint can process up to 10,000 UDP DNS queries per second”; as low as 1,500 for inbound with connection tracking or behind a Network Load Balancer; 300 VPCs per private hosted zone), https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/DNSLimitations.html (accessed Oct 29, 2026).

20. AWS, Amazon Route 53 Developer Guide, “Using rules to control which queries are forwarded to your network” (autodefined, forwarding, system and delegation rules; most specific match; “.” rule), https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/resolver-overview-forward-vpc-to-network-using-rules.html (accessed Oct 29, 2026).

21. AWS, Amazon Route 53 Developer Guide, “Using rules to control which queries are forwarded to your network” (autodefined, forwarding, system and delegation rules; most specific match; “.” rule), https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/resolver-overview-forward-vpc-to-network-using-rules.html (accessed Oct 29, 2026).

22. AWS, Amazon Route 53 Developer Guide, “Managing forwarding rules,” including “Sharing Resolver rules with other AWS accounts and using shared rules” (AWS RAM; accounts, OUs or organization; “The account that a rule is shared with can’t change or delete the rule”; OU moves; the Internet Resolver rule), https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/resolver-rules-managing.html (accessed Oct 29, 2026).

23. AWS, Amazon Route 53 Developer Guide, “Using rules to control which queries are forwarded to your network” (autodefined, forwarding, system and delegation rules; most specific match; “.” rule), https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/resolver-overview-forward-vpc-to-network-using-rules.html (accessed Oct 29, 2026).

24. AWS, Amazon Route 53 Developer Guide, “Managing forwarding rules,” including “Sharing Resolver rules with other AWS accounts and using shared rules” (AWS RAM; accounts, OUs or organization; “The account that a rule is shared with can’t change or delete the rule”; OU moves; the Internet Resolver rule), https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/resolver-rules-managing.html (accessed Oct 29, 2026).

25. AWS, Amazon Route 53 Developer Guide, “Managing forwarding rules,” including “Sharing Resolver rules with other AWS accounts and using shared rules” (AWS RAM; accounts, OUs or organization; “The account that a rule is shared with can’t change or delete the rule”; OU moves; the Internet Resolver rule), https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/resolver-rules-managing.html (accessed Oct 29, 2026).

26. AWS, Amazon Route 53 Developer Guide, “Using DNS Firewall to filter outbound DNS traffic,” https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/resolver-dns-firewall.html (accessed Oct 29, 2026).

27. AWS, Amazon Route 53 Developer Guide, “Rule actions in DNS Firewall” (Allow, Alert, Block with NODATA, NXDOMAIN or OVERRIDE), https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/resolver-dns-firewall-rule-actions.html (accessed Oct 29, 2026).

28. AWS, Amazon Route 53 Developer Guide, “DNS Firewall Advanced” (DGA, DNS tunneling and dictionary DGA; block or alert), https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/firewall-advanced.html; and AWS What’s New, November 17, 2025, dictionary DGA protection “available in all AWS Regions … including the AWS GovCloud (US) Regions,” https://aws.amazon.com/about-aws/whats-new/2025/11/amazon-route-53-dns-firewall-protection-dictionary-dga-attacks/ (both accessed Oct 29, 2026).

29. AWS, Amazon Route 53 Developer Guide, “How Resolver DNS Firewall works” (filters “DNS queries originating within that VPC and passing through VPC DNS” and queries arriving through Resolver endpoints into that VPC), https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/resolver-dns-firewall-overview.html (accessed Oct 29, 2026).

30. AWS, Amazon Route 53 Developer Guide, “DNS Firewall VPC configuration” (“By default, the failure mode is closed,” with a SERVFAIL response), https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/resolver-dns-firewall-vpc-configuration.html (accessed Oct 29, 2026). The overview’s high-level steps describe blocking on failure as optional; this page relies on the configuration page.

31. AWS, Amazon Route 53 Developer Guide, “AWS Managed Domain Lists” (“AWS Managed Domain Lists cannot be downloaded or browsed”; Region table lists AWS GovCloud (US) as Yes), https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/resolver-dns-firewall-managed-domain-lists.html (accessed Oct 29, 2026).

32. AWS, Amazon Route 53 Developer Guide, “Resolver query logging” (queries from VPCs, through inbound and outbound endpoints, and DNS Firewall actions; CloudWatch Logs, S3 or Firehose; “logs only unique queries, not queries that VPC Resolver is able to respond to from the cache”), https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/resolver-query-logs.html (accessed Oct 29, 2026).

33. AWS, Amazon Route 53 Developer Guide, “Values that appear in VPC Resolver query logs,” https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/resolver-query-logs-format.html (accessed Oct 29, 2026).

34. AWS, Amazon Route 53 Developer Guide, “Resolver query logging” (queries from VPCs, through inbound and outbound endpoints, and DNS Firewall actions; CloudWatch Logs, S3 or Firehose; “logs only unique queries, not queries that VPC Resolver is able to respond to from the cache”), https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/resolver-query-logs.html (accessed Oct 29, 2026).

35. AWS, Amazon Route 53 Developer Guide, “Sharing Resolver query logging configurations with other AWS accounts,” https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/query-logging-configurations-managing-sharing.html (accessed Oct 29, 2026).

36. AWS, Amazon Route 53 Developer Guide, “Working with private hosted zones,” https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/hosted-zones-private.html, and “Considerations when working with a private hosted zone” (enableDnsHostnames and enableDnsSupport; split-view DNS; most specific match and NXDOMAIN; a Resolver rule for the same name takes precedence), https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/hosted-zone-private-considerations.html (both accessed Oct 29, 2026).

37. AWS, Amazon Route 53 Developer Guide, “Working with private hosted zones,” https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/hosted-zones-private.html, and “Considerations when working with a private hosted zone” (enableDnsHostnames and enableDnsSupport; split-view DNS; most specific match and NXDOMAIN; a Resolver rule for the same name takes precedence), https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/hosted-zone-private-considerations.html (both accessed Oct 29, 2026).

38. AWS, Amazon Route 53 Developer Guide, “Associating an Amazon VPC and a private hosted zone that you created with different AWS accounts” (CreateVPCAssociationAuthorization, then AssociateVPCWithHostedZone; not in the console), https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/hosted-zone-private-associate-vpcs-different-accounts.html (accessed Oct 29, 2026).

39. AWS, Amazon Route 53 Developer Guide, “Quotas” (IP addresses per endpoint 6; rules per Region 1,000; IP addresses per rule 6; “Each IP address in an endpoint can process up to 10,000 UDP DNS queries per second”; as low as 1,500 for inbound with connection tracking or behind a Network Load Balancer; 300 VPCs per private hosted zone), https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/DNSLimitations.html (accessed Oct 29, 2026).

40. AWS, Amazon Route 53 Developer Guide, “What are Amazon Route 53 Profiles?” (resources and settings; RAM sharing; one Profile per VPC; precedence), https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/profiles.html (accessed Oct 29, 2026).

41. AWS, Amazon Route 53 Developer Guide, “What are Amazon Route 53 Profiles?” (resources and settings; RAM sharing; one Profile per VPC; precedence), https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/profiles.html (accessed Oct 29, 2026).

42. AWS, Amazon Route 53 Developer Guide, “Enabling DNSSEC validation in Amazon Route 53” (“DNSSEC validation is applied by VPC Resolver to public signed names when it is performing recursive DNS resolution”; a resolver it forwards to “must also apply the DNSSEC validation”; it “ignores the DO (DNSSEC OK) EDNS header bit and the CD (Checking Disabled) bit … doesn’t return DNSSEC records nor set the AD bit”; enabling it “could result in an outage”), https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/resolver-dnssec-validation.html (accessed Oct 29, 2026).

43. AWS, Amazon Route 53 Developer Guide, “Configuring DNSSEC signing in Amazon Route 53” (“DNSSEC signing is supported only for public hosted zones”; KSK from a customer managed key in AWS KMS), https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/dns-configuring-dnssec.html (accessed Oct 29, 2026).

44. AWS, Amazon Route 53 Developer Guide, “Enabling DNSSEC validation in Amazon Route 53” (“DNSSEC validation is applied by VPC Resolver to public signed names when it is performing recursive DNS resolution”; a resolver it forwards to “must also apply the DNSSEC validation”; it “ignores the DO (DNSSEC OK) EDNS header bit and the CD (Checking Disabled) bit … doesn’t return DNSSEC records nor set the AD bit”; enabling it “could result in an outage”), https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/resolver-dnssec-validation.html (accessed Oct 29, 2026).

45. AWS, Amazon Route 53 Developer Guide, “Configuring DNSSEC signing in Amazon Route 53” (“DNSSEC signing is supported only for public hosted zones”; KSK from a customer managed key in AWS KMS), https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/dns-configuring-dnssec.html (accessed Oct 29, 2026).

46. AWS, Amazon Route 53 Developer Guide, “What is Route 53 Global Resolver?,” https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/gr-what-is-global-resolver.html; and AWS What’s New, March 9, 2026 (general availability in 30 Regions), https://aws.amazon.com/about-aws/whats-new/2026/03/amazon-route-53-global-resolver/ (both accessed Oct 29, 2026). No GovCloud Region appears in its Region list.

47. AWS, Amazon Route 53 Developer Guide, “What is Route 53 Global Resolver?,” https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/gr-what-is-global-resolver.html; and AWS What’s New, March 9, 2026 (general availability in 30 Regions), https://aws.amazon.com/about-aws/whats-new/2026/03/amazon-route-53-global-resolver/ (both accessed Oct 29, 2026). No GovCloud Region appears in its Region list.

48. AWS, AWS GovCloud (US) User Guide, “Amazon Route 53 in AWS GovCloud (US)” (public and private DNS and health checks in US-West and US-East; control plane in US-West; public hosted zone queries “answered from within FedRAMP boundary”; DNSSEC key and query-log group in US-West; routing types not available in private zones; “Route 53 Resolver delegation is not available”), https://docs.aws.amazon.com/govcloud-us/latest/UserGuide/govcloud-r53.html (accessed Oct 29, 2026).

49. AWS, AWS General Reference, “Amazon Route 53 endpoints and quotas” (Route 53 Resolver and Route 53 Profiles endpoints, including us-gov-east-1 and us-gov-west-1), https://docs.aws.amazon.com/general/latest/gr/r53.html; and AWS What’s New, June 4, 2024 (Route 53 Profiles in the AWS GovCloud (US-East) and (US-West) Regions) (accessed Oct 29, 2026).

50. AWS, AWS GovCloud (US) User Guide, “Amazon Route 53 in AWS GovCloud (US)” (public and private DNS and health checks in US-West and US-East; control plane in US-West; public hosted zone queries “answered from within FedRAMP boundary”; DNSSEC key and query-log group in US-West; routing types not available in private zones; “Route 53 Resolver delegation is not available”), https://docs.aws.amazon.com/govcloud-us/latest/UserGuide/govcloud-r53.html (accessed Oct 29, 2026).

51. AWS What’s New, April 8, 2026, “Amazon Route 53 Resolver endpoints now support DNS delegation for private hosted zones in AWS GovCloud (US) Regions,” https://aws.amazon.com/about-aws/whats-new/2026/04/route-53-resolver-endpoints/ (accessed Oct 29, 2026).

52. AWS, Amazon Route 53 Developer Guide, “DNS Firewall availability” (lists AWS GovCloud (US)), https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/resolver-dns-firewall-availability.html (accessed Oct 29, 2026).

53. AWS, Amazon Route 53 Developer Guide, “AWS Managed Domain Lists” (“AWS Managed Domain Lists cannot be downloaded or browsed”; Region table lists AWS GovCloud (US) as Yes), https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/resolver-dns-firewall-managed-domain-lists.html (accessed Oct 29, 2026).

54. AWS, Amazon Route 53 Developer Guide, “DNS Firewall Advanced” (DGA, DNS tunneling and dictionary DGA; block or alert), https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/firewall-advanced.html; and AWS What’s New, November 17, 2025, dictionary DGA protection “available in all AWS Regions … including the AWS GovCloud (US) Regions,” https://aws.amazon.com/about-aws/whats-new/2025/11/amazon-route-53-dns-firewall-protection-dictionary-dga-attacks/ (both accessed Oct 29, 2026).

55. AWS What’s New, September 2020, “Amazon Route 53 Resolver now supports VPC DNS query logging in AWS GovCloud (US) Regions,” https://aws.amazon.com/about-aws/whats-new/2020/09/amazon-route-53-resolver-supports-vpc-dns-query-logging-aws-govcloud-us-regions/ (as cited in Book 08, Chapter 07; accessed Oct 30, 2026).

56. AWS, AWS General Reference, “Amazon Route 53 endpoints and quotas” (Route 53 Resolver and Route 53 Profiles endpoints, including us-gov-east-1 and us-gov-west-1), https://docs.aws.amazon.com/general/latest/gr/r53.html; and AWS What’s New, June 4, 2024 (Route 53 Profiles in the AWS GovCloud (US-East) and (US-West) Regions) (accessed Oct 29, 2026).

57. AWS, AWS GovCloud (US) User Guide, “Amazon Route 53 in AWS GovCloud (US)” (public and private DNS and health checks in US-West and US-East; control plane in US-West; public hosted zone queries “answered from within FedRAMP boundary”; DNSSEC key and query-log group in US-West; routing types not available in private zones; “Route 53 Resolver delegation is not available”), https://docs.aws.amazon.com/govcloud-us/latest/UserGuide/govcloud-r53.html (accessed Oct 29, 2026).

58. AWS, AWS GovCloud (US) User Guide, “Amazon Route 53 in AWS GovCloud (US)” (public and private DNS and health checks in US-West and US-East; control plane in US-West; public hosted zone queries “answered from within FedRAMP boundary”; DNSSEC key and query-log group in US-West; routing types not available in private zones; “Route 53 Resolver delegation is not available”), https://docs.aws.amazon.com/govcloud-us/latest/UserGuide/govcloud-r53.html (accessed Oct 29, 2026).

59. AWS, Amazon Route 53 Developer Guide, “What is Route 53 Global Resolver?,” https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/gr-what-is-global-resolver.html; and AWS What’s New, March 9, 2026 (general availability in 30 Regions), https://aws.amazon.com/about-aws/whats-new/2026/03/amazon-route-53-global-resolver/ (both accessed Oct 29, 2026). No GovCloud Region appears in its Region list.

60. Book 08, Chapter 07 — Cloud Private Endpoints, SDN and IPAM Consistency, and its verification log (AWS VPC IPAM’s Infoblox integration excludes the GovCloud (US) Regions; Azure Government private endpoint zone names).

61. AWS, “AWS Services in Scope by Compliance Program: FedRAMP,” last updated October 15, 2026 (Amazon Route 53, SDK route53, checked for “FedRAMP Class C (formerly Moderate baseline) (East/West)” and “FedRAMP Class D (formerly High baseline) (GovCloud)”; “Unless specifically excluded, generally available features of each of the services are considered in scope”), https://aws.amazon.com/compliance/services-in-scope/FedRAMP/ (accessed Oct 29, 2026).

62. FedRAMP, Marketplace product data (AGENCYAMAZONEW, AWS US East/West: FedRAMP Certified, Moderate; F1603047866, AWS GovCloud: FedRAMP Certified, High), https://www.fedramp.gov/marketplace/products.json (accessed Oct 29, 2026).

63. Microsoft Learn, “What is Azure DNS Private Resolver?” (endpoints, rulesets, limits, subnet restrictions, no encrypted virtual networks or IPv6-enabled subnets), https://learn.microsoft.com/azure/dns/dns-private-resolver-overview (accessed Oct 29, 2026).

64. Microsoft Learn, “Azure DNS Private Resolver endpoints and rulesets” (static inbound address; ruleset links; avoiding loops), https://learn.microsoft.com/azure/dns/private-resolver-endpoints-rulesets (accessed Oct 29, 2026).

65. Microsoft Learn, “What is Azure DNS Private Resolver?” (endpoints, rulesets, limits, subnet restrictions, no encrypted virtual networks or IPv6-enabled subnets), https://learn.microsoft.com/azure/dns/dns-private-resolver-overview (accessed Oct 29, 2026).

66. Microsoft Learn, “Azure subscription and service limits, quotas, and constraints,” DNS Private Resolver limits, and “Azure-provided DNS resolver VM limits” (1,000 queries per second and 200 pending per VM to the Azure DNS resolver; “DNS queries exceeding these limits are dropped”; limits per VM, not per virtual network, and not for the Private Resolver), https://learn.microsoft.com/azure/azure-resource-manager/management/azure-subscription-service-limits (accessed Oct 29, 2026).

67. Microsoft Learn, “What is Azure DNS Private Resolver?” (endpoints, rulesets, limits, subnet restrictions, no encrypted virtual networks or IPv6-enabled subnets), https://learn.microsoft.com/azure/dns/dns-private-resolver-overview (accessed Oct 29, 2026).

68. Microsoft Learn, “Reliability in Azure DNS Private Resolver” (zone-redundant automatically; “a single-region service”), https://learn.microsoft.com/azure/reliability/reliability-dns-private-resolver (accessed Oct 29, 2026).

69. Microsoft Learn, “Overview of DNS resolver policy” (filter and log DNS queries at the VNet level, public and private; Allow, Block, Alert; threat intelligence “sourced by Microsoft’s Security Response Center (MSRC)”; one policy per VNet; same region; logs to storage, Log Analytics or Event Hubs), https://learn.microsoft.com/azure/dns/dns-security-policy (accessed Oct 29, 2026).

70. Microsoft Learn, “Secure and view DNS traffic” (diagnostic settings; DnsResponse category; DNSQueryLogs fields), https://learn.microsoft.com/azure/dns/dns-traffic-log-how-to (accessed Oct 29, 2026).

71. Microsoft Learn, “Azure DNS monitoring data reference” (resolver and ruleset metrics; resource logs listed only for Microsoft.Network/dnsResolverPolicies), https://learn.microsoft.com/azure/dns/monitor-dns-reference (accessed Oct 29, 2026).

72. Microsoft Learn, Azure Architecture Center, “Design a hybrid Domain Name System (DNS) solution by using Azure” (custom DNS software like BIND as an alternative with “management overhead”; “Use DNS Private Resolver instead of custom DNS server software like BIND when possible”; VM-hosted authoritative DNS for NS-delegated subdomains; at least two DNS VMs across availability zones; logging through Azure Firewall or DNS security policy), https://learn.microsoft.com/azure/architecture/hybrid/hybrid-dns-infra (accessed Oct 29, 2026).

73. Microsoft Learn, “DNSSEC overview” (Azure DNS) (“DNSSEC response validation is not performed by the default Azure-provided resolver”; signing of Azure Public DNS zones), https://learn.microsoft.com/azure/dns/dnssec (accessed Oct 29, 2026).

74. Microsoft Learn, “Azure DNS FAQ” (“Azure DNS doesn’t currently support zone transfers (AXFR/IXFR)”), https://learn.microsoft.com/azure/dns/dns-faq (accessed Oct 29, 2026).

75. Microsoft Learn, “Overview of DNS resolver policy” (filter and log DNS queries at the VNet level, public and private; Allow, Block, Alert; threat intelligence “sourced by Microsoft’s Security Response Center (MSRC)”; one policy per VNet; same region; logs to storage, Log Analytics or Event Hubs), https://learn.microsoft.com/azure/dns/dns-security-policy (accessed Oct 29, 2026).

76. Microsoft Learn, “Azure, Dynamics 365, Microsoft 365, and Power Platform services compliance scope,” last updated February 2026 (one “DNS” row: FedRAMP High and DoD IL2 in Azure; FedRAMP High and DoD levels in Azure Government; no separate Private Resolver or resolver policy row), https://learn.microsoft.com/azure/azure-government/compliance/azure-services-in-fedramp-auditscope (accessed Oct 29, 2026).

77. Microsoft, “Products available by region,” https://azure.microsoft.com/explore/global-infrastructure/products-by-region/, and Microsoft Learn, “Compare Azure Government and global Azure,” https://learn.microsoft.com/azure/azure-government/compare-azure-government-global-azure (both accessed Oct 29, 2026). The public region table lists Azure DNS Private Resolver but shows no Azure Government regions; the comparison page lists no DNS differences.

78. Microsoft, Azure Retail Prices API, serviceName eq 'Azure DNS' filtered to US Gov locations (Private Resolver inbound and outbound endpoint and forwarding ruleset meters in US Gov Zone 1 and 2, effective October 1, 2024; DNS Security Policy query and managed-domain meters, effective June 1, 2026), https://prices.azure.com/api/retail/prices (retrieved Oct 29, 2026).

79. Oracle, Oracle Cloud Infrastructure Documentation, “Private DNS” (dedicated VCN resolver on 169.254.169.254; “performs recursion to the internet and DNSSEC validation for DNSSEC-signed zones”; views shared by any number of resolvers across VCNs in the same region; split horizon; listening endpoint one address, forwarding endpoint two; security rules; resolution between VCNs over LPG or RPG; “Traffic Management is only available for public DNS”), https://docs.oracle.com/en-us/iaas/Content/DNS/Tasks/privatedns.htm (accessed Oct 31, 2026).

80. Oracle, Oracle Cloud Infrastructure Documentation, “Troubleshooting DNS” (an unreachable forward target ends rule processing; 169.254.169.254 must be in a custom DHCP nameserver list to reach private views and rules; evaluation order views, rules, internet; a match ends resolution even if NXDOMAIN; stale answers per RFC 8767 with a 30-second TTL for up to 24 hours), https://docs.oracle.com/en-us/iaas/Content/DNS/Tasks/troubleshooting_general.htm (accessed Oct 31, 2026).

81. Oracle, Oracle Cloud Infrastructure Documentation, “Private DNS” (dedicated VCN resolver on 169.254.169.254; “performs recursion to the internet and DNSSEC validation for DNSSEC-signed zones”; views shared by any number of resolvers across VCNs in the same region; split horizon; listening endpoint one address, forwarding endpoint two; security rules; resolution between VCNs over LPG or RPG; “Traffic Management is only available for public DNS”), https://docs.oracle.com/en-us/iaas/Content/DNS/Tasks/privatedns.htm (accessed Oct 31, 2026).

82. Oracle, Oracle Cloud Infrastructure Documentation, “Private DNS” (dedicated VCN resolver on 169.254.169.254; “performs recursion to the internet and DNSSEC validation for DNSSEC-signed zones”; views shared by any number of resolvers across VCNs in the same region; split horizon; listening endpoint one address, forwarding endpoint two; security rules; resolution between VCNs over LPG or RPG; “Traffic Management is only available for public DNS”), https://docs.oracle.com/en-us/iaas/Content/DNS/Tasks/privatedns.htm (accessed Oct 31, 2026).

83. Oracle, Oracle Cloud Infrastructure Documentation, “Private DNS” (dedicated VCN resolver on 169.254.169.254; “performs recursion to the internet and DNSSEC validation for DNSSEC-signed zones”; views shared by any number of resolvers across VCNs in the same region; split horizon; listening endpoint one address, forwarding endpoint two; security rules; resolution between VCNs over LPG or RPG; “Traffic Management is only available for public DNS”), https://docs.oracle.com/en-us/iaas/Content/DNS/Tasks/privatedns.htm (accessed Oct 31, 2026).

84. Oracle, Oracle Cloud Infrastructure Documentation, “Creating a Resolver Rule” (up to 50 rules per resolver; condition client CIDR block, domain (up to 10) or None “to match any CIDR Block or Domain”; forward is the only action), https://docs.oracle.com/en-us/iaas/Content/Network/Tasks/resolver-rule-create.htm (accessed Oct 31, 2026).

85. Oracle, Oracle Cloud Infrastructure Documentation, “Troubleshooting DNS” (an unreachable forward target ends rule processing; 169.254.169.254 must be in a custom DHCP nameserver list to reach private views and rules; evaluation order views, rules, internet; a match ends resolution even if NXDOMAIN; stale answers per RFC 8767 with a 30-second TTL for up to 24 hours), https://docs.oracle.com/en-us/iaas/Content/DNS/Tasks/troubleshooting_general.htm (accessed Oct 31, 2026).

86. Oracle, Oracle Cloud Infrastructure Documentation, “DNS in a Virtual Cloud Network” (Internet and VCN Resolver by default; custom resolver of up to three DNS servers in a subnet’s DHCP options; oraclevcn.com domain names), https://docs.oracle.com/en-us/iaas/Content/Network/Concepts/dns.htm (accessed Oct 31, 2026).

87. Oracle, Oracle Cloud Infrastructure Documentation, “Troubleshooting DNS” (an unreachable forward target ends rule processing; 169.254.169.254 must be in a custom DHCP nameserver list to reach private views and rules; evaluation order views, rules, internet; a match ends resolution even if NXDOMAIN; stale answers per RFC 8767 with a 30-second TTL for up to 24 hours), https://docs.oracle.com/en-us/iaas/Content/DNS/Tasks/troubleshooting_general.htm (accessed Oct 31, 2026).

88. Oracle, Oracle Cloud Infrastructure Documentation, “Traffic Management Steering Policies” (available only for public DNS), https://docs.oracle.com/iaas/Content/TrafficManagement/Concepts/overview.htm (accessed Oct 31, 2026). No Oracle page describes a DNS firewall or response policy for the VCN resolver (Book 08, Chapter 07 verification).

89. Oracle, Oracle Cloud Infrastructure Documentation, “Private DNS Logs” (category dns.dnsresolver.private_resolver_query_response; resolution path per query; “available in all regions of the commercial realms”), https://docs.oracle.com/en-us/iaas/Content/Logging/Reference/details_for_privatedns.htm (as cited in Book 08, Chapter 07; accessed Oct 30, 2026).

90. Oracle, Oracle Cloud Infrastructure Documentation, “Private DNS Logs” (category dns.dnsresolver.private_resolver_query_response; resolution path per query; “available in all regions of the commercial realms”), https://docs.oracle.com/en-us/iaas/Content/Logging/Reference/details_for_privatedns.htm (as cited in Book 08, Chapter 07; accessed Oct 30, 2026).

91. Oracle, Oracle Cloud Infrastructure Documentation, “Troubleshooting DNS” (an unreachable forward target ends rule processing; 169.254.169.254 must be in a custom DHCP nameserver list to reach private views and rules; evaluation order views, rules, internet; a match ends resolution even if NXDOMAIN; stale answers per RFC 8767 with a 30-second TTL for up to 24 hours), https://docs.oracle.com/en-us/iaas/Content/DNS/Tasks/troubleshooting_general.htm (accessed Oct 31, 2026).

92. Oracle, Oracle Cloud Infrastructure Documentation, “Oracle Cloud Infrastructure US Government Cloud with FedRAMP Authorization” (FedRAMP High and DISA Impact Level 4; regions us-langley-1 and us-luke-1, realm OC2; tenancies “can’t subscribe to the commercial regions”; DNS API “for private DNS only. Public DNS isn’t available in government realms”), https://docs.oracle.com/en-us/iaas/Content/General/Concepts/govfedramp.htm (accessed Oct 31, 2026).

93. FedRAMP, Marketplace product data, dataset last changed October 31, 2026 (FR1900048743, Oracle Cloud Infrastructure-Government Cloud: FedRAMP Certified, Class D, High, JAB, October 1, 2020; F1603257882, Fusion Cloud: FedRAMP Certified, Class C, Moderate; no commercial OCI infrastructure entry), https://www.fedramp.gov/marketplace/products.json (accessed Oct 31, 2026).

94. AWS, Amazon Route 53 Developer Guide, “Resolving DNS queries between VPCs and your network” (inbound and delegation inbound endpoints; outbound endpoints; most specific rule wins; “Forwarding private DNS queries to any VPC CIDR + 2 address from on-premises or other VPC DNS servers is not supported, and can cause unstable results”), https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/resolver-overview-DSN-queries-to-vpc.html (accessed Oct 29, 2026).

95. Microsoft Learn, Azure Architecture Center, “Azure DNS Private Resolver” (“a recursive resolver and conditional forwarding service, not an authoritative name server”), https://learn.microsoft.com/azure/architecture/networking/architecture/azure-dns-private-resolver (accessed Oct 29, 2026).

96. AWS, Amazon Route 53 Developer Guide, “Managing forwarding rules,” including “Sharing Resolver rules with other AWS accounts and using shared rules” (AWS RAM; accounts, OUs or organization; “The account that a rule is shared with can’t change or delete the rule”; OU moves; the Internet Resolver rule), https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/resolver-rules-managing.html (accessed Oct 29, 2026).

97. AWS, Amazon Route 53 Developer Guide, “What are Amazon Route 53 Profiles?” (resources and settings; RAM sharing; one Profile per VPC; precedence), https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/profiles.html (accessed Oct 29, 2026).

98. CISA, Encrypted DNS Implementation Guidance, v1.0, April 2024 (announced May 16, 2024): executive summary and checklist (“Agency Cloud Deployments”); §2.1 phases 1 and 5 (IaaS upstream to “Protective DNS or agency internal DNS infrastructure”); the service description (DoH and DoT over IPv4 and IPv6, plain DNS “for authorized FCEB DNS infrastructure”; agency DNS “should use only Protective DNS as its upstream provider”); §3.6 cloud deployments; Appendix A.3.1 “BIND DNS Server,” https://www.cisa.gov/resources-tools/resources/encrypted-dns-implementation-guidance; PDF https://www.cisa.gov/sites/default/files/2024-05/Encrypted%20DNS%20Implementation%20Guidance_508c.pdf (accessed Oct 29, 2026).

99. Oracle, Oracle Cloud Infrastructure Documentation, “Creating a Resolver Rule” (up to 50 rules per resolver; condition client CIDR block, domain (up to 10) or None “to match any CIDR Block or Domain”; forward is the only action), https://docs.oracle.com/en-us/iaas/Content/Network/Tasks/resolver-rule-create.htm (accessed Oct 31, 2026).

100. Microsoft Learn, Azure Architecture Center, “Design a hybrid Domain Name System (DNS) solution by using Azure” (custom DNS software like BIND as an alternative with “management overhead”; “Use DNS Private Resolver instead of custom DNS server software like BIND when possible”; VM-hosted authoritative DNS for NS-delegated subdomains; at least two DNS VMs across availability zones; logging through Azure Firewall or DNS security policy), https://learn.microsoft.com/azure/architecture/hybrid/hybrid-dns-infra (accessed Oct 29, 2026).

101. AWS, Amazon Route 53 Developer Guide, “Resolving DNS queries between VPCs and your network” (inbound and delegation inbound endpoints; outbound endpoints; most specific rule wins; “Forwarding private DNS queries to any VPC CIDR + 2 address from on-premises or other VPC DNS servers is not supported, and can cause unstable results”), https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/resolver-overview-DSN-queries-to-vpc.html (accessed Oct 29, 2026).

102. AWS Whitepaper, Hybrid Cloud DNS Options for Amazon VPC, December 2, 2022, marked “for historical reference only” (“Each EC2 instance is limited to 1024 packets per second for DNS queries”; custom resolvers on EC2; for BIND, “it is critical to specify the forward only option”; auto-recovery and secondary addresses), https://docs.aws.amazon.com/pdfs/whitepapers/latest/hybrid-cloud-dns-options-for-vpc/hybrid-cloud-dns-options-for-vpc.pdf (accessed Oct 29, 2026, at its HTML address, which since redirects to the Route 53 Developer Guide’s “What is Route 53 VPC Resolver?”; the quoted text re-checked in the PDF on November 9, 2026).

103. AWS, Amazon VPC User Guide, “Understanding Amazon DNS” (169.254.169.253 and VPC+2; recursive queries only; not filtered by network ACLs or security groups; “There is a 1024 packet per second (PPS) limit to services that use link-local addresses,” covering DNS, IMDS, NTP and Windows licensing; “This quota cannot be increased”), https://docs.aws.amazon.com/vpc/latest/userguide/AmazonDNS-concepts.html (accessed Oct 29, 2026).

104. Microsoft Learn, “Azure subscription and service limits, quotas, and constraints,” DNS Private Resolver limits, and “Azure-provided DNS resolver VM limits” (1,000 queries per second and 200 pending per VM to the Azure DNS resolver; “DNS queries exceeding these limits are dropped”; limits per VM, not per virtual network, and not for the Private Resolver), https://learn.microsoft.com/azure/azure-resource-manager/management/azure-subscription-service-limits (accessed Oct 29, 2026).

105. ISC Knowledge Base, “ISC’s Software Support Policy and Version Numbering” (each even-numbered version supported for four years; 9.18 end of life; 9.20 stable moving to Extended Support; 9.21 development), https://kb.isc.org/docs/aa-00896 (accessed Oct 29, 2026).

106. ISC, “Download” (9.20.30, October 2026, current stable with ESV label, end of life Q2 2028; 9.18 end of life), https://www.isc.org/download/ (accessed Oct 29, 2026).

107. ISC Knowledge Base, “ISC Software Defect and Vulnerability Disclosure Policy” (“Only the most recent monthly releases of our stable maintenance versions are covered by this policy”; advance notice to support customers), https://kb.isc.org/docs/aa-00861 (accessed Oct 29, 2026).

108. NIST SP 800-81r3, §2.3 “Protecting the DNS Service and Infrastructure” and §2.3.1 “Dedicated DNS Services” (dedicated, hardened hosts; recursion off on authoritative servers; an internet-facing instance “should not be configured to serve in both roles”; combining roles acceptable on internal-only servers), https://csrc.nist.gov/pubs/sp/800/81/r3/final (accessed Oct 29, 2026).

109. ISC Knowledge Base, “BIND Best Practices - Authoritative” (“Run BIND on a server dedicated to DNS only”; “Do not combine authoritative and recursive nameserver functions”; subscribe to bind-announce), https://kb.isc.org/docs/bind-best-practices-authoritative (accessed Oct 29, 2026).

110. AWS, Amazon Route 53 Developer Guide, “Resolving DNS queries between VPCs and your network” (inbound and delegation inbound endpoints; outbound endpoints; most specific rule wins; “Forwarding private DNS queries to any VPC CIDR + 2 address from on-premises or other VPC DNS servers is not supported, and can cause unstable results”), https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/resolver-overview-DSN-queries-to-vpc.html (accessed Oct 29, 2026).

111. Microsoft Learn, “Configure DNS name resolution for Azure virtual networks” (Private Resolver “replaces the need to use VM-based DNS servers”; DNS server VMs in the same virtual network forward hostname queries to Azure; forwarding timeout “more than four seconds”), https://learn.microsoft.com/azure/virtual-network/virtual-networks-name-resolution-for-vms-and-role-instances (accessed Oct 29, 2026).

112. Oracle, Oracle Cloud Infrastructure Documentation, “DNS in a Virtual Cloud Network” (Internet and VCN Resolver by default; custom resolver of up to three DNS servers in a subnet’s DHCP options; oraclevcn.com domain names), https://docs.oracle.com/en-us/iaas/Content/Network/Concepts/dns.htm (accessed Oct 31, 2026).

113. Oracle, Oracle Cloud Infrastructure Documentation, “Troubleshooting DNS” (an unreachable forward target ends rule processing; 169.254.169.254 must be in a custom DHCP nameserver list to reach private views and rules; evaluation order views, rules, internet; a match ends resolution even if NXDOMAIN; stale answers per RFC 8767 with a 30-second TTL for up to 24 hours), https://docs.oracle.com/en-us/iaas/Content/DNS/Tasks/troubleshooting_general.htm (accessed Oct 31, 2026).

114. NIST SP 800-81r3, §2.3.2 “Resiliency and High Availability of DNS Servers” (at least two authoritative servers on different segments, dispersed geographically; a hidden primary), https://csrc.nist.gov/pubs/sp/800/81/r3/final (accessed Oct 29, 2026).

115. Microsoft Learn, Azure Architecture Center, “Design a hybrid Domain Name System (DNS) solution by using Azure” (custom DNS software like BIND as an alternative with “management overhead”; “Use DNS Private Resolver instead of custom DNS server software like BIND when possible”; VM-hosted authoritative DNS for NS-delegated subdomains; at least two DNS VMs across availability zones; logging through Azure Firewall or DNS security policy), https://learn.microsoft.com/azure/architecture/hybrid/hybrid-dns-infra (accessed Oct 29, 2026).

116. AWS Whitepaper, Hybrid Cloud DNS Options for Amazon VPC, December 2, 2022, marked “for historical reference only” (“Each EC2 instance is limited to 1024 packets per second for DNS queries”; custom resolvers on EC2; for BIND, “it is critical to specify the forward only option”; auto-recovery and secondary addresses), https://docs.aws.amazon.com/pdfs/whitepapers/latest/hybrid-cloud-dns-options-for-vpc/hybrid-cloud-dns-options-for-vpc.pdf (accessed Oct 29, 2026, at its HTML address, which since redirects to the Route 53 Developer Guide’s “What is Route 53 VPC Resolver?”; the quoted text re-checked in the PDF on November 9, 2026).

117. AWS, Amazon Route 53 Developer Guide, “Considerations when working with a private hosted zone” (custom DNS servers: “you must configure those DNS servers to route your private DNS queries to the IP address of the Amazon-provided DNS servers for your VPC”), https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/hosted-zone-private-considerations.html (accessed Oct 29, 2026).

118. ISC, BIND 9 Administrator Reference Manual, 9.20 (stable), “Configuration Reference”: forward (“A value of first is the default”), forwarders (optional TLS transport), type forward, allow-query, allow-recursion, allow-transfer, version, dnssec-validation (default auto), validate-except, tls, http, listen-on, logging categories, querylog, dnstap and dnstap-output (requires --enable-dnstap), https://bind9.readthedocs.io/en/stable/reference.html (accessed Oct 29, 2026).

119. AWS Whitepaper, Hybrid Cloud DNS Options for Amazon VPC, December 2, 2022, marked “for historical reference only” (“Each EC2 instance is limited to 1024 packets per second for DNS queries”; custom resolvers on EC2; for BIND, “it is critical to specify the forward only option”; auto-recovery and secondary addresses), https://docs.aws.amazon.com/pdfs/whitepapers/latest/hybrid-cloud-dns-options-for-vpc/hybrid-cloud-dns-options-for-vpc.pdf (accessed Oct 29, 2026, at its HTML address, which since redirects to the Route 53 Developer Guide’s “What is Route 53 VPC Resolver?”; the quoted text re-checked in the PDF on November 9, 2026).

120. AWS, Amazon VPC User Guide, “Understanding Amazon DNS” (169.254.169.253 and VPC+2; recursive queries only; not filtered by network ACLs or security groups; “There is a 1024 packet per second (PPS) limit to services that use link-local addresses,” covering DNS, IMDS, NTP and Windows licensing; “This quota cannot be increased”), https://docs.aws.amazon.com/vpc/latest/userguide/AmazonDNS-concepts.html (accessed Oct 29, 2026).

121. Microsoft Learn, “Azure subscription and service limits, quotas, and constraints,” DNS Private Resolver limits, and “Azure-provided DNS resolver VM limits” (1,000 queries per second and 200 pending per VM to the Azure DNS resolver; “DNS queries exceeding these limits are dropped”; limits per VM, not per virtual network, and not for the Private Resolver), https://learn.microsoft.com/azure/azure-resource-manager/management/azure-subscription-service-limits (accessed Oct 29, 2026).

122. Microsoft Learn, “Configure DNS name resolution for Azure virtual networks” (Private Resolver “replaces the need to use VM-based DNS servers”; DNS server VMs in the same virtual network forward hostname queries to Azure; forwarding timeout “more than four seconds”), https://learn.microsoft.com/azure/virtual-network/virtual-networks-name-resolution-for-vms-and-role-instances (accessed Oct 29, 2026).

123. AWS, Amazon Route 53 Developer Guide, “Resolver query logging” (queries from VPCs, through inbound and outbound endpoints, and DNS Firewall actions; CloudWatch Logs, S3 or Firehose; “logs only unique queries, not queries that VPC Resolver is able to respond to from the cache”), https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/resolver-query-logs.html (accessed Oct 29, 2026).

124. AWS, Amazon Route 53 Developer Guide, “How Resolver DNS Firewall works” (filters “DNS queries originating within that VPC and passing through VPC DNS” and queries arriving through Resolver endpoints into that VPC), https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/resolver-dns-firewall-overview.html (accessed Oct 29, 2026).

125. AWS, Amazon Route 53 Developer Guide, “Best practices for Resolver” (avoid loops; connection tracking; at least two Availability Zones), https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/best-practices-resolver.html (accessed Oct 29, 2026).

126. Microsoft Learn, “Azure DNS Private Resolver endpoints and rulesets” (static inbound address; ruleset links; avoiding loops), https://learn.microsoft.com/azure/dns/private-resolver-endpoints-rulesets (accessed Oct 29, 2026).

127. Oracle, Oracle Cloud Infrastructure Documentation, “DNS in a Virtual Cloud Network” (Internet and VCN Resolver by default; custom resolver of up to three DNS servers in a subnet’s DHCP options; oraclevcn.com domain names), https://docs.oracle.com/en-us/iaas/Content/Network/Concepts/dns.htm (accessed Oct 31, 2026).

128. Book 08, Chapter 07 — Cloud Private Endpoints, SDN and IPAM Consistency, and its verification log (AWS VPC IPAM’s Infoblox integration excludes the GovCloud (US) Regions; Azure Government private endpoint zone names).

129. Microsoft Learn, “Configure DNS name resolution for Azure virtual networks” (Private Resolver “replaces the need to use VM-based DNS servers”; DNS server VMs in the same virtual network forward hostname queries to Azure; forwarding timeout “more than four seconds”), https://learn.microsoft.com/azure/virtual-network/virtual-networks-name-resolution-for-vms-and-role-instances (accessed Oct 29, 2026).

130. Book 08, Chapter 07 — Cloud Private Endpoints, SDN and IPAM Consistency, and its verification log (AWS VPC IPAM’s Infoblox integration excludes the GovCloud (US) Regions; Azure Government private endpoint zone names).

131. ISC, BIND 9 Administrator Reference Manual, 9.20 (stable), “Configuration Reference”: forward (“A value of first is the default”), forwarders (optional TLS transport), type forward, allow-query, allow-recursion, allow-transfer, version, dnssec-validation (default auto), validate-except, tls, http, listen-on, logging categories, querylog, dnstap and dnstap-output (requires --enable-dnstap), https://bind9.readthedocs.io/en/stable/reference.html (accessed Oct 29, 2026).

132. ISC, BIND 9 Administrator Reference Manual, 9.20, chapter 5, “DNSSEC” (§5.1.2 fully automated signing: dnssec-policy default is “the recommended, fully automated way to sign and maintain DNS zones”; key rollover; §5.3 validation by default), https://bind9.readthedocs.io/en/stable/chapter5.html (accessed Oct 29, 2026).

133. NIST SP 800-81r3, §4.2.5 “Enabling DNSSEC Validation,” §4.2.6 “Maintaining DNSSEC Trust Anchors” and §4.3 “Operational Recommendations” (recursion for internal hosts only), https://csrc.nist.gov/pubs/sp/800/81/r3/final (accessed Oct 29, 2026).

134. AWS, Amazon Route 53 Developer Guide, “Enabling DNSSEC validation in Amazon Route 53” (“DNSSEC validation is applied by VPC Resolver to public signed names when it is performing recursive DNS resolution”; a resolver it forwards to “must also apply the DNSSEC validation”; it “ignores the DO (DNSSEC OK) EDNS header bit and the CD (Checking Disabled) bit … doesn’t return DNSSEC records nor set the AD bit”; enabling it “could result in an outage”), https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/resolver-dnssec-validation.html (accessed Oct 29, 2026).

135. Oracle, Oracle Cloud Infrastructure Documentation, “Private DNS” (dedicated VCN resolver on 169.254.169.254; “performs recursion to the internet and DNSSEC validation for DNSSEC-signed zones”; views shared by any number of resolvers across VCNs in the same region; split horizon; listening endpoint one address, forwarding endpoint two; security rules; resolution between VCNs over LPG or RPG; “Traffic Management is only available for public DNS”), https://docs.oracle.com/en-us/iaas/Content/DNS/Tasks/privatedns.htm (accessed Oct 31, 2026).

136. ISC, BIND 9 Administrator Reference Manual, 9.20 (stable), “Configuration Reference”: forward (“A value of first is the default”), forwarders (optional TLS transport), type forward, allow-query, allow-recursion, allow-transfer, version, dnssec-validation (default auto), validate-except, tls, http, listen-on, logging categories, querylog, dnstap and dnstap-output (requires --enable-dnstap), https://bind9.readthedocs.io/en/stable/reference.html (accessed Oct 29, 2026).

137. NIST SP 800-53 Rev. 5, Security and Privacy Controls for Information Systems and Organizations (release 5.2.0), CM-2, CM-3, CM-6, CM-7, CM-8, SC-20, SC-21, SC-22, SI-2, SI-4, AU-2 and AU-12, https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final (accessed Oct 29, 2026). As cited in Book 08, Chapters 03 and 06.

138. Office of Management and Budget, M-08-23, Securing the Federal Government’s Domain Name System Infrastructure, August 22, 2008, https://georgewbush-whitehouse.archives.gov/omb/memoranda/fy2008/m08-23.pdf (as cited in Book 08, Chapter 03; accessed Oct 20, 2026).

139. AWS, Amazon Route 53 Developer Guide, “Configuring DNSSEC signing in Amazon Route 53” (“DNSSEC signing is supported only for public hosted zones”; KSK from a customer managed key in AWS KMS), https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/dns-configuring-dnssec.html (accessed Oct 29, 2026).

140. Microsoft Learn, “DNSSEC overview” (Azure DNS) (“DNSSEC response validation is not performed by the default Azure-provided resolver”; signing of Azure Public DNS zones), https://learn.microsoft.com/azure/dns/dnssec (accessed Oct 29, 2026).

141. Oracle, Oracle Cloud Infrastructure Documentation, “Private DNS” (dedicated VCN resolver on 169.254.169.254; “performs recursion to the internet and DNSSEC validation for DNSSEC-signed zones”; views shared by any number of resolvers across VCNs in the same region; split horizon; listening endpoint one address, forwarding endpoint two; security rules; resolution between VCNs over LPG or RPG; “Traffic Management is only available for public DNS”), https://docs.oracle.com/en-us/iaas/Content/DNS/Tasks/privatedns.htm (accessed Oct 31, 2026).

142. NIST SP 800-81r3, §3.8 “DNSSEC Signing Considerations for Authoritative Service” and §3.8.6 “DNSSEC Signing Internal Zones,” https://csrc.nist.gov/pubs/sp/800/81/r3/final (accessed Oct 29, 2026).

143. ISC, BIND 9 Administrator Reference Manual, 9.20, chapter 5, “DNSSEC” (§5.1.2 fully automated signing: dnssec-policy default is “the recommended, fully automated way to sign and maintain DNS zones”; key rollover; §5.3 validation by default), https://bind9.readthedocs.io/en/stable/chapter5.html (accessed Oct 29, 2026).

144. ISC, BIND 9 Administrator Reference Manual, 9.20, “Response Policy Zone (RPZ) Rewriting” (response-policy; five triggers; actions; up to 64 zones) and chapter 6, §6.9 “DNS Firewalls and Response Policy Zones” (rules maintained and synchronized like any other zone; IXFR and NOTIFY), https://bind9.readthedocs.io/en/stable/reference.html and https://bind9.readthedocs.io/en/stable/chapter6.html (accessed Oct 29, 2026).

145. NIST SP 800-81r3, §2.1 “Protective DNS” (service, internal infrastructure or both; footnote: “not the CISA program of the same name”) and §2.1.2 “Name Resolution Filtering” (“generally implemented by using DNS firewalls or RPZs”; secondaries for RPZ feeds), https://csrc.nist.gov/pubs/sp/800/81/r3/final (accessed Oct 29, 2026).

146. CISA, “Protective Domain Name System (DNS) Resolver” (mandated for FCEB agencies; “implemented upstream from agency networks”; “does not interfere with internal DNS architecture”; mobile, roaming and cloud traffic flows to it directly), https://www.cisa.gov/resources-tools/services/protective-domain-name-system-dns-resolver (accessed Oct 29, 2026).

147. CISA, Encrypted DNS Implementation Guidance, v1.0, April 2024 (announced May 16, 2024): executive summary and checklist (“Agency Cloud Deployments”); §2.1 phases 1 and 5 (IaaS upstream to “Protective DNS or agency internal DNS infrastructure”); the service description (DoH and DoT over IPv4 and IPv6, plain DNS “for authorized FCEB DNS infrastructure”; agency DNS “should use only Protective DNS as its upstream provider”); §3.6 cloud deployments; Appendix A.3.1 “BIND DNS Server,” https://www.cisa.gov/resources-tools/resources/encrypted-dns-implementation-guidance; PDF https://www.cisa.gov/sites/default/files/2024-05/Encrypted%20DNS%20Implementation%20Guidance_508c.pdf (accessed Oct 29, 2026).

148. NIST SP 800-81r3, §2.1 “Protective DNS” (service, internal infrastructure or both; footnote: “not the CISA program of the same name”) and §2.1.2 “Name Resolution Filtering” (“generally implemented by using DNS firewalls or RPZs”; secondaries for RPZ feeds), https://csrc.nist.gov/pubs/sp/800/81/r3/final (accessed Oct 29, 2026).

149. ISC, BIND 9 Administrator Reference Manual, 9.20 (stable), “Configuration Reference”: forward (“A value of first is the default”), forwarders (optional TLS transport), type forward, allow-query, allow-recursion, allow-transfer, version, dnssec-validation (default auto), validate-except, tls, http, listen-on, logging categories, querylog, dnstap and dnstap-output (requires --enable-dnstap), https://bind9.readthedocs.io/en/stable/reference.html (accessed Oct 29, 2026).

150. CISA, Encrypted DNS Implementation Guidance, v1.0, April 2024 (announced May 16, 2024): executive summary and checklist (“Agency Cloud Deployments”); §2.1 phases 1 and 5 (IaaS upstream to “Protective DNS or agency internal DNS infrastructure”); the service description (DoH and DoT over IPv4 and IPv6, plain DNS “for authorized FCEB DNS infrastructure”; agency DNS “should use only Protective DNS as its upstream provider”); §3.6 cloud deployments; Appendix A.3.1 “BIND DNS Server,” https://www.cisa.gov/resources-tools/resources/encrypted-dns-implementation-guidance; PDF https://www.cisa.gov/sites/default/files/2024-05/Encrypted%20DNS%20Implementation%20Guidance_508c.pdf (accessed Oct 29, 2026).

151. ISC, BIND 9 Administrator Reference Manual, 9.20 (stable), “Configuration Reference”: forward (“A value of first is the default”), forwarders (optional TLS transport), type forward, allow-query, allow-recursion, allow-transfer, version, dnssec-validation (default auto), validate-except, tls, http, listen-on, logging categories, querylog, dnstap and dnstap-output (requires --enable-dnstap), https://bind9.readthedocs.io/en/stable/reference.html (accessed Oct 29, 2026).

152. NIST SP 800-81r3, §2.1.3 “DNS for Digital Forensics and Incident Response” (“robust DNS traffic logging”; DNSTAP; blocked or malicious queries “should always be logged”; SIEM integration) and §2.3.3, https://csrc.nist.gov/pubs/sp/800/81/r3/final (accessed Oct 29, 2026).

153. Office of Management and Budget, M-22-09, Moving the U.S. Government Toward Zero Trust Cybersecurity Principles, January 26, 2022, section “Encrypting DNS traffic,” https://www.whitehouse.gov/wp-content/uploads/2022/01/M-22-09.pdf (as cited in Book 08, Chapter 03; accessed Oct 20, 2026).

154. Office of Management and Budget, M-26-14, Ensuring Effective and Efficient Agency Logging and Network Visibility to Defend Against Evolving Cyber Threats, May 22, 2026, Appendix B, https://www.whitehouse.gov/wp-content/uploads/2026/05/M-26-14-Ensuring-Effective-and-Efficient-Agency-Logging-and-Network-Visibility-to-Defend-Against-Evolving-Cyber-Threats.pdf (as cited in Book 08, Chapters 03 and 11; accessed Oct 21, 2026).

155. ISC, BIND 9 Administrator Reference Manual, 9.20 (stable), “Configuration Reference”: forward (“A value of first is the default”), forwarders (optional TLS transport), type forward, allow-query, allow-recursion, allow-transfer, version, dnssec-validation (default auto), validate-except, tls, http, listen-on, logging categories, querylog, dnstap and dnstap-output (requires --enable-dnstap), https://bind9.readthedocs.io/en/stable/reference.html (accessed Oct 29, 2026).

156. ISC Knowledge Base, “BIND Best Practices - Recursive” (restrict recursion to authorized clients; validation; query logging overhead; marked stale by ISC), https://kb.isc.org/docs/bind-best-practices-recursive (accessed Oct 29, 2026).

157. NIST SP 800-81r3, §2.3 “Protecting the DNS Service and Infrastructure” and §2.3.1 “Dedicated DNS Services” (dedicated, hardened hosts; recursion off on authoritative servers; an internet-facing instance “should not be configured to serve in both roles”; combining roles acceptable on internal-only servers), https://csrc.nist.gov/pubs/sp/800/81/r3/final (accessed Oct 29, 2026).

158. ISC Knowledge Base, “BIND Best Practices - Authoritative” (“Run BIND on a server dedicated to DNS only”; “Do not combine authoritative and recursive nameserver functions”; subscribe to bind-announce), https://kb.isc.org/docs/bind-best-practices-authoritative (accessed Oct 29, 2026).

159. ISC Knowledge Base, “BIND 9 Software Vulnerability Matrix,” https://kb.isc.org/docs/aa-00913; and the bind-announce list, https://lists.isc.org/mailman/listinfo/bind-announce (both accessed Oct 29, 2026).

160. ISC Knowledge Base, “ISC Software Defect and Vulnerability Disclosure Policy” (“Only the most recent monthly releases of our stable maintenance versions are covered by this policy”; advance notice to support customers), https://kb.isc.org/docs/aa-00861 (accessed Oct 29, 2026).

161. CISA, BOD 26-04, Prioritizing Security Updates Based on Risk, June 10, 2026, https://www.cisa.gov/news-events/directives/bod-26-04-prioritizing-security-updates-based-risk (as cited in Book 09, Chapter 02 and Book 12, Chapter 06; accessed Oct 20, 2026). Revokes BOD 22-01 and BOD 19-02.

162. CISA, BOD 23-01, Improving Asset Visibility and Vulnerability Detection on Federal Networks, October 3, 2022 (asset discovery every 7 days; vulnerability enumeration every 14 days; cloud deployment models in scope), https://www.cisa.gov/news-events/directives/bod-23-01-improving-asset-visibility-and-vulnerability-detection-federal-networks (accessed Oct 29, 2026).

163. ISC, BIND 9 Administrator Reference Manual, 9.20 (stable), “Configuration Reference”: forward (“A value of first is the default”), forwarders (optional TLS transport), type forward, allow-query, allow-recursion, allow-transfer, version, dnssec-validation (default auto), validate-except, tls, http, listen-on, logging categories, querylog, dnstap and dnstap-output (requires --enable-dnstap), https://bind9.readthedocs.io/en/stable/reference.html (accessed Oct 29, 2026).

164. ISC, BIND 9 Administrator Reference Manual, 9.20, chapter 7, “Security Configurations” (access control lists; chroot and setuid; dynamic update security; TSIG and SIG(0)), https://bind9.readthedocs.io/en/stable/chapter7.html (accessed Oct 29, 2026).

165. NIST SP 800-81r3, §3.1 “Zone Transfer Threats and Protection Approaches” (TSIG; “The confidentiality of zone transfers can be provided by using TLS”) and §3.1.1, https://csrc.nist.gov/pubs/sp/800/81/r3/final (accessed Oct 29, 2026).

166. NIST SP 800-81r3, Secure Domain Name System (DNS) Deployment Guide, S. Rose (NIST), C. Liu and R. Gibson (Infoblox), March 2026, https://csrc.nist.gov/pubs/sp/800/81/r3/final; PDF https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-81r3.pdf (accessed Oct 29, 2026).

167. ISC, BIND 9 Administrator Reference Manual, 9.20, chapter 7, “Security Configurations” (access control lists; chroot and setuid; dynamic update security; TSIG and SIG(0)), https://bind9.readthedocs.io/en/stable/chapter7.html (accessed Oct 29, 2026).

168. ISC Knowledge Base, “BIND Best Practices - Authoritative” (“Run BIND on a server dedicated to DNS only”; “Do not combine authoritative and recursive nameserver functions”; subscribe to bind-announce), https://kb.isc.org/docs/bind-best-practices-authoritative (accessed Oct 29, 2026).

169. ISC Knowledge Base, “BIND Best Practices - Recursive” (restrict recursion to authorized clients; validation; query logging overhead; marked stale by ISC), https://kb.isc.org/docs/bind-best-practices-recursive (accessed Oct 29, 2026).

170. Center for Internet Security, “CIS Benchmarks: BIND” (ISC BIND DNS Server 9.11, v1.0.0; ISC BIND DNS Server 9.9, v3.0.1), https://www.cisecurity.org/benchmark/bind (retrieved October 29, 2026, before removal; HTTP 404 on November 9, 2026), and the benchmark list, https://www.cisecurity.org/cis-benchmarks (accessed October 29 and November 9, 2026; on November 9 its only BIND entry is “BIND 9.x STIG (1.0.0)” under DISA STIG, and it says “Old Benchmarks that are no longer supported by CIS and the CIS Benchmarks Community are not listed above”).

171. NIST SP 800-53 Rev. 5, Security and Privacy Controls for Information Systems and Organizations (release 5.2.0), CM-2, CM-3, CM-6, CM-7, CM-8, SC-20, SC-21, SC-22, SI-2, SI-4, AU-2 and AU-12, https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final (accessed Oct 29, 2026). As cited in Book 08, Chapters 03 and 06.

172. CISA, BOD 23-01, Improving Asset Visibility and Vulnerability Detection on Federal Networks, October 3, 2022 (asset discovery every 7 days; vulnerability enumeration every 14 days; cloud deployment models in scope), https://www.cisa.gov/news-events/directives/bod-23-01-improving-asset-visibility-and-vulnerability-detection-federal-networks (accessed Oct 29, 2026).

173. CISA, BOD 26-04, Prioritizing Security Updates Based on Risk, June 10, 2026, https://www.cisa.gov/news-events/directives/bod-26-04-prioritizing-security-updates-based-risk (as cited in Book 09, Chapter 02 and Book 12, Chapter 06; accessed Oct 20, 2026). Revokes BOD 22-01 and BOD 19-02.

174. Office of Management and Budget, M-26-14, Ensuring Effective and Efficient Agency Logging and Network Visibility to Defend Against Evolving Cyber Threats, May 22, 2026, Appendix B, https://www.whitehouse.gov/wp-content/uploads/2026/05/M-26-14-Ensuring-Effective-and-Efficient-Agency-Logging-and-Network-Visibility-to-Defend-Against-Evolving-Cyber-Threats.pdf (as cited in Book 08, Chapters 03 and 11; accessed Oct 21, 2026).

175. Office of Management and Budget, M-22-09, Moving the U.S. Government Toward Zero Trust Cybersecurity Principles, January 26, 2022, section “Encrypting DNS traffic,” https://www.whitehouse.gov/wp-content/uploads/2022/01/M-22-09.pdf (as cited in Book 08, Chapter 03; accessed Oct 20, 2026).

176. CISA, “Protective Domain Name System (DNS) Resolver” (mandated for FCEB agencies; “implemented upstream from agency networks”; “does not interfere with internal DNS architecture”; mobile, roaming and cloud traffic flows to it directly), https://www.cisa.gov/resources-tools/services/protective-domain-name-system-dns-resolver (accessed Oct 29, 2026).

177. CISA, Encrypted DNS Implementation Guidance, v1.0, April 2024 (announced May 16, 2024): executive summary and checklist (“Agency Cloud Deployments”); §2.1 phases 1 and 5 (IaaS upstream to “Protective DNS or agency internal DNS infrastructure”); the service description (DoH and DoT over IPv4 and IPv6, plain DNS “for authorized FCEB DNS infrastructure”; agency DNS “should use only Protective DNS as its upstream provider”); §3.6 cloud deployments; Appendix A.3.1 “BIND DNS Server,” https://www.cisa.gov/resources-tools/resources/encrypted-dns-implementation-guidance; PDF https://www.cisa.gov/sites/default/files/2024-05/Encrypted%20DNS%20Implementation%20Guidance_508c.pdf (accessed Oct 29, 2026).

178. CISA, Emergency Directive 19-01, Mitigate DNS Infrastructure Tampering, January 22, 2019 (audit DNS records; change passwords; add MFA; monitor Certificate Transparency logs), with CISA’s January 8, 2026 update sunsetting the directive and its required actions, https://www.cisa.gov/news-events/directives/ed-19-01-mitigate-dns-infrastructure-tampering-closed (accessed Oct 29, 2026).