ENS support for canonical names

EIPS/eip-2375.md

@@ -0,0 +1,112 @@
+---
+eip: 2375
+title: ENS support for canonical names
+author: Ilan Olkies (@ilanolkies)
+discussions-to: https://discuss.ens.domains/t/new-standard-proposal-ens-cname-support/1236
+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](https://tools.ietf.org/html/rfc1034).
+
+## Backwards Compatibility
+
+No special actions in ENS resolution protocol.
+
+## Implementation
+
+https://github.com/ilanolkies/ens-cname
+
+```solidity
+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(msg.data.length >= 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)
+      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 https://discuss.ens.domains/t/new-standard-proposal-ens-cname-support/1236/2
+
+## Copyright
+
+Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/).