GeezerVison is showing github.com — DNS-01 responder creates incorrect DNS records in Route53 · Issue #419 · haproxytech/dataplaneapi
DNS-01 responder creates incorrect DNS records in Route53 #419DescriptionWhen using the route53 provider, with a certificate for foo.bar.example.com and a hosted zone of bar.example.com, DPAPI ends up creating the DNS record _acme-challenge.foo.bar.example.com.bar.example.com rather than _acme-challenge.foo.bar.example.com. I'm not sure if this affects other providers.
The (anonymized) logs are as follows:
time="2026-10-07T03:17:31Z" level=debug msg="events: new: 'Oct 7 02:52:07.891746 acme deploy @acme_certs/test thumbprint aJ6h23ZTBFaDSczvi4uF_QI99mJJ6JzPrev32AjAVkc\nprovider-name \"route53\"\nacme-vars \"region=us-west-2,access_key_id=************,secret_access_key=*************,hosted_zone_id=************\"\ndns-01-record \"1ugpdr7wIGxDVLw4McLM5Fr6W8yxxft6FXqagaApqV0\"\n{\n \"identifier\": {\n \"type\": \"dns\",\n \"value\": \"foo.bar.example.com\"\n },\n \"status\": \"pending\",\n \"expires\": \"2026-10-14T02:52:07Z\",\n \"challenges\": [\n {\n \"type\": \"dns-persist-01\",\n \"url\": \"https://acme-staging-v02.api.letsencrypt.org/acme/chall/******/******/******\",\n \"status\": \"pending\",\n \"issuer-domain-names\": [\n \"letsencrypt.org\"\n ]\n },\n {\n \"type\": \"dns-01\",\n \"url\": \"https://acme-staging-v02.api.letsencrypt.org/acme/chall/********/*******/******\",\n \"status\": \"pending\",\n \"token\": \"*****************\"\n },\n {\n \"type\": \"tls-alpn-01\",\n \"url\": \"https://acme-staging-v02.api.letsencrypt.org/acme/chall/*******/******/******\",\n \"status\": \"pending\",\n \"token\": \"****************\"\n },\n {\n \"type\": \"http-01\",\n \"url\": \"https://acme-staging-v02.api.letsencrypt.org/acme/chall/********/********/********\",\n \"status\": \"pending\",\n \"token\": \"************\"\n }\n ]\n}'"
time="2026-10-07T03:17:31Z" level=debug msg="events: acme deploy: foo.bar.example.com: using DNS provider route53"
time="2026-10-07T03:17:31Z" level=debug msg="events: acme deploy: foo.bar.example.com: found DNS zone: \"bar.example.com.\""
time="2026-10-07T03:17:32Z" level=debug msg="-- command socket Server. conf ready..."
time="2026-10-07T03:17:32Z" level=debug msg="-- command socket updating client_native client"
time="2026-10-07T03:17:32Z" level=info msg="Serving data plane at http://127.0.0.1:5555"
time="2026-10-07T03:17:32Z" level=debug msg="-- command socket handleClientNativeClientUpdate stopped"
time="2026-10-07T03:17:32Z" level=debug msg="-- command socket not set (--debug_socket_path). Not running the command socket server"
time="2026-10-07T03:17:32Z" level=debug msg="events: acme deploy: foo.bar.example.com: record created, waiting for propagation. Timeout: 1h0m0s"
time="2026-10-07T03:17:32Z" level=debug msg="events: acme deploy: foo.bar.example.com: using DNS resolvers [10.37.0.2:53], check authoritative servers=true"
time="2026-10-07T03:17:37Z" level=debug msg="events: acme deploy: _acme-challenge.foo.bar.example.com.: using DNS resolvers [ns-235.awsdns-29.com.:53 ns-906.awsdns-49.net.:53 ns-1282.awsdns-32.org.:53 ns-1870.awsdns-41.co.uk.:53], check authoritative servers=true"
As you can see, if successfully creates the DNS record; however, checking Route53 directly shows that the wrong record has been created, so the validation step (which does check the correct record), never sees the newly create incorrect record. Activityphilomory commented on Oct 7, 2026 Ah, I see that this was actually fixed last week, but, isn't in any released build yet.
MetadataMetadataDevelopmentNo branches or pull requestsIssue actions
|