fix(hostedzone): Set NS record's TTL to 900

[yngvark]

Description

Set TTL of NS record to 15 minutes when creating a hosted zone.

Motivation and Context

When users delete a cluster, and creates it again with the same domain name, okctl create fails. This is due to DNS resolvers having cached a now outdated NS record for the domain. The step immediately after creating a hosted zone, create cognito identity pool, fails.

And because users frequently creates and deletes clusters when testing okctl for the first x times, they will run into this quite often.

The current problem before this PR is something like this (not 100% sure here): After a delete cluster, and when trying to create it again, oslo.systems's NS records correctly points to the new NS record of mycluster.oslo.systems. However, the NS record of the old mycluster.oslo.systems had TTL two days, meaning DNS resolvers still will return the old NS record. So when okctl create (or anyone) attempts to use mycluster.oslo.systems for anything, DNS resolvers will ask the old NS name servers to do lookups, making any request fail to mynewcluster.oslo.systems fail. For instance, getting the A-record of myapp.mycluster.oslo.systems will resolve to the IP of myapp in my previous cluster.

By setting the TTL to 900 seconds, the user can just wait 15 minutes, instead of two days, after deleting a cluster before creating it again.

Why 900 secs / 15 minutes? Because this observation: https://blog.apnic.net/2019/11/12/stop-using-ridiculously-low-dns-ttls/

The number of required queries drops from 47% to 34% by setting a minimum TTL of 5 minutes, to 25% with a 15-minute minimum, and to 13% with a 1-hour minimum.

Our users can increase to 1 or 2 hours later when they are done testing, 15 minutes seems like a good sweet spot to facilitate multiple runs of okctl and a inefficient and too low TTL.

How Has This Been Tested?

Manually.

Screenshots (if appropriate):

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)

Checklist:

• My code follows the code style of this project.
• My change requires a change to the documentation.
• I have updated the documentation accordingly.
• I have added tests to cover my changes.
• All new and existing tests passed.
• I have updated the release notes (for the next release).

[deifyed]

Looks good!

Maybe we could add a default value to the NSTTL somewhere? Not sure if its needed, I'd just prefer to not have to read deep into DNS RFC's to figure out a sane value when using the create hosted zone function in the future

[ivaruf]

Looks good 👍

[codecov]

Codecov Report

Merging #231 (296e291) into master (e13a4ca) will decrease coverage by 0.24%.
The diff coverage is 0.00%.

@@            Coverage Diff             @@
##           master     #231      +/-   ##
==========================================
- Coverage   38.51%   38.26%   -0.25%     
==========================================
  Files         102      102              
  Lines        2942     2961      +19     
==========================================
  Hits         1133     1133              
- Misses       1809     1828      +19     

Impacted Files	Coverage Δ
pkg/api/core/service_domain.go	0.00% <0.00%> (ø)
pkg/route53/route53.go	20.00% <0.00%> (-18.10%)	⬇️
pkg/api/core/service_certificate_api.go
pkg/api/core/service_cluster_api.go
pkg/api/core/service_vpc_api.go
pkg/api/core/service_domain_api.go
pkg/api/core/service_parameter_api.go
pkg/api/core/service_identitymanager_api.go
pkg/apis/okctl.io/v1alpha1/cluster_v1alpha1.go
pkg/client/store/filesystem_store.go
... and 10 more

[sonarcloud]

Kudos, SonarCloud Quality Gate passed!

0 Bugs
0 Vulnerabilities
0 Security Hotspots
0 Code Smells

No Coverage information
0.0% Duplication