[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.

[icedchai]

Keep hoping. Most orgs are updating their DNS through some awful web interface that often doesn't even have the ability to add a comment.

[singron]

The service could also MitM you. They give you a code that validates their account against a second service.

[remram]

Interesting point. I guess it would be possible to mask them, e.g. they give you the string "gitlab-123token123" and you set the TXT to hash("gitlab-123token123").

[agwa]

In a perfect world there would be a special DNS record type for this. The DNS server would store the full token value, but would return the hash when someone queries it. I think this would provide both maximum security and maximum privacy.

[c4mpute]

You could use your DNSSEC signing key to sign a validation message (offline, because that doesn't work over DNS).

[bawolff]

In real life,lots of companies infrastructure is an undocumented non-version controlled mess

[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.

[jorams]

> Every DNS provider I've used in recent memory, has offered a non-authoritative / non-DNS-exposed "comment" or "description" field for each record.

In my experience this is not at all common. I think I know of 3 that do, and I've used many more that don't.

[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.

[agwa]

That can help with the ongoing maintenance of your records, but doesn't help you when you're adding the record in the first place.

As pointed out by singron at https://news.ycombinator.com/item?id=38069760 a malicious service provider (SP1) could give you a DNS record that was really issued by a different service provider (SP2). When you publish the DNS record, you're actually authorizing SP1's account at SP2 to use your domain.

With non-opaque records, you can be sure of what you're publishing.

[c4mpute]

Ah, now I get it. Yes, that is a possible problem.

[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.

[agwa]

No, domain validation should be frequent, so that revoking authorization can take effect quickly, which is particularly important if the domain changes ownership.

[leni536]

It should be one-time, yes. Maybe it shouldn't be rare though. But your point still stands as the TXT records should be ephemeral. So I don't think this deserves the downvotes.

At least ACME's DNS challenge protocol is designed this way.

> The client SHOULD de-provision the resource record(s) provisioned for this challenge once the challenge is complete, i.e., once the "status" field of the challenge has the value "valid" or "invalid".

https://datatracker.ietf.org/doc/html/rfc8555#page-67

[3c6bYDXLMj]

That’s insane. Domains are not owned by the same entity forever.

[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.

[remram]

Those comments have a very short length limit (smaller than the records themselves) and I don't understand why.

[magicalhippo]

Simple, indirection to the rescue again! Just add an increasing number in the comment field and keep track of which number is which comment in an Excel sheet on SharePoint or similar.

And yes, I'm mostly joking.

[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.

[snowwrestler]

It’s pointless against a targeted attack, but it will help attackers target you? That doesn’t really make sense to me. Can you share an example?

[c4mpute]

If an attacker knows about some exploit involving someservice.com, which you are using. That attacker will try to find out where he can use that exploit of his. E.g. he might use something like shodan, google or DNS to get a list of users of someservice.com. Those potential victims that turn up in that list will get attacked first. Later on, if that list is used up, the attacker might then look at other means of getting new victims, like e.g. just trying out the exploit on targets where he doesn't know they are vulnerable. So in that case, not being "visible" to an attacker buys you time to fix the vulnerability.

On the other hand, if you are on the attacker's hotlist, he'll try you first and you gain nothing.