experimental DNSLINK support doesn't work with /ipns/ path

[bonds]

I have a DNS TXT entry for ggr.com:

~ ❯❯❯ dig ggr.com TXT                                                       Mon 2017-10-09 10:47:56 -0700

; <<>> DiG 9.4.2-P2 <<>> ggr.com TXT
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 6017
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;ggr.com.                       IN      TXT

;; ANSWER SECTION:
ggr.com.                60      IN      TXT     "ALIAS for home.ggr.com"
ggr.com.                3600    IN      TXT     "dnslink=/ipns/QmVTofH3UuafnKihbGa6whtsLaH7YyqMWiR9Pzha9xQYuK"

;; Query time: 90 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Mon Oct  9 10:47:59 2017
;; MSG SIZE  rcvd: 133

~ ❯❯❯                                                                       Mon 2017-10-09 10:47:59 -0700

Yet, when I visit https://ggr.com using Firefox 56.0 on OpenBSD 6.1-stable-amd64 with ipfs-companion 0.4.11-dev I am NOT redirected to the IPFS version of the site as I had hoped/expected I would be.

I have HSTS enabled on ggr.com. I have more than one TXT DNS entry. I wonder if one of those is causing problems. In any case, even though its an experimental feature, I figured a 100% repro example problem case might be useful.

[lidel]

For a little background, browser extension uses /api/v0/dns/ for dnslink lookups.

Basic troubleshooting is to check if both public and your local gateway return the same result:

• https://ipfs.io/api/v0/dns/ggr.com
• http://127.0.0.1:8080/api/v0/dns/ggr.com

Right now both return this error for your FQDN:

{"Message":"Could not resolve name (recursion limit exceeded).","Code":0}

It looks like the source of problem is IPNS path in your dnslink (most of sites use static IPFS path).
May be a bug in go-ipfs.

cc @Kubuxu

[bonds]

Based on the example:

https://github.com/ipfs/examples/tree/master/examples/websites

it seems an IPNS path in my dnslink was at least intended to work at some point. It works on the command line:

~/Downloads ❯❯❯ ipfs --debug name resolve -r ggr.com                        Mon 2017-10-09 12:09:19 -0700
14:09:29.683  INFO   cmd/ipfs: IPFS_PATH /home/scott/.ipfs main.go:301
14:09:29.687 DEBUG   cmd/ipfs: calling pre-command hooks... main.go:295
14:09:29.687 DEBUG   cmd/ipfs: executing command via API main.go:332
/ipfs/QmWqNxbUnGZzmLeyA8jMi1VeyuHpBcYDYH9WcYZY31zijk

but only if I pass in the -r, without it I get the same error as with the api call through the browser:

~/Downloads ❯❯❯ ipfs --debug name resolve ggr.com                           Mon 2017-10-09 14:10:30 -0700
14:11:28.500  INFO   cmd/ipfs: IPFS_PATH /home/scott/.ipfs main.go:301
14:11:28.500 DEBUG   cmd/ipfs: calling pre-command hooks... main.go:295
14:11:28.500 DEBUG   cmd/ipfs: executing command via API main.go:332
Error: Could not resolve name (recursion limit exceeded).

So...should I file a bug on go-ipfs do you think?

[bonds]

I wonder if the api doesn't recurse by default, reminds me of: ipfs/kubo#4167

[fimbaz]

Here's the setup that works for me (and behaves nicely with the UI
# dig -t txt +short ipfs.mydomain.com
  "dnslink=/ipns/#KEY_REDACTED"
# ipfs name resolve -r ipfs.mydomain.com
  /ipfs/#KEY_REDACTED#

[lidel]

Fix from ipfs/kubo#4293 (comment) will be introduced when #558 is merged.