DNS and Cloudflare Operations

Overview

DNS at Cirius Group is split across two systems depending on the domain:

Zone	Authoritative DNS	How to Manage
ciriusgroup.com (Cloudflare-fronted hostnames)	Cloudflare	Terraform via azure-infra (preferred) or Cloudflare dashboard
ciriusgroup.com (non-Cloudflare hostnames)	Cloudflare DNS (delegated from U2 Web registrar)	Terraform or Cloudflare dashboard
ciriusdde.com	TBD — check current state	Check Cloudflare or U2 Web
Internal / on-prem (*.ciriusgroup.internal)	Windows DNS (on-prem AD)	AD DNS console via Kevin/Greg
AWS VPC internal DNS	Route 53 Resolver (auto)	Terraform in aws-infra

Registrar: U2 Web — the nameservers are delegated to Cloudflare. Do not change nameservers at U2 Web without coordinating with Rory. Changing nameservers takes 24–48 hours to propagate and causes a full DNS outage for the zone during transition.

---

Cloudflare — Adding / Changing DNS Records

Preferred: Terraform

All Cloudflare DNS is managed as code. DNS records in Terraform are reviewed, version-controlled, and auditable.

# Example: Add a new A record in azure-infra Cloudflare Terraform
resource "cloudflare_record" "new_service" {
  zone_id = var.cloudflare_zone_id
  name    = "new-service"   # results in new-service.ciriusgroup.com
  type    = "A"
  value   = "10.20.5.100"
  ttl     = 300
  proxied = false           # true = traffic routes through Cloudflare CDN/WAF
}

proxied = true — traffic goes through Cloudflare (CDN, WAF, DDoS protection). Use for public-facing web services.
proxied = false — DNS-only. Cloudflare resolves to the real IP. Use for internal services, mail records (MX, DKIM), and anything that can't go through a proxy.

Workflow:

1. Add the record to the relevant .tf file in azure-infra
2. Open a PR — CI runs terraform plan showing the new record
3. Rory reviews and merges → record is created automatically

Manual: Cloudflare Dashboard

For urgent DNS changes that can't wait for a PR cycle:

1. Log into Cloudflare at https://dash.cloudflare.com
2. Credentials in Keeper → IT Operations → Cloudflare Admin
3. Select the ciriusgroup.com zone
4. DNS → Records → Add record
5. After the urgent fix, open a PR in azure-infra to bring the Terraform state in sync — otherwise the next terraform plan will show a drift and may revert the manual change

Important: Manual Cloudflare changes that aren't in Terraform will be overwritten on the next terraform apply. Always follow up with a Terraform PR.

---

Common DNS Record Types

Type	Use Case	Example
A	Maps hostname to IPv4	secops.bedrockcybersecurity.org → 10.20.5.100
CNAME	Alias to another hostname	www.ciriusgroup.com → ciriusgroup.com
MX	Mail exchanger for email routing	Priority 10 → ciriusgroup-com.mail.protection.outlook.com
TXT	SPF, DKIM, DMARC, domain verification	v=spf1 include:spf.protection.outlook.com -all
SRV	Service discovery (e.g., LDAP, SIP)	Used by on-prem AD DNS; not Cloudflare
PTR	Reverse DNS (IP → hostname)	Managed by Azure/AWS, not Cloudflare

---

Email DNS Records (Do Not Break These)

Email deliverability depends on these records being correct. Do not modify them without understanding the impact.

Record	Value	Purpose
@ MX	ciriusgroup-com.mail.protection.outlook.com (priority 10)	Routes email to M365
@ TXT (SPF)	v=spf1 include:spf.protection.outlook.com -all	Authorizes M365 to send as ciriusgroup.com
selector1._domainkey CNAME	Points to M365 DKIM selector	Email signing
selector2._domainkey CNAME	Points to M365 DKIM selector (rotation)	Email signing
_dmarc TXT	v=DMARC1; p=reject; rua=mailto:...	DMARC enforcement

Check these are intact:

dig MX ciriusgroup.com
dig TXT ciriusgroup.com
dig TXT selector1._domainkey.ciriusgroup.com
dig TXT _dmarc.ciriusgroup.com

If any of these are missing or wrong, email delivery from @ciriusgroup.com will fail or be marked spam. See DMARC Enforcement Plan.

