FreeBSDwiki - User contributions [en]

Named.conf

2007-06-17T15:06:49Z

216.110.12.175:

== named.conf ==

'''Named.conf''' controls system-wide configuration of [[named]] (*nix's standard [[DNS]] server, the Berkeley Internet Name Daemon), and also tells it where to find the files used to control individual domains, which are usually referred to as '''zones''' when discussing DNS administration.

Here is an sample '''named.conf''', in which the global section instructs [[named]] to try to resolve queries through an ISP's DNS servers before falling back on the [[root servers]] if the ISP's servers fail to respond. After that, a few sample zone configurations are given - but as you will see, in most cases, the majority of the detail in individual zones is in the '''zone files''' themselves.

<nowiki>// $FreeBSD: src/etc/namedb/named.conf,v 1.6.2.4 2001/12/05 22:10:12 cjc Exp $
//
// Refer to the named.conf(5) and named(8) man pages for details. If
// you are ever going to setup a primary server, make sure you've
// understood the hairy details of how DNS is working. Even with
// simple mistakes, you can break connectivity for affected parties,
// or cause huge amount of useless Internet traffic.

options {
directory "/etc/namedb";

// Limit to using forwarders ONLY by enabling the following line:
//
// forward only;

// Set forwarders to attempt to resolve DNS queries at lower-level
// caching DNS servers (typically, your ISP's), reducing load on
// the root servers and the internet in general. NOTE: even without
// setting "forward only", using frequently-broken forwarders will,
// sadly, DRASTICALLY impact your own performance.

forwarders {
4.21.223.2;
4.21.223.2;
};

// Set query-source address to force a specific source port
// for outbound queries.
//
// query-source address * port 53;

/*
* Specify a location for the dumpfile (may be necessary if running in a sandbox)
*/
// dump-file "s/named_dump.db";
};

// If you are running a local name server, don't forget to put 127.0.0.1 in the first place
// in your </nowiki>[[/etc/resolv.conf]] and enable it in /[[etc/rc.conf]].<nowiki>

// Ultimately, DNS queries are an example of hierarchical buck-passing: root queries begin
// with the [[root servers]] for the internet, which don't know the answer, and possibly not
// even who does know the answer - but they know how to get you one step closer. The buck keeps
// passing downwards until you finally reach the [[authoritative nameserver]] for the record
// you're trying to resolve. This entry points out the [[root servers]] if your server should
// need them.

zone "." {
type hint;
file "named.root";
};

// This is a simple "reverse zone", which points IP addresses to [[canonical DNS names]] instead
// of vice-versa. Ideally, you should have a complete zone file for your LAN IP space as well as
// the subnet your WAN occupies. In practice, many smaller companies never get this done properly.

zone "0.0.127.IN-ADDR.ARPA" {
type master;
file "localhost.rev";
};

// This is a reverse IPv6 zone. We won't have enough IPv4 (dotted quad style) addresses for
// everybody forever. Life will not be fun when six-bone is a necessity. Life will be even LESS
// fun in the last, gruesome days of the necessary switch. (Look at this monster!)

zone "0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.IP6.INT" {
type master;
file "localhost.rev";
};

// This is a simple slave zone. We don't actually write or control this zone file, we just
// ask its real master if we can have a copy of it so that we can help distribute it to others.
// NOTE: attempting to slave a domain that you don't have any business with is VERY frowned upon.

zone "slavedomain.com" {
type slave;
file "zones/slavedomain.com";
masters {
65.43.99.11;
};
};

// This is a simple master zone. We originate and control the zone file which describes this
// zone. We may or may not choose to allow others to slave it for us. In this case, we are
// not securing it, so anyone who wants to slave it may do so.

zone "masterdomain.net" {
type master;
file "zones/masterdomain.net";
};

// This is a dynamically updated zone. We originate and control it, but only a small "seed"
// is statically maintained on the server - the rest is updated, deleted, refreshed, etc by
// clients with no fixed IP address as they need to in order to let others find them. The
// privilege to update records in this zone is secured with a crypto key. The key is *not*
// visible to simple queries from the internet.

key dynamic.domain.net. {
algorithm "HMAC-MD5";
secret "omr5O5so/tZB5XeGuBBf42rrRJRQZB8I9f uIIxxei8qm7AVgNBprxtcU FQMzBvU/Y nyM2xbs/C8kF3eJQUA=="";
};

zone "dynamic.domain.net" {
type master;
file "zones/dynamic.domain.net";
allow-update{
key dynamic.domain.net;
};
};</nowiki>

== Zone files ==

This is a simple '''zone file''' which corresponds to the '''masterdomain.net''' entry outlined in the sample '''named.conf''' above. In our example configuration, this file is /etc/namedb/zones/masterdomain.net.

$ORIGIN net.
$TTL 5m

masterdomain IN SOA www.masterdomain.net. hostmaster.www.masterdomain.net. (
1 ; serial
4h ; refresh
15m ; retry
8h ; expire
4m) ; negative caching TTL
IN NS ns1.masterdomain.net.
IN NS ns2.masterdomain.net.
MX 10 mail.masterdomain.net.
IN A 68.96.111.12

$ORIGIN masterdomain.net.
www IN CNAME masterdomain.net.
ns1 IN A 68.96.111.10
ns2 IN A 68.96.111.11

This is a very simple (but serviceable) zone file, with one webserver that responds to either masterdomain.net or www.masterdomain.net, and two individual nameservers. (These nameservers will also have A records configured in the [[root servers]], since masterdomain.net is a second level domain. For more complex examples, see also [[DNS record types]] and [[BIND (dynamic DNS)]].

[[Category:Important Config Files]]

At

2007-06-17T04:45:41Z

216.110.12.175:

The '''at''' scheduler is used to schedule a job for one-time-only running at a later date. For comparison, the [[cron]] scheduler is used to schedule jobs for repeated execution at regular intervals. One very handy use of the '''at''' scheduler is to schedule lengthy jobs to run in the background immediately - that way even if you need to (or are forced to) close your [[shell]] session, your job will continue running.

The basic syntax of '''at''' is to type '''at''' followed by a time (specified in [[POSIX time format]]) you wish your new job to be executed. Examples would be "at now" to run the job immediately, "at 0400" to run the job at 4 AM today, or "at 200409282300" to run the job at 11:00 PM on September 28th of 2004. Once this is done, you enter interactive mode, and any further commands you type will be part of the '''at''' job scheduled. Once you're done entering in commands to be scheduled, you press CTRL-D (aka the [[eof]] character) and the scheduler tells you what your job number is and what shell it will be executed with (typically /bin/sh by default).

ph34r#''' at now'''
'''cvsup /usr/share/examples/cvsup/ports-supfile'''
''' ''<nowiki>[user presses CTRL-D]</nowiki>'' '''
Job 3 will be executed using /bin/sh
ph34r#

You may also use the -f option to specify a file that contains the list of commands you wish to process - for example:

ph34r#''' echo "cvsup /usr/share/examples/cvsup/ports-supfile" > at-job.txt'''
ph34r#''' at -f at-job.txt now'''
Job 5 will be executed using /bin/sh
ph34r#

If all you want to do is force a job started from the shell into the background, you can do that without using '''at''' simply by adding an ampersand to the end of your command line - for example:

ph34r#''' cvsup /usr/share/examples/cvsup/ports-supfile

OpenVPN

2007-06-17T03:27:41Z

216.110.12.175:

[http://openvpn.sourceforge.net OpenVPN] is a very useful open source, cross platform Virtual Private Networking tool. It uses SSL encryption (dynamic or 2048-bit static shared key), can use LZO stream compression, and is blindingly fast as well as much more secure compared to typical industry standard IPSEC DES or IPSEC 3DES solutions. Better yet, it's so simple it can be run entirely from the command line.

==Installing==
To build it on a FreeBSD machine, just:

cd /usr/ports/security/openvpn
make install clean

it's that easy. Actually doing anything with it will require a little more work. There are many MANY ways to do this, but this one's useful, simple, and clean.

First, generate yourself a private key file and '''chmod''' it so that only its owner can read it:

ph34r# '''openvpn --genkey --secret /usr/local/etc/openvpn.key'''
ph34r# '''chmod 400 /usr/local/etc/openvpn.key'''

==Starting OpenVPN==
Now you'll need a command to start it with. It can be done purely from the command line - and in fact, in one sense, that's exactly what we're going to do - but to make our lives a little easier, we'll ''actually'' use command line stuff from a shell script in '''/usr/local/etc/rc.d'''. So place this - or something similar - in your '''/usr/local/etc/rc.d''':

#!/bin/sh

case "$1" in
start)
# VPN subnets are contained in 10.10.x.x / 255.255.0.0
# port range forwarded through the router is 4900-4982

# first make sure the TAP module is loaded
kldload if_tap

# now ensure IP forwarding is enabled
/sbin/sysctl -w net.inet.ip.forwarding=1

# Now, make sure there are enough tun* / tap* devices in /dev
cd /dev
/bin/sh MAKEDEV tap0 tap1 tap2 tap3 tap4 tap5 tap6 tap7 tap8 tap9

# Finally, open up for business.
# A tunnel numbered [x] is configured as follows:
# device tun[x], port (4900 [x]), network 10.10.(10 [x])
# Client machine is always .2, server is always .1

# note - ping-restart on server end with disconnected clients
# seems to be the problem resulting in exhausted mbufs. Trying
# ping-restart on client end only and hoping for the best.

# 0. Server side - dynamic VPN
/usr/local/sbin/openvpn \
--dev tap0 --port 4900 --ifconfig 10.10.10.1 255.255.255.252 \
--tun-mtu 1500 --tun-mtu-extra 32 --mssfix 1450 --key-method 2 \
--secret /usr/local/etc/openvpn.key --ping 1