Let's say I own two servers with the static IPv4 addresses a.a.a.a
and b.b.b.b
. Can I run my own DNS servers on them, so me and my friends can set a.a.a.a
and b.b.b.b
in our resolvers' settings, anywhere in the world, and have our own toy DNS root zone, where we can register any domain names we want on any level, without ever depending on registrars? Something like an internal DNS, but without the boundaries of a private network. If not, what exactly would be stopping me?
Currently I'm using a LAMP
configuration for both my landing page page, for the web app, and for the APIs. Now I'd like to split these things across multiple Virtual Servers (VS). I'm unsure of the network settings and before messing up all my DNS configurations I'd like to understand if I'm about to crash my configuration.
The landing page is hosted at the second level domain
(e.g. myurl.com
), the web app is hosted at the lower level domain app.myurl.com
, and the api at api.myurl.com
. I also have a preview domain: preview.myurl.com
, used for testing.
Since everything is hosted on the same VS, I currently have also four different folders (landing
, api
, webapp
, preview
), that act as "virtual hosts" for each subdomain.
My DNS configuration looks like this:
myurl.com. A 300 123.123.123.123
www.myurl.com. CNAME 300 myurl.com.
api.myurl.com. CNAME 300 myurl.com.
app.myurl.com. CNAME 300 myurl.com.
preview.myurl.com. CNAME 300 myurl.com.
To start I'd like to change the data of each CNAME entry to the actual IP of the current VS. So that it would look like this:
myurl.com. A 300 123.123.123.123
www.myurl.com. CNAME 300 myurl.com.
api.myurl.com. CNAME 300 123.123.123.123
app.myurl.com. CNAME 300 123.123.123.123
preview.myurl.com. CNAME 300 123.123.123.123
Then the idea is to point each subdomain to the proper VS. Initially all lower level domains (except for www.
) will still be pointing to the current VS, while the second level domain for the landing page (A
record for myurl.com.
) will need to point to a new IP
for a new VS.
Questions:
- Will these changes affect the way in which the current Apache Server is distributing the traffic to each subfolder (i.e.
landing
,api
,webapp
,preview
)? If so, even if allIP
addresses remain the same? - To test things out, could I start by changing only the
data
value forpreview.myurl.com.
without risking of compromising the rest? - Once all lower level domains (e.g. api.myurl.com) point to the IP of the VM, can I point the
A
value ofmyurl.com.
to a different IP without compromising the other lower level domains (api
,app
,preview
)?
I have been reading http://www.centos.org/docs/5/html/Deployment_Guide-en-US/s1-bind-zone.html but the document raised a question. What is the meaning of IN? Is it just a class which is optional or does it mean more than that?
(Yes I read that in named.conf IN is a class statement but I don't know if the same applies to the zone files)
I understand that if I don't define a class "IN" in the named.conf zone statement then I don't have to use it either in the zone files like for example:
With class statement
named.conf
zone "example.com" IN {
file "example.com.zone";
};
example.com.zone
server1 IN A 10.0.1.5
server2 IN A 10.0.1.6
Without class statement
named.conf
zone "example.com" {
file "example.com.zone";
};
example.com.zone
server1 A 10.0.1.5
server2 A 10.0.1.6
UPDATE:
BIND Version:
[[email protected]] $ named -v
BIND 9.3.6-P1-RedHat-9.3.6-16.P1.el5
Operating System:
CentOS release 5.6 (Final)
After running [[email protected]] $ dig @10.224.45.130 example.com. axfr
:
Slave:
; <<>> DiG 9.3.6-P1-RedHat-9.3.6-16.P1.el5 <<>> @10.224.45.130 example.com. axfr
; (1 server found)
;; global options: printcmd
; Transfer failed.
Master:
28-Aug-2011 12:29:01.384 client 10.224.45.131#60553: query: example.com IN AXFR -
28-Aug-2011 12:29:01.384 client 10.224.45.131#60553: zone transfer 'example.com/AXFR/IN' denied
Same error message as before.
UPDATE 2:
[[email protected] ~] # iptables -L -n -v
Chain INPUT (policy DROP 30235 packets, 1747K bytes)
pkts bytes target prot opt in out source destination
171K 23M ACCEPT all -- lo * 0.0.0.0/0 0.0.0.0/0
0 0 ACCEPT all -- tun0 * 0.0.0.0/0 0.0.0.0/0
0 0 ACCEPT all -- tap0 * 0.0.0.0/0 0.0.0.0/0
57196 6930K ACCEPT all -- br0 * 0.0.0.0/0 0.0.0.0/0
688 57376 ACCEPT icmp -- * * 0.0.0.0/0 0.0.0.0/0 icmp type 8
37869 6120K ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED
392 21216 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:22
1 64 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:53
74 5275 ACCEPT udp -- * * 0.0.0.0/0 0.0.0.0/0 udp dpt:53
0 0 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:80
1 64 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:110
0 0 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:143
3 192 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:389
0 0 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:443
1 64 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:465
1 64 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:587
13 832 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:636
0 0 ACCEPT udp -- * * 0.0.0.0/0 0.0.0.0/0 udp dpt:694
1 64 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:843
1 64 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:873
0 0 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:953
119 7584 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:993
0 0 ACCEPT udp -- * * 0.0.0.0/0 0.0.0.0/0 udp dpt:993
0 0 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:1194
0 0 ACCEPT udp -- * * 0.0.0.0/0 0.0.0.0/0 udp dpt:1194
1 48 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:3306
1 64 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:5901
0 0 ACCEPT tcp -- * * 0.0.0.0/0 10.224.45.130 tcp dpt:10000
0 0 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:11211
0 0 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:11212
0 0 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:11213
0 0 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:11511
0 0 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:11512
0 0 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:11513
Chain FORWARD (policy DROP 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
2987 372K ACCEPT all -- br0 * 0.0.0.0/0 0.0.0.0/0
0 0 ACCEPT all -- * br0 0.0.0.0/0 0.0.0.0/0
0 0 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:80
0 0 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:443
Chain OUTPUT (policy ACCEPT 246K packets, 37M bytes)
pkts bytes target prot opt in out source destination
I've probably looked at every single page regarding BIND master/slave setup, and I cannot for the life of me get the zone transfer working.
Here's my setup: (scroll down for description of problem)
Master: 10.224.45.130
/etc/named.conf
options {
directory "/var/named";
version "unknown";
pid-file "/var/run/named/named.pid";
recursion yes;
allow-recursion { localhost; localnets; };
notify explicit;
allow-transfer {
10.224.45.131;
};
also-notify {
10.224.45.131;
};
};
zone "." {
type hint;
file "named.root";
};
zone "example.com" IN {
type master;
file "data/example.com.hosts";
};
Slave: 10.224.45.131
/etc/named.conf
options {
directory "/var/named";
version "unknown";
pid-file "/var/run/named/named.pid";
recursion yes;
allow-recursion { localhost; localnets; };
notify yes;
allow-transfer { "none"; };
allow-notify {
10.224.45.130;
};
};
zone "." {
type hint;
file "named.root";
};
zone "example.com" IN {
type slave;
file "slaves/example.com.hosts";
masters {
10.224.45.130;
};
};
Here's the problem. When I restart named on the slave server it sees that the zone files do not exist yet and requests a transfer from the master server:
named.log (Slave)
[10.224.45.131] zone example.com/IN: no database exists yet, requesting AXFR of initial version from 10.224.45.130#53
...after which the master server receives the transfer request:
named.log (Master)
[10.224.45.130] client 10.224.45.131#53467: query: example.com IN AXFR -
...and replies with the transfer request, which gets denied:
named.log (Master)
[10.224.45.130] client 10.224.45.131#53467: zone transfer 'example.com/AXFR/IN' denied
...on the slave server it shows up as being REFUSED:
named.log (Slave)
[10.224.45.131] transfer of 'example.com/IN' from 10.224.45.130#53: failed while receiving responses: REFUSED
Looking at all the configs over and over I can't find anything wrong with the settings. I have the master server's IP address listed in the masters
setting of the slave zone configuration, I have the slave server's IP address listed in the allow-transfer
setting of the master options settings.
All the IP addresses are what they should be, it's not like it's trying to use the public IP address and being rejected because the IP address doesn't match. I have iptables setup to allow TCP/UDP connections on port 53 (and 953) on both servers. I have setup the file permissions properly so that the /slaves directory where the slave zone files are stored is writable by the named
user.
No matter what I do I always get this same error. If anyone can give me a clue as to what I'm missing I would really appreciate it!