dihutenosa

Step 1: be psychologically prepared to break it all. Don’t depend on your services, at first, and don’t host stuff for others, for the same reason.

Yunohost? Good for trying out stuff, I suppose. I haven’t tried it myself. You could also try Debian, Alpine, or any other. They’re approximately equivalent. Any differences between distros will be minuscule compared to differences between software packages (Debian is much more similar to Alpine than Nextcloud to Syncthing).

4GB of RAM? Don’t set up a graphical interface. You don’t need a desktop environment to run a server. Connect to it via SSh from your regular PC or phone. Set up pubkey auth and then disable password auth.

I recommend setting up SSH login first, then a webserver serving up HTTP, only, accessible via IP address.

Next comes DNS - get a name at https://freedns.afraid.org/

Then add HTTPS, get the certs from LetsEncrypt.

Finally, Nextcloud. It runs kind of “inside” your webserver. Now you can back up your phone, and share photos with family, etc.

I’m not sure if I agree.

You can’t easy man in the middle authenticated protocols like SSH or HTTPS.

Unless you own a CA, or are a powerful country able to coerce a CA, or mandate installing one into users’ PCs.

As for SSH - you missed the “TOFU” bit, Trust On First Use. Do you verify your SSH host keys every time before connecting to a new server? The docs for GitHub doesn’t even mention it.

unencrypted/unauthenticated protocols are on their death bed.

I partially agree - encryption appears to be a solved problem today. Key distribution, however is not, it’s layers upon layers of half-solutions of wishful thinking, glued together with hope.

The layers should be independent to allow for maximum flexibility.

Depends on your threat model and priorities, right :) HPKP is helpful and does not require DNSSEC. DANE and CAA are helpful but require DNSSEC.

How could a hijacked DNS entry harm you?

• redirect to ads/spam
• downgrade to HTTP (no HSTS), then steal creds
• MitM the TOFU of SSH
• probably something more…

You can leverage the trust in DNSSEC to distribute TLS and SSH fingerprints too, look up DANE.

Oh, now I see. I guess then the DNS64 server needs to do the dnssec verification on behalf of the user, then drop the RRSIG records for the v4->v6 translated names.

Oh, and now I realize I confused the direction. DNS64 makes v4 into v6.

I’m fortunate to get native IPv6, so I’m not very familiar, tho I think I have basic understanding.

Did you mean you need to pick just one of {authoritative DNS server, DNS64} to listen on port 53? No, because the authoritative DNS only needs to be accessible from the outside. Run it on another machine or nonstandard port, then expose via port forwarding. Machines in LAN don’t need direct access to the authoritative DNS server, they can just as well resolve via the regular system.

Are you sure you need DYNDNS? My ‘dynamic’ IP address changes so rarely that I just update my DNS entries manually when it does.

Could you elaborate on the “non-spying” bit? There’s not much they can infer from people looking up your IP. Unless you run their daemon that updates the IP, as opposed to curl in cron.

I just self-host my own DNS server. Works like a charm. Setting up DNSSEC was a tad fiddly tho.

Long story short:

1. Set up Knot, teach it to serve your zone
2. Test via resolving names in your server (dig can use a specific server)
3. Disable DNSSEC
4. Tell your registrar to “use my own DNS server”
5. Generate the DNSSEC keys, upload only the pubkey to registrar, reenable