Add support to more DNS types

[Falci]

The goal here is to collect opinions around the idea of adding more DNS record types on chain.

I'd like to start pointing out that the current implementation is versioned. It seems like the authors were expecting it to be updated.

While working on hns.id, I learned about "DNS wire format". It's covered by the RFC1035. In a nutshell: it's a standard way to represent DNS records as bytes.

I believe our current implementation is not based on this RFC.

Also, I'd like to share the dns-packet: An abstract-encoding compliant module for encoding / decoding DNS packets. We could use it as implementation reference.

That said, I believe the efforts to update the current implementation and add a new version that supports all DNS types would be relatively small. No need to hard/soft forks, just a regular software update.

Note: the total space is actually 511 bytes, since the first one is used for the version.

[taylormartens]

Expanding the available record types will increases the utility and versatility of Handshake. In particular adding A and AAAA records would give the ability to point directly to IP addresses via the blockchain, providing those focused on direct TLD linking with more options for how they can use their names.

Since the proposed changes are straightforward and require only a software update this seems like a low-risk, high-reward update. This change not only enhances Handshake’s functionality but also can improve UX by reducing friction for new users, making it more attractive for those looking to utilize their TLDs in a simpler, more direct way.

[flikites]

I vote yes.

[TobesVibration]

as long as the standards are followed then yes, I agree it makes sense. Good luck

[AndreiChyrych]

@Falci Does this means that we can add almost any type of records (A, MX, AAAA etc) on chain without the need to do hard/soft fork?

User will still be limited to just 512 bytes per TLD but the user will now decide what kind of stuff to put on chain. Is that correct?

[Falci]

That's correct. While a hard/soft fork is not necessary, it would still require an update (like from version 6.1 to 7.0), otherwise the resolver won't be able to resolve any record, not even the already existing ones (NS/DS...)

[AndreiChyrych]

How hard and resource intense is it to make such an update?

[flikites]

Bumping this to see where the discussion goes;

@pinheadmz made some comments on how this might look here: #61 (comment)

[AndreiChyrych]

Any updates, new ideas or thoughts about adding more onchain records, @Falci ?