Que lindo corre bind9 en alpine linux. Ahora que mis servidores están todo en el pool de xenserver (los reyes magos me trajeron un servidor pro) tengo un nuevo problema. Dentro de la red interna de xen, los servidores tienen una ip distinta. Por ejemplo, para todo el mundo, el alpine linux que hace de router, es 192.168.0.1, pero para los servidores, es 169.254.0.10

Además, el forward para infomed, es un privilegio que solo los servidores tienen. Por tanto, lo más seguro, será usar una zona para la LAN y otra para la red interna del pool.

Esto me recuerda las DMZ, pero no es lo mismo, porque no estoy creando cuellos de botella. La red interna del pool es una vif, que funciona sin emitir tráfico real por alguna pif.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72

// vim:set ts=4 sw=4 et:

options {

   directory "/etc/bind/";
   pid-file "/run/named/named.pid";
   listen-on-v6 { none; };
   listen-on { 169.254.0.0/16; localhost; 192.168.1.0/24; };
   allow-transfer { none; };
   allow-update { none; };
   version none;
   hostname none;
   server-id none;

   // los servidores hacen recursion
   allow-recursion { 169.254.0.0/16; localhost;};
   recursion yes;

};

view lan  { // la red LAN

   match-clients {192.168.1.0/24;};

   zone "localhost" IN {
      type master;
      file "localhost.zone";
   };

   zone "hcg.sld.cu" IN {
      type master;
      file "hcg.zone";
      notify no;
   };

   zone "." {
      type master;
      file "fakeroot.zone";
   };

}; // view lan



view xen { // la red interna de XenServer

   match-clients {169.254.0.0/16; localhost;};

   zone "localhost" IN {
      type master;
      file "localhost.zone";
   };

   zone "xen" IN {
      type master;
      file "xen.zone";
      notify no;
   };

   zone "hcg.sld.cu" IN {
      type master;
      file "hcg.zone";
      notify no;
   };

   zone "sld.cu" {
      forwarders { 201.220.222.131; 201.220.222.132; };
      type forward;
      forward only;
   };

}; // view xen

Como ven, cree el dominio “.xen” que solo será visible a la red interna del pool. La zona “hcg.sld.cu” también será visible para los servidores ya que estos tienen una pata en la LAN; a esto suele llamarse “shared zone” (zona compartida). Finalmente, la zona “sld.cu” (debajo de hcg) es una zona forward en la vista de la interfaz interna.

El host proxy.hcg.sld.cu resolverá una ip de la lan; de esta misma manera, el host proxy.xen, resolverá la ip de dicho host, pero dentro de la red interna del pool.

¿y por qué?

Por que esta menera, solo los servidores (a través de la red del pool), harán forward. Por ejemplo, el servidor de correo, podrá enviar y recibir su correo multipop, ya que el alpine que está haciendo como router, permite forward desde la red del pool hacia la WAN; o sea, todos los servidores, ven a la WAN. Es obligaría al servidor de correo, a usar el dns de infomed para resolver direcciones de infomed y el servidor local para resolver las direcciones de la LAN, lo cual funciona de asco. Sin embargo, la vista del pool tiene una zona forward. Cabe destacar, que una zona forward y un fakeroot, no se por qué; hace que ninguna pinche.

Sensillo y seguro.