It's useful for the the primary VA to know what its backend perspectives are. It can check at startup that all its perspectives are distinct. And it can log errors by perspective even when those errors are due to a perspective being down.
However, there's a risk that the primary VA could be configured wrong: it could think a given backend is perspective A, when actually it's perspective B. In fact, a given SRV record could mistakenly resolve to a pool of backends with some in perspective A and some in perspective B!
We can add some double-checking here. We should have the primary know which perspective each of its backends is in, and assert that in each RPC. The backends (remotes) should also know what perspective it considers itself to be in. They can check the asserted perspective against the locally configured perspective, and return an error if there is a mismatch.
Discussed in https://github.com/letsencrypt/boulder/pull/7817#issuecomment-2479618426 and at standup.
It's useful for the the primary VA to know what its backend perspectives are. It can check at startup that all its perspectives are distinct. And it can log errors by perspective even when those errors are due to a perspective being down.
However, there's a risk that the primary VA could be configured wrong: it could think a given backend is perspective A, when actually it's perspective B. In fact, a given SRV record could mistakenly resolve to a pool of backends with some in perspective A and some in perspective B!
We can add some double-checking here. We should have the primary know which perspective each of its backends is in, and assert that in each RPC. The backends (remotes) should also know what perspective it considers itself to be in. They can check the asserted perspective against the locally configured perspective, and return an error if there is a mismatch.