Boulder doesn’t resolve the actual client IP; instead, it uses the FAKE_DNS-assigned IP

Help
1

Hi, I’m using Boulder for my own project, and it’s up and running. I’ve changed the FAKE_DNS setting to point to my own DNS server. However, when I attempt an HTTP-01 challenge using Certbot from a client, the validation fails with the following error:

"type":"connection","detail":"10.200.6.80: Fetching http://client.srv.net/.well-known/acme-challenge/4tHN-LBSynzI6bW7B06lxPQqOAqymuNUgtqeea44hwE: Connection refused","status":400,"token":"4tHN-LBSynzI6bW7B06lxPQqOAqymuNUgtqeea44hwE","validationRecord":[{"url":"http://client.srv.n/.well-known/acme-challenge/4tHN-LBSynzI6bW7B06lxPQqOAqymuNUgtqeea44hwE","hostname":"client.srv.net","port":"80","addressesResolved":["10.200.6.80"],"addressUsed":"10.200.6.80","resolverAddrs":["A:10.77.77.77:8054","AAAA:10.77.77.77:8053"]}],"Error":"connection :: 10.200.6.80: Fetching http://client.srv.net/.well-known/acme-challenge/4tHN-LBSynzI6bW7B06lxPQqOAqymuNUgtqeea44hwE: Connection refused","InternalError":"10.200.6.80: Get \"http://client.srv.net/.well-known/acme-challenge/4tHN-LBSynzI6bW7B06lxPQqOAqymuNUgtqeea44hwE\": dial tcp 10.200.6.80:80: connect: connection refused","Latency":0.002

The strange thing is that Boulder doesn’t resolve the actual client IP; instead, it uses the FAKE_DNS-assigned IP 10.200.6.80, which results in a connection refusal. is there anything am i missing to point boulder to my client network ?

is boulder uses the port 80 by default for http-01 challenge ?

i really appreciate if anybody can help me on this ?

thanks in advance

2

IIRC boulder uses two stage dns: first one to resolve some internal name to actual dns server, than that unbound server to actually resolve outside names

1 Like
3

I’m really sorry — I didn’t fully understand what you meant or how it applies to my case.
Did you mean that I need to make changes to the Consul configuration as well?
So far, I’ve only updated the FAKE_DNS value in the docker-compose file to 10.200.6.80.

4

If you need a self-hosted ACME CA it might be simpler to use Smallstep step-ca or Hashicorp Vault, both of which are relatively easy to setup. Boulder is more designed for production CA use.

4 Likes
5

hank you for the reply. In fact, the older version of Boulder is working perfectly fine for me.
I’m just trying out the latest version, but I’m not sure if there’s anything else I need to do to point Boulder to a DNS server IP — in other words, is there any configuration required beyond setting FAKE_DNS?

In the older version, the default port for HTTP-01 was not port 80, so I had to change it manually. But as I understand, the latest version uses port 80 by default.

I’m confident it will work fine — I just wanted to confirm:
Is it expected that while resolving the domain, Boulder uses the IP assigned by FAKE_DNS to resolve the IP of the host running Certbot? as you can see my error log the ip is my dns server not the certbot host ip it supposed to be host ip right ? or am i wrong ?

i also can see a dns parameter in docker as below do i have to add my dns server ip here ?

# Use consul as a backup to Docker's embedded DNS server. If there's a name
# Docker's DNS server doesn't know about, it will forward the query to this
# IP (running consul).
# (https://docs.docker.com/config/containers/container-networking/#dns-services).
# This is used to look up service names via A records (like ra.service.consul) that
# are configured via the ServerAddress field of cmd.GRPCClientConfig.
# TODO: Remove this when ServerAddress is deprecated in favor of SRV records
# and DNSAuthority.
dns: 10.55.55.10

thanks in advance.

6

honestly running boulder proper by itself would be full time paying job.
from what I see you'd need to edit console config to different path than make a actual unbound server listing on that port

3 Likes
7

Note that the docker-compose file you're editing and using is not intended for production deploys. It is used by our integration test environment, hence names like FAKE_DNS. As such, it does some things very differently from our real deployment: for example, the same DNS system is used to resolve both the addresses of other Boulder components and the addresses of fake dnsnames which are undergoing validation as part of the tests. You absolutely should not do this in a real deployment.

7 Likes
8

You might also want to read the notes in Boulder #8250 about recent changes to Boulder's ability to use reserved IP address ranges.

6 Likes
9

Thank you for your reply.

I understand that Boulder is not intended for production deployments — we’re fully aware of that — and we've only been using it for an internal use case. The older version works perfectly fine for us.

The version I’m currently testing is from around 5–6 months ago (sorry, I couldn't find the exact version number).

Previously, we were able to simply replace fake_dns with our internal DNS server, and validations would resolve correctly.

However, in the version I'm testing now, after making the same change, Boulder appears to use the internal DNS server’s IP directly instead of resolving to the client’s IP. As you can see from the error, it attempts validation against dns_server_ip:80 instead of certbot_host_ip:80.

Could you please help me understand what’s going wrong here? Has there been any change in the recent versions that affects this behavior? Do I now need to update additional configuration to point Boulder to our internal DNS server correctly?

thank you very much in advance

10

Thank you for your reply.

I’ve gone through the notes, and as I understand it, there has been a recent change affecting Boulder VA’s ability to use private IPs. In my case, this means it no longer allows connections to my internal DNS server IP by default even though the "FAKE_DNS" is specified to the one i needed as a resolver.

As you mentioned, to enable this, should I change the DNSAllowLoopbackAddresses setting to false?

Currently, I can see that this setting is set to true in my VA config. Does changing it to false allow Boulder VA to access internal IPs again?

Thank you in advance.