Recently, an article I wrote for Bitcoin Magazine explained how we can use DNS underscore scope to better summarize lightning addresses and even create a de facto spec that could work on any resource (like a wallet or smart contract) across all blockchains.
The TL; DR was simply to reference the desired resource using the underscore scope in the DNS labels in the TXT records:
$ORIGIN bombthrower.com. _lud16.markjr IN TXT "https://ln-node/.well-known/lnurlp/markjr" _btc.markjr IN TXT "bc1qu059yx6ygg9e6tgedktlsndm56jrckyf3waszl" _ens.markjr IN TXT "0xEbE7CcC5A0D656AD3A153AFA3d543160B2E9EdFb"
There has long been confusion about whether underscores are allowed in DNS, and the short answer is: they are, provided you differentiate between hostnames, domains, and labels correctly.
But anyone who’s ever worked with SRV records is used to emphasizing scope; we see them all the time to specify protocols (_tcp versus. _udp) or services like _xmppin fact, they can be freeform, any alphanumeric label, and they can appear on the left side of TXT records, they are not limited to use in SRV records.
When I was finishing the Bitcoin Magazine article, I concluded after the fact that you could use a similar convention to solve “The Fake Twitter” problem that has plagued Bitcoin and crypto luminaries for centuries.
The Fake Twitter Scam
Criminals create Twitter profiles that copy the original profile in every aspect, but are slightly different in the Twitter handle, similar to a homoglyph or typo attack on a domain name. Then they send private messages to the followers of the original nickname, or people who interact with the original nickname, and try to engage them in a conversation and lure them into a business scam.
Since these scammers usually copy every aspect of the original handle, from the background and profile images to the profile URL of the Twitter account, we have the ability to affirm the true handle via DNS for the domain in the URL field:
We do this through of them delimited TXT records, one to assert the true Twitter ID of the account, and the other is a wildcard to catch any misfires any fake account would generate:
$ORIGIN bombthrower.com. stuntpope._twitter IN TXT "StuntPope" *._twitter IN TXT "null"
In this case, we reverse the order of the handle name and scope type so that we can make everything else generic for these failures.
We do not expect people receiving “How’s your trading going today?” through their DMs to open a shell and type…
$ dig +short -t txt stuntpope._twitter.bombthrower.com "StuntPope"
But if it became a convention to add those TXT records to your area, then those searches could be integrated into Web3 clients, social media dashboards, even Twitter itself, if they were so inclined to do it. solve this issue.
We’ve released proof-of-concept code for a Chrome extension via our Github (if you’re an email admin, you can also check out the Postfix Policy Manager we released earlier this year).
Can’t scammers just use a fake domain name in the URL field?
They certainly can. We have the same problem in the domain/hosting world when spammers or phishers register similar domains and then obtain TLS certificates. for the realm of look-alikes – it’s an arms race and something we focus on at our Domainsure Platform—for critical and sensitive domain names (think crypto exchanges).
But do this imposes a cost on running this variant of the scam, and once you go from no cost to cost, the dynamics and economics of running these scams change dramatically.
What this offers is nothing exclusive, and there’s no secret sauce involved. We simply offer a agreement or a best practice that uses something that already underpins the entire internet (DNS). If successful, we could eliminate one of the most toxic sources of noise on Twitter and social media platforms in general.