I would like to use single boulder instance to test several services with letsencrypt clients. For that I have found that using FAKE_DNS is inconvenient. I effectively have to restart the boulder with different FAKE_DNS pointing to a particular client. I tried to disable the internal fake dns service and pointed boulder to the real dns server provided by a Docker network, but that now generates an error:
DNS problem: server failure at resolver looking up MX for …
Is it possible to disable that MX lookup so just having DNS entries for my services is enough to test the boulder?
We recently landed a change to treat DNS timeouts during email validation as a soft fail. So one workaround for your situation would be to set the DNS timeout at the RA to 0. I’m surprised, though, that Docker’s DNS is producing a SERVFAIL for MX lookups as opposed to NOERROR. Do you know how it’s implemented under the hood?
I do not now about DNS implementation details, but what I observed is that LookupMX in bdns/dns.go gets EOF from dnsResolver.exchangeOne() under Docker DNS proxy. Note that dig mail.domain MX running from the same container works.
Apparently I run rather old boulder build that has not implemented soft timeout. With the latest tip my test installation passed through email registration. However now my test setup fails when boulder checks for CAA. As with MX records, the boulder DNS client returns EOF as an error after asking Docker DNS proxy for an CAA record.
The problem is that boulder always uses TCP to talk to the DNS server, https://github.com/letsencrypt/boulder/blob/master/bdns/dns.go#L193 . I suspect that either Docker DNS proxy does not support querying MX or CAA records over tcp or perhaps the github.com/miekg/dns client that boulder uses incorrectly interprets empty read (0, EOF) for DNS tcp reply from Docker proxy as an error, not as no-record-found indication.
In any case, the moment I changed that line to “udp”, boulder test setup started to work.