This should have been added in the HTTP/3 commits[2][3], but it was my
understanding that it was not supported by Hetzner DNS. It apparently is
supported but not documented.

Cloudflare has a blog post[4] explaining how this speeds up HTTP/3
negotiation. Basically, the clients can connect over HTTP/3 right away,
rather than having to connect with an older protocol (probably HTTP/2 in
our case) and then upgrade to HTTP/3 (based on the Alt-Svc header).

Our domains are HSTS preloaded[1], so it would not speed up HTTPS
negotiation in most cases.

[1] https://datatracker.ietf.org/doc/html/rfc9460
[2] 8dfa7e8c ("nginx: Add plumbing for enabling HTTP/3 conditionally")
[3] 28e0f03c ("Enable HTTP/3 for {,aur.,wiki.}archlinux.org")
[4] https://blog.cloudflare.com/speeding-up-https-and-http-3-negotiation-with-dns
[5] https://hstspreload.org/

Ref #606

pkgbuild_org_a    -> pkgbuild_com_a
pkgbuild_org_aaaa -> pkgbuild_com_aaaa

Initial setup bootstrapped from arch-boxes repo [1], default user 'arch'
removed after.

https://gitlab.archlinux.org/archlinux/arch-boxes/-/jobs/157024/artifacts/browse/output



Signed-off-by: Leonidas Spyropoulos <artafinde@archlinux.org>

New feature by Hetzner, primary IPs are a way to manage addresses
assigned to each cloud server. This allows having IPv6-only boxes.

Useful if we wanted to create a Geo-based archive consisting of machines
in the archive_mirrors group (though this will likely not happen because
it'd break archlinux-repro due to the ~4 hour sync delay).

Its disks were migrated to a new server (prompted by an unsolvable issue
with the previous box's network interface; might have been a mobo issue).

There's a bit of a chicken and egg situation here but it's preferable to
manage the server's attributes the same way as all of the cloud servers.

We want non-DevOps to be able to deploy project documentation (ex:
repod) with GitLab Pages and a separate domain was considered the only
sensible solution due to security issues[1].

[1] https://github.blog/2013-04-09-yummy-cookies-across-domains/

asia.mirror.pkgbuild.com has been offline for 12 days so far while we
wait for a NIC replacement. Should have taken it out of DNS NS duties
earlier but better late than never.

When adding a new geo domain or doing other testing, we would want to
use a low TTL to allow for making quick changes to the configuration.

- add the new role to redirect.archlinux.org
- release mirror.pkgbuild.com of all DNS duties

New hcloud adds protection fields to servers, volumes and floating IPs.

Gives the option to downgrade a server in the future, similar to the
default on Hetzner's Cloud Console ("CPU and RAM only").

Sven considers this location to have higher capacity and reliability.

Follow-up to [1]; while most of our cloud servers are in Helsinki, the
latency from most of Europe is lower when accessing servers in Germany.

Pinging from multiple locations using ping.pe, the latency to Nuremberg
from most locations appears to be 10-20ms lower (compared to Helsinki).

[1] !500

Kristian Klausen authored 3 years ago and Jelle van der Waa committed 3 years ago

With Hetzner now having a datacenter in the US[1], we don't want to
accidentally create a server in the US, so let's always create them in
Helsinki where most of our cloud servers are.

[1] https://www.hetzner.com/news/11-21-usa-cloud/

machine.domain has been an mandatory attribute which creates
<domain>.archlinux.org entries automagically. For migrations this can be
a problem if <domain>.archlinux.org supposed to point to a different
machine. Adding the new machine with the same domain leads to additional
DNS entries. The DNS ends up pointing to both machines in this case.
By making the domain attribute optional for machines, we allow the new
machines to be created without any domain pointing to them.

Kristian Klausen authored 4 years ago and Frederik Schwan committed 4 years ago

We need to keep the balance between automation and readability.