Domain Name System
The Domain Name System (DNS) is the foundational layer upon which nearly every aspect of modern business operations depends. Far beyond simple website resolution, DNS now serves as a critical trust anchor for identity federation, email authentication, service verification, single sign-on (SSO), certificate validation, and zero-trust architecture enforcement.
This policy establishes the requirements for DNS management, domain registration security, and the broader domain trust ecosystem. It addresses the growing role of DNS in identity and access management (IAM), trust validation protocols such as SAML and OIDC, and the supply chain risks associated with domain compromise.
CRITICAL RISK STATEMENT A compromised domain is not merely an IT inconvenience. It can enable account takeover of every federated identity system, interception of all organizational email, impersonation of the organization to customers and partners, hijacking of SSO and SAML authentication flows, issuance of fraudulent TLS certificates, and complete loss of brand trust. The blast radius of a domain compromise is the entire organization. |
2. DNS Management Policy
2.1 Core Policy Statement
Organizations shall use a dedicated, enterprise-grade DNS provider to manage DNS records independent of the website host, mail host, and domain registrar. Approved providers include Amazon Route 53, Microsoft Azure DNS, Cloudflare DNS, and Google Cloud DNS.
2.2 Approved Exceptions
The following exceptions are recognized where the operational benefit outweighs the risk of co-locating DNS with another service:
Scenario | Rationale | Risk Acceptance |
Microsoft 365 + GoDaddy | Automatic record management for Exchange Online, Teams, and Entra ID domain verification reduces misconfiguration risk. | GoDaddy lacks SOC 2 / ISO 27001 certification. Vendor risk review required. |
Google Workspace + Google Domains | Tight integration with Google Workspace domain verification, DKIM signing, and MX management. | Google Cloud infrastructure provides adequate resilience and security controls. |
E-commerce platforms (Shopify, BigCommerce) | Platform-managed DNS simplifies storefront, CDN, and SSL certificate provisioning. | Only acceptable for single-purpose domains. Primary corporate domain must remain on an approved provider. |
2.3 Why Separation of DNS Matters
Convenience vs. Control: Web hosts and SaaS platforms frequently request DNS delegation because it reduces their support burden. This self-serving convenience transfers control and risk to a party whose primary competency is not DNS security. Separation ensures that a compromise of any single service provider does not cascade to the DNS layer, which underpins all other services.
Resilience: Dedicated DNS providers such as Route 53 and Azure DNS operate on globally distributed anycast networks with SLAs of 100% availability. Web host DNS infrastructure cannot match this. An outage at your web host should not take your email, SSO, or domain validation offline.
Infrastructure as Code: Enterprise DNS providers support Terraform, CloudFormation, and API-driven record management, enabling version-controlled, auditable, and repeatable DNS configuration. This is essential for compliance, disaster recovery, and change management.
3. Domain Registration Security
Domain registration is the root of the trust chain. Compromise of a registrar account can override every other security control. The following requirements are mandatory for all organizational domains.
3.1 Registrar Account Security Requirements
Control | Requirement | Priority |
Multi-Factor Authentication | Hardware security key (FIDO2/WebAuthn) required. TOTP acceptable as fallback. SMS-based MFA is not acceptable. | CRITICAL |
Registrar Lock | Enable registrar lock (clientTransferProhibited) on all domains to prevent unauthorized transfers. | CRITICAL |
Registry Lock | For primary business domains, enable registry-level lock where supported. Requires out-of-band verification for changes. | HIGH |
Account Recovery | Security questions, backup PINs, and recovery procedures must be documented and stored in a secure vault. | HIGH |
WHOIS/RDAP Privacy | Enable privacy protection. Administrative contact information should reference a role-based email, not an individual. | MEDIUM |
Renewal Management | Enable auto-renewal. Maintain multi-year registrations for critical domains. Monitor expiration with automated alerts. | HIGH |
4. Domain-Based Trust and Identity
Modern domains serve as the root of trust for identity federation, service-to-service authentication, and organizational verification. A compromised domain undermines every system that relies on domain-based trust validation.
4.1 The Domain as a Trust Anchor
The following table maps the critical functions that depend on domain integrity. Each represents a potential attack vector if domain control is lost.
Function | DNS Dependency | Compromise Impact |
Brand Presence | A/AAAA records, CNAME for CDN | Website defacement, phishing redirection, brand impersonation |
Email Routing | MX records | Email interception, business email compromise (BEC), data exfiltration |
Email Authentication | SPF (TXT), DKIM (TXT), DMARC (TXT) | Email spoofing at scale, phishing campaigns impersonating the organization |
SSO / SAML Federation | Domain verification TXT records, federation metadata endpoints | Identity provider impersonation, unauthorized access to all federated applications |
OIDC / OAuth Flows | Redirect URI validation via domain, well-known endpoints | Token theft, authorization code interception, session hijacking |
TLS Certificate Issuance | CAA records, DNS-01 ACME challenges | Fraudulent certificate issuance enabling man-in-the-middle attacks |
Service Verification | TXT records for Google, Microsoft, Salesforce, etc. | Takeover of SaaS tenant verification, shadow IT enablement |
Zero Trust / Device Trust | DNS-based service discovery, mTLS endpoint resolution | Bypass of conditional access policies, device trust chain corruption |
DMARC Reporting | DMARC RUA/RUF TXT records | Loss of email authentication visibility, inability to detect spoofing |
BIMI (Brand Indicators) | BIMI TXT records, VMC certificate references | Brand impersonation in email clients displaying verified logos |
5. SSO, SAML, and Identity Federation Security
Single Sign-On (SSO) and Security Assertion Markup Language (SAML) are among the most consequential systems that depend on domain trust. When an organization federates identity through SAML, OpenID Connect (OIDC), or similar protocols, the domain becomes the identity anchor for every user and every application in the federation.
5.1 How Domain Compromise Breaks Federation
SAML Federation: SAML identity providers (IdPs) such as Microsoft Entra ID, Okta, and Google Workspace publish federation metadata at well-known domain-based URLs. Service providers (SPs) validate SAML assertions by verifying the signing certificate referenced in the IdP metadata. If an attacker controls the domain, they can publish fraudulent metadata, substitute their own signing certificate, and forge SAML assertions granting access to any relying party.
OIDC / OAuth 2.0: OpenID Connect discovery relies on the .well-known/openid-configuration endpoint hosted on the IdP domain. The authorization server’s issuer, token endpoint, and JWKS URI are all domain-based. Domain compromise allows an attacker to redirect authorization flows, intercept tokens, and impersonate the authorization server.
Domain Verification for Tenant Binding: Cloud identity platforms (Entra ID, Google Workspace, Okta) require domain ownership verification via DNS TXT records before allowing the domain to be used for SSO. If an attacker can modify DNS TXT records, they can verify the domain against a rogue tenant and effectively hijack the identity infrastructure.
FEDERATION TRUST CHAIN Domain Registration → DNS Control → Domain Verification (TXT Record) → IdP Tenant Binding → SAML/OIDC Metadata Publication → SP Trust Configuration → User Authentication. Every link in this chain depends on domain integrity. A break at the DNS layer compromises everything downstream. |
5.2 Federation Security Requirements
Requirement | Implementation Detail |
Domain Verification Monitoring | Monitor DNS TXT records for unauthorized changes to domain verification tokens. Alert on any modification to Microsoft, Google, or Okta verification records. Implement DNSSEC to prevent spoofing of verification records. |
IdP Metadata Pinning | Service providers should pin the IdP signing certificate or metadata URL rather than dynamically fetching it. Implement certificate rollover procedures with manual verification steps. |
SAML Assertion Validation | Enforce audience restriction, recipient validation, and assertion lifetime checks. Reject assertions with overly broad audience URIs or missing InResponseTo fields. |
OIDC Issuer Validation | Strictly validate the issuer claim in ID tokens against the expected domain. Implement JWKS key rotation monitoring and alert on unexpected key changes. |
Conditional Access Integration | Bind conditional access policies to verified domains. Require device compliance, network location, and risk-based authentication signals in addition to federation trust. |
Federation Metadata Backup | Maintain offline backups of IdP federation metadata and signing certificates. In a domain compromise scenario, these backups enable rapid re-establishment of trust without depending on DNS. |
Cross-Tenant Access Policies | For Microsoft Entra ID, configure cross-tenant access settings to restrict which external organizations can establish federation trust. Deny by default and allow by exception. |
6. Email Authentication and Anti-Spoofing
Email authentication records are among the most critical DNS entries an organization maintains. They are the primary defense against business email compromise, phishing, and brand impersonation.
6.1 Required DNS Records for Email Security
Protocol | DNS Record | Purpose |
SPF | TXT record listing authorized mail senders by IP and include mechanism | Prevents unauthorized servers from sending email as your domain |
DKIM | TXT record(s) containing public key for cryptographic email signing | Verifies email integrity and authenticity via digital signature |
DMARC | TXT record at _dmarc subdomain specifying policy (none, quarantine, reject) and reporting URIs | Instructs receiving servers how to handle SPF/DKIM failures; provides aggregate and forensic reporting |
BIMI | TXT record at default._bimi subdomain referencing SVG logo and optional VMC certificate | Displays verified brand logo in supporting email clients, increasing trust and recognition |
MTA-STS | TXT record at _mta-sts subdomain plus HTTPS-hosted policy file | Enforces TLS encryption for inbound mail, preventing downgrade attacks |
DANE/TLSA | TLSA records binding mail server certificates to DNS (requires DNSSEC) | Provides certificate pinning for mail transport, eliminating reliance on public CA trust |
6.2 DMARC Policy Progression
Organizations should implement DMARC progressively, moving from monitoring to enforcement over a defined timeline. Begin with p=none to collect reports, advance to p=quarantine after verifying all legitimate senders, and ultimately enforce p=reject. The target state is p=reject with rua and ruf reporting enabled and 100% alignment.
7. TLS Certificate Trust and DNS Validation
DNS plays a central role in TLS certificate issuance and validation. Certificate Authorities (CAs) rely on domain control validation, most commonly via DNS records, to verify that a requestor has authority over a domain before issuing a certificate.
7.1 Certificate Authority Authorization (CAA)
CAA records specify which Certificate Authorities are permitted to issue certificates for a domain. Without CAA records, any CA can issue a certificate for your domain if an attacker can pass domain validation. Organizations must publish CAA records listing only their authorized CA(s) and include an iodef tag for violation reporting.
7.2 ACME DNS-01 Challenge Security
Automated Certificate Management Environment (ACME) protocols, used by Let’s Encrypt and other CAs, support DNS-01 challenges where a specific TXT record proves domain control. If an attacker gains write access to DNS, they can complete an ACME challenge and obtain a valid, publicly trusted TLS certificate for the organization’s domain, enabling man-in-the-middle attacks that are invisible to end users.
7.3 DNSSEC Requirements
DNS Security Extensions (DNSSEC) cryptographically signs DNS responses, preventing cache poisoning and response manipulation. DNSSEC is required for organizations implementing DANE/TLSA for mail transport security and is strongly recommended for all domains. DNSSEC protects the integrity of every DNS-based trust validation mechanism described in this policy.
8. Supply Chain Risk and Threat Landscape
Domain and DNS compromise sits at the intersection of multiple attack taxonomies. Unlike application-layer attacks that affect a single system, domain compromise is a supply chain attack that cascades across every system trusting the domain.
8.1 Threat Scenarios
Threat | Attack Method | Business Impact |
Registrar Account Takeover | Credential stuffing, SIM swap for SMS MFA, social engineering of registrar support | Complete domain control loss; attacker redirects all services, issues certificates, hijacks SSO |
DNS Hijacking | Compromised DNS provider credentials, BGP hijacking of DNS provider prefixes | Transparent interception of web traffic, email, and API calls; undetectable by end users |
Subdomain Takeover | Dangling CNAME records pointing to deprovisioned cloud resources (S3, Azure, Heroku) | Attacker claims the cloud resource and serves content on the organization’s subdomain; enables phishing and cookie theft |
Domain Verification Hijack | Temporary DNS control used to verify domain in attacker-controlled SaaS tenant | Attacker establishes SSO federation, creates accounts, and gains persistent access even after DNS is restored |
Expired Domain Re-registration | Monitoring and registering lapsed domains still referenced in SPF, DKIM, or CNAME records | Attacker receives email intended for the organization or passes SPF checks to spoof email from the domain |
Cache Poisoning | Exploiting DNS resolvers to inject fraudulent records without compromising authoritative servers | Targeted redirection of users or services to attacker-controlled infrastructure; mitigated by DNSSEC |
8.2 Third-Party DNS Delegation Risks
Web Hosts: Web hosting providers are the most common requestors of DNS delegation. They frame this as a convenience, but it is self-serving, as it reduces their support overhead while transferring risk to the customer. A compromised web host with DNS control can redirect email, disable email authentication, issue certificates, and modify service verification records. No web host, regardless of size, maintains the security posture of AWS, Azure, Google Cloud, or Cloudflare for DNS operations.
SaaS Platforms: Many SaaS applications require DNS record creation for domain verification, custom domains, or email routing. These records should be created on the dedicated DNS provider and should never require delegation of the entire zone. Any SaaS vendor that requires full DNS delegation rather than specific record creation should be considered a risk.
9. DNS Monitoring and Incident Response
9.1 Continuous Monitoring Requirements
Organizations must implement monitoring for DNS changes, domain expiration, certificate issuance, and subdomain integrity. The following monitoring capabilities are required:
Monitoring Area | Implementation | Alert Threshold |
DNS Record Changes | API-driven polling or webhook integration with DNS provider; compare against known-good baseline | Any unauthorized change; immediate alert |
Certificate Transparency Logs | Monitor CT logs for certificates issued for organizational domains using tools such as certspotter or crt.sh | Any certificate from unauthorized CA |
Domain Expiration | Automated monitoring of WHOIS/RDAP expiration dates with 90/60/30-day alerts | 90 days before expiration |
Subdomain Inventory | Regular enumeration of subdomains; validate all CNAME targets resolve to active resources | Dangling CNAME detection; weekly scan |
DMARC Reporting | Aggregate (RUA) and forensic (RUF) report processing via a DMARC analytics platform | SPF/DKIM failure rate exceeding baseline |
Registrar Account Activity | Enable login notifications and change alerts on registrar accounts | Any login from unrecognized IP or device |
9.2 Domain Compromise Response Playbook
In the event of confirmed or suspected domain compromise, the following response actions must be executed immediately and in order:
Phase | Actions |
1. Contain | Lock the registrar account. Enable emergency registrar lock. Change all credentials associated with DNS provider and registrar accounts. Revoke API keys. |
2. Assess | Identify all records modified. Check Certificate Transparency logs for unauthorized certificate issuance. Review SAML/OIDC metadata endpoints for tampering. Verify domain verification TXT records across all SaaS platforms. |
3. Remediate | Restore DNS records from known-good backup. Rotate DKIM keys. Update SAML IdP signing certificates and republish metadata. Revoke any fraudulently issued TLS certificates. Notify federated service providers. |
4. Communicate | Notify affected partners and customers. File abuse reports with the relevant registrar and CA. Engage legal counsel regarding potential fraud or data breach notification obligations. |
5. Harden | Implement registry lock. Upgrade to FIDO2 MFA on registrar. Deploy DNSSEC if not already active. Conduct post-incident review and update this policy as needed. |
10. Compliance and Governance
10.1 Policy Applicability
This policy applies to all domains registered by or on behalf of the organization, including primary corporate domains, product and service domains, marketing and campaign domains, internal-use and development domains, and any domain used for email sending, SSO federation, or service verification.
10.2 Roles and Responsibilities
Role | Responsibility |
Information Security | Policy ownership, risk assessments, monitoring oversight, incident response coordination |
IT Operations / MSP | DNS record management, registrar account administration, DNSSEC deployment, monitoring implementation |
Identity & Access Management | Federation configuration, SAML/OIDC metadata management, domain verification for IdP tenants |
Legal / Compliance | Domain portfolio management, trademark protection, breach notification, regulatory compliance |
Executive Sponsor | Risk acceptance for policy exceptions, budget approval for security tooling, escalation authority |
10.3 Review and Audit
This policy shall be reviewed annually or following any domain security incident. DNS configurations shall be audited quarterly against the approved baseline. Registrar account security controls shall be verified semi-annually. DMARC enforcement status and reporting shall be reviewed monthly. Federation metadata and domain verification records shall be validated quarterly.
11. Summary of Recommendations
BCSF RECOMMENDATION All organizations should maintain DNS control on a dedicated, enterprise-grade provider separate from their web host, mail host, and registrar. Domains are no longer just addresses. They are the trust foundation for identity, authentication, encryption, and brand integrity. Treat domain security with the same rigor applied to your identity provider and certificate infrastructure, because they are inseparable. |
This document supersedes all prior versions of the Domain Name System policy. Questions regarding interpretation or exception requests should be directed to Information Security.