CHT Docker Helper Gets Fix to DNS issues with

Hi all!

tl;dr - Please update your copy of the CHT Core repository to get important fixes to CHT Docker Helper.

In recent months, there’s been a number of issues with the CHT Docker Helper’s use of the site This site offers a free wildcard TLS along with DNS to resolve URLs which embed the IP in them so would resolve to The combination of the free certificate with handy IP-in-URL DNS resolution, made it great for doing local CHT app development with Android, which requires a valid TLS certificate.

However, when problems arose (see here, here and here for example as well as CHT Core ticket), developers would become quite frustrated and often resort to restarting their computer or thinking that their CHT App had a bug. Neither were true and both were a massive waste of time!

To bring back stability to development, we’ve released which mirrors the functionality of, but is Medic hosted. Medic has committed to ensuring this resource is stable for the foreseeable future. As well, if any partners don’t want to depend on Medic or prefer to run everything in country, the solution is entirely open source (We’re even working to get some improvements merged upstream!)

If you use CHT Docker helper, you only need to pull the latest changes in the CHT Core repository (git pull orgin) and use restart your project with the CHT Docker Helper.


@mrjones should we also update GitHub - medic/nginx-local-ip: HTTPS Nginx reverse-proxy: public URLs to expose your local webapp in your LAN to use this new service?

Thanks for calling that out @jkuester ! It was on my to-do list, but I’ve gone ahead and filed a ticket against the project and we’ll update it is soon.

Thanks @mrjones, docker helper is really useful!

Some observations I made while trying it out:

  1. Compose v1 is approaching EOL in June 2023 and it’s the default version in use by CHT docker helper. I’ll paste the exception thrown here so that it’s searchable in case anyone runs into a similar issue while using compose v2:

    Traceback (most recent call last):
      File "/usr/local/bin/docker-compose", line 5, in <module>
        from compose.cli.main import main
    ModuleNotFoundError: No module named 'compose'

    To get around this I updated this line:

    docker-compose --env-file "./$projectFile" --file "$homeDir/upgrade-service.yml" up --detach


    docker compose --env-file "./$projectFile" --file "$homeDir/upgrade-service.yml" up --detach

  2. I had DNS problems using the address. Queries are not being responded to by, see dig results:

    ➜  helper4 dig  
    ; <<>> DiG 9.18.12-0ubuntu0.22.04.1-Ubuntu <<>>
    ;; global options: +cmd
    ;; Got answer:
    ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 58914
    ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
    ; EDNS: version: 0, flags:; udp: 65494
    ;	IN A
    ;; Query time: 283 msec
    ;; SERVER: (UDP)
    ;; WHEN: Mon May 08 08:27:29 EAT 2023
    ;; MSG SIZE  rcvd: 67 was responding:

    ➜  helper4 dig            
    ; <<>> DiG 9.18.12-0ubuntu0.22.04.1-Ubuntu <<>>
    ;; global options: +cmd
    ;; Got answer:
    ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 53796
    ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
    ; EDNS: version: 0, flags:; udp: 65494
    ;	IN	A
    ;; ANSWER SECTION: 5263 IN	A
    ;; Query time: 0 msec
    ;; SERVER: (UDP)
    ;; WHEN: Mon May 08 08:32:40 EAT 2023
    ;; MSG SIZE  rcvd: 73

I used conventional ports in my docker helper configuration i.e. 80 & 443.

@elijah - thanks so much for the feedback!

I was actually just thinking that we should audit all of our projects and settle on docker compose, which as you cited, is explicitly v2. We do have a lot of docker-compose (which can actually be v1 or v2, so it’s confusing!). We’ll look into this!

On the DNS front, that’s frustrating to hear after all the issues we had with DNS! However, it’s really, helpful to know about - thank you!

Out of of curiosity, do other resolvers work, like Can you run this and let me know what you get back?

dig  +short @


Thanks @mrjones for the ideas around these issues. I haven’t tried with other DNS resolvers and the dig + short command combination resolves correctly to

Thanks for reporting that the dig command against works. You might consider switching to that DNS provider (Quad 9) or another of your choosing if that solves for the LAN your working on (at the router) or for just the clients (per laptop or phone).

Also I wanted to note that I’ve opened an issue to standardize Medic’s use of compose on docker compose. Thanks again!

1 Like

@elijah - I found and fixed a recent issue with DNS for * I’d be curious if your same dig command works for you now?

1 Like

Hello again! @jkuester and anybody else following along - a quick note to mention that both nginx-local-ip and the TLS helper scripts (see ./add-local-ip-certs*.sh( have been updated to use the new provider. We’ll soon be updating our docs as well!

1 Like

Thanks @mrjones!

Short version: I tested using Google’s dig tool on android and received the expected response:

id 41661
opcode QUERY
flags QR RD RA
;ANSWER 21600 IN A

Long version:
I had discovered that my router’s DNS is hard coded to use for DNS queries with as secondary. The only option I had to fix this was update Ubuntu’s DNS lookup to use using this guide and I’ve been able to work with CHT docker helper since then.
Rather than undo this update for this latest round of testing, I tested using Google’s online dig tool from my android device and it works! I think we can rely on this result and it would be great to get more varied test results from the community across DNS providers to ensure it works for everyone.

Thanks for the update @elijah !

One of the benefits of a the * URLs resolving LAN wide (internet wide even!) is that you can seamlessly test mobile devices as the URL is resolvable, accessible and has a valid TLS cert. Getting the DNS to work beyond using Quad9 directly on your workstation is a big win!