Dorian and me retested the configuration this Monday evening, with the same findings.

So it's definitely ns1.he.net, because if I put slave.dns.he.net the TCP connection isn't established:

Claude Sonnet artifacts

I think configuration could actually be nice but I forgot in D3766 to bump the serial. Let's check (and do a test to detect that).

Dorian and me meet this evening to do the switch.

Not spot anymore. Python 3.11 is used on every FreeBSD systems now.

Closing as a duplicate, as with T1217 task, automation is there:

• new records can be submitted as a commit against zone file
• new zones can be added by creating a new file and pillar entry

Per T2105, current solution is to use an external provider (Hurricane Electric?) to host our secondary zone.

To reduce Python issues, one of the solution could be to switch to acme.sh

DNS change

Both are already set in DNS:

We use a wildcard certificate, so issuewild is needed, yes.

D3291 can be use to deploy, IP in DNS record has been also been modified to match the server, not the IPFO.

Iodine is still maintained, and the DNS is already configured for Ysul, so why not reevaluate it with a live demo?

Even with correct SRV records, no HTTP request reach nginx, neither on www1. or packages.

Comparing to pkg.pfsense.org, we only use subdomains, not full domains:

This is a blocker for the use of pkg.

Documentation for HTTPS isn't clear, perhaps we should check the pkg source code for the exact seek.

DNS record according the documentation:

I guess it would make sense to manage DNS records as a Git repository.

The server works fine. Next step is to integrate Certbot or any other client with it and create relevant CNAMEs.

Server is deployed on Equatower.