Recently, an article I wrote for Bitcoin Magazine talked about how we can use DNS underscore scoping to better abstract Lightning addresses and even create a de facto specification that could work on any resource (like a wallet or a smart contract) across all blockchains.
The TL,DR there was to simply reference the resource you want using underscore scoping in DNS labels within 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 whether underscores are allowed in DNS and the short answer there is: they are, provided you are correctly differentiating between hostnames, domains and labels.
But anybody who has ever worked with SRV records is already used to underscore scoping, we see them all the time to specify protocols (_tcp vs _udp) or services like _xmpp, in fact they can be free form, any alphanumeric label, and they can appear on the left-hand-side of TXT records, they aren’t confined to use in SRV recs.
When I was wrapping up the Bitcoin Magazine article, I concluded with an afterthought – that you could use a similar convention to solve “The Fake Twitter” problem that has been the scourge of Bitcoin and crypto luminaries for ages.
The Fake Twitter Handle Scam
Criminals set up Twitter profiles that copy the original profile in all aspects, but are slightly different in the Twitter handle, similar to a homoglyph or typo attack against a domain name. Then they private message followers of the original handle, or people who are interacting with the original handle, and try to engage them in conversation and lure them into some trading scam.
Because these scammers typically copy every aspect of the original handle, from background and profile images down to the URL in the Twitter account’s profile, we have an opportunity to assert the real handle via DNS for the domain in the URL field:
We do this via two scoped TXT records, one to assert the real Twitter handle for the account, the other is a wildcard to catch all the misses that any fake accounts would generate:
$ORIGIN bombthrower.com. stuntpope._twitter IN TXT “StuntPope” *._twitter IN TXT “null”
In this case we’re reversing the order of the handle name and the scoped type so that we can wildcard everything else for those misses.
We don’t expect people receiving “How is your trading going today?” via their DMs to open up 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 zone, then these lookups could be integrated into Web3 clients, social media dashboards, even into Twitter itself, were they so inclined to actually solve this problem
Can’t scammers simply use a fake domain name in the URL field?
They sure can. We have the same problem in the domain / hosting world when spammers or phishers register look-alike domains, and then get TLS certificates issed for the look-alike domain – it’s an arms race and something we focus on over at our Domainsure platform – for mission critical and sensitive domain names (think, crypto exchanges).
But doing that imposes a cost on running that variation of the scam, and once you’ve gone from no-cost to cost, the dynamics and economics of running these scams changes immensely.
What this proposes isn’t anything proprietary and there’s no secret sauce involved. We’re simply proposing a convention or a best practice that uses something that already underpins the entire Internet (the DNS). Were it to achieve traction we could eliminate one of the more toxic sources of noise on Twitter and social media platforms in general.