Bind DNS Package AAAA filtering problem
-
@dweimer wasn't the whole filter-aaaa stuff deprecated.
So if someone could provide some steps to getting it working with current bind that is part of 2.6, I will then try duplicating that after changing it to zfs.
There should be no possible way that the file system is the problem here, but there could be something missing that is causing the problem..
-
@johnpoz There isn't a check box to enable it or anything, you have to add it to the custom options under the View configuration to enable it. Yes they are pushing to disable removing IPv6 responses in order to get more people using IPv6. However when you are stuck with a local ISP that doesn't support IPv6. I have found it problematic having remote VPN clients that do have IPv6 support not getting correct routing of traffic that I want on VPN. Due to them taking direct IPv6 path instead of resolving IPv4 address that would have been routed over VPN.
plugin query "/usr/local/lib/named/filter-aaaa.so" { filter-aaaa-on-v4 yes; filter-aaaa-on-v6 yes; filter-aaaa { any; }; }; -
@johnpoz you can just import that portion from the xml?
-
@johnpoz Sorry, I misunderstood. I thought you wanted a way to recreate what I had. To add Bind to your system, it is easy.
Here are instructions on how to setup the filtering via Bind the way I do it. I am basically setting Unbound to forward DNS requests for certain domains to Bind, where Bind only returns ipv4 addresses.Install Bind:
Set things up as follows:
Settings for Unbound:
Change IP address to your LAN address. 127.0.0.1 might work but I have not tried that.
-
@fitch & @johnpoz It is absolutely the ZFS file system. I built two VMs today one with ZFS and one with UFS (v2.6.0). I confirmed what was already reported UFS one worked ZFS one didn't. And I found out why and a way to make it work on the ZFS system.
zfs get exec pfSense/cfThe install sets this value to off, if you change it to on it works.
zfs set exec=on pfSense/cfThere is of course a security based reason this was set, and this undoes that. But the filesystem is disallowing the execution of the bind plugin even though the file level permissions are correct.
-
@dweimer said in Bind DNS Package AAAA filtering problem:
zfs set exec=on pfSense/cf
That seems like a bug, since bind runs in a chroot - but that is not really a "filesystem" problem that is a problem with a setting pfsense on where the chroot environment when it sets it up. Which is under cf.
I would think that would cause issues with anything running under chroot that needs to exec a file..
Should be put in as bug, so they could fix it..
I would think its something like this bug
https://redmine.pfsense.org/issues/10413Where the file was not copied into the chroot.
I would "think" I am by no means a jail or chroot guy - would your setting of the exec on cf/named would allow for the aaaa to also work..
I show these as the settings
[22.01-RELEASE][admin@sg4860.local.lan]/: zfs get exec NAME PROPERTY VALUE SOURCE pfSense exec on default pfSense/ROOT exec on default pfSense/ROOT/default exec on default pfSense/cf exec off local pfSense/home exec on default pfSense/reservation exec on default pfSense/tmp exec on local pfSense/var exec on default pfSense/var/cache exec off local pfSense/var/db exec off local pfSense/var/log exec off local pfSense/var/tmp exec on defaultThey should prob setup something specific for bind so that its plugins can work. But doesn't seem to be defined.
-
@johnpoz I went ahead and created a bug report.
-
@johnpoz Just an FYI I went back and checked through release notes back to where the ZFS option was added to installer. I don't see any reference to when the separate /cf filesystem was added I have an older install on ZFS (that is updated all the way to 2.6.0) that wasn't using Bind plugin. It doesn't have that as a separate filesystem Bind AAAA plugin worked after installing it. I was hoping to update the bug as to which versions were effected.
-
@dweimer Yeah they changed the layout a few times for zfs. I know that the old 21.05.x layout was different than 22.01 that is for sure - there is a thread around here somewhere talking about that..
I would "guess" the same sort of changes happened with 2.5.2 to 2.6..
And I think the layout was different before that as well - there at least a couple of different changes to the zfs layout.. I recall I was going to do a clean install of say 21.05.2 but there was something mentioned somewhere around here that zfs was going to change again in the then 21.09 which got pushed to 22.01 so I didn't bother doing clean for 21.05.2 etc. and just upgraded since figured when 21.09 came out I would do clean for the new layout.
This is a good catch for sure - and sure will make many people happy when corrected.. Prob a few people scratching their heads on this one.. Why and the F is not working - and could see how zfs was the most likely culprit.. But I still stand by my statement that is not an actual file system problem ;)
You could have the same sort of problem with how UFS stuff is mounted read only for example.. Not sure if you can set exec permissions via UFS?
I will have to take a look at your bug - did you list the full zfs exec set showing cf set to off? I would think they would either have to change that setting, or I assume change the zfs layout yet again? ;)
I wonder if might be a good idea on the widget to list exec or not? Or option to show that in the widget?
edit: I linked to this thread in your bug report. They always like to see discussion and if others are seeing the problem, etc..
-
It was broken in 2.5.2 as well, it was a 2.5.2 install that I had when I first opened this thread. I don't know what the best solution is. The file itself doesn't even have executable bit set. No I didn't list the full zfs exec set in the bug report. I am not sure why that path was chosen by the package maintainers, that's of course not the default chroot path used in a FreeBSD port installation (/var/named).
