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

Closed
wants to merge 12 commits into from
118 changes: 118 additions & 0 deletions EIPS/eip-2375.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,118 @@
---
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
Copy link
Contributor

Choose a reason for hiding this comment

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

Dead link. Needs to be fixed for merge.

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 call data.
2. Fetches the canonical name's resolver.
3. Queries 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.
Comment on lines +28 to +40
Copy link
Contributor

Choose a reason for hiding this comment

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

Maybe I'm missing something, but this doesn't look nearly specific enough to be a standard. It seems to just describe an idea in high level terms. It describes a fallback function that does some stuff and doesn't return anything, which suggests that the "stuff" it does is just an implementation detail and not relevant to the spec, at which point this spec is pretty meaningless.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

The initial idea was specifying a cname standard record that was queried after a 0 response from a resolver. Then, it evolved into a resolver implementing this “substitution”. The discussion was held in ENS forum and was lost.


## 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.

Keeps compatibility with

- Contract addresses - [EIP-137](https://eips.ethereum.org/EIPS/eip-137#resolver-specification)
- Multicoin addresses - [EIP-2304](https://eips.ethereum.org/EIPS/eip-2304)
- Contenthash - [EIP-1577](https://eips.ethereum.org/EIPS/eip-1577)
- Contract ABI - [EIP-205](https://eips.ethereum.org/EIPS/eip-205)
- SECP256k1 public keys - [EIP-619](https://github.com/ethereum/EIPs/pull/619)
- Text records - [EIP-634](https://eips.ethereum.org/EIPS/eip-634)
- Interface discovery - [EIP-1844](https://eips.ethereum.org/EIPS/eip-1844)

## 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 := staticcall(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;
}
}
```

## Copyright
Copy link
Contributor

Choose a reason for hiding this comment

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

Suggested change
## Copyright
## Security Considerations
TBD
## Copyright

Copy link
Contributor Author

@ilanolkies ilanolkies Oct 1, 2020

Choose a reason for hiding this comment

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

Suggested change
## Copyright
## Security considerations
- Aliases pointing to other aliases produce inefficient gas usage.
- Aliases loops produce gas limit exceeded. The domain will no longer be resolved.
## Copyright


Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/).