Greetings. imc.org (imported gasless) has two TXT records:
“ENS1 dnsname.ens.eth 0xb775502c76b4672B0D820E3AA534F7cF9312c263”
“ENS1 dnsname.ens.eth 0x1111111111111111111111111111111111111111”
As expected from the resolver API, ens.app reports only one, and ens-resolution.vercel.app reports only one. Each reports a different one.
In the DNS, it is completely expected that an RRset might have multiple records. I propose that this be mentioned in the gasless DNS documentation. I also recommend that it be mentioned that any of the TXT records that match the format might be returned: in the DNS, RRsets are indeed sets, not ordered lists.
In DNS, TXT are meant to have multiple values, CNAME are meant to have single value. MX has priority value.
I would be curious about technical rationale when choosing TXT which can have multi-value. Also it’s generally assume to have multiple Nameserver (NS) records. In loadbalancing DNS are being used to divert different traffic for different client based on randomness or routing location. It means it is possible to have different Resource Record Set response in different occasion.
What’s ENS’s view on this convention / widely relied on pattern by DNS
I believe the TXT record is selected because it allows the addition of multiple records to a domain, such as email, Twitter, and more. ENS1 specifically caters to Ethereum wallet addresses, but there are additional keywords in the pipeline to accommodate Bitcoin and other wallet addresses. @nick.eth could provide further clarity on this topic.
Big missing piece of puzzle here is proper ENSIP to spec out all about DNSSEC and TXT format… it’s kinda funny to see everything passed in voting & working stack but there no ENSIP for this…/or I’m not digging deep enough to find those ENSIP docs… on side note, we’re working to store those extra records using web2 domain.tld itself as CCIP gateway, all records are signed by owner/address set in TXT records & stored in https://domain.tld/.well-known/tld/domain/<record ttype>.json format.
obviously using multi txt records value for different specs is ok but duplicate value for same standards isn’t… it’d be nice to have properly formatted single TXT value with L2 resolver support, something like…
“enslink=eip155:<chainid>/<ensip-number>:<0xresolver>:<0xaddress>”
“enslink=eip155:<chainid>/<ensip-number>:<0xresolver>”
“ENS1 <0xresolver> <0xaddress>” is good for mainnet only.
Good point! Yes, which one is resolved will depend on the order of the records - though this should be consistent due to DNSSEC signing requirements, so the vercel app is incorrect here. You’re right that we should document this better, too.
All DNS record types can return multiple values. TXT was selected because there’s no other widely-deployed record that’s a better match.
We intend to extend support by improving the extended resolver (dnsname.ens.eth) to understand a more sophisticated record format. The current gasless DNSSEC implementation will only read the first ENS1 record it encounters, so there’s no reason to have more than one in DNS right now.
You’re right, we need to document this, either as an ENSIP or just as standard docs. Adding a todo for myself to do that.
All ENS resolution starts on mainnet. If you wish to resolve the data via both gasless DNS and an L2, you can do that by writing an L1 resolver that subsequently delegates to L2 - but it will incur two CCIP-read lookups, and the consequent increase in latency.
Just a note on “Yes, which one is resolved will depend on the order of the records - though this should be consistent due to DNSSEC signing requirements, so the vercel app is incorrect here.” That is not correct. The canonicalization for DNSSEC signing and validating is only for DNSSEC, not for resolution of the RRset after validation. Neither resolver is incorrect in picking one from the returned set: “first”, “last”, “tastiest” are all valid ways to pick one from a set. The thing that might surprise some people here is that only one from a set can be returned; in the global DNS, one would expect to see all records.
You are technically correct (the best kind of correct) when it comes to DNS in general, but not for ENS. DNS RRSets are returned by the gateway in canonical order, and after the contract validates them it parses them in that order, meaning that’s the order they are processed by the gasless DNSSEC code.
No, but the raw DNS records aren’t accessible to resolvers, so this isn’t a public interface. Nevertheless, we’ll document it in order to make the gateway itself an API others can use.