-
-
Notifications
You must be signed in to change notification settings - Fork 612
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
sa: add authz reuse table #7715
Comments
Schema could look like: CREATE TABLE `authzReuse` (
`accountID_identifier` VARCHAR(300) NOT NULL,
`authzID` VARCHAR(255) NOT NULL,
`expires` DATETIME NOT NULL
) Note that As per usual, we should create the new schema in the This will require updating:
I said in the original comment:
This was incorrect, because we currently allow pending authz reuse as well. So to faithfully implement our current behavior we would have to write to the The other possibility regarding pending authz reuse would be to remove it. It exists solely for our benefit1: in the case of clients that are repeatedly requesting the same names but not fulfilling them, it allows us to avoid creating database objects. However, these days order reuse probably fulfills the same purpose and we could turn off pending authz reuse without much impact. We should measure this, and if it checks out we should do it as a precursor to this issue. Also in researching this issue I was reminded that our order-creation process is weird: The RA is responsible for checking if there are any reusable authzs (by calling the Footnotes
|
This isn't quite true today -- we create a new (pending) authz even when there is an existing (valid) authz if that valid authz is going to expire very soon, to ensure that the order (whose lifetime is limited by the shortest authz attached to it) has a reasonably-far-out expiration time. |
You're right. I should have said "so long as authz reuse is working properly, we would never be creating a pending authz if there was a valid authz reusable." In other words, when we create that new pending authz, it's okay to overwrite the |
Edited the initial post to add:
|
Pending authz reuse is a nice-to-have feature because it allows us to create fewer rows in the authz database table when creating new orders. However, stats show that less than 2% of authorizations that we attach to new orders are reused pending authzs. And as we move towards using a more streamlined database schema to store our orders, authorizations, and validation attempts, disabling pending authz reuse will greatly simplify our database schema and code. CPS Compliance Review: our CPS does not speak to whether or not we reuse pending authorizations for new orders. IN-10859 tracks enabling this flag in prod Part of #7715
Right now our authz2 table looks like this:
Those indexes are pretty big, particularly the
regID_identifier_status_expires_idx
one. Among other problems, it has a datetime field, which is high cardinality.One of the main things (only thing?) we use that index for is authz reuse. We can do that more efficiently with a separate table, and we can also design that table to better fit the assumptions of key-value storage: only one key, and it's the primary key.
Roughly speaking, this table would map:
Each time an authz is successfully validated, we would append or update a row in this table. Compared to the current system, this defers some amount of work until successful validation, which is nice because so many validations fail.
We can skip encoding the identifier type, because the only two identifier types we ever plan to support have completely non-overlapping syntax (hostnames and IP addresses).
If we deploy this table in a database that supports TTLs, we would set the TTL of this row to the expiration of the authz, and update it as new authzs are written to it. Old rows would automatically be removed by the database system. If we choose to deploy it in a database that does not support TTLs, we could prepend a rough granularity epoch (e.g. number of 90-day periods since Jan 2024), making the key
(epoch, account, identifier)
. That would allow partitioning and dropping of old partitions.If the key is
(epoch, account, identifier)
, that means querying for authzs to reuse would have to query for multiple keys: one in the current epoch, one in the previous epoch, and potential longer-ago epochs. If we assume the authz lifetime is always less than the epoch (which would be true with our current 30-day authzs and a hypothetical epoch of 90 days), then we would only ever have to query for two epochs, current and previous.To find authzs for reuse for a new order, we would query for the appropriate account and identifier, check the result's expiration, then fetch the corresponding authz (to check whether it has been deactivated). This will require one additional round trip compared to our current system, which queries the authz2 table directly and so gets status right away. This can be a batch query for several identifiers (using
IN
syntax) or it could be several parallel queries.One refinement could be: when an authz2 is deactivated, we delete its row in the reuse table. That would allow us to directly incorporate returned authzs in a new-order without a second query to check their status.
The text was updated successfully, but these errors were encountered: