Current Best Practices

[JamesFrisch]

Hi guys!

Sometimes we do things a certain way, just because we did it like that in the past. I am in no way immune to it :)

Anyway, I don't want to end up like people I see often, that don't use IPv6 or even suggest turning it off, just because I am stuck in the nineties with some ways of thinking.

And sometimes you think afterwards "how the hell did I do it in that bad way and wasted so much time on it" (me taking way too long before switching to public key auth).

So here are my questions:

1. IPv6 only
Is it time to go IPv6 only already? Like why bother with DHCPv4 and stuff? Just because of some sites? Why not just use NAT64 for these instead?
Currently it seems to me that enabling IPv4 is still the more foolproof. On the other hand, if you disable IPv4, some IPv6 misconfigs are easier to detect.
Like I was wondering why my Pihole was so slow. Turns out it first timed out for IPv6 (because of some misconfig) and then falls back to IPv4. That would not have happened without IPv4, then it would just not have worked.

2. DNS instead of static IPs
Currently I am still using static IPv4 for stuff like accessing Pihole VM over SSH.
Instead of just switching that to IPv6, I was wondering if this is obsolete anyway. Why not just use DNS instead?

3. Certs
For everything public I am using Certbot. But for internal stuff, I am using self-signed certs (intermediate CA). Simply because there is no Certbot for stuff like a Supermicro IPMI.
I choose certs to be valid for 10y. Some browsers like Safari, complain about the cert not being up to standard because of that long lifetime. Is there any other way of doing it the right way? I am hesitant on using DNS certs, since I fear the one compromise would compromise the whole setup instead of just one subdomain.


4. .internal instead of .arpa
I was under the impression that best practice is to use something like home.arpa.
Docs suggest that I should rather use something like home.internal

5. HSTS and .internal
Docs also recommend to use something like lan.internal.mydomain.com
But what if mydomain.com is preloaded for HSTS?
My guess would be that internal isn't excluded from HSTS?
But of course you could argue that everything should be encrypted, even local connections.
My NGINX reverse proxy uses http for some internal hosts.


6. Do you use DNSSEC for local recursive unbound?
I fail to say much security gains for my local recursive DNS unbound being recursive. Anyone using DNSSEC that points to their local unbound? 

[meyergru]

1. IPv6 only
Is it time to go IPv6 only already? Like why bother with DHCPv4 and stuff? Just because of some sites? Why not just use NAT64 for these instead?
Currently it seems to me that enabling IPv4 is still the more foolproof. On the other hand, if you disable IPv4, some IPv6 misconfigs are easier to detect.
Like I was wondering why my Pihole was so slow. Turns out it first timed out for IPv6 (because of some misconfig) and then falls back to IPv4. That would not have happened without IPv4, then it would just not have worked.

Most definitely not. Why? Because of your internal networks. This is especially true if you have an ISP who hands out dynamic GUA ranges.
It is a PITA to handle these with firewall rules and naming (see next section). ULA addressing can be done, but in that case, your devices all will have to deal with at least 3 IPv6s (link-local, ULA and GUA), if not 4 because of privacy extensions.

I covered most of this here already. The gist of it is: use IPv4 for internal networking, with dual-stack GUA for outbound IPv6 access (preferably with IPv6 privacy extensions). For inbound access, a reverse proxy is nice, because it allows both IPv4 and IPv6 from outside, while haveing only IPv4 on the internal networks.

2. DNS instead of static IPs
Currently I am still using static IPv4 for stuff like accessing Pihole VM over SSH.
Instead of just switching that to IPv6, I was wondering if this is obsolete anyway. Why not just use DNS instead?

Yes, of course. That would be paramount for IPv6, because you do not want to memorize IPv6 addresses, or do you? I have it for all IPv4 as well. Also, there are a lot of aliases, like for docker services (behind traefik).

3. Certs
For everything public I am using Certbot. But for internal stuff, I am using self-signed certs (intermediate CA). Simply because there is no Certbot for stuff like a Supermicro IPMI.
I choose certs to be valid for 10y. Some browsers like Safari, complain about the cert not being up to standard because of that long lifetime. Is there any other way of doing it the right way? I am hesitant on using DNS certs, since I fear the one compromise would compromise the whole setup instead of just one subdomain.

