The suggestion immediately exploded in my brain and I realized that I had been overthinking this for years.
A scoped label in DNS, like _tcp or _udp, are case insensitive and we see them in SRV and NAPTR records for use in SIP, VOIP and ENUM applications, load balancing, not to mention in TXT records for DKIM and DomainKeys.
Pretty well any valid DNS label, like _lud16 or _btc, provides us with a mechanism to confine a response to a query matching the scope, under the parent node in the DNS tree.
Meaning:
$ORIGIN example.com.
_eg.test IN TXT “this is a separate test”
A DNS query for type TXT on “test.example.com” will not return an answer (NXDOMAIN).
A DNS query for type TXT on “_ie.test.example.com” will only return a result for the first record.
A DNS query for type TXT on “test._ie.example.com” will only return the second record.
In other words, we have multiple TXT records for the test.example.com leaf, however, we will only return the one queried with the scoped label, the one that begins with an underscore.
It turns out this is quite powerful for our purposes. It is also the easiest, optimal solution in our use case because:
Everybody can use it.
It’s a format people easily recognize.
It can be retrofitted onto any existing email address via DNS.
It provides the ability for a json record to exist someplace other than the server (like how an MX record functions).
Can provide any kind of payload.
Can work across all blockchains.
How Underscore Scoping Could Be Used In Blockchains
By taking the email address format used in Lightning Addresses: , we can use the convention via the DNS to specify all kinds of endpoints for the same identity:
$ORIGIN bombthrower.com.https://my.ln-node/.well-known/lnurlp/markjr “
We can get there from here without breaking anything already in place:
Applications already using LNURL address can always keep using that
Applications can add the DNS lookup
But DNS Is Centralized!
It’s true that DNS has an inverted tree structure that terminates at the root “.”. But even that root is fairly decentralized, comprising thousands of servers operated by at least 13 disparate operators. The legacy DNS may be logically centralized but in reality functions more like a decentralized federation of sorts.
Even this is changing, evolving. I think where we eventually end up is where namespaces straddle both the existing inverted tree root and fully decentralized blockchains.
Some of this is already here today: you could use something like Stacks and .btc domains which pins to Bitcoin and there will probably be other namespaces built directly atop Bitcoin.
Not all decentralized namespaces have legacy DNS resolvers, but that will change too. There is also work being done on a new DNSresolvers implementation which will resolve Stacks, .btc, and HNS domains by Handshake, and Unstoppable top-level domains. You can test it via lookups to alpha.dnsresolvers.com:
% dig +short easydns.btc @alpha.dnsresolvers.com
3.14.49.122
(This server is proof-of-concept and will go away in the future, please don’t add it
All This, And It Solves The Fake Twitter Handle Problem Too!
Once we make it a convention to use underscore scoping, we find we can solve all manner of problems using existing methods.
Let’s look at the fake Twitter handle problem that plagues the Bitcoin space.
The data structure of a Twitter user looks like this:
With underscore scoping we can assert the true Twitter handle from the hostname in the url element using the following convention:
$ORIGIN bombthrower.com.
stuntpope._twitter IN TXT “StuntPope”
*._twitter IN TXT “fake”
On its own, this doesn’t do anything. Nobody is going to open up a terminal window and type:
“dig -t TXT +short stuntpope._twitter.bombthrower.com”
… to find out if the person DMing you, “How is your trading going today?” is really me, or one of the legions of StuntPope imposters out there on Twitter. (I’m kidding of course, nobody in their right mind would impersonate me. But for a lot of the fintwit luminaries, this is a real problem.)
But what can happen if this becomes the convention, is developers can build quick and dirty hooks into their apps to do these lookups.
When a fake Twitter profile impersonates someone, they typically copy all the data verbatim, including the hostname in the URL field of the Twitter profile. If the real user has the records outlined above, then the convention of looking up the fake Twitter handle at the real URL will miss the actual _twitter TXT record for the real profile, and hit the wildcard record, causing a mismatch.
We’ve released a proof-of-concept Chrome extension through the easyDNS Github , which does just that with three modes:
A) No information asserted;
B) The profile matches the information asserted;
C) The profile does not match the information asserted (it’s a fake).
All this and more, can be done using very simple conventions in a ubiquitous protocol that’s already deployed.
Conclusion
Wallet addresses lend themselves to needing some kind of naming mechanism. There are multiple use cases where the need to securely assert an address from an identity takes precedence over pseudonymity or anonymity.
Further, to use human-readable labels or identifiers, we need an abstraction layer that provides flexibility and a format that is easily recognizable.
Finally, we can achieve all this using the DNS, which already underpins the technical infrastructure of the internet, is already a decentralized federation and on its way to anchoring on decentralized Layer 1 protocols. We can do so without adding any new record types or making any protocol additions to the existing specifications.
This is a guest post by Mark Jeftovic. Opinions expressed are entirely their own and do not necessarily reflect those of BTC Inc or Bitcoin Magazine .
