Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support for local server as dns provider #1620

Open
5 tasks done
paragor opened this issue Apr 10, 2022 · 2 comments · May be fixed by #1621
Open
5 tasks done

Support for local server as dns provider #1620

paragor opened this issue Apr 10, 2022 · 2 comments · May be fixed by #1621

Comments

@paragor
Copy link

paragor commented Apr 10, 2022

Welcome

  • Yes, I've searched similar issues on GitHub and didn't find any.
  • Yes, the DNS provider exposes a public API.
  • Yes, I know that the lego maintainers don't have an account in all DNS providers in the world.
  • Yes, I'm able to create a pull request and be able to maintain the implementation.
  • Yes, I'm able to test an implementation if someone creates a pull request to add the support of this DNS provider.

How do you use lego?

Binary

Link to the DNS provider

Link to the API documentation

Additional Notes

I use coredns as my dns server, it does not support rfc2136 (dyndns), but i can use forward request like:

_acme-challenge.foo.com {
    forward . 127.0.0.1:5353
}

So I suggest running a local dns server to serve wildcard dns requests.

@ldez
Copy link
Member

ldez commented Apr 10, 2022

Hello,

you can use:

@benaryorg
Copy link

The setup that I have in place currently, but looking to possibly replace with lego for the sake of using tools that automate this task, is built on the principle of having an NS record for every server's _acme-challenge pointing to the server itself.
Example:

server.example.com.                     128     IN      AAAA  2001:db8::1
_acme-challenge.server.example.com.     128     IN      NS    server.example.com.

This has several advantages, like every server being entirely self-sustainable in terms of DNS needing only the authoritative nameserver to respond to queries in a way that is predictable and easy to automate, it even works programmatically without any configuration required per service and it alleviates all necessity for credential management.
It also does not require an "always on" service that is accessible at any time, instead the DNS service is only required at time of authorization.

Hello,

you can use:

* https://go-acme.github.io/lego/dns/exec/

* https://go-acme.github.io/lego/dns/httpreq/

This leads me to my point in regards to the methods suggested here; httpreq doesn't work in my case at all because no service is actually running, while exec with its current interface would require significant boilerplate code to ensure that the service is stopped.
The setup I have currently in place (shameless plug) starts a dnsmasq process on demand, and ensures that after the authorization has gone through, or a timeout has been hit the process is always shut down again.
The exec interface offered by lego does offer no such mechanic.

The code provided in #1621 would solve my issue exactly, as the built-in server could then simply host the response for the DNS query on demand and shut down right after that, at least as far as I can see.
I've glanced over the code but seeing as I'm not a golang person I'm very hesitant to give it my approval as part of a GitHub review.
If anyone could have a look at the code, that'd be great!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Development

Successfully merging a pull request may close this issue.

3 participants