Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Canonical name resolver #161

Draft
wants to merge 1 commit into
base: master
Choose a base branch
from
Draft
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
51 changes: 51 additions & 0 deletions ens-improvement-proposals/ensip-xx-canonical-name-resolver.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,51 @@
---
description: Allows names to set a cname to alias records to another name
---

# ENSIP-XX: CNAME resolver

| **Author** | Jeff Lau \<[email protected]>
| ------------- | ---------------------------------------------------------------- |
| **Status** | Draft |
| **Submitted** | 2023-09-25 |

### Abstract

Canonical Name records have existed for DNS since the 1987 in [RFC 1034](https://datatracker.ietf.org/doc/html/rfc1034). They allow aliasing a name to another name e.g. vitalik.eth to records.vitalik.eth. This specification outlines a resolver standard to implement CNAMEs at a resolver level without having to change the base ENS name resolution protocol.

### Specification

If a cname is found on a name, all records that are unset will be expected to proxy through the specified cname's records. Records that are already set on the resolver will ignore the cname.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This should clarify that it's the resolver's reponsibility to implement CNAME functionality, not the client.


### Implementation

```solidity
interface ICnameResolver {
event CNameChanged(bytes32 indexed node, string name);
function cname(bytes32 node) external view returns (string memory);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we need to make a decision here: Either cname takes a node and doesn't implement CCIP-Read and wildcards (so only onchain names can be CNAMEd to), or it takes a DNS-encoded name and does implement CCIP-Read and wildcards. The latter is the more future-proof option, but this implementation requirement needs to be called out.

}
```

```solidity
contract CnameResolver {
function addr(bytes32 node, uint256 coinType){
bytes memory currentAddr = versionable_addresses[recordVersions[node]][node][coinType];

if(currentAddr.length == 0 && cname.length != 0){
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This will have to be a lot more complex to support CCIP Read and wildcards.

Perhaps we should just implement a canonical CNAME resolver mixin instead of writing a spec?

return ens.resolver(namehash(cname)).addr();
}

return currentAddr
}
}
```

### Motivation

* Allows separation of concerns between records and ownership of a high value name
* Allows mirroring records for other names without having to set the records manually

### Open Questions

* DNS does not allow other records (except DNSSEC) when a cname has been set. ENS could optionally allow records on the main name to overwrite the cname, or it could choose to ignore them until a cname has been deleted. In the above specification, I've chosen to respect the main resolver's records.
* We could also make the protocol more granular by allowing cnames per-record, which would allow you to delegate just a single record to a different name if necessary. This could be useful for allowing a service to take over that record for a name (e.g. contenthash)