Comments (5)
Thanks so much for the detailed feedback, this is really great! I'm glad it's working well in Sandstorm for you.
As you noted, ACME.js does have its own propagationDelay
, but this doesn't seem to work with greenlock.js (how we use it internally), thus the need for the verificationProgation
option. We don't use this directly with ACME.js, so never ran into the double propagation issue. There's an open PR to fix this for greenlock, but it's been pending for months. The main reason we added this feature was just due to the sheer number of DNS related failures we were having without it, and whilst this doesn't (and really can't) solve them all, it does greatly reduce them.
You're also absolutely right regarding the DNS caching problems, and it's very much an estimate, since there's no way to really know where/when/how Let's Encrypt are going to query for that record, or if it's going to be cached. DNS is "fun" in this regard, and a better way to guarantee this would be awesome, but I'm just not sure there is one. Even if this plugin reports everything as 100% successfully propagated, there's still a chance that when Let's Encrypt query for the record content, it's going to be stale, and fail.
Regarding the specific ideas for improvement:
Perhaps acme-dns-01-cloudflare should set propagationDelay to something like 15 seconds when verifyPropagation is off, and zero when it is on. That'll silence the warning and should provide reasonable behavior either way.
This is a good suggestion, I'll implement this.
When verifyPropagation is on, wait 5-10 seconds before the first verification attempt. This should make verification take less time overall since it won't pollute caches in the common case that propagation happens quickly.
Great feedback. I'll definitely implement this.
When verifyPropagation is on, the stderr output is pretty verbose and makes it look like things are going horribly wrong when in fact it's working as intended.
Great feedback. The latest version in git actually does hide these logs behind a verbose
config option, but this hasn't hit npm yet. I think reducing the output as suggested, and the new verbose
logging option should make this much nicer.
I noticed that even when verifyPropagation is off, the plugin seems to verify deletions. But deletions only happen as the very last step of the ACME.js process and there's really no need to verify them, so this just adds a lot of stderr spam for no reason. Maybe verification of deletions should be skipped?
This should only be happening when verifyPropagation
is on, but I'm not sure about skipping it entirely. I'll think about this and any possible side-effects this may cause.
from acme-dns-01-cloudflare.
Published most of these suggested changes in 1.2.0
. Thanks for the fantastic feedback!
from acme-dns-01-cloudflare.
Huh, doesn't greenlock.js itself use ACME.js?
This should only be happening when
verifyPropagation
is on
Hmm, this morning when I tried turning the option off I still saw it verifying deletions, but not creations. Though maybe what actually happened was that the option was still on somehow but the creation succeeded on the first verification attempt? Still, I was pretty sure I had turned it off... I guess I'll try testing it some more later.
from acme-dns-01-cloudflare.
Huh, doesn't greenlock.js itself use ACME.js?
It does, but the propagationDelay
gets stripped somewhere in the middle of the challenge module being passed around greenlock to ACME.js.
Hmm, this morning when I tried turning the option off I still saw it verifying deletions, but not creations.
I should have clarified, sorry. It definitely used to be broken in the way you described and was only intended to run when verifyPropagation
was on - this was fixed in a8e4d40#diff-168726dbe96b3ce427e7fedce31bb0bcR111-R116
from acme-dns-01-cloudflare.
Awesome, thanks for the changes!
from acme-dns-01-cloudflare.
Related Issues (14)
- Fails to resolve challenge when requesting wildcard of subdomain HOT 22
- Promise.reject() should take Error instead of string HOT 5
- HTTPError: Response code 400 (Bad Request) HOT 5
- Example / Greenlock broken HOT 4
- Over-eager zone matching HOT 3
- Log errors when applying for certificates (Cloudflare) HOT 3
- Update README with ACME.js example HOT 1
- Error the "id" argument must be of a type String HOT 10
- Using with Greenlock-Express HOT 1
- Add CI pipeline for testing (GitHub Actions) HOT 5
- Action required: Greenkeeper could not be activated 🚨 HOT 2
- [Bug ?] doesn't seem to ever be able to perform domain validation HOT 2
- API Token requires access to all zones on account HOT 8
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from acme-dns-01-cloudflare.