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.
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.
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.
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").
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.
As discussed elsewhere in this thread, domain validation needs to be frequently rechecked. Therefore, it's far more convenient to publish a DNS record than to manually sign messages out-of-band.
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.
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.
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.
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.
No, domain validation should be frequent, so that revoking authorization can take effect quickly, which is particularly important if the domain changes ownership.
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".
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.
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.
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?
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.
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.
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.”
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.
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.
TXT records are useful for OSINT. I've used them to tie together fake business listings on Google Maps. It also allowed me to tie the listings directly to the marketer responsible.
No blog post. But, since you and another have requested I'll just write a comment.
I work for a small, local, family company. I maintain the websites and do some of the marketing.
We've noticed an uptick in websites for fake businesses and fake business listings in our area/industry in the past 3-4 years. The goal is to generate leads which can be resold to local contractors--usually without the customer knowing. It's a scheme called "rank and rent."
A few months ago, I noticed a new listing in our area. I started digging into the SEO spam for it. There was a website, a couple of one-episode podcasts, social media profiles, business listings, PDF spam, and more.
Looking into the HTML source of the site, I discovered some JSON-LD for a completely different company. I looked up the company on Google Maps. Sure enough, there was a listing. And the website was using the same theme as the one I was digging into.
I decided to pull the DNS records. They both used the same Cloudflare NS. Not a smoking gun, but interesting. Then when I pulled the TXT records, I noticed both used the same IP for the SPF record. Bingo!
A quick cURL resolving the domains to the IP, and I had proof they were hosted on the same shared hosting server.
With the IP, I was able to do a reverse lookup for other sites hosted on the same server. This netted me several domains that also used the same theme and had Google Maps listings (GBP). The money result was several marketing firm domains.
One turned out to have a GBP. It had videos and photos the person used to verify the listing. Fortunately, it had the marketer speaking in the video as well. That voice sample allowed me to compare it to the podcasts mentioned above. Aside from him faking an accent, it was definitely the same guy. I've since discovered ~30 such podcasts for his different listings.
The other marketing domains were even more interesting. They were also run by the same guy. Again, verified via voice in a video on these sites. He used these websites to recruit people for "social media gigs." The gigs were setting up Google Business listings in their area. They'd setup a listing, get the postcard with a verification code, pass it off to the marketer, and he'd pay them $50-100.
The kicker was a Google form on the recruitment page. It asked if the person would be willing to leave 5-star reviews for businesses they'd never done business with for $20.
I went back to Google Maps and started bouncing through people who'd left reviews. That opened up a whole world of listings that I hadn't known about.
At present, I'm over 80 listings which can be tied back to him.
I've also identified several websites that don't have GBP listings yet thanks to the TXT records and reverse lookups.
I left a comment in the thread. Feel free to ask questions. Though, I'm cautious about giving too many details as I plan to report the guy to the AG in his state.
You just give it a domain like this: `pig example.com` and it spits out anything it can find about your DNS, including matching services for about 150 different common services.
Remember the recent Hacker News discussion, where you could send mails from 2 million domains through mailchannel? They got the number "2 million" through builtwith.com as you can see which domains use mailchannel. It's in the slides in the submission.
This actually really annoys me about AWS route53 private hosted zones. It makes perfect sense that a general-purpose ACME service can only query public DNS servers, but it doesn't make nearly as much sense when getting certificates through Amazon Certificate Manager. AWS clearly has the ability to hit private IPs in your VPC; otherwise, basic EC2 healthchecks would not be possible. Yet they require you to create a DNS record in a public hosted zone anyway. This becomes particularly annoying when you're operating in GovCloud because GovCloud doesn't offer public hosted zones at all, so your organization has to maintain a separate commercial account and create a public hosted zone there that acts as a second authoritative name server for your otherwise private domain. Then you run into an additional annoyance when using IaC tooling to provision certificates and DNS records because GovCloud and commercial IAM services are air-gapped from each other, so you can't use an assume role. Instead, whatever user account runs your IaC tool needs to keep separate AWS SDK profiles for GovCloud and Commercial and, assuming you want your IaC to be runnable by multiple users, you have to externally prescribe how these profiles are named.
There are so many levels of leaky abstraction here.
Amazon Certificate Manager issues publicly-trusted certificates, so they have to abide by the validation rules mandated by the Baseline Requirements, which do not permit what you desire.
CAs have often sought to bypass domain or CAA validation for domains which they believe are hosted with them, and this has repeatedly proven to be a bad idea because it relies on the CA to maintain accurate records about what domains are hosted with them. The source of truth for this information is in the public DNS, so it's more robust to require CAs to check public DNS records.
See for example the now-forbidden DNS Operator Exemption to CAA, which I advocated to be banned after Microsoft bypassed CAA checking for domains which they thought they controlled but really didn't: https://groups.google.com/g/mozilla.dev.security.policy/c/0T...
If your domains don't otherwise have public DNS records, maybe you should be using private certificates instead of publicly-trusted ones?
It's really nice to see a company with a cloud offering ... using a rivals cloud offering (yes, Oracle is large, AWS probably has Azure/Google-services, but it's fun :) )
Is it good hygiene to delete these records once they've served their purpose (i.e. validating control of the domain in question)? Or do these records server more than that use?
I think it's more about the opposite. If you are the new owner, you don't want the old owner to continue to have access to features connected to your new domain.
So as a new owner you would want to remove the tokens.
I've done this for https://www.nslookup.io. Downloaded a list of the 1 million most popular domain names, scraped TXT records for them, and mined common patterns to add formatting with logos to the TXT records section.
It doesn't tell you which Atlassian or Google products are used. Could be as simple as wanting access to Google Search Console, formerly Webmaster Tools, or wanting to publish an app to the Atlassian Marketplace. It doesn't mean they use Gmail or Jira.
It was early days (although TXT records have been around ‘forever’) but they were one of the indicators used by BackChannel to profile target companies, since reading them was minimally invasive and light on resources to do.
https://blog.eutopian.io/nsa-prisms-commercial-cousin/
There is a recent rule based python tool for doing DNS record based service dependency fingerprinting at https://github.com/joniumGit/dnsmule/. It was written as part of a master's thesis work for OUSPG at University of Oulu.
Hmm I thought the article was going to be about finding actual services companies, like plumbers/contractors/salons/lawyers. Anyone with ideas on how to sites owned by these services companies?
These TXT records are also commonly used for DNS amplification DoS. If you run a public resolver you probably have already noticed the constant influx of "TXT? cisco.com" sort of queries.
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.