Open adunkman opened 3 years ago
If we had DNSSEC enabled, we could protect against issues such as #775 (only one set of records would be signed and authorized).
Search.gov has had a rough experience with DNSSEC, but it sounds like it would be significantly easier today now that Route53 supports DNSSEC, and the Tax Court is using Route53 for all domains + subdomains in question.
For us to get the benefits of DNSSEC, it would require enabling at all the relevant hosted zones — the ustaxcort.gov level as well as in development (ef-cms.ustaxcourt.gov) and then in production (dawson.ustaxcourt.gov).
Would require collaboration with Court OIS team to get the ustaxcourt.gov
and .gov
.
Will document what we learned to ready this for when we have more bandwidth.
Enabling DNSSEC (guide on how to do so on Route53) is done in two steps:
DS
record to the parent hosted zone (up through .gov
).For the US Tax Court, that would mean our steps will be:
ustaxcourt.gov
.ef-cms.ustaxcourt.gov
.DS
record to ustaxcourt.gov
for the subdomain.dawson.ustaxcourt.gov
.DS
record to ustaxcourt.gov
for the subdomain.I’ve also spoken with devs over at login.gov, and they’re keeping their eyes out for others to go first. I think we’re a bit ahead of the curve on this issue, and it would be beneficial to do this when others have "lessons learned" ready to share and we have the capacity to coordinate across the org on it.
Punting it back into the backlog!
Here’s an example implementation for Route53, in case it’s useful in the future: https://github.com/GSA/datagov-ssb/pull/99
Our Email architecture documentation reads:
This is no longer true:
Background
From the email documentation: