BluVPN:DNS
This article is a part of BluVPN.
Contents |
[edit] Dependencies
For this to work you will require the following:
- Bind
- A server inside BluVPN
- The willingness to let hawken know every time you set up a server and every time you change what it serves (inside 159.10.in-addr.arpa and vpn.blucoders.net)
[edit] Learn how bind pulls in its config
Just a quick note before we start: The files used here are placed in the /etc/bind directory in debian by default. On arch, this is not true; you have a single file: /etc/named.conf. Before you start, this can be a good way to work around it:
# For arch users: # make the directories we want (/etc/bind and /etc/bind/db) mkdir -pv /etc/bind/db # move the file into the dir mv /etc/named.conf /etc/bind/ touch /etc/named.conf
In /etc/named.conf:
include "/etc/bind/named.conf";
For debian users, the options are by default found in /etc/bind/named.conf.options, have a look look in /etc/bind/named.conf and the files it includes.
For arch users: You can link the whole thing together using small files if you want: The include "file" statement makes it possible!
Learn how bind is configured already, so that you put statements where they make the most sense. After all, we are doing this because we want to learn something from it! :)
[edit] Let's go break something!
[edit] Introduction
Note: The root hints are ready and waiting for all of you (lamers) to set up your server and let hawken know! :D
One of the services to be run on BluVPN is DNS. We are trying to manage the domains:
159.10.in-addr.arpa vpn.blucoders.net
[edit] Access lists
The root hints are placed as a master zone on gamma, with transfer access for the other servers so that they can clone the root hints and become root servers as well. For each of the nameservers, there will be an access list for resolving names inside bluvpn. This is what the bluvpn clients will match under, allowing them to use this nameserver:
acl bluvpn {
10.159.0.0/16;
};
And an access list for transfer. This is what the other nameservers matches under, allowing them to download your zone and clone it. If you do not want other nameservers to be able to do this, you can tighten this list:
acl bluvpn-transfer {
10.159.1.1;
10.159.2.1;
10.159.3.1;
10.159.4.1;
10.159.6.1;
};
As an example, gamma is going to host the root hints. The other servers will want to download these, so that downtime at gamma won't bring down the entire DNS system.
We will also need access lists for other lans your computer is in who should use the BluVPN view.
acl lan {
127.0.0.0/8;
192.168.0.0/24;
};
You don't need that particular lan there, though. But localhost is always a good idea.
[edit] Options
We want to restrict our nameserver to avoid internet any access to it (You heard about the massive DDoS of root servers by "hackers" trying to resolve root names using a lot of misconfigured nameservers?)
options {
listen-on-v6{any;};
allow-transfer{none;};
allow-recursion{none;};
allow-query{none;};
};
We will open up again shortly. This is the global, or default access lists, and "no" by default is always a good thing.
Listen-on-v6: If you want this nameserver to listen on IPv6 addresses.
Transfer: People who can ask for you to send them all the data for the domains you own/host.
Recursion: People who can ask this nameserver to ask other nameservers for a domain name.
Query: People who can ask this server anything at all.
Ktulu noticed that his nameserver kept asking the google nameservers for names inside BluVPN. That happened because the nameserver used forwarders. When you use forwarders, it basically means that the nameserver is going to ask the specified nameserver for any zone that it doesn't host itself. If turned off, the nameserver will ask other nameservers on the web directly, including the nameservers inside BluVPN.
TL;DR, Do NOT use forwarders.
[edit] Views
Then, we will create the bluvpn view (most likely directly in named.conf)
view "bluvpn" {
match-clients{bluvpn; lan;};
allow-transfer{bluvpn-transfer;};
allow-query{bluvpn; lan;};
allow-recursion{bluvpn; lan;};
include "/etc/bind/named.conf.internet";
include "/etc/bind/named.conf.bluvpn";
};
Note that the files included will be set up shortly. If you want to host a domain on the internet, you can create another view, the internet view.
view "internet" {
match-clients{any;};
allow-transfer{none;};
allow-query{any;};
allow-recursion{none;};
include "/etc/bind/named.conf.external";
};
If you want to be able to resolve that domain from BluVPN, you can also add the line
include "/etc/bind/named.conf.external";
to the bluvpn view.
[edit] Zones
named.conf.internet is the file which defines root hints needed to resolve internet names. This file and the database files related to it are in this archive:
# Download the internet: wget http://www.thehawken.org/internet.tar.gz
named.conf.bluvpn will have the zone files for BluVPN. It contains hints for the root BluVPN zones!: (10.159.2.1 is gamma, which hosts these hints) Your server will also be the master for your own subdomain.
zone "vpn.blucoders.net" {
type slave;
file "/etc/bind/db/vpn.blucoders.net";
masters { 10.159.2.1; };
};
zone "159.10.in-addr.arpa" {
type slave;
file "/etc/bind/db/159.10.in-addr.arpa";
masters { 10.159.2.1; };
};
zone "abk.vpn.blucoders.net" {
type master;
file "/etc/bind/db/abk.vpn.blucoders.net";
};
zone "1.159.10.in-addr.arpa" {
type master;
file "/etc/bind/db/1.159.10.in-addr.arpa";
};
[edit] Your zonefile
After you're finished with the zone definitions, you have probably realized that the zones themselves actually should exist. The "slave" entries may create themselves, but only if the user bind runs under has permission to edit /etc/bind/db. In debian, this user is bind. In arch, this user is named.
# Debian chown bind /etc/bind/db # Arch chown named /etc/bind/db
When it comes to your master entries, you have to create the zone file yourself.
# Creating the file cd /etc/bind/db touch abk.vpn.blucoders.net 1.159.10.in-addr.arpa
In abk.vpn.blucoders.net:
;
; BIND abk.vpn.blucoders.net
;
$TTL 300
; TTL = how long cached names will last before asking again.
$ORIGIN abk.vpn.blucoders.net.
; So that we can shorten nyu.abk.vpn.blucoders.net down to nyu
@ IN SOA abk.vpn.blucoders.net. bluserv.abk.vpn.blucoders.net. (
; The above two entries are 1: the subdomain name and 2: the full name of the primary nameserver.
2011050900 ; Serial, format YYYY MM DD ##
604800 ; Refresh
86400 ; Retry
2419200 ; Expire
604800 ; Negative Cache TTL
)
IN NS bluserv
IN NS nyu
; ABK has two nameservers, nyu and bluserv
IN MX 10 bluserv
; ABK wants his internal mail delivered to bluserv. His internal mail being abk@abk.vpn.blucoders.net.
IN A 10.159.6.1
; ABK wants the front page (abk.vpn.blucoders.net) to link to his non-existant vhost at nyu.
bluserv IN A 10.159.1.1
switch IN A 10.159.1.2
the_rest_of_your_lan IN A 10.159.1.3
nyu IN A 10.159.6.1
; It is very important that you add A's for your nameservers here.
; from here, you have absolute freedom..
www IN CNAME nyu
rfc-ignorant IN CNAME rfc-ignorant
; This will also make me shoot you if I see it...
When it comes to the serial, it's set up of Year, month and day, and finally something that looks like a revision number.
2011050900 = 2011 05 09 00 = 2011, may, 9th, rev 0 = YYYY MM DD ##
You also need to tell hawken what you want to use as the nameservers name. In this case it is bluserv, and should be mentioned in the SOA-line and in the NS-line.
In 1.159.10.in-arrd.arpa:
;
; BIND 1.159.10.in-addr.arpa (rDNS for 10.159.1.0/24)
;
$TTL 300
$ORIGIN 1.159.10.in-addr.arpa.
; Sadly, we have to provide LOOONG names....
@ IN SOA abk.vpn.blucoders.net. bluserv.abk.vpn.blucoders.net. (
2011050900 ; Serial, format YYYY MM DD ##
604800 ; Refresh
86400 ; Retry
2419200 ; Expire
604800 ; Negative Cache TTL
)
IN NS bluserv.abk.vpn.blucoders.net.
IN NS nyu.abk.vpn.blucoders.net.
1 IN PTR bluserv.abk.vpn.blucoders.net.
2 IN PTR switch.abk.vpn.blucoders.net.
3 IN PTR the_rest_of_your_lan.abk.vpn.blucoders.net.
; It is very important that you add A's to point back when you add an entry here.
; from here, you have a little less freedom..
4 IN PTR I.am.a.lamer.
; this will also make me shoot you if I discover it..
[edit] Extra
If you want to mirror one of the servers "private" zone, you can put that servers zones as slaves in your own nameserver, like this:
zone "abk.vpn.blucoders.net" {
type slave;
file "/etc/bind/db/abk.vpn.blucoders.net";
masters { 10.159.1.1; };
};
zone "1.159.10.in-addr.arpa" {
type slave;
file "/etc/bind/db/1.159.10.in-addr.arpa";
masters { 10.159.1.1; };
};
PS: This is not really needed, but ABK might want it because he will probably make two identical mirrors at nyu and bluserv.
[edit] Last but not least
Every time you make a configuration change and want to apply it, you will need to restart bind.
# Debian /etc/init.d/bind restart # Arch /etc/rc.d/named restart
If it won't start up, it's probably a syntax error. The feedback named gives you is very nice, in some cases the file it says has errors is not the file with the syntax error. The most common syntax error is the lack of ';'.
For every one of these zone definitions, there is one syntax error. Can you spot it?
zone "vpn.blucoders.net" {
type slave;
file "/etc/bind/db/vpn.blucoders.net";
masters { 10.159.2.1 };
};
zone "159.10.in-addr.arpa" {
type slave;
file "/etc/bind/db/159.10.in-addr.arpa";
masters { 10.159.2.1; }
};
zone "1.159.10.in-addr.arpa" {
type master;
file "/etc/bind/db/1.159.10.in-addr.arpa";
}
[edit] resolv.conf
Now that you got DNS working, you may want to fix your resolv.conf file!
domain abk.vpn.blucoders.net search abk.vpn.blucoders.net vpn.blucoders.net your-own-domain.tld nameserver 127.0.0.1
Basically, you set your domain name to that one on your subnet. In the search field, you set up other domains to search for an entry. That means, when you run
$ host gamma
The command does these lookups
gamma.abk.vpn.blucoders.net gamma.vpn.blucoders.net gamma.your-own-domain.tld
For fully qualified domain names, it will search for them without appending those domains first. The reason not to have blucoders.net in your search line, is that it matches wildcard! That means, anything that doesn't get hit before blucoders.net will be directed to bluserv... That's fun!
[edit] LEMME KNOW, YOU...
And since hawken takes care of the root, it means that if you want a server to actually resolve what you configured it for, hawken _must_ add it to the root of BluVPN-DNS :)
