25.1.6 - DNS/DHCP best practice

[foggygray]

I use home.arpa for my local domain since that was purposely set aside for home networks.

Any way between the great documentation and this thread I was able to go full ipv4 and ipv6+ra with dnsmasq and it has been working wonderfully.

[Patrick M. Hausen]

Ok, I find myself confused about this, again.
If I have no VLANs and I am simply using the OPNsense default ".localdomain" for my LAN, would you recommend I be using .localdomain or lan.internal?

You can use either of the two... both will work.

Mind you that there can be a minor downside to using "localdomain". If you want to run your own local CA - on OPNsense or anywhere else - and you also want to use a wildcard certificate for a variety of devices that for some reason cannot use a real FQDN and Letsencrypt, then ...

- *.home.arpa will work while
- *.localdomain will not work

with current browsers. There have to be at least two dots in there.

I prefer - at work just like at home - to use a subdomain of a real domain I own.

So if I own e.g. company.com, then for the internal network I use internal.company.com. I know this will never conflict with anybody else, I do not publish this domain anywhere outside on the Internet, therefore I will not have leaks of any kind ... perfect solution but for the slightly longer FQDNs.

Also *.internal.company.com works with certificates as well as with MS Active Directory. Using your official Internet domain company.com with AD leads to all sorts of unexpected constraints.

HTH,
Patrick

[gspannu]

Ok, I find myself confused about this, again.
If I have no VLANs and I am simply using the OPNsense default ".localdomain" for my LAN, would you recommend I be using .localdomain or lan.internal?

You can use either of the two... both will work.

Mind you that there can be a minor downside to using "localdomain". If you want to run your own local CA - on OPNsense or anywhere else - and you also want to use a wildcard certificate for a variety of devices that for some reason cannot use a real FQDN and Letsencrypt, then ...

- *.home.arpa will work while
- *.localdomain will not work

with current browsers. There have to be at least two dots in there.

I prefer - at work just like at home - to use a subdomain of a real domain I own.

So if I own e.g. company.com, then for the internal network I use internal.company.com. I know this will never conflict with anybody else, I do not publish this domain anywhere outside on the Internet, therefore I will not have leaks of any kind ... perfect solution but for the slightly longer FQDNs.

Also *.internal.company.com works with certificates as well as with MS Active Directory. Using your official Internet domain company.com with AD leads to all sorts of unexpected constraints.

HTH,
Patrick

Thanks for the great tip about browsers possibly having an issue with .localdomain 👍

[Ground_0]

Anyone who uses OPNsense belongs here... let no one make you think otherwise !

Thank you, brother.

[wootonius]

I apologize if I've missed something in this thread but I'm not sure how best to implement my current IPV6 DHCP setup with Kea or dnsmasq.

My current IPV6 setup is based on this guide: https://github.com/lilchancep/att-pfsense-ipv6

In short, when my WAN interface is configured to run a script which requests IPV6 prefixes from AT&T to be delegated for each my my vlans. Each VLAN interface uses the "Tracking" option for IPV6 to determine its delegated prefix. I believe selecting "Tracking" means that SLAAC is used to determine addresses for each device but I may be wrong. Is there a way in Kea or dnsmasq to duplicate this functionality or is it best that I sit tight until the dust settles on the changes that are being worked on?

[Monviech (Cedrik)]

If it works for you right now better wait for a while. No need to change anything.

[wootonius]

If it works for you right now better wait for a while. No need to change anything.

Will do, I appreciate the feedback.

[fumantsu]

Are any plans in the documentation to include as scenario where DNSMasq is alone or it is not in best practices?

[Monviech (Cedrik)]

Nothing planned for the documentation, but running it alone should be pretty simple. Set it on port 53 and disable Unbound.

Only thing you need to take care of are reachable DNS servers in System - Settings - General. E.g., your ISP provided ones via the DHCP option there, or manually inserted ones like google or cloudflare.

[Anchor]

Ok, I find myself confused about this, again.
If I have no VLANs and I am simply using the OPNsense default ".localdomain" for my LAN, would you recommend I be using .localdomain or lan.internal?

You can use either of the two... both will work.

Mind you that there can be a minor downside to using "localdomain". If you want to run your own local CA - on OPNsense or anywhere else - and you also want to use a wildcard certificate for a variety of devices that for some reason cannot use a real FQDN and Letsencrypt, then ...

