Messages

Why ?!

It's missing a sound architecture and does too many things in a single tool. Like systemd.

DHCP, DNS and RA are three completely separate services and I like to treat them as such. Kea, Unbound, radvd.

Also it's "alien" to the FreeBSD ecosystem. Why import a Linux centred single person project when there is standard software for the task. Similarly I do not understand why "we" import radvd. rtadvd has been a part of FreeBSD ever since IPv6 was introduced. I would pick that. Kea is the successor to ISC DHCPd. By ISC. Just use it.

If I were to decide I would use BIND instead of Unbound and implement proper dynamic updates via RFC 2137. Also provide in the UI only

- DHCP
- DNS
- RA

without even mentioning the products. Choice is not good in this firewall context. Choice means waisted effort on the development side.

Especially "boosted" by the Pi-Hole Team as their FTLDNS it's really nice to work with in general :)

[/quote]

Pihole is again Linux centred and you need a separate system. I run AdGuard Home on my OPNsense for filtering.

Hier war das von Anfang an reibungslos, nachdem ich im RC noch einen bug melden konnte, der von Franco fix behoben wurde.

YMMV.

Mach einen Snapshot und probiers aus 🙂 Dazu sind die da.

EDIT: If anybody knows please let me know how to report bugs: Unbound does not respect: Flush DNS Cache during reload
Reloading the service is purging the cache every time.

Even if you remove the check mark?

Open an issue on Github: https://github.com/opnsense/core/issues

[only static reservations will be synchronized]

Kea does register static mappings as documented:

Currently it is not possible to register hostnames dynamically between KEA and Unbound, only static reservations will be synchronized on an Unbound service restart.

https://docs.opnsense.org/manual/kea.html

If you must have registration of dynamic mappings, your only choice is DNSmasq. For recursion you can either

- use Unbound as the client facing recursive server and forward the local domain to DNSmasq
- use DNSmasq as the client facing not recursive server and forward to unbound as upstream for recursion

I'd say which one to pick is a matter of taste.

But since I absolutely dislike DNSmasq and never register dynamic leases, anyway, I am happy with Kea and Unbound.

YMMV

You cannot have the same address on two interfaces. You cannot have addresses from the same network on two interfaces. You need to completely change one of the networks, LAN is probably easier.

To get ISC back install the plugin. Kea does support registration of static mappings in Unbound. Or go DNSmasq for DHCP and DNS.

Impossible to NAT external port.

Is your WAN interface an Ethernet network and are you texting from that network?

In that case you need to disable reply-to:

Firewall > Settings > Advanced > Disable reply-to

You did split horizon with Unbound. Just keep doing it the same way. Split horizon and dynamic leases are in no way related.

If you only use unbound (unlinked from dnsmasq), you will need overrides to resolve your hostnames internally.
For overrides, you need (static) IP addresses.

I am only interested in hosts I need to address, like internal services/servers. I don't need and don't want clients registered in DNS. Too much fragile technology for essentially nothing. Like reverse mapping getting stale and then I get nonsensical information back. Better no information than the wrong one. I can always browse the "Bonjour" (mDNS) domain with Discovery, look up the MAC, or use nmap to identify a system if I really need to.

I use Unbound with Kea to register static mappings.

Top!

Registration of hostnames was nowhere mentioned. I don't use it. That's probably why I failed to understand the problem.

Also I still don't get how ISC or DNSmasq can be in any way connected to split DNS.


Old config:

DNS: Unbound
DHCP: ISC

New config:

DNS: Unbound
DHCP: DNSmasq


If he introduced DNSmasq into the DNS resolver chain, I'd still recommend simply not to do that. With Unbound unchanged everything will work exactly as before, won't it?

You can keep 127.0.0.1 and let Unbound (? probably) do its recursive thing using both WAN links according to the current routing table and state of the links.

Genau, beide verifizieren denselben TXT-Eintrag. Bzw. Letsencrypt verifiziert, dass der da ist, und das richtige enthält.

Mit _acme-challenge.meinedomain.de kannst du ein Zertifikat für "*.meinedomain.de" ausstellen. Das läuft dann auf beiden Firewalls, egal wo "opnsense.meinedomain.de" gerade hin zeigt. Wildcard ist besser, weil alle ausgestellten Zertifikate ja in einer öffentlichen Datenbank landen. Den eigenen FQDN also nicht im Zertifikat zu haben verkleinert die Angriffsfläche.