Bind package for pfsense 2.1
-
- No, maybe to remove the serial field from the zone editing page.
- See attachment and below. I am running the 2.1 nanobsd release on an ALIX board.
The resulting Zone file:
$TTL 1h
;
$ORIGIN example.com.; Database file example.com.DB for example.com zone.
; Do not edit this file!!!
; Zone version 2385644025
;
example.com. IN SOA ns1.example.com. cl.example.com. (
2385644025 ; serial
1d ; refresh
2h ; retry
4w ; expire
1h ; default_ttl
);
; Zone Records
;
@ IN NS ns1.example.com.
@ IN A 93.184.216.119
www IN AAAA 2606:2800:220:6d::aa7.
-
@2.: yes, this is a known issue and already resolved. You can check changes in Git or wait for the next version.
-
@2.: yes, this is a known issue and already resolved. You can check changes in Git or wait for the next version.
Just reinstall the package to get latest version.
-
I have been reinstalled the bind package, now it is 9.9.4 pkg v0.3.2, with no luck :-
It still append a dot at the end of ipv6 address in AAAA record.
Any workarounds?Upd. I edited this files manualy and everything is ok! 8)
-
I have no idea what happened with the patch. I've updated it again.
Thanks for the feedback.
-
Awesome looking package - thanks (again) marcelloc!
It's been a while since I have messed with BIND - anyone have a quick walkthrough for setting up BIND via the pfSense package to be a slave server for a DNS zone? In the meantime off to find the old BIND tutorials…
-
anyone have a quick walkthrough for setting up BIND via the pfSense package to be a slave server for a DNS zone? In the meantime off to find the old BIND tutorials…
Config service from left to right, check field descriptions, it will be easy if you know how bind works.
-
Editing zones which are also updated dynamically causes configuration to get out of sync with journal. This is a common problem and there is a known workaround. Read this short article for a brief explanation
http://www.thedumbterminal.co.uk/?action=showArticle&articleId=168
-
Hi, I would like to report some issues on the package for I am migrating my old setup of bind (terminal-based) to the new GUI package:
1. Serial auto-generates by itself. Which opposed from my current configuration (we need it to be timestamped for example: 2013122701)
2. zone domain record TYPE does not have NAPTR
3. When creating a SLAVE zone. The slave file (slave.example.com.DB) was missing at the SLAVE DIR : /cf/named/etc/namedb/slave/sample_slave/.
4. Cannot assign separate logging severity for each Logging Options.and BTW this package is AWESOME ;D
-
Other feature I noticed: adding a new static DHCP lease does not automatically update in bind. It doesn't automatically update when restarting bind. It doesn't update until you edit the relevant zone file and click Save, then restart bind.
With regard to my other bug post:
I'd like to recommend that zone files be configured to be bare, then the data for the zone be loaded dynamically for editing and modified dynamically when editing/clicking apply. The utility nsupdate from the bind utility can be configured for this functionality. -
I installed the bind package today to set a couple of slave zones up. I added the zones, but they don't seem to get put into the config - they never transfer. The masters have transfer allowed. I did a quick packet capture and saw no traffic to the master on port 53. The bind config file in pfSense doesn't seem to have anything related to my zones in it…
Any ideas?
-
-
Any ideas?
Did you created firewall rules to allow dns traffic between slave and master?
Thanks, sure did.
I was just looking at the named.conf on the firewall, and there are no configuration directives for the slave zone. Seems like the package is not properly creating the named.conf file.
-
Seems like the package is not properly creating the named.conf file.
On what dir are you looking for config files?
-
Seems like the package is not properly creating the named.conf file.
On what dir are you looking for config files?
/cf/named/etc/namedb
A screen shot of the zones tab under BIND config is attached. This is the resulting config file (named.conf):
#Bind pfsense configuration #Do not edit this file!!! key "rndc-key" { algorithm hmac-md5; secret "**removed**"; }; controls { inet 127.0.0.1 port 953 allow { 127.0.0.1; } keys { "rndc-key"; }; }; options { directory "/etc/namedb"; pid-file "/var/run/named/pid"; statistics-file "/var/log/named.stats"; max-cache-size 256M; listen-on-v6 { none; }; listen-on { *public ip address*; }; }; logging { category default { null; }; };
-
I don't think this quite ready for prime time?
Oct 14 23:33:49 named[69425]: starting BIND 9.9.4 -c /etc/namedb/named.conf -u bind -t /conf/named/
Oct 14 23:33:49 named[69425]: loading configuration from '/etc/namedb/named.conf'The command that it is starting with
named -c /etc/namedb/named.conf -u bind -t /conf/named/
Option -c for specifying the configuration file
-c /etc/namedb/named.conf/
@named(8):
-c config-file
Use config-file as the configuration file instead of the default,
/etc/namedb/named.conf. To ensure that reloading the configuration
file continues to work after the server has changed its working
directory due to to a possible directory option in the
configuration file, config-file should be an absolute pathname.Option -u for setting user
-u bind
@named(8):
-u user
Setuid to user after completing privileged operations, such as
creating sockets that listen on privileged ports.
Note: On Linux, named uses the kernel's capability mechanism
to drop all root privileges except the ability to bind(2) to
a privileged port and set process resource limits.
Unfortunately, this means that the -u option only works when
named is run on kernel 2.2.18 or later, or kernel
2.3.99-pre3 or later, since previous kernels did not allow
privileges to be retained after setuid(2).Option -t for chrooting/jailing named to the folder
-t /conf/named/
@named(8):
-t directory
Chroot to directory after processing the command line arguments,
but before reading the configuration file.
Warning: This option should be used in conjunction with the
-u option, as chrooting a process running as root doesn't
enhance security on most systems; the way chroot(2) is
defined allows a process with root privileges to escape a
chroot jail.So you can see that by jailing it with a chroot using -t the path for -c is actually going to be the -t path + -c path or:
/cf/conf/named/etc/namedb/named.conf
Had a look through the whole thread. Thought maybe this post would be helpful for anyone else.
-
So you can see that by jailing it with a chroot using -t the path for -c is actually going to be the -t path + -c path or:
/cf/conf/named/etc/namedb/named.conf
Had a look through the whole thread. Thought maybe this post would be helpful for anyone else.
This is the bind process that I currently see running on my firewall:
bind 55193 0.0 0.7 22108 14140 ?? INs 22Jan14 0:00.48 /usr/pbi/bind-i386/sbin/named -c /etc/namedb/named.conf -u bind -t /cf/named/
In this case, -t path + -c path = /cf/named/etc/namedb/named.conf, which is where the named config file actually is as part of this package. So that doesn't seem to be a problem.
My problem is that I configured a secondary zone, but that configuration does not appear in the config file.
-
This is the bind process that I currently see running on my firewall:
Quote wasn't directed at your problem but another uses post that prompted me to write up a breakdown of the command and the reason it looks the way it is.
My problem is that I configured a secondary zone, but that configuration does not appear in the config file.
In pfsense packages store pretty much most of the configuration in /cf/conf/config.xml. They store it under <installedpackages><packagename><packagestuff></packagestuff></packagename></installedpackages>In this case the daemon is started with named but the package is called bind and its configuration is in this xml file. Example below:
<bindacls><config><name>any</name></config></bindacls> <tab><text>Settings</text> <url>/pkg_edit.php?xml=bind.xml</url> <active></active></tab> <bind><config><temp01><enable_bind>on</enable_bind> <listenon><bind_notify><bind_hide_version><bind_ram_limit>256M</bind_ram_limit> <bind_logging>on</bind_logging> <log_severity>info</log_severity> <log_options><rate_enabled><log_only>no</log_only> <rate_limit><bind_forwarder><bind_forwarder_ips></bind_forwarder_ips></bind_forwarder></rate_limit></rate_enabled></log_options></bind_hide_version></bind_notify></listenon></temp01></config></bind>
Or more specifically for zones
<bindzone><config><temp01><disabled><name>testzone</name> <type>master</type> <view><reverso><custom><temp04><dnssec><backupkeys><dsset><slaveip><forwarders><temp03><tll><nameserver>192.168.55.1</nameserver> <ipns><mail><serial>2391066341</serial> <refresh>1d</refresh> <retry>2h</retry> <expire>4w</expire> <minimum>1h</minimum> <allowupdate><allowquery><allowtransfer><temp02><row><hostname>www</hostname> <hosttype>A</hosttype> <hostvalue><hostdst>192.168.55.200</hostdst></hostvalue></row> <regdhcpstatic></regdhcpstatic></temp02></allowtransfer></allowquery></allowupdate></mail></ipns></tll></temp03></forwarders></slaveip></dsset></backupkeys></dnssec></temp04></custom></reverso></view></disabled></temp01></config></bindzone>
-
Ahhh…ok, thanks.
So under <installedpackages>, there are some bind configuration entries:
<bindacls><config><name>any</name></config></bindacls>
<bindzone><config><temp01><disabled><name>*****.com</name> <description><type>slave</type> <view><reverso><custom><temp04><dnssec><backupkeys><dsset><slaveip>71.*****</slaveip> <forwarders><temp03><tll><nameserver><ipns><mail><serial><refresh><retry><expire><minimum><allowupdate><allowquery><allowtransfer><temp02><row><hostname><hosttype>A</hosttype> <hostvalue><hostdst></hostdst></hostvalue></hostname></row> <regdhcpstatic></regdhcpstatic></temp02></allowtransfer></allowquery></allowupdate></minimum></expire></retry></refresh></serial></mail></ipns></nameserver></tll></temp03></forwarders></dsset></backupkeys></dnssec></temp04></custom></reverso></view></description></disabled></temp01></config></bindzone>
(***** are done by me just for this post)
<bind><config><temp01><enable_bind>on</enable_bind> <listenon>wan</listenon> <bind_notify><bind_hide_version><bind_ram_limit>256M</bind_ram_limit> <bind_logging><log_severity>critical</log_severity> <log_options><rate_enabled><log_only>no</log_only> <rate_limit><bind_forwarder><bind_forwarder_ips></bind_forwarder_ips></bind_forwarder></rate_limit></rate_enabled></log_options></bind_logging></bind_hide_version></bind_notify></temp01></config></bind>
So the slave zone information is in the pfsense config…but doesn't seem to make it's way into the bind config.</installedpackages>
-
I think I found the problem. Looking through the code that generates the bind config from the pfsense config, I noticed the only place it writes out the zone config is under code that processes Views. I did not create a view. As soon as I created one and assigned the zone to it, the bind config was created correctly - and it's working (zone was transferred). I did have to fix one more thing - the server was not resolving and I noticed there was no rule to allow dns traffic on the interface I selected bind to listen on.
So to sum it up - with this package, there were two gotchas that I had to deal with:
- You must create a View to associate with your zones
- You need to manually add firewall rules to allow port 53 (DNS) traffic