@marcosm said in PHP Fatal Error Kea2Unbound:
@Gertjan It includes all unbound records not just LAN leases. It's a lot but it makes sense once you include multiple DNSBL sources in pfBlockerNG. Setting DNSBL Mode to python may help with the issue.
Yea, the Python DNSBL mode should help in this case.
backstory:
Unbound is architected as a collection of middleware "modules". As a DNS query comes in, these modules can choose to either handle the query outright, modify the query, and/or punt it to the next module in the list. By default there are two modules: validator and iterator. validator does DNSEC and iterator does the actual recursive resolving that Unbound is known for.
The Python module can sit somewhere in this list of modules...hence the Pre validator or Post validator distinction in the GUI. The ordering of the modules is important as you'll see.
The idea behind the Python module is to wrap and expose the C interface (Unbound is written in C) to a Python script. However, this has the added overhead of calling into the Python interpreter for every DNS query that Unbound receives. There is also the memory overhead for allocating python objects, etc. Hence the warning about Python mode requiring more memory...it does.
I've always considered the Python module more as a development tool for prototyping and doing PoCs for exploring a problem space, not something you'd necessarily want to implement a production solution in.
The next version of the kea2unbound solution will probably look something like this:
Implemented as a true Unbound module (first prototyped in Python and then rewritten in C, or perhaps Go with a C shim).
When a DNS query comes in for a host with a domain that is considered to be a "local domain" from the perspective of Kea, this host will first get checked against the active lease database from Kea.
A matching lease record will be transformed into appropriate DNS records (A/AAAA + PTR records) and inserted into the Unbound cache with the TTL being one-third of the lease duration. These records will be served to clients. Unbound cache rotation will take over the lifecycle of these records.
The next time a request is made for said host, the Unbound cache will be inspected first, so no further communication with Kea is necessary so-long as the cache is warm.
This new module will naturally come first in the list of Unbound modules so that we can handle it early, and it has the benefit of being about as fast as you could imagine it can possibly go. There is no need for reconciling and synchronizing lists of records for Unbound configuration files, etc.
The current implementation inserts and removes DNS records in response to Kea events, but that might not be the best solution.
