Skip to content
Snippets Groups Projects

duniter container image uses google DNS resolvers to make queries

    • Open Issue created by Olivier @olivier

    Hello Installed duniter today with docker image: duniter/duniter-v2s-gdev-800

    My docker logs are filled with lines :

    duniter-mirror-1 | 2025-03-29 16:04:42 💤 Idle (0 peers), best: #0 (0xc184…b6c3), finalized #0 (0xc184…b6c3), ⬇ 0 ⬆ 0

    It seems that peers can't be found because container tries to find peers with their dns names via google resolvers, but in my infrastructure, external resolvers are filtered.

    Below is the result of tcpdump with ip address of container as host.

    17:07:30.327540 IP 172.18.1.4.61680 > 8.8.8.8.53: 65271+ A? gdev-smith.pini.fr. (36)
17:07:30.327671 IP 172.18.1.4.63040 > 8.8.4.4.53: 37861+ A? gdev-smith.pini.fr. (36)
17:07:30.415444 IP 172.18.1.4.64419 > 8.8.8.8.53: 54661+ A? gdev.pini.fr. (30)
17:07:31.327190 IP 172.18.1.4.64072 > 8.8.4.4.53: 37157+ A? gdev.gyroi.de. (31)
17:07:31.327947 IP 172.18.1.4.64592 > 8.8.8.8.53: 16587+ A? gdev.txmn.tk. (30)
17:07:31.328076 IP 172.18.1.4.63459 > 8.8.4.4.53: 20279+ A? gdev.txmn.tk. (30)
17:07:31.328666 IP 172.18.1.4.49974 > 8.8.8.8.53: 42271+ A? duniter-v2-vjrj-gdev.comunes.net. (50)
17:07:31.328793 IP 172.18.1.4.50322 > 8.8.4.4.53: 53458+ A? duniter-v2-vjrj-gdev.comunes.net. (50)
17:07:31.416129 IP 172.18.1.4.55512 > 8.8.8.8.53: 44437+ A? gdev.cgeek.fr. (31)
17:07:31.416430 IP 172.18.1.4.51746 > 8.8.4.4.53: 61642+ A? gdev.matograine.fr. (36)
17:07:31.416571 IP 172.18.1.4.52844 > 8.8.8.8.53: 21076+ A? gdev.matograine.fr. (36)
    To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information

    Child items 0

    • No child items are currently assigned. Use child items to break down this issue into smaller parts.

    Activity

    • Moul
      Moul @moul ·
      Owner

      Hi Olivier,

      What’s the goal of this ticket? To inform us about Google DNS resolver usage? A request to change to an other DNS resolver? A request for help?

      Thanks for clarifying.

      Edited by Moul
    • Olivier
      Olivier @olivier ·
      Author

      Sorry for the lack of precision.

      No need for help about this issue, thanks. I've set up a temporary workaround to keep on installing duniter by allowing TCP&udp on port 53 to Google resolvers.

      But i shouldn't have had to, since any container should use the resolver of the host it runs on.

      So the purpose of this issue is to suggest to remove this dependency to Google resolvers which is unusual on docker containers, subject to misbehaviour in situations similar to mine, and a privacy issue.

    • Moul
      Moul @moul ·
      Owner

      I already found out about this issue. https://forum.duniter.org/t/le-noeud-forgeron-de-moul-n-est-pas-a-l-heure/12479/23

      Not sure we can change something here. It’s probably in Substrate/libp2p/pasta code. Of course, this is kind of wrong usage.

      Ok, so the goal of this ticket is to find a way to use the local DNS resolver instead of Google one.

      Thanks for clarifying!

      Edited by Moul
    • Pascal Engélibert
      Pascal Engélibert @tuxmain ·
      Maintainer

      I can confirm that Duniter makes requests to 8.8.8.8.

      It does not happen with a local node --dev --tmp, but happens when adding a bootnode:

      ./target/debug/duniter --dev --tmp --bootnodes /dns/gdev.cgeek.fr/tcp/30334/p2p/12D3KooWN7QhcPbTZgNMnS7AUZh3ZfnM43VdVKqy4JbAEp5AJh4f

      sudo tcpdump -i wlp40s0 |grep 8\\.8\\.8\\.8
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on wlp40s0, link-type EN10MB (Ethernet), snapshot length 262144 bytes
19:02:47.353590 IP belpomme-1.home.45933 > livebox.home.domain: 54617+ PTR? 8.8.8.8.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.6.8.4.0.6.8.4.1.0.0.2.ip6.arpa. (90)
19:02:53.476784 IP belpomme-1.home.46350 > livebox.home.domain: 15204+ PTR? 8.8.8.8.in-addr.arpa. (38)

      I did not find this IP using grep in the substrate repo. I will try to search the transitive dependencies or using tools like ltrace or strace.

    • Pascal Engélibert
      Pascal Engélibert @tuxmain ·
      Maintainer

      trust-dns-resolver, dependency of litep2p, reads /etc/hosts and /etc/resolv.conf and seems to default to google if it finds nothing.

      I don't know whether this is good practice but it seems a little naive. In comparison, curl reads /etc/nsswitch.conf but I'm surprised it reads nothing else.

      I'll try to configure DNS correctly on my system. (if it is possible?)

      [edit] I've configured NetworkManager to use systemd-resolved at 127.0.0.53, it works and is visible in /etc/resolv.conf, but Duniter still uses 8.8.8.8. I'm not sure if it a parsing bug of hickory-resolver (formerly trust-dns-resolver) or at misuse of its API by litep2p.

      Edited by Pascal Engélibert
    • Pascal Engélibert added C-binary bug labels

      added C-binary bug labels

    Please register or sign in to reply