BNS Upgrade: zonefile resolution

BNS
#1

This post is part of a larger effort to discuss potential features to be included in an upgraded version of BNS. Please see the megathread for more information.

Proposal: implement a system for abstracting resolution of a name’s zonefile

BNS zonefiles are built on top of the “atlas” network. Atlas is a protocol built in to Stacks node’s software for replication and distribution of zonefiles.

At the moment, BNS apps and APIs only recognize zonefiles that are part of the Atlas network. This proposed change would allow zonefiles to be resolved through other mechanisms, such as directly on-chain and via other off-chain networks.

If implemented, this proposed change would allow name owners to specify how to resolve their zonefile. There would be three high-level mechanisms for resolving a zonefile:

  • Atlas (default)
  • On-chain: name owners can specify a contract as the mechanism for resolving a zonefile
  • Off-chain: name owners can specify an off-chain URI, such as a https URL or IPFS content hash
Megathread: BNS upgrade discussion
#2

I see more flexibility in zonefile resolution as something that would be useful for BNS. One current limit of the current approach is the size limit.

What about keeping all zonefiles in atlas as it is today but instead defining a record (similar to the NS DNS record) that would instruction BNS resolvers to fetch the remainder of the zonefile from elsewhere? This moves the problem out of the smart contract, keeping things simple on chain and into resolvers which can either run on servers or client-side.

What’s an example use case of the on-chain scenario?