/dns/ is no longer resolving records that are actually resolvable

[montekki]

Addr of bootnode in form /dns/bootnode/tcp/30333/p2p/12D3KooWEyoppNCUx8Yx66oV9fJnriXwCcXwDDUA2kj6vnc6iDEp can no longer be reached, however curl bootnode:9944 there from the node's machine works perfectly fine, here are the logs of the node.

[tomaka]

Did you replace the actual domain name with bootnode in the logs, or is bootnode some sort of alias?
If it's an alias, we'll need more information.

[montekki]

The logs are unmodified copypaste, the bootnode is the name within the k8s cluster enviroment that can be nslookuped:

kubectl exec -i -t dnsutils -n fedor-gurke -- nslookup bootnode
Server:         10.27.240.10
Address:        10.27.240.10#53

Name:   bootnode.fedor-gurke.svc.cluster.local
Address: 10.27.247.34

[tomaka]

Ah, so it's not a full qualified domain name.

@mxinden Do you know why we do this?

[romanb]

Do you know why we do this?

Really just as a naive attempt at optimisation that I didn't think much about, i.e. from the docs:

For the least expensive query a fully-qualified-domain-name, FQDN, which ends in a final ., e.g. www.example.com., will only issue one query. Anything else will always incur the cost of querying the ResolverConfig::domain and ResolverConfig::search.

This obviously does not work with these kinds of indirections that require taking into account the local domain or search domains from the resolver configuration. I didn't really consider that at the time (i.e. we're taking about this). In hindsight we certainly cannot assume to always be given a domain that is an FQDN if we just stick a . at the end, though the behaviour could be made configurable if we're still interested in this optimisation.

[montekki]

So, is there a chance for a fix, or should we just continue with FQDNs for now (a bit tricky for our case)?

[mxinden]

libp2p-dns v0.28.1 is published and tagged.