How to have bad domain in config skipped

(Brian) #1

Hello. I am running 0.9.1 and would like to find out how I can have caddy skip a bad domain inside the configuration file. When TLS certificate is not able to resolve (for example a brand new domain) it will fail and not have any of the sites in the configuration file work. Ideas or comments? Sucks to have all 100 sites go down because 1 site’s DNS isn’t operating properly.

Behavior of automatic HTTPS on failure to generate cert
(Matt Holt) #2

Hey Brian, thanks for your request.

This is a common misunderstanding. Caddy doesn’t take all the sites down just because one can’t be served. If you are initially starting Caddy, there is nothing to take down because it was not running before. If you are reloading Caddy (signal USR1), it rolls back on error and doesn’t take your existing sites down.

Caddy needs to get verification from a third party (a certificate authority) before it can serve your site. If it can’t do that, it won’t. A half-working zombie server is not a good alternative because you would not want your web server running only some of your config, for the same reason you would not want to execute a truncated shell script.

In a sense, this is the same as nginx. If you tell nginx to bind to a hostname that can’t be resolved, it can’t start. From nginx’s Pitfalls and Common Mistakes page:

You should never use a hostname in a listen directive. While this may work, it will come with a large number of issues. One such issue being that the hostname may not resolve at boot time or during a service restart. This can cause NGINX to be unable to bind to the desired TCP socket which will prevent NGINX from starting at all.

With Caddy, our philosophy is a little different. Because security is not considered optional, you should use your real site name in the Caddyfile so that Caddy can serve your site securely for you. But this requires third party verification. Caddy won’t take your site down, but it won’t start when it knows there is a security problem.

Caddy Frequently Asked Questions (FAQ)
(Brian) #3

Thank you very much for the details and explanation. I greatly appreciate it and definitely understand. I’m not a super techy person and have already restarted a server/service with the restart command. What it did past that I assume is the proper and correct way to stop then start back again. I suggest maybe have specific/detailed instructions on how to properly restart the caddy server without having to require restarting it.

I have looked on google to find more details about doing a signal USR1 but don’t find too much other than other services (nginx/apache/etc) have it integrated with a command like -k or similar. I looked at the caddy --help to see if it has a syntax on how to include it, but it doesn’t have information on that. Also I looked on the which includes the Signals, but no example of how or where in the cli to include this.

(Michael) #4

I mainly use htop to send the USR1 signal as it also enables me to see, if it worked right away.

(Brian) #5

Thank you for the suggestion. So I tried that:

  1. ran htop
  2. found the PID running caddy
  3. went into caddy file and removed a domain
  4. go back into htop, I press F9 to kill, then select SIGUSR1
  5. i check to see if the site is up or down, and it’s still up even though I removed it from the configuration file

any suggestions?

(Matt Holt) #6

The log would probably tell you why; if you run caddy with -log and specify a log location you can get that information.

(Michael) #7

As suggested by matt the assumption is, that the new caddyfile has an error and therefore will not restart, but instead of killing the old process it waits for a new signal and a correct caddyfile.

(Rodney Hester) #8


Actually, nginx’s admonishment about using hostnames in listen directives is quite valid, and doesn’t differ at all from Caddy’s philosophy, as it’s equivalent in Caddy is “bind” - and rare indeed are the scenarios where you want Caddy binding to an address by DNS name rather than direct IP, as you will fail utterly with any issues (configuration, outage, etc.) concerning local DNS.


(Matt Holt) #9

It is definitely valid (which is why I quoted it) – I agree with their technical reasoning, but let me explain what I mean when you say:

What I mean is that Caddy’s philosophy is different by design and purpose. 1) Sites are defined by their name/address, not listening interface. 2) Third-party verification is considered an essential part of serving the (production) site, which does require a DNS lookup. Indeed, you can customize Caddy’s listen address with the bind directive, but with nginx the DNS is optional. With Caddy it isn’t.

(system) closed #10

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.