Security finding
A DNS record points at a service that no longer answers, or mail records contradict each other
Security Error Severity: High
Part of the audit DNS points at things that are gone or unlisted. Finding id: security.dnsVsServices.
What it costs you
A DNS record says something that is no longer true, and others act on it.
What to do
Delete records for services that are gone. Keep SPF as strict as the DMARC policy that relies on it.
What it checks
- Record points to unclaimed cloud resource
- Mail record points to dead host
- Strict DMARC with permissive mail policy
How to fix it
Remove the record that points at the deleted resource
- Delete the CNAME of [host] at the DNS provider now.
- If the service is still needed, create the resource again first and check you hold the exact name [target].
- From now on, delete the DNS record in the same change that cancels a service.
How to check: dig +short [host] (expect no answer for a deleted CNAME)
Correct the MX record
- Point the MX record of [host] at the mail host you use today.
- If the name receives no mail, delete the record.
How to check: dig +short MX [host]
Tighten the SPF record
- End the SPF record of [host] in -all.
- List only the systems that send your mail.
How to check: dig +short TXT [host] | grep -i spf1
A real case
Researchers found about 8,800 domains and over 13,000 subdomains of brands such as MSN, VMware and McAfee sending about five million spam emails a day in the brands' names, because DNS and SPF records had outlived the services they pointed to.
How to verify by hand
The DNS and mail provider consoles.
What this relies on
Records outlive the services they were created for.