- *.home.arpa will work while
- *.localdomain will not work

with current browsers. There have to be at least two dots in there.

I prefer - at work just like at home - to use a subdomain of a real domain I own.

So if I own e.g. company.com, then for the internal network I use internal.company.com. I know this will never conflict with anybody else, I do not publish this domain anywhere outside on the Internet, therefore I will not have leaks of any kind ... perfect solution but for the slightly longer FQDNs.

Also *.internal.company.com works with certificates as well as with MS Active Directory. Using your official Internet domain company.com with AD leads to all sorts of unexpected constraints.

HTH,
Patrick

Hello, so that's why, because i use "localdomain", and if i leave on Macintosh IPv6 as "automatic" i get dns on IPv6 losing their signatures?

I was think was a related problem of using Suricata on an working IPv6 connection (in this case with Starlink), but since i read this and also trying to use a correct configuration, that's could be the problem, also because i was thinking a Suricata issue like reported on one of this forum FAQ's, and i tried using the IPv6 option on the Mac as "only local" the signatures was getting checked correctly.

I don't know if i should continue to try using a different "localdomain" or is just a problem as described, of suricata and should start to expect as IPv6 only workinkg before OPNsense until a new update will resolve this?

Thank you.

[meyergru]

You should be able to determine the difference between a rejected certificate vs. DNS or IP blocking caused by Suricata vs. IPv6 misconfigurations.

The symptoms of each of those are clearly discernible.

Patrick just pointed out that certificates for wildcard domains will not work if they contain just one dot, so if you want to use those, you will have to use a domain with at least two dots in them.

Your problem is not clearly stated, but does not seem to correlate to the cited post.

[Anchor]

You should be able to determine the difference between a rejected certificate vs. DNS or IP blocking caused by Suricata vs. IPv6 misconfigurations.

The symptoms of each of those are clearly discernible.

Patrick just pointed out that certificates for wildcard domains will not work if they contain just one dot, so if you want to use those, you will have to use a domain with at least two dots in them.

Your problem is not clearly stated, but does not seem to correlate to the cited post.

Hi, thanks for your quick reply,

Can i ask discernible how? Since the IPv6 connection is working well in OPNsense?

That's what i get for the dns's checks:

https://ibb.co/35gp0dr6

I can add a domain again but i would like to know before if is something i can avoid and if i should follow this advice as reported in  this topic: "https://forum.opnsense.org/index.php?topic=42985.0" :

13. I do not believe in IPSs like Zenarmor, Crowdsec or Suricata, but YMMV. At least do not use Suricata on WAN, unless you are willing to sacrifice IPv6 connectivity. This is a fine example for always having a tradeoff between (perceived) security and useability. Also: If you use IPS and experience any problems, please state that in your posting - or better, disable it and test again! The same goes for any kind of blocklists: check if they are the culprit.

Thank you.

[Anchor]

13. I do not believe in IPSs like Zenarmor, Crowdsec or Suricata, but YMMV. At least do not use Suricata on WAN, unless you are willing to sacrifice IPv6 connectivity. This is a fine example for always having a tradeoff between (perceived) security and useability. Also: If you use IPS and experience any problems, please state that in your posting - or better, disable it and test again! The same goes for any kind of blocklists: check if they are the culprit.

(BTW this post seems that was edited after the last time i did read it.)

[meyergru]

I still do not get what your problem is or what it has to do with wildcard certificates. The problem with just one dot can only occur when you use your own CA, because official CAs will only issue certificates for "real" domains, which always have a TLD, and thus, *.domain.tld will always have at least two dots.

What are you trying to do and what happens?

And yes, I sometimes add items to the list and clarify or extend others.

[Anchor]

I am just trying to get DNSSEC checks going pass successfully instead of fail in checks.

And in the same context understand (why i am replying to this post), if could have wrongly set something, or is Suricata over IPv6, that is know to not function properly (as reported on the quoted post).

At the moment i am just using "localdomain" without any dots, because is not a real website, and it was expected to be reliable just for the internal LAN.

I had a domain correctly set before and i can't remember if DNSSEC over IPv6 was working fine, also now i use a new DNS resolver.

It shouldn't have nothing to do in particular with wildcards and i have replied to a post at the beginning where it was explained how to get certificates being in conflict with nothing.