I do that in much the same way. And read this on why your certificates may not be accepted by some browsers. As it turns out, when you add a non-standard CA to a browser, long-lived certificates issued by those should work, but it depends on how you add them. You can have them start before 2020, because before that, long-lived certificates were allowed and are still valid.

4. .internal instead of .arpa
I was under the impression that best practice is to use something like home.arpa.
Docs suggest that I should rather use something like home.internal

Since you probably need DNS and matching certificates, you are free to use anything that does not collide with official TLDs. You could also use just one level, like xxx.internal. However, be aware that browsers do not accept wildcards with just one level like '*.xxx' - only '*.xxx.yyy'.

5. HSTS and .internal
Docs also recommend to use something like lan.internal.mydomain.com
But what if mydomain.com is preloaded for HSTS?
My guess would be that internal isn't excluded from HSTS?
But of course you could argue that everything should be encrypted, even local connections.
My NGINX reverse proxy uses http for some internal hosts.

You would use this if you main goal is to have ACME certs for your internal names. With your own CA, you do not need it and as you said, some devices cannot be provisioned by ACME anyway, so you still need your own CA for internal DNS. For that, why would you a. use long names (and you have to type them regardless of search domains because your certificates must match and b. use HSTS, because some devices do not support HTTPS.

6. Do you use DNSSEC for local recursive unbound?
I fail to say much security gains for my local recursive DNS unbound being recursive. Anyone using DNSSEC that points to their local unbound? 

If you fear internal DNS poisoning... I do not.

[OPNenthu]

If you're considering IPv6 with privacy extensions for outbound (as client devices may be want to do), you may run into an unresolved issue:

https://forum.opnsense.org/index.php?topic=44435.0
https://community.ui.com/questions/Unreliable-IPv6-temporary-address-generation/64ae65cb-f7d7-4a79-8bfc-c97efdc0005d#answer/555238e2-8705-410d-8f32-a231e1bbb4a5
https://community.ui.com/questions/IPv6-Privacy-Extensions-Broken-Temporary-Addresses-Not-Rotating-UDM-Pro/8aad42a8-d514-453d-8881-d6cc67f74ff5

[JamesFrisch]

Most definitely not. Why? Because of your internal networks. This is especially true if you have an ISP who hands out dynamic GUA ranges.

I have a good ISP. Good ISPs follow RIPE recommendations. AKA I get a static /48 prefix.
Are there any other points you see against IPv6 only?

I am not sure if can NGINX reverse proxy from my IPv4 WAN to an internal IPv6. Should be possible, will have to give it a try.

I do that in much the same way. And read this on why your certificates may not be accepted by some browsers.

Looks like I have to switch from Safari to Firefox for my homelab stuff then or try if Safari accepts certs from before 2020. Thank you for that tipp!

If you fear internal DNS poisoning... I do not.

My neither. But to be fair, I also don't fear MITM attacks on my local network. So I am not sure if I even think that https is worth it internally.


Cheers for these great inputs.

If you're considering IPv6 with privacy extensions for outbound (as client devices may be want to do), you may run into an unresolved issue:

I think I never had any problems with IPv6 privacy extensions. But you are making a great point on why to disable IPv4. I would not notice if IPv6 is broken. I don't use google, let alone ipv6.google.com for searches :) So without IPv4 I would notice it and could start to troubleshoot.

[meyergru]

I have a good ISP. Good ISPs follow RIPE recommendations. AKA I get a static /48 prefix.
Are there any other points you see against IPv6 only?

Yes, I have old devices that can handle IPv4 only - and also Docker services. Handling IPv6 in Docker is extra hard and completely out of the question with dynamic prefixes anyway. Because of dynamic prefixes being the rule and not the exception in Germany, I would need IPv4 anyway, so I do not bother to find any complex solution like Nat for IPv6 just to enable internal DNS.

I do not want the complexity of going "full" dual-stack in my internal network (i.e. I use IPv6 only outbound).

Thus, with the choice of wanting to keep only one protocol for internal traffic, I still choose IPv4 over IPv6. If you have static IPv6 GUA and no more devices that would require IPv4, your choice might be different (but then: don't ever change your ISP!).

I am not sure if can NGINX reverse proxy from my IPv4 WAN to an internal IPv6. Should be possible, will have to give it a try.

Nginx can handle that, and Caddy and HAproxy can, too.