Yes, that’s right. I am going to try to clarify.
I wanted to send back a 410 when there is no match in caddy. This means that if someone sent me 10000 requests to https://req1.swtk.eu, https://req2.swtk.eu, … https://req10000.swtk.eu, Let’s Encrypt would have been queried 10000 times and I would have hit the quota somewhere in the meantime.
This is a danger that is clearly documented and the solution is to have a database that keeps of the names that have been configured. This is fine, but not relevant to my case because I do not know which domain will be requested.
Hope this is better now.
As for the “why” part: I do not care about forged requests but I have monitoring set up for my services (applications behind caddy). I can have two cases of replies (in addition to a correct one):
- if an application really fails (crashes, does not respond, …) I will get a
50xreply and this is for me the signal that something is wrong with my app. - if an application that existed has been removed (deleted), it would be the case of the “forged” URL and I would like to respond with the
410. This will be a signal for me that I have to fix the monitoring
This is in reality a nice to have - I am not Google and have, what, 30 services or so. I add or remove one maybe once a month or even less so whatever I get in the monitoring will mean “something needs to be fixed”. It would be just aesthetically pleasing to differentiate the two cases.
Another thing is that I have a generic domain attacked through typical means - notably though the public certificate log, so for known (and at some point registered) FQDNs. I do not expect to be DDoSed with the 10000 forged URLs I mentioned earlier so I could go for it, use on-demand TLS and hope for the best (worst case I will need to wait until the quota is reset)