Putting DNS A Records On-Chain, Handshake Improvement Proposal 18, codename ReRecord
As we approach our fourth HandyCon this March 13-15, 2024, as always, get the pleasure to connect and network with various movers and shakers in HNS.
While in a conversation with Andrew Lee, the King of Joseon, who will be presenting at HandyCon this year (his first appearance!), he mentioned what he felt was the biggest “mistake” that Handshake protocol has made :
Not allowing A , AAAA records to be set on the TLD at the protocol level (on-chain).
Meaning, the only way to set a IP address to the TLD domain on Handshake, one has to point to / refer to a third party NS (Name server). But by allowing people to set their own A AAAA record IP address on-chain it would allow for more domains to be quickly setup and used - without needing to setup your own name server or trust someone else’s service.
You may be saying “huh”?
If you look at the blockchain records you as a HNS TLD owner have - they currently are:
DS, NS, GLUE4, GLUE6, SYNTH4, SYNTH6, TXT
Those who often look at Cloudflare, Godaddy, Namecheap, and other DNS settings, they have more robust options such as:
A, CNAME, MX, TXT
These are not included on HNS blockchain, to keep the chain more like ICANN TLD root zone only, and then each TLD owner points to their own SLD / Domain / hosting solution (on-chain in ETH, COSMOS, or off-chain like normal domains)
So essentially - adding this to your Bob Wallet / Namebase On-chain record options
For Bob Wallet it would be
I was intrigued by this conversation, and asked him where I could learn more about this discussion and ultimate decision to not have A records on chain - and he sent me this, which is worth a read.
Investigating What It Would Take to “Reconsider” , “Rerecord”ing
And diving deeper into a group discussion about this, in the earlier days of Handshake it was built to integrate with DNS and not have on-chain data like this for scalability and other reasons.
But the majority of the community now sees HNS on its own - for better or for worse - and more of an identity than trying to integrate w/ ICANN - as it seems apparent ICANN is aware of HNS and has no intention to integrate (4 years would show this, with reports issued by them, and their 2026 TLD process opening).
So back to the story - I took this inspiration from Andrew and started asking some of my core devs in the community - Rithvik and Matt Zipkin. I was worried (but prepared) this would require a soft fork, or worse yet, a hard fork, to implement. But I was sold on the idea that allowing users to have a “quick and dirty” was to point their bare TLD to a IP address to host a site is very practical.
Why? The Pros Of This Proposal
- Gives more immediate utility to the HNS TLD name - I have to be frank here, I do use and appreciate Sinpappeles and Varo Domains for making Name server services available to me and the community. But it is another barrier to me as a creator to have to point to their name server, wait for a merkle tree update (6 hours approx) - and no offense to them - but I would rather not have to trust and rely on their servers staying online to maintain my site DNS. By allowing a simple A Record on-chain I can point a landing page to the TLD. Many have been asking for DLinks service to come back - and Nathan Woodburn made one - but the first popup is to login wit Varo - which means I need to set my name servers for small TLD names I’d like to setup a mini site for - and I’d rather just point at the A record on-chain once and be done with it.
- Feels more decentralized - one could argue still using an IP address / A record - but the name itself is immutable on the HNS POW blockchain. If the IP address goes down, the name remains and I would simply update the IP, and wait for it to update On-chain.
- Gives miners more fees - simply waiting for HNS to have renewals (heart beat transactions every 2 years from the TLD) is not enough. Allowing users to set records on-chain gives miners more fees, more transaction, and more health. Some have pushed back on this - but one could say the same for Ordinals on the Bitcoin blockchain - love it or hate it- it generates revenue and usage on BTC. The same here for HNS.
MOST IMPORTANT
Some negatives
- Nodes would need to host more data - same as Ordinals on Bitcoin, the nodes would get bigger to store all this on-chain A-record date for those who opt in for it.
- Slower and more costly to update than using a third party Name Server (NS) - no argument there - is you are serious about building on your TLD and growing it - point it to a Name Server. But for those who want a quick proof of concept, use a fun TLD you won at auction as a landing page or username lander, this is a great solution (in my and most people I speak with’s opinion).
- What is the limit to types of data to store online - A record, AAAA record - what about MX record, CNAME, and many other records? Already we are talking about needing SSL / DANE - and TSLA records. How much should we allow and where does it stop? (But then the argument to this is - it is a fee market and those who want to pay will pay, those who want to save the fees - do a one time NS name server update on-chain and you’re on your way).
Some Unexpected Benefits
As I ponder this more, I have listened to the community in Handshake over the years - and many wanted to “bind” the content of the TLD with the transfer.
By having these records on-chain - when you sell / transfer the name - those records would remain (just like when you transfer a web2 domain and opt to keep the domain settings, same goes here).
So imagine you setup a website on the TLD and it is some artwork, you can then transfer that name to the new owner, they would have the same DNS settings when they receive it. Full disclosure, to update the IP address/ records, they would of course need to have access to that host - but there would be no interruption during the transfer process and the new owner could then update the A record to a host they control.
SkyInclude’s First HIP - HIP018 code name ReRecord
So with the help of many in the HNS community and HNS Dev chat - we are trying our best here to draft a HIP (Handshake Improvement Proposal), number 18 - which we have code named “ReRecord”
Feels great to have true influence on the direction of a blockchain, and this is how I feel it should be in crypto in general.
Why the code name “ReRecord”?
Was searching for TLDs to use - wanted Record in it - as it represents recording on-chain. The Re represents re-doing, re-reviewing, changing the past by allowing those in the future to record on the HNS blockchain.
And hey, it’s a nice TLD and easy to remember. And better than HIP018, and we will setup a lander on rerecord/ - and once this HIP018 is implemented, use that improvement to have an A Record to point to the landing page.
Read & Put Your Suggestions (Hopefully You Support!)
Would love you to head on over to the HIP018 (ReRecord) and show your support (hopefully) or your critiques.
link to HIP018 on GitHub:
Here's the Pull Request:
https://github.com/handshake-org/HIPs/pull/61
Here's the HIP018 draft:
https://github.com/skyinclude/HIPs/blob/HIP018-Adding-A-AAAA-Records/HIP-XXXX-adding-A-AAAA-records.md
We also setup a mini site for this
https://rerecord.skyinclude.com
And will be making a site on the bare TLD - https://rerecord/ as we develop this.
Question - How Many New Fields To Put On Chain? A, AAAA - more?
Be Open Minded to Adapt - This Makes The Chain Host More Records, But Also Gives More Immediate Utility
Curious what JJ will say on this - I know from his talks and his work he wants clean and simple - but the reality is have is - ICANN doesn’t seem to be embracing Handshake with open arms - 4 years proves that. We did the soft fork - probably upset them more with releasing name they wouldn’t have liked - now it is time to adjust our strategy.
Allowing the community to point to a hosting solution directly at the HNS blockchain drops a lot of the barrier of setting up decentralized websites - and to me they are even more decentralized having the A record on the HNS chain rather than centralized servers in some of our community friends spare closets (no offense to those friends closets!)
Rithvik’s Suggestion on How to Make This Happen
From Rithvik:
To make this happen somebody needs to:
- Write a detailed standard including what changes in Resource v0, if possible, how they are compressed, look into approx how many records can be added, see how
DNSSEC will work (required for DANE)
- Write code for HSD: Add new record types, tests that old v0 don't break, Update root ns to serve all the new records and make sure they are signed properly, make sure recursive resolver also works with it
- For HNSD: update Resource for new types, most of the changes to HSDto be re-done here also
- Update fingertip to use new hsd