Bugs in the Vercel ens-resolution app?

Greetings. Where is the right place to report bugs in the https://ens-resolution.vercel.app/ that the new gasless DNS pages suggest to use? It gives negative responses for some domains that have valid TXT records, and for others it says “This name resolves to 0x20” instead of the full wallet address.

If this falls within the scope of the ENS Bug Bounty Program outlined here this should be submitted via email to bugs@ens.domains, or on Keybase to @arachnid.

If this (does) fall within the scope of the above then please do not provide any further details publicly.

If it (does not) fall within the scope and does not affect anything with attached transferable value then you should be free to either address it here or on Canny


edit

I’m not sure if that is considered official ENS or not. @gregskril did you build this? request you confirm or…

Just to be clear, I’m not looking for a bug bounty, I’m asking where to report the bug.

1 Like

feel free to describe the bugs here. additionally though, you should be able to now check gasless DNS in the ENS app at https://ens.app

I have two names, imc.org and jan1.date, which have the records correctly but the Vercel app has errors for. The ens.app has problems with both of them as well. You can see from https://dnsviz.net/ that they are both properly signed.

dig +short imc.org TXT
“ENS1” “dnsname.ens.eth” “0xb775502c76b4672B0D820E3AA534F7cF9312c263”

dig +short jan1.date TXT
“ENS1” “dnsname.ens.eth” “0xb775502c76b4672B0D820E3AA534F7cF9312c263”

the value needs to be without quotes:

ENS1 dnsname.ens.eth 0xb775502c76b4672B0D820E3AA534F7cF9312c263

This would indicate that the bug is in the instruction for the new names. Where it says:
The format is ENS1 dnsname.ens.eth <eth-address>
It should instead say:
The format is "ENS1 dnsname.ens.eth <eth-address>"
Otherwise, all RFC-compliant name servers will read the zone file as having three individual character-strings. See Section 3.3.14 of RFC 1035.

After fixing this in my zone files, imc.org is correctly shown in ens.app, but jan1.date still fails. In Vercel ens-resolution, they both still have the same errors as above.

it’s most likely same old Universal resolver bug reading first 32 bytes of revert message as address “0x0000000…20”. displaying “0x20” as address is certainly bad decoder.

Hey @paulehoffman thanks for the bug report, we’re taking a look now and will have it resolved shortly.

Yes I built this as a little testing tool for name resolution. It does not fall under the bug bounty as it’s not new (see below), and not related to core protocol smart contracts.

Yep nice catch, this seems to be the case. The latest Universal Resolver patches this issue.

2 Likes

imc.org seems fine in both, but jan1.date is still not. The Vercel app reports:
Your DNS TXT record is set but no Ethereum address is resolving :thinking:
TXT record: ENS1 dnsname.ens.eth 0xb775502c76b4672B0D820E3AA534F7cF9312c263

~ % dig jan1.date +dnssec +short
127.0.0.1
A 13 2 60 20240214232009 20240201150844 48145 jan1.date. zwI+4Q1FrU2jsjP/2PJrekO4vYT4DKnoSeLXfBJVcmbmXW0P/imzfeTU zipiWh9YJSgq35NoCKpGGJFP+UdxMA==

Could be because of “No DS records found for jan1.date in the date zone”? *I’m not so sure… I see 127.0.01 :laughing:

DNSSEC Debugger - jan1.date

Viem is using Universal resolver internally so new DNSSEC tests work all ok… except for that case of revert data decoded to address… It’d be better if Universal resolver is deployed as a proxy/EIP2535 upgradable contract so js/libraries don’t have to change it for future version.

import { createPublicClient, http } from 'viem'
import { mainnet } from 'viem/chains'
import { normalize } from 'viem/ens'
export const publicClient = createPublicClient({
  chain: mainnet,
  transport: http()
})
publicClient.getEnsAddress({
  name: normalize('namesys.xyz'), // all good setup
}).then(console.log) // returns 0x59AD62Fe873409969AC636Ec38eDD000411b0847

publicClient.getEnsAddress({
  name: normalize('ens.domains'), // ?? DNSSEC but no TXT = ENS1...
}).then(console.log) // returns 0x0000000000000000000000000000000000000020

publicClient.getEnsAddress({
  name: normalize('google.com'), // any domains without DNSKEY/bad configs 
}).then(console.log) // returns null

@paulehoffman
I see you fixed it…

Found 1 DS records for jan1.date in the date zone

Well, my registrar fixed it, but yes.