El SysAdmin del 3er Mundo

todo lo que expliqué mientras nadie prestaba atención

bind en infomed

| Comments

Seguimos con bind…

No hace mucho le comentaba a alguien, a raíz de una duda que tenía el colega Paradyx; la manera correcta de configurar un servidor bind para una red que cuelga de infomed.

Le comentaba que no vale la pena usar un forward por defecto; que hacer del dominio ‘.sld.cu’ una zona forward sería más que suficiente. Digo esto porque infomed no resuelve ningún dominio que valla más allá de “.sld.cu”, por tanto, no vale la pena transferirle las sepetecientas peticiones que hacen cuanta mierda se conecta a nuestra red (especialmente android).

“named.conf”
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
options {
   directory "/etc/bind/";
   pid-file "/run/named/named.pid";
   listen-on { 10.1.1.1; localhost; };
   allow-transfer { none; };
   allow-update { none; };
   version none;
   hostname none;
   server-id none;
};


view lan {

   match-clients {10.1.1.0/24;};

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

   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 lan

Como mi dominio es hcg.sld.cu (subdominio de .sld.cu) lo declaramos ARRIBA del dominio sld.cu. El dominio hcg.sld.cu es una zona master, sin embargo, el dominio sld.cu es del tipo forward y entonces ahí declaramos los forwarders (los dns de infomed).

Así solo le reenviaremos a infomed, aquellas peticiones que sean para infomed.

En mi opinión esto no es necesario. Tanto así, que la zona donde infomed hace forward; la tengo para los servidores. En el caso de la zona para LAN, simplemente declaro los servidores de correo en un fakeroot y listo.

Si este artículo te resultó interesante, considere donar 0.03 BTC: 1Kg4gu3e7u8HUw8bj5NbBciRg6Y56kuFCU

Comments