/api/v0/dns/pkg.pacman.store false-negative?

[lidel]

This was originally found in ipfs/ipfs-companion#877 – cc @RubenKelevra

Version information:

go-ipfs/0.6.0-rc1/aa16952

Description:

Valid DNSLink

pkg.pacman.store has a valid DNSLink set up on _dnslink:

$ dig +short TXT _dnslink.pkg.pacman.store
dnslink=/ipns/QmfYwNBmDaGXP8cxTRxoSmGkYQFRFT4HjeeFjMvc9Y4KHq

Unsure if it is relevant, but the main hostname has TXT record which si not related to DNSLink:

$ dig +short TXT pkg.pacman.store
"1|https://ipfs.io/ipns/pkg.pacman.store/"

Resolv works

Recursive resolution works fine via resolve command:

$ ipfs resolve -r /ipns/pkg.pacman.store
/ipfs/bafybeif7tmfpjaaospz2ephgmzifw66jm2foqaxcokf2zehufbvegu566y

and via Host HTTP header on public gateways:

curl -Is -H 'Host: pkg.pacman.store' http://gateway.ipfs.io | grep X-Ipfs-Path
X-Ipfs-Path: /ipns/pkg.pacman.store/

/api/v0/dns/ check fails

DNSLink check itself returns false-negative for some reason (both on CLI and HTTP API) 🙃

$ ipfs dns pkg.pacman.store
Error: not a valid domain name

[RubenKelevra]

Do we have any outdated ACL for domains which might not include store as tld?

Also: I had the DNS-Link entry directly on the subdomain pkg..

Which leads to the same result.

[AluisioASG]

Because I'm having the same problem with my domain (aasg.name), I built v0.6.0-rc7 with a patch to show the domain name with the error:

diff --git i/namesys/dns.go w/namesys/dns.go
index 984a27a..738612f 100644
--- i/namesys/dns.go
+++ w/namesys/dns.go
@@ -3,6 +3,7 @@ package namesys
 import (
 	"context"
 	"errors"
+	"fmt"
 	"net"
 	"strings"
 
@@ -53,7 +54,7 @@ func (r *DNSResolver) resolveOnceAsync(ctx context.Context, name string, options
 	domain := segments[0]
 
 	if !isd.IsDomain(domain) {
-		out <- onceResult{err: errors.New("not a valid domain name")}
+		out <- onceResult{err: fmt.Errorf("not a valid domain name: %s", domain)}
 		close(out)
 		return out
 	}

which shows that ipfs dns does not recurse:

$ ipfs dns pkg.pacman.store
Error: not a valid domain name: QmfYwNBmDaGXP8cxTRxoSmGkYQFRFT4HjeeFjMvc9Y4KHq

which is documented:

Note: This command can only recursively resolve DNS links, it will fail to recursively resolve through IPNS keys etc. For general-purpose recursive resolution, use ipfs name resolve -r.

and also makes this ipfs/ipfs-companion#288.

[gileri]

Looks like the same issue described in #6454

[RubenKelevra]

@gileri wrote:

Looks like the same issue described in #6454

You're right. This one is a duplicate.

@lidel can you close one of the two tickets?

Additionally, I've changed the subdomain layout a bit, the same service is now available under:

x86-64.archlinux.pkg.pacman.store

[RubenKelevra]

@AluisioASG wrote:

Because I'm having the same problem with my domain (aasg.name), I built v0.6.0-rc7 with a patch to show the domain name with the error

Sounds like an improvement, mind doing a PR?

[lidel]

@AluisioASG (or @RubenKelevra) mind opening a PR with that one-line change? it will be very useful 🙏

I'm closing this one, let's continue in #6454 (comment)
FYSA this issue no longer impacts IPFS Companion, we switched to name resolve: ipfs/ipfs-companion#959