> > On Thu, Nov 12, 2015 at 4:05 PM, Hugo Landau <[email protected]> wrote: > >> Currently, the DNS challenge uses a random token which changes every >> time an authorization is performed. >> >> This seems problematic, however. Changes to DNS can take time to >> propagate, > > > If the issuer of the DNS challenge flushes its DNS cache and checks with > the authoritative server itself, the propagation delay doesn't seem like > an issue. Are there particular issuers/conditions for which you believe the > issuer would have to rely on caching resolvers? >
For certain dns provider, you are given the ability to change dns configuration using an api (eg: ovh.com), but you don't have any guaranty on the time it will take for the changes to be applied. In my current dns implementation I had to make sure that the authoritative server where up to date before submitting the challenge response. Another approach would be to retry several times on the acme server (let's say 3 times respectively after 5min, 15min, 1h) before considering the challenge as failed. > and changes to DNS may involve manual intervention. If an >> authorization fails for any reason, the process has to be started again. >> > > But isn't that the point? We're looking for a demonstration that they > are capable of making a specified change. > If you really want to change the challenge each time, I would suggest using a new dns prefix for each challenge (eg: _ acme-challenge_zbn9gshv.example.org). This would solve the cache issue, and perhaps increase the security as an attacker would also have to guess the proper prefix.
_______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
