Discussion with Netgate needed: Missing DNS reply logging is critical

keyser

I hope I can stir a discussion here, that will involve Netgate senior descision makers:
Why is proper DNS reply logging - still - not top of mind at Netgate?

I’m looking into 2 customers that will retire their pfSense platforms soon. The reason is simple: There is no structured DNS reply logging possible in pfSense, and that is CRITICAL in modern installations for both behaviour analysis and especially forensics. It’s simple best best practise and considered mandatory for compliance reasons by several parts of industry in EU now.
This has been a problem for a decade now, and with the new CoreDNS it seems we are looking into even less logging options than with Unbound.

Today there is a - BAD - workaround by doing reply logging in pfBlockerNG, but that’s not really structured nor is there a good way to syslog it off the host (which is similarly critical and mandatory).

Why does netgate keep ignoring this, and is the reality that I should accept it will never be available? Should I start looking for pfSense alternatives for those that do not want a separate DNS infrastructure?

tinfoilmatt

Strictly speaking—a router is not a DNS server, and a resolver not a router. If your customers have such technical needs, perhaps they should be considering more robust DNS infrastructure, as opposed to trying to bolt it onto their edge firewalls? Something about babies and bathwater...?

That said, Unbound reply logging would be extremely compelling. Perhaps it's a better discussion to initiate upstream?

keyser

@tinfoilmatt said in Discussion with Netgate needed: Missing DNS reply logging is critical:

Strictly speaking—a router is not a DNS server, and a resolver not a router. If your customers have such technical needs, perhaps they should be considering more robust DNS infrastructure, as opposed to trying to bolt it onto their edge firewalls? Something about babies and bathwater...?

That said, Unbound reply logging would be extremely compelling. Perhaps it's a better discussion to initiate upstream?

I agree - at least when installations have a “certain” size - but sattelite offices and production facilities are often best served by a combined solution as there is little or none ekstra IT, and for availability its a bad idea to haul DNS back to the DC when it can be resolved autonomously on-site.

Unbound does support structured DNS reply logging and has done for years -> It supports DNSTAP.
But it requires that unbound is compiled with a dnstap option so it is included in the build. That is not done with unbound in pfSense even though it has been a redmine for 7 years:
https://redmine.pfsense.org/issues/9436

tinfoilmatt

Would definitely be nice to get some 'official' comment on that Redmine at the very least.

But some cursory 'googling' makes me think dnstap will almost certainly be enabled in the Netgate fork (?) of CoreDNS at some point. It seems to all be there already:

https://github.com/coredns/coredns/blob/master/plugin/dnstap/README.md

keyser

@tinfoilmatt Well, I certainly hope so, because it’s as desperately needed in CoreDNS as it is in Unbound :-)

DNSTAP is the way forward - separate reply syslog’ging with reply IPs given, could be nice and simple in small installs. But for performance, details and structure, DNSTAP is the proper solution.

But as it has been impossible to get Netgate involved or getting them to even talk about their plans, I’m at the cusp of giving up now…..

tinfoilmatt

It should be noted that the cited Redmine is specific to Unbound dnstap enablement, which I wouldn't hold my breath for.

keyser

@tinfoilmatt said in Discussion with Netgate needed: Missing DNS reply logging is critical:

It should be noted that the cited Redmine is specific to Unbound dnstap enablement, which I wouldn't hold my breath for.

I suffocated years ago trying to hold my breath for it
But I just don’t understand why it is omitted, as it would require no work from Netgate (apart from testing) to include a DNSTAP enabled compiled binary instead.
That means they probably have actively decided not to include it for some reason. I wish they would communicate a bit more why ;-)

tinfoilmatt

I'd bet it has something to do with the fact that, improperly configured, it could bring a system to its knees and/or destroy a system storage device. 'Demand versus risk' doesn't make sense to support when technical alternatives are possible.

One could mirror a trunk or transit link port and capture all DNS traffic to/from the integrated resolver/forwarder, for example.

keyser

@tinfoilmatt said in Discussion with Netgate needed: Missing DNS reply logging is critical:

I'd bet it has something to do with the fact that, improperly configured, it could bring a system to its knees and/or destroy a system storage device. 'Demand versus risk' doesn't make sense to support when technical alternatives are possible.

One could mirror a trunk or transit link port and capture all DNS traffic to/from the integrated resolver/forwarder, for example.

Ahh, That is hardly a valid explanation - enabling DNSTAP simply starts an Binary UDP stream with info on DNS activity to the designated collector. It does not punish or impact the local system nearly as much as the current locally supported query and reply logging (without answer IP) to local log (and syslog).

Gertjan

[26.07-RELEASE][root@pfSense.bhf.tld]/root: unbound -V
Version 1.25.2

Configure line: --with-libexpat=/usr/local --with-libnghttp2 --with-ssl=/usr --enable-dnscrypt --disable-dnstap --with-dynlibmodule --enable-ecdsa --enable-event-api --enable-gost --with-libevent --with-pythonmodule=yes --with-pyunbound=yes ac_cv_path_SWIG=/usr/local/bin/swig LDFLAGS=-L/usr/local/lib --disable-subnet --disable-tfo-client --disable-tfo-server --with-pthreads --prefix=/usr/local --localstatedir=/var --mandir=/usr/local/share/man --infodir=/usr/local/share/info/ --build=amd64-portbld-freebsd16.0
Linked libs: libevent 2.1.12-stable (it uses kqueue), OpenSSL 3.5.7 9 Jun 2026
Linked modules: dns64 python dynlib respip validator iterator
DNSCrypt feature available

BSD licensed, see LICENSE in source package for details.
Report bugs to unbound-bugs@nlnetlabs.nl or https://github.com/NLnetLabs/unbound/issues

The "--disable-dnstap" says it isn't there.
Including it would produce more 'code real estate' for sure and probably more dependencies on (other ?) libraries ...
Ok, we probably never know the real reason, but Netgate decides probably with the "less is better" reasoning when it comes to adding features ...
Just enabling it, without any 'Netgate' GUI support code, would give you access, because we have :

and we have the unbound manual ^^

tinfoilmatt

we probably never know the real reason

Because it's all but inevitably coming to Netgate's CoreDNS instead.