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

ENS support for canonical names #2375

wants to merge 10 commits into
base: master
@@ -0,0 +1,112 @@
eip: 2375
title: ENS support for canonical names
author: Ilan Olkies (@ilanolkies)
status: Draft
type: Standards Track
category: ERC
created: 2019-11-11

## Simple Summary
ENS CNAME-like resolver.

## Abstract
This EIP specifies a resolver for canonical name resolution for ENS. This permits identifying the same resource with several names.

## Motivation
In existing systems, resources often have several names that identify the same resource. For example, the names *mew.eth* and *myetherwallet.eth* may both identify the same address. Similarly, in the case of mailboxes, many organizations provide many names that actually go to the
same mailbox.

Most of these systems have a notion that one of the equivalent set of names is the canonical or primary name and all others are aliases.

DNS provides such a feature using the canonical name (CNAME) RR. A CNAME RR identifies its owner name as an alias, and specifies the corresponding canonical name in the RDATA section of the RR.

## Specification

A resolver supporting `cname` interface identifies its name as an alias, and specifies the corresponding canonical name. It must provide a fallback function that:

1. Fetches the canonical name of the queried name.
4. Replaces the canonical name in the transaction data.
2. Fetches the canonical name's resolver.
3. Forwards transaction to the canonical name's resolver.<sup>1</sup>

If a `cname` resolution is present at a node, no other resolution should be present; this ensures that the data for a canonical name and its aliases cannot be different.

Domain names which point at another name should always point at the primary name and not the alias. This avoids extra indirections in
accessing information.

By the robustness principle, domain resolution should not fail when presented with `cname` chains or loops; `cname` chains should be followed and `cname` loops signalled as an error.

## Rationale

This EIP is strongly based on [RFC 1034 - Domain names - concepts and facilities](

## Backwards Compatibility

No special actions in ENS resolution protocol.

## Implementation

pragma solidity ^0.5.0;
import "@ensdomains/ens/contracts/ENS.sol";
contract CnameResolver {
ENS ens;
mapping(bytes32 => bytes32) public cname;
constructor(ENS _ens) public {
ens = _ens;
function () payable external {
require( >= 36);
bytes32 node;
assembly {
node := calldataload(4)
node = cname[node];
address resolver = ens.resolver(node);
assembly {
let ptr := mload(0x40)
calldatacopy(ptr, 0, 4)
mstore(add(ptr, 4), node)
if gt(calldatasize, 36) {
calldatacopy(add(ptr, 36), 36, calldatasize)
let result := delegatecall(gas, resolver, ptr, calldatasize, 0, 0)

This comment has been minimized.

Copy link

Amxx Dec 13, 2019

If you do a delegate call, you will execute the father's node resolver code in the context of this CNameResolver. This means that, unless the node's owner did duplicate the data by setting it up on this CNameResolver (using the same fallback function) you will return empty results.

I believe the correct behaviour here would be to do a static call (or eventually a "normal" call, but NOT a delegate call)

let size := returndatasize
returndatacopy(ptr, 0, size)
switch result
case 0 { revert(ptr, size) }
default { return(ptr, size) }
function setCname(bytes32 node, bytes32 canonical) public {
require(msg.sender == ens.owner(node));
cname[node] = canonical;

## References

1. Based on

## Copyright

Copyright and related rights waived via [CC0](
ProTip! Use n and p to navigate between commits in a pull request.
You can’t perform that action at this time.