The ENS documentation says that ENS is a hierarchical name system. This would indicate that there can only be one entry for a particular name in the ENS. However, scanning the ENS shows that there are many names for which there are multiple entries.
For example: jessica.chainlinknode.eth has two entries (ids are 0x9a2a60aa4aab39364fa79d6be6fa76146677b122776b4fdd5f27aeda4e6322f8 and 0xf5a40cc6ec7bbacc59a29c4d1fada576df4e7e30c4f8bcde0a98f39419b397f4) and two different resolvers.
If it is intentional that a name can appear twice, can the ENS documents be updated to clarify this and explain how ENS’ view of “hierarchical” differs from the global DNS? If it is not intentional, what will be done to fix these duplications?
Your base assumptions there are incorrect, though. Those are not duplicates.
The first one is subdomain jessica under domain chainlinknode.eth.
The second one is an invalid name. It’s a .eth 2LD with label of jessica.chainlinknode. Someone must have incorrectly registered that directly against the contracts, probably a developer testing out code or something.
The .eth registrar doesn’t block invalid names at the contract level. You can register all capital-letter names like VITALIK.eth, for example. But they will be useless to you, because all clients/wallets/sites and libraries like ethers.js will properly normalize names into canonical forms. So VITALIK.eth will be normalized to vitalik.eth first. And given a string like jessica.chainlinknode.eth, the namehash algorithm will always treat . as the label separator and output the correct and canonical 0x9a2a... value.
A query to the ENS for a single name returns two answers so the two records can only be seen as duplicates to the outside world. I see that one record is considered an “invalid name”, but the registry is returning a domain list of two answers, and both have exactly the same text for the “name” field. This feels a lot like it is either a bug in the documentation (unlikely) or in the registry (for returning two records with the same value in the “name” field but with different data in the rest of the record).
That is not correct, “two answers” are not being returned. The input for the ENS registry contract is the nodehash. And there is no “name field”, I’m not sure what you mean. It sounds like you are “querying” something other than the ENS registry.
Edit: If by “name field” you mean in the subgraph data, then yes, both of those names have the same jessica.chainlinknode.eth value there. But you will also note that they have different labelName and different id values too, this is how they should be distinguished. The ENS subgraph is not a source of truth either. It is not part of the ENS protocol; the subgraph is a separate indexing convenience tool for third-party integrations/frontends.
Thank you, this is helpful. Nick Johnson had earlier told me “If you want to enumate everything I’d suggest the subgraph”, so I kinda assumed it was authoritative, but I now hear it is not. The ENS Subgraph at ENS Subgraph certainly looks official, including using the ENS logo. If it is not authoritative, someone should talk to whomever is running it and have them change the introductory text to say so.
Given what you say, the bug I reported yesterday is likely to be from the Subgraph, not in the ENS itself.
Is there an appropriate place to report bugs in the ENS Subgraph?
That subgraph is official in that it’s developed and maintained by ENS Labs, and (barring any bugs) it should have correct data, as it does in this case. But the ultimate source of truth will always be the actual Ethereum smart contracts, in particular the Registry. It’s possible, for example, for the subgraph to temporarily lag behind the on-chain data.
You can report bugs here, and I or someone else will relay that to the appropriate dev team!
However in this case, I don’t think there is a bug, right?
Those two distinct nodes exist in the registry, and the information that the subgraph has indexed for them is all correct, right?
I suppose if you’re coming at it from the angle of “a query to the subgraph using just domain → name should never return more than 1 result”, I can understand that argument. Perhaps the name should be null if it is invalid or something, not sure. Maybe @taytems has an opinion on that.
Thanks for keeping in on this; I’m glad to hear that the subgraph is official.
In the specific case of duplicate names, there are over a dozen names in the ENS where, if you send a query to the subgraph with that name as the query, you’ll get back more than one response. I don’t know if you would say that is a bug in the ENS registry (for accepting two names that would resolve to the same value) or to the subgraph (for reporting two answers where there should only be one) or somewhere else.
It really does feel like there is a bug somewhere here if ENS is supposed to be hierarchical like the global DNS and therefore a query for a particular name should have exactly one authoritative record, but I may be not looking at the ENS as folks in the ENS world do.
We should fix this, however. It’s unfortunately not practical to perform full normalization in a subgraph, but we can at least change the representation for names with dots in them - for example to [jessica.chainlinknode].eth.
Aside from the bug in how we represent invalid labels in the subgraph, it’s important to know that you should not use the subgraph to resolve ENS names.
The subgraph is intended to be a complete record of ENS onchain data. However, not everything about ENS can be represented statically by processing events. Resolvers can be programmed to return dynamic results, which cannot be indexed, and with wildcard support and CCIP Read, name data may not be stored onchain at all. As a result, the subgraph should be correct, but isn’t complete.
Thanks, Nick, that sounds like a good first-cut solution. If that fix will prevent subgraph searches by “name” from finding the two responses, all the better.
And, yes, I am not using the subgraph to resolve ENS names into IDs, but am just storing the results for later comparison. Later research might look into how resolvers return dynamic results, or we might just note that the can and not look further.
Apologies for re-opening this, but I had a note about “Aside from the bug in how we represent invalid labels in the subgraph…” from @nick.eth above. There are a bunch of non-text names that appear twice in the subgraph data, such as [41ff1915eef2bf5841388d748bfcd23bd49ff5521ca4200c20bc0978b136c3cb].eth. This isn’t getting in the way of my research, but I wanted to point it out for those of you fixing bugs in the subgraph names.
Thanks for asking, I probed further. I was incorrect. The other name that contained [41ff1915eef2bf5841388d748bfcd23bd49ff5521ca4200c20bc0978b136c3cb] was [41ff1915eef2bf5841388d748bfcd23bd49ff5521ca4200c20bc0978b136c3cb].addr.reverse. Apologies.
The three names that appear to be truly duplicated (test.matthiasegli.eth, jessica123.thisisme.eth, and jessica.chainlinknode.eth) could easily be related to the invalid label display bug.
Yep, all three of those are not truly “duplicates”, they are separate nodes in the ENS registry (one of the names is invalid since it has a literal period . in the label). But two results are returned if you query the subgraph by name. Sounds like Nick agrees that is a subgraph display bug that should be addressed for invalid names!