---

Cloudflare WAF and Proxied Records

When proxied = true, traffic for that hostname routes through Cloudflare's edge before reaching the origin. This adds:

• WAF (Managed Ruleset enabled — OWASP-aligned rules)
• DDoS protection
• CDN caching
• SSL at the edge (Cloudflare issues the cert visitors see; origin uses a separate cert)

Currently proxied hostnames: dashboard.ciriusgroup.com (and others per Cloudflare integration plan).

Cloudflare Access (Zero Trust)

secops.bedrockcybersecurity.org is behind Cloudflare Access — users must authenticate before reaching the application. This is configured in:

• Cloudflare Dashboard → Zero Trust → Access → Applications
• Auth provider: OneLogin SAML

If someone can't reach SecOps and you've verified the Container App is running:

1. Cloudflare → Zero Trust → Access → Applications → secops.bedrockcybersecurity.org
2. Check the Access policy — is the user's email domain allowed?
3. Check the Identity Provider status (OneLogin → Cloudflare integration)

---

On-Premises DNS (Internal Hostnames)

Internal hostnames (*.ciriusgroup.internal, server names within the domain) are managed by Windows DNS on the domain controllers. Kevin and Greg manage this.

For operational reference:

• Windows DNS is integrated with Active Directory — most internal records are created automatically when machines join the domain
• To add a manual record: DNS Manager on the primary DC → Forward Lookup Zones → ciriusgroup.internal → New Host (A record)
• Internal DNS is not replicated to Cloudflare — internal names only resolve within the network (via Twingate or on-prem)

---

AWS DNS

AWS VPC internal DNS uses Route 53 Resolver. Each VPC has an automatic DNS server at the VPC CIDR +2 (e.g., 10.80.0.2 for vpc-aws-transit).

For internal AWS records (private hosted zones), these are managed in Terraform under aws-infra. Do not create Route 53 records manually — they won't be tracked.

# Check what's in a Route 53 hosted zone
aws route53 list-resource-record-sets \
  --hosted-zone-id <zone-id> \
  --profile networking \
  --output table

---

Troubleshooting DNS

Record Not Resolving After Creation

1. Check the TTL — new records may take up to the TTL value to propagate. Cloudflare-managed records default to 300s (5 minutes) or Auto.
2. Confirm the record exists in Cloudflare dashboard (not just in Terraform plan — check that the apply ran successfully)
3. Test resolution:

   # Force query against Cloudflare's nameserver directly
   dig @1.1.1.1 new-record.ciriusgroup.com
   
   # Check which nameservers are authoritative
   dig NS ciriusgroup.com

Old IP Cached (Propagation Lag)

# Flush your local DNS cache (Linux)
sudo systemd-resolve --flush-caches

# Check from a different DNS resolver
dig @8.8.8.8 hostname.ciriusgroup.com

Email Delivery Failures

If mail is bouncing or marked spam:

1. Check SPF: dig TXT ciriusgroup.com — must include spf.protection.outlook.com
2. Check DKIM: dig TXT selector1._domainkey.ciriusgroup.com — must return a key
3. Check DMARC: dig TXT _dmarc.ciriusgroup.com — must return v=DMARC1
4. Use MXToolbox or dmarcian for a full email deliverability check

Palo Alto DNS Security Blocking a Legitimate Domain

If Palo Alto DNS Security is blocking a domain that should be accessible:

1. Panorama → Monitor → Logs → Threat → filter for the blocked domain
2. Verify it's not actually malicious (check VirusTotal, Palo Alto threat intel)
3. If confirmed benign: add a DNS Security policy exception in Panorama (Policies → Security → DNS Security → Custom categories)
4. Coordinate with Rory before making exceptions

---

Related Documents

• Cloudflare Terraform Integration — full Cloudflare IaC setup
• DMARC Enforcement Plan — email authentication config
• Panorama Day-to-Day — Palo Alto DNS Security policy management
• Network Topology — IP ranges for DNS A record references

---

Document History

Date	Change	Author
May 2026	Initial draft — DNS split (Cloudflare/on-prem/AWS), Terraform vs manual changes, email records, Cloudflare WAF/Access, on-prem DNS, AWS Route 53, troubleshooting.	Rory