- Sponsor
-
Notifications
You must be signed in to change notification settings - Fork 4.1k
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
Caddy 2.0 resolving addresses #3518
Comments
Thanks for opening an issue! We'll look into this. It's not immediately clear to me what is going on, so I'll need your help to understand it better. Ideally, we need to be able to reproduce the bug in the most minimal way possible. This allows us to write regression tests to verify the fix is working. If we can't reproduce it, then you'll have to test our changes for us until it's fixed -- and then we can't add test cases, either. I've attached a template below that will help make this easier and faster! This will require some effort on your part -- please understand that we will be dedicating time to fix the bug you are reporting if you can just help us understand it and reproduce it easily. This template will ask for some information you've already provided; that's OK, just fill it out the best you can. 👍 I've also included some helpful tips below the template. Feel free to let me know if you have any questions! Thank you again for your report, we look forward to resolving it! Template
Helpful tips
Example of a tutorial: Create a config file: |
Updated with more info, feel free to delete this and the template response. |
The problem is that something in your network stack is causing localhost to resolve to something different than 127.0.0.1 or ::1 Caddy tries to bind to localhost:2019 for its admin API to provide features like graceful config reloading and changing the config on the fly. You can either fix your DNS to properly make localhost resolve to a loopback address like it should, or use the |
Every other tool I've ever used never tries to resolve
Even if I were to use something else, why is Caddy trying to resolve in the first place? |
Why is your DNS resolver answering with a non-loopback IP? Caddy just does what Go does, and that is respect your DNS settings. (Unlike Chromecast, which hard-codes its DNS resolvers, mmph.) The admin endpoint binds to I would either:
to solve the problem. |
I fould this issue from 2017 in the golang repo golang/go#22846, where Go apparently decides if the By creating this with A followup of that issue is found at golang/go#35305, where they're considering not following the glibc standard of DNS > /etc/hosts when no /etc/nsswitch.conf is present. |
@p3lim Nice detective work, that's actually really good to know. Thanks for finding that! I'll point people this direction if they report a similar issue. |
@p3lim so if you make a Dockerfile based on the Caddy docker image and add this line, it fixes the problem? https://github.com/docker-library/golang/blob/master/1.14/alpine3.12/Dockerfile#L9 Looping in @hairyhenderson, if that works we should probably add that to the Caddy image by default. The official golang alpine image includes that workaround as well, so I definitely think there's precedent for doing it in the Caddy image as well if it fixes this sort of problem. I don't understand how the environment should look exactly to reproduce this issue either. If you're able to describe how the system should be set up to replicate, that would be helpful so we can test workarounds. (Reopening while we make a decision regarding the docker image, might move this issue to the Edit: For reference, this is what I have in my
|
@francislavoie Yes, and I've seen quite a few other images do that as well (kubernetes control plane, traefik, fluxcd, influxdata, and many many more). Providing the hosts specific part should be enough. Edit: To reproduce, simply use a system that doesn't depend on glibc, like Alpine (or perhaps Void, I think they use musl too), glibc provides For reference, on a Fedora 31 box:
|
Alright I think we can close this now. Thanks @p3lim for the help 😄 |
1. Environment
1a. Operating system and version
Although this issue should be present on any distribution.
1b. Caddy version (run
caddy version
or paste commit SHA)From the assets on GitHub releases. Also tested with v1.0.3, also from the release assets.
2. Description
2a. What happens (briefly explain what is wrong)
I run
caddy run
with the following adjacent Caddyfile:And assume that this will run, presenting me with a locally accessible web directory. Caddy fails to start, see the logs in 2c.
2b. Why it's a bug (if it's not obvious)
This used to work in v1.x, with the following Caddyfile:
The problem is that with a typical (but depending on the distribution - modified) resolvconf (
/etc/resolv.conf
) where the search path and/or the nameserver is non-default, Caddy (or a library Caddy/certmagic is using) will try to resolve the address/hostname configured in the Caddyfile before starting.Assuming this
/etc/resolv.conf
file:Everything works (the
local
search path is the default, unless DHCP provides one).Change either of those to something non-default (like the search path to something internal like
search mydomain.com
, or the nameserver to a DNS that with records that would resolve the address/hostname in the Caddyfile to a different IP than the host's), it fails with the attached error.The problem is that Caddy (or a library it's using) attempts to resolve the address/hostname before starting, which is unneccessary and will break in a situation like this.
2c. Log output
The host I ran Caddy on was not
10.0.1.3
, my internal DNS has a wildcard A record pointing to that adress as a black hole.Essentially, Caddy tried to resolve
127.0.0.1.lab
.2d. Workaround(s)
local
(not feasible/wanted in a properly configured network/environment)2e. Relevant links
Referencing this issue: caddyserver/caddy-docker#44
3. Tutorial (minimal steps to reproduce the bug)
Assuming DHCP provides a search path and/or nameserver that is non-standard like descibed above, or manually modify
/etc/resolv.conf
to provide a custom search path and/or a nameserver that has127.0.0.1.lab
as a configured record.The text was updated successfully, but these errors were encountered: