BIND 9.12 / bind-pfsense-9.11.2 RNDC port breaking Unbound
-
Using the packages in the subject line, installed via webconfigurator on 2.4.2-RELEASE-p1. I'm using Unbound as my primary resolver, but running named on an alternate port, listening to localhost. Unbound selectively forwards to named via domain overrides. (The goal is to work around Netflix/etc retarded policies which block legitimate users of the Hurricane Electric IPv6 tunnel, by stripping out AAAA replies from DNS servers. You've probably all seen the recipes by now.)
This means that I have two DNS servers running, but as unbound is listening on 53 and named is listening on 10053, there shouldn't be a conflict. However, I'm now seeing this in my logs:
/etc/namedb/named.conf:10: couldn't add command channel 127.0.0.1#953: address in use
This seems buggy, as there is no /etc/namedb directory, so it shouldn't be complaining about files there.
Anyway, both unbound and named are trying to listen on 953 for RNDC controls. Whichever one claims it first breaks the other. There's an open bug report about this (7271) but the last activity was six months ago.
So, my questions:
1) Can RNDC be disabled for either resolver? I don't make special use of RNDC, so if both stopped, it wouldn't break anything as far as I know. If either stopped trying, the other one could claim the port and they'd both be able to run at startup. To the best of my knowledge, RNDC isn't used internally by pfsense, but I could be very wrong there.
2) Can the port number be reassigned, for either resolver, in the GUI webconfigurator? I can't find an easy "RNDC port on: nnn" field, but both resolvers support arbitrary options in the appropriate text field.
In an attempt to solve (2), I added
controls { inet 127.0.0.1 port 10953 allow { 127.0.0.1; } keys { "rndc-key"; }; };
to the Global Settings textbox for BIND, based on the syntax I found in the config file's actual location, /cf/named/etc/namedb/named.conf, on the theory that the settings later in the generated conf file would override the earlier settings. Unfortunately, named accumulates settings and tries to listen on both ports for RNDC, giving even more errors.
Next, I added "remote-control: control-port: 8953" to the custom options for unbound, thinking to move that back to its upstream default. That would have worked, except that the generated conf file puts "include: /var/unbound/remotecontrol.conf" at the end of the file, after the entries from the webconfigurator text box. So my change gets overruled by the default file anyhow.
As a desperate attempt, I just edited /var/unbound/remotecontrol.conf by hand and changed the port number. That file doesn't get generated, only included, so the change will stay until I next upgrade the package. Hopefully before then I can figure out how to "properly" make this change, but for the life of me I don't see how.
(Possible unrelated: I also have no clue what I'm supposed to do to fix "socket.c:5695: unexpected error: setsockopt(22, TCP_FASTOPEN) failed with Protocol not available" in the named log when it starts up.)
-
if your goal is to just strip out netflix AAAA you can do that much easier with a python script you can get running in unbound..
https://forum.pfsense.org/index.php?topic=134352.0
Netflix and HE.net tunnel fixed using Unbound python module -
(Possible unrelated: I also have no clue what I'm supposed to do to fix "socket.c:5695: unexpected error: setsockopt(22, TCP_FASTOPEN) failed with Protocol not available" in the named log when it starts up.)
Unrelated, safe to ignore. pfSense/kernel does not currently support TCP Fast Open, which is all that warning is telling you.
-
if your goal is to just strip out netflix AAAA you can do that much easier with a python script you can get running in unbound..
https://forum.pfsense.org/index.php?topic=134352.0
Netflix and HE.net tunnel fixed using Unbound python moduleThat is… not what I would call "much easier", given how much hand-hacking is required. The nice feature of the DNS method is that it's all standard packages, entirely controlled via the webconfigurator, using built-in features (Unbound's domain overrides and BIND's AAAA-stripping). The only tweaking by hand that I've done is to work around what strikes me as a package misconfiguration, in that neither resolver can be told to listen on a different port for remote controls. The fact that Unbound's configuration includes the defaults at the end rather than the beginning seems to me to be a bug, but I don't want to have that fight.
And in fact, I bet that somebody really good at BIND configs could accomplish the same thing using only named, no script fiddling needed, and turning off Unbound entirely. (I am not that person. I've spent too much of my life being pissed off at BIND.)
But it's good that there are multiple ways to solve Netflix and other organizations' stupidity! The people who love getting their hands into scripts will prefer the method you linked. I was that person when I was younger, but I don't want that kind of thing on my homelab anymore. :-) I do like that Unbound can use python that way now.
Unrelated, safe to ignore. pfSense/kernel does not currently support TCP Fast Open, which is all that warning is telling you.
Yeah, I just this morning found a discussion on a mailing list describing how ISC's configuration on this feature is really, really braindead. It's apparently turned on/off by what the kernel on the build machine can do, and there's no way to control it other than editing the generated header file, e.g., post-config sed script. Anything at runtime not matching what the build machine used ends up reported as "unexpected error".
Come to think of it, stuff like this is why I stopped using BIND… auuugh I drank heavily to purge the memories of those years now it's all coming back noooo