[c4mpute]

Domain validation TXT records are poor infosec hygiene. If used at all, those records should never include any hint as to what service they are intended for.

E.g. the record should NOT be:

example.com IN TXT "someservice.com-validation=029845yn0sidng0345randomnyosndgf03548yn"

instead, it should be something like

example.com IN TXT "029845yn0sidng0345randomnyosndgf03548yn"

Of course there will be multiple such records for different service providers. The service providers will just have to check all those (handful) of TXT records for the random assigned token in their database instead of pre-filtering them by the someservice.com-validation prefix.

As jelavich pointed out, there is also https://www.ietf.org/archive/id/draft-ietf-dnsop-domain-veri... which suggests another improvement on that. To avoid polluting the example.com name with tons of TXT records and to avoid problems with CNAME records and such, those records should be further down in the tree like

_validation_mv0395ng035.example.com IN TXT "029845yn0sidng0345randomnyosndgf03548yn"

The record name token "mv0395ng035" could either be another random number assigned to example.com by someservice.com they just put in their database. Or it could be something like HMAC(example.com, <common secret known to someservice.com>), so they don't have to save all those tokens. In any case, the check will be just one DNS lookup, one comparison and done. Quicker, equally easy and more privacy-preserving and infosec-hygienic.

[agwa]

The problem with opaque records like "029845yn0sidng0345randomnyosndgf03548yn" is that you have zero clue what it's authorizing, making it impossible to audit your DNS records to ensure that you're only authorizing what you want to be authorizing.

And what do opaque records gain you anyways? Security by obscurity is not real security, and it's often possible to determine a domain's service providers by other means, such as CNAME/MX records, or by scanning the website for <script> tags.

Ideally, domain validation records would be of the form ACCOUNT_ID@SERVICEPROVIDER so you can know exactly what the record is authorizing.

[snowwrestler]

To make this explicit: maintaining accurate DNS configuration is extremely important to enterprise security and availability.

Allowing outdated DNS entries to persist can open up all sorts of horrible opportunities for impersonation, phishing, etc.

At the same time, removing a DNS entry that you still need can cause massive downtime.

So anything that makes it easier for ops teams to observe and maintain DNS (in whatever ugly way available) is probably a security win in the long run.

[gray_-_wolf]

> The problem with opaque records like "029845yn0sidng0345randomnyosndgf03548yn" is that you have zero clue what it's authorizing,

I would have hoped the DNS management is automated and IaC-ed, so you just check the relevant commit message.

[derefr]

> making it impossible to audit your DNS records

Every DNS provider I've used in recent memory, has offered a non-authoritative / non-DNS-exposed "comment" or "description" field for each record. Even if you aren't doing "DNS infrastructure as code" but just editing DNS records in a UI dashboard, you can just use these fields to describe the motivation behind each record at creation time.

[c4mpute]

Even stupid age-old BIND zone files can be version controlled and commented. Anything inferior to that level of documentability should be an instant no-no.

[tallanvor]

Domain verification should typically be a one-time or at least rare event. You shouldn't have to keep the txt records after the verification is completed.

[jabart]

You can also look up common cnames or historical DNS records which would always point back to the vendor. For instance, do they use sendgrid, look for a bounce. record that points to sendgrid's servers. Do they use Facebook, well if they have a Facebook page that is verified yes. I would assume that Docusign and Attlasian also list Stripe as one of their customers on their website as well. Public TXT records are not that big of a deal.

[brightball]

There are two sides to this issue.

On one hand, the InfoSec side where you want to hide info. On the other side, the service provider doing the validation WANTS to advertise their service on these DNS records so they are disincentivized to make the changes you’re suggesting.

[katsura]

If you are using TXT records like "029845yn0sidng0345randomnyosndgf03548yn" then how do you know which one to delete once you are not using that service? Do you just go back and forth between different services to find the one (some services only show this while you are in a validation phase, so finding them later might be a pain), or do you just leave them around?

[jabroni_salad]

Ops guy... These days cloudflare allows you to put comments directly into their service, but for a long time I would just export the zonefile and annotate that. There is a KB article somewhere in jira that will tell you what stuff is. I can also summon the ticket history to see what changes were made and why.

[organsnyder]

Hopefully you're managing DNS as code, so you have a repo commit log that can give you that context.

[djbusby]

Keep a log of every record added and why it was added. When making any DNS changes review the log as well.

[snowwrestler]

This type of “hygiene” is pointless; it does nothing but provide a tiny amount of obscurity, which is easily pierced in other ways.

It’s not hard to figure out what services a company is using, and most of these services requiring verification are so ubiquitous that confirming the knowledge adds no marginal utility to attackers. “Oh wow, this SaaS company has verified with Atlassian and Google, who could have guessed.”

[c4mpute]

This kind of thing is pointless against a targeted attack. But it can hide you long enough in case of zero-days/fresh unpatched vulnerabilities because attackers will first target the more easily visible victims.