A private BSD laboratory

Did you read my previous posts about RcptFilter? After having put in production the third BSD server running BIND and Sendmail with ClamAV, I decided to extend a bit the central management configuration features of that tiny scripting solution. At scheduled times, few Perl and MSFT shell scripts running on a Windows Server 2003 machine produce and publish on a public web location a compressed archive containing all configuration files we need to distribute on all our BSD managed servers.

Some troubles occurred in generating the configuration files, because the Microsoft text file format is a bit different (each line ends with CR and LF characters instead of using LF only, as all Unix-like machines do), but with the utility dos2unix all came back compliant.

Considering the settings we need to centrally manage for our few servers, this solution fits well until now, but I wish extend it in order to distribute even some machine-specific settings, maybe using authenticated and protected channel to the hosts and a central repository of policies. Looking also forward to find a good solution which, I am sure, it has already been developed by good Unix administrators out there.

Some days ago I had to setup a public DNS server (on FreeBSD) to act as primary name server for a couple of domains and (since I was there) to maintain slave zones for all my public domains.

I’m not exactly what you’d call a “Unix system administrator”, but I have some experience about configuring BIND since the 8.x family, so I was a bit disappointed when, after spending some time to accurately write down the named.conf, I read a “connection reset” error in the log file.

At first, the matter appeared to be related to somewhat resolvable by inserting the right statements in the config, because I noticed the following alert message from the Cisco IOS firewall IDS module at the location of the primary name server:
“%IDS-4-DNS_ZONE_XFER_REQUEST_HIGH: Sig:6052:DNS High Zone Transfer Request”.

Thus I combined all these statements:
[ query-source [ address ( ip_addr | * ) ] [ port ( ip_port | * ) ]; ]
[ transfer-source (ip4_addr | *) [port ip_port] ; ]
[ alt-transfer-source (ip4_addr | *) [port ip_port] ; ]

Nothing changed. So I tried to transfer the same zone using a different name server in the same network of my FreeBSD machine: it was a Windows Server 2003 host. By using the Microsoft DNS service (without changing anything at the network layer) all worked fine at the fist shoot!

By looking for someone who’d have ever had such a problem, I found a post in a bug tracker list. It was explained that there is no way (neither there will ever be) to have BIND sending zone transfer request to other name server from its port 53 TCP. All the statements I had tried apply only to UDP traffic, since all TCP request are always sent from a random high port.

Thus, the only applicable solution has revealed to be changing the Cisco IOS firewall behavior in such a way to not react if a request originating from known external DNS servers matches any ip audit signature… 100 point to subtract from my personal BIND scorecard! 🙁

I had setup a front-end SMTP relay system one more time, running on the latest release currently in the stable branch of the FreeBSD Project development (6.2).
I’m a bit experienced in running Sendmail on BSD systems, so I spent only few minutes to configure and test e-mail routing, and I took some time for having a look at a strange behavior that I’m not be able to understand yet.

Think as if the host name was mx2.mydomain.com: since I had to build it as a secondary mail exchanger for several email domains, after the insertion of all the domains in the relay-domains Sendmail configuration file, I wrote in the mailertable to have all messages sent to these domains relayed to the primary SMTP inbound server (maybe located in a different location), by inserting this lines:

With this config, delivery problems came for the messages sent to the first domain, whereas all mail sent to others domains were successfully relayed. The error messages that appeared in the log files were suggesting a clear matter: “stat=Deferred: Name server: mx1.mydomain.com : host name lookup failure”. This should not leave you any doubt, but after I checked there was not any name resolution problem, I found that a bit strange: in fact, why only delivering to the first domain was faulting?
I decided to change the mx1.mydomain.com name with its corresponding IP address, and all worked fine, for all domains!

After a lot of testing, I found that Sendmail seems not to be able to relay any message to the primary MX if its FQDN lies in the same DNS domain of the Sendmail host!! I posted this unbelievable matter in the comp.mail.sendmail newsgroup, but I haven’t got any reply yet… please someone show me that the problem is due only to an error in my configuration: I cannot believe there is such a serious bug in Sendmail without anyone has ever noticed it! :S

The first major release of the multi-user edition has been released several weeks ago. Only for testing purposes, the Phoibos project team members have begun the testing phase on the same BSD system used by the production Phoibos blog hosting service. The new collection of blogs is available at http://wp.valsania.it. Feel free to register and contribute to all other beta testers, here!