Validator resolves old IP address after sentry IP change when using FQDN

[mazzy89]

Description

The scenario refers to the case of having one sentry node and one validator and FQDN are used in persistent peers.

A simple configuration to replicate this scenario looks like the following:

name: gnoland

services:
  gno-val-1:
    image: "ghcr.io/gnolang/gno/gnoland:0.1.0"
    networks:
    - chain
    command:
      - start
      - -data-dir
      - /gnoland-data
      - -genesis
      - /gnoland-data/genesis.json
      - -log-level
      - info
    volumes:
      - ./gno-val-1:/gnoland-data

  gno-sen-1:
    image: "ghcr.io/gnolang/gno/gnoland:0.1.0"
    networks:
      chain:
        ipv4_address: 192.199.0.120
    command:
      - start
      - -data-dir
      - /gnoland-data
      - -genesis
      - /gnoland-data/genesis.json
      - -log-level
      - info
    volumes:
      - ./gno-sen-1:/gnoland-data

networks:
  chain:
    ipam:
      config:
        - subnet: 192.199.0.0/24
          gateway: 192.199.0.1

It is important to specify that it is used the FQDN in place in the configuration file at the line p2p.persistent_peers to reach the other node i.e. the validator node points to the sentry node using the internal hostname gno-sen-1.

persistent_peers = "g1sthz4jmxyve5wg7rejszu2em9cly027x904xmr@gno-sen-1:26656"

Run this example. Assist with some blocks singing. Afterwards, stop only the sentry container with the command docker compose down gno-sen-1. Change the static IP address from 192.199.0.120 to any other static IP address in the range 192.199.0.0/24 in the docker-compose.yaml i.e. 192.199.0.10. Send again up the sentry node running the command docker compose up -d gno-sen-1. Check in the validator logs that it continues to resolve the old IP address.

This error is only present when FQDN are used.

It is important to notice that due to the nature of Sentry nodes, they can have different IPs that can vary over time. Sentry nodes can be brought up/down easily and continuously to reply to the traffic demand. Further validators commonly communicate to Sentry via internal IP address in a private network and commonly in private networks DHCP is used or IPs tend to vary constantly (see the case of running containers in cloud platform).

@zivkovicmilos

[mazzy89]

It seems that the DNS resolution for P2P peers happens at the bootstrap time when a new node is created https://github.com/gnolang/gno/blob/b5560e20bb79ebff56eac956acddeca94e5f05f0/tm2/pkg/bft/node/node.go#L536

This invokes the function that makes the DNS lookup in the case that the peer has been set using an FQDN (rather than its IP address) https://github.com/gnolang/gno/blob/90aa89c28d3c8ad3b7d7b67d0256426bde6cfbc9/tm2/pkg/p2p/switch.go#L500 The peer is then added always as an IP address.

I'm wondering whether the FQDN can be added here rather than the IP address. What would be the implications of having the FQDN added rather than the IP?

[miguelito766]

Hello,

From what i understand and saw :

• Maybe you could flush your DNS and update from the validator if he lost the connection ?

• Do you actually own the public /24 you've configured ? If you own the network public subnet, maybe you could had something to reach out one of the node in that sentry's IP range ?

[mazzy89]

Maybe you could flush your DNS and update from the validator if he lost the connection ?

This helps only if you restart the validator which is not a great approach.

Do you actually own the public /24 you've configured ?

If IPs are static then it helps but it is not that the final goal.