Go-ipfs: /api/v0/dns/ fails with "not a valid domain name" error on IPNS DNSLinks

[Gozala]

Version information:

go-ipfs version: 0.4.18-
Repo version: 7
System version: amd64/darwin
Golang version: go1.11.1

Description:

/api/v0/dns API endpoint no longer seems to work for DNSLinks that have ipns values e.g:

dig +noall +answer TXT _dnslink.ipns.gozala.io                                                                                             
_dnslink.ipns.gozala.io. 3600   IN      TXT     "dnslink=/ipns/QmYhQG9JXYeBF6pL7yafFJfEYcKPp9N8n4aRmYZzU6z47u/"

calling following API call seems to fail:

curl http://localhost:5001/api/v0/dns\?arg\=dweb.gozala.io -v                                                                              ✗ ✭
*   Trying ::1...
* TCP_NODELAY set
* Connection failed
* connect to ::1 port 5001 failed: Connection refused
*   Trying 127.0.0.1...
* TCP_NODELAY set
* Connected to localhost (127.0.0.1) port 5001 (#0)
> GET /api/v0/dns?arg=dweb.gozala.io HTTP/1.1
> Host: localhost:5001
> User-Agent: curl/7.54.0
> Accept: */*
> 
< HTTP/1.1 500 Internal Server Error
< Access-Control-Allow-Headers: X-Stream-Output, X-Chunked-Output, X-Content-Length
< Access-Control-Expose-Headers: X-Stream-Output, X-Chunked-Output, X-Content-Length
< Content-Type: application/json
< Server: go-ipfs/0.4.21
< Trailer: X-Stream-Error
< Vary: Origin
< Date: Sat, 15 Jun 2019 23:33:54 GMT
< Transfer-Encoding: chunked
< 
{"Message":"not a valid domain name","Code":0,"Type":"error"}
* Connection #0 to host localhost left intact

Public gateway seems to also suffer from the same issue:

url https://ipfs.io/api/v0/dns\?arg\=ipns.gozala.io -v                                                                                    ✗ ✭
*   Trying 209.94.90.1...
* TCP_NODELAY set
* Connected to ipfs.io (209.94.90.1) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* Cipher selection: ALL:!EXPORT:!EXPORT40:!EXPORT56:!aNULL:!LOW:!RC4:@STRENGTH
* successfully set certificate verify locations:
*   CAfile: /etc/ssl/cert.pem
  CApath: none
* TLSv1.2 (OUT), TLS handshake, Client hello (1):
* TLSv1.2 (IN), TLS handshake, Server hello (2):
* TLSv1.2 (IN), TLS handshake, Certificate (11):
* TLSv1.2 (IN), TLS handshake, Server key exchange (12):
* TLSv1.2 (IN), TLS handshake, Server finished (14):
* TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
* TLSv1.2 (OUT), TLS change cipher, Client hello (1):
* TLSv1.2 (OUT), TLS handshake, Finished (20):
* TLSv1.2 (IN), TLS change cipher, Client hello (1):
* TLSv1.2 (IN), TLS handshake, Finished (20):
* SSL connection using TLSv1.2 / ECDHE-RSA-AES256-GCM-SHA384
* ALPN, server accepted to use h2
* Server certificate:
*  subject: CN=ipfs.io
*  start date: May  7 21:37:01 2019 GMT
*  expire date: Aug  5 21:37:01 2019 GMT
*  subjectAltName: host "ipfs.io" matched cert's "ipfs.io"
*  issuer: C=US; O=Let's Encrypt; CN=Let's Encrypt Authority X3
*  SSL certificate verify ok.
* Using HTTP2, server supports multi-use
* Connection state changed (HTTP/2 confirmed)
* Copying HTTP/2 data in stream buffer to connection buffer after upgrade: len=0
* Using Stream ID: 1 (easy handle 0x7f87aa805200)
> GET /api/v0/dns?arg=ipns.gozala.io HTTP/2
> Host: ipfs.io
> User-Agent: curl/7.54.0
> Accept: */*
> 
* Connection state changed (MAX_CONCURRENT_STREAMS updated)!
< HTTP/2 500 
< server: nginx
< date: Sat, 15 Jun 2019 23:36:57 GMT
< content-type: application/json
< trailer: X-Stream-Error
< vary: Origin
< access-control-allow-origin: *
< access-control-allow-methods: GET, POST, OPTIONS
< access-control-allow-headers: X-Requested-With, Range, Content-Range, X-Chunked-Output, X-Stream-Output
< access-control-expose-headers: Content-Range, X-Chunked-Output, X-Stream-Output
< x-ipfs-pop: gateway-bank3-sjc1
< strict-transport-security: max-age=31536000; includeSubDomains; preload
< 
{"Message":"not a valid domain name","Code":0,"Type":"error"}
* Connection #0 to host ipfs.io left intact

[eingenito]

Hey @Gozala, thanks for the report. Is this a recent change? Do you know of an IPFS version where this last worked?

[Gozala]

@eingenito Sadly I don't know exactly when this has changed, but it definitely used to work in the past. The project that used it has last commit on Feb 22, 2019 & I'm inclined to believe that it worked around then.

I also have being using it through IPFS Desktop so I'd say it regressed somewhere between 0.7.0-rc and 0.8.

I hope this helps to narrow it down somewhat.

[Stebalien]

This _should_ resolve to /ipns/Qm... I'm not sure if this ever worked.

Note: If you actually want to resolve it, you can use ipfs resolve.

[RubenKelevra]

I can confirm this bug, it works fine if the dnslink is /ipfs but does not work if it's /ipns.

[Stebalien]

You're correct, this has not been fixed. If you want to resolve a path, I recommend using ipfs resolve ....

Ideally, ipfs dns ... would resolve all DNSLink names until the first non-DNSLink. If you want to take a stab at this, the issue is in namesys/base.go.

[RubenKelevra]

Ideally, ipfs dns ... would resolve all DNSLink names until the first non-DNSLink. If you want to take a stab at this, the issue is in namesys/base.go.

I would really enjoy to so this, but I know nothing about Go.

I don't think I'm the right one to do this. 😕

[Stebalien]

Up to you. Contributing to OSS projects is one of the best ways to learn a language (https://tour.golang.org/welcome/1).

[DougAnderson444]

The thing is, js-ipfs relies on this to resolve the dns
https://github.com/ipfs/js-ipfs/issues/2212
so until this is fixed, it break js-ipfs for resolving /ipns/QmHashes too...

[lidel]

For the record, this is still broken in v0.7.0:

$ dig +noall +answer TXT _dnslink.seanbehan.dev
_dnslink.seanbehan.dev. 300 IN  TXT "dnslink=/ipns/k51qzi5uqu5djnx8xr1du720eheh7fmkehu5ltzkr0ksvvd43v6zfhez9y7o70"

$ ipfs dns -r seanbehan.dev
Error: not a valid domain name

Not only it does not work, it also produces invalid error message (domain is valid).