ENS support for canonical names #2375
Conversation
|
There has been no activity on this pull request for two months. It will be closed in a week if no further activity occurs. If you would like to move this EIP forward, please respond to any outstanding feedback or add a comment indicating that you have addressed all required feedback and are ready for a review. |
|
@ilanolkies This draft is pretty old, and I apologize on behalf of the editors to not merging it sooner. Given its age, I wanted to check with you to make sure you are still interested in pursuing this before merging. If not we can just close this PR, but if you are interested we can merge it (I encourage you to make the suggested changes first though). |
|
Hi. I can work on it during this month to have a new revision ready. Thanks |
|
Also |
There was a problem hiding this comment.
Before merging this, I want to make sure this is appropriate as an EIP. Keep in mind, not all Good Ideas are good candidates for being standardized. Why does an ENS feature need an EIP? Can't you just add the feature to ENS without creating a standard? There is only one ENS, which suggests that you could just publish some updated ENS documentation without an EIP.
| } | ||
| ``` | ||
|
|
||
| ## Copyright |
There was a problem hiding this comment.
| ## Copyright | |
| ## Security Considerations | |
| TBD | |
| ## Copyright |
There was a problem hiding this comment.
| ## 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 |
| 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. |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
| 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 |
There was a problem hiding this comment.
Dead link. Needs to be fixed for merge.
|
There has been no activity on this pull request for two months. It will be closed in a week if no further activity occurs. If you would like to move this EIP forward, please respond to any outstanding feedback or add a comment indicating that you have addressed all required feedback and are ready for a review. |
|
This pull request was closed due to inactivity. If you are still pursuing it, feel free to reopen it and respond to any feedback or request a review in a comment. |
This EIP specifies a resolver for canonical name resolution for ENS. This permits identifying the same resource with several names.