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 
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 
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
Well, my registrar fixed it, but yes.
Most likely DNSSEC for your domain is not set…
docs on how to setup DNSSEC
verify DNSSEC is ok
Thank you so much! Got it resolved. I had to toggle on the DNSSEC and talk with customer service to setup DS keys. If anyone else with a Bluehost domain runs into this problem: open a customer service chatbox and once you are connected with an agent, paste the following:
“I need to setup Delegation Signer (DS) records for either either RSA/SHA-256 or ECDSA keys. Offchain Gasless DNSSEC Names in ENS | ENS Support”