The dns service on port 8600 is unavailable

[xiaohei114]

Name and Version

bitnami/consul:latest

What architecture are you using?

amd64

What steps will reproduce the bug?

1. Use this docker compose file

version: '2'

networks:
  consul-network:
    driver: bridge

services:
  consul:
    image: bitnami/consul:latest
    networks:
      - consul-network
    ports:
      - '8300:8300'
      - '8301:8301'
      - '8301:8301/udp'
      - '8500:8500'
      - '8600:8600'
      - '8600:8600/udp'

2. Some background information
   server os: ubuntu-22.04.3-live-server-amd64
   server ip address for running consul: 192.168.1.100
   bitnami/consul container id: 045d470b6ef4

3. Register a service using python code

import json
import httpx
import fastapi
import uvicorn

def register_to_consul():
    consul_host = '192.168.1.100'
    consul_port = '8500'
    url = f"http://{consul_host}:{consul_port}/v1/agent/service/register"
    data = {
        "Name": "school",
        "Tags": ['school'],
        'Address': '192.168.1.250',
        'Port': 8000,
        "Check": {
            'http': f'http://192.168.1.250:8000/health',
            'interval': '10s'
        }
    }
    res = httpx.put(url, data=json.dumps(data))
    return res.text

app = fastapi.FastAPI()

@app.get("/health")
def health_status():
    print('health')
    return {"status": "healthy"}

if __name__ == '__main__':
    register_to_consul()
    uvicorn.run(app, port=8000, host='0.0.0.0')

4. Query the ip of the service on the server using dig

$ dig school.service.consul @192.168.1.24 -p 8600 +tcp
;; Connection to 192.168.1.24#8600(192.168.1.24) for school.service.consul failed: connection refused.
;; Connection to 192.168.1.24#8600(192.168.1.24) for school.service.consul failed: connection refused.
;; Connection to 192.168.1.24#8600(192.168.1.24) for school.service.consul failed: connection refused.

$ dig school.service.consul @192.168.1.24 -p 8600
;; communications error to 192.168.1.24#8600: connection refused
;; communications error to 192.168.1.24#8600: connection refused
;; communications error to 192.168.1.24#8600: connection refused
; <<>> DiG 9.18.12-0ubuntu0.22.04.2-Ubuntu <<>> school.service.consul @192.168.1.24 -p 8600
;; global options: +cmd
;; no servers could be reached

5. Use dig to query the service ip inside consul

# Enter the consul container as root
docker exec -u 0 -it 045d /bin/bash

# Install the packages needed to run dig
$ apt update && apt install dnsutils -y

# tcp query
$  dig school.service.consul @127.0.0.1 -p 8600 +tcp
school.service.consul.  0       IN      A       192.168.1.250

# udp query
$  dig school.service.consul @127.0.0.1 -p 8600
school.service.consul.  0       IN      A       192.168.1.250

# Query by ubuntu server port
$ dig school.service.consul @192.168.1.100 -p 8600 +tcp
;; communications error to 192.168.1.24#8600: connection reset
;; communications error to 192.168.1.24#8600: connection reset
;; communications error to 192.168.1.24#8600: connection reset

What is the expected behavior?

Just like using hashicorp/consul image, The following is the return result of hashicorp/consul

$ dig school.service.consul @192.168.1.100 -p 8600 +tcp

school.service.consul.  0       IN      A       192.168.1.250

What do you see instead?

Only inside the container can dns results be returned correctly

[carrodher]

Hi, the issue may not be directly related to the Bitnami container image/Helm chart, but rather to how the application is being utilized, configured in your specific environment, or tied to a particular scenario that is not easy to reproduce on our side.

If you think that's not the case and want to contribute a solution, we'd like to invite you to create a pull request. The Bitnami team is excited to review your submission and offer feedback. You can find the contributing guidelines here.

Your contribution will greatly benefit the community. Please feel free to contact us if you have any questions or need assistance.

Suppose you have any questions about the application, customizing its content, or technology and infrastructure usage. In that case, we highly recommend that you refer to the forums and user guides provided by the project responsible for the application or technology.

With that said, we'll keep this ticket open until the stale bot automatically closes it, in case someone from the community contributes valuable insights.

[github-actions]

This Issue has been automatically marked as "stale" because it has not had recent activity (for 15 days). It will be closed if no further activity occurs. Thanks for the feedback.

[github-actions]

Due to the lack of activity in the last 5 days since it was marked as "stale", we proceed to close this Issue. Do not hesitate to reopen it later if necessary.