Configurar un servidor de nombres de solo almacenamiento en cache

Este es un objetivo bien facil, y no creo que tengan problemas en la implementacion del mismo si llegaran a preguntarle esto en el examen.

Para comenzar partiremos de la siguiente configuracion:

Cliente 1: labsystem1.home.cert.com 192.168.4.60
Cliente 2: labsystem2.home.cert.com 192.168.4.70

Partiendo de esta configuracion vamos a comenzar con la instalacion de los paquetes necesarios. Para la configuracion de un servidor de nombres de solo almacenamiento vamos a necesitar el paquete “unbound”, entonces los instalamos en el cliente 1:

[root@labsystem1 ~]# yum install -y unbound
Loaded plugins: langpacks, product-id, search-disabled-repos, subscription-
: manager
This system is not registered to Red Hat Subscription Management. You can use subscription-manager to register.
Resolving Dependencies
--> Running transaction check
---> Package unbound.x86_64 0:1.4.20-28.el7 will be installed
--> Finished Dependency Resolution

Dependencies Resolved

===========================================================================
Package Arch Version Repository Size
===========================================================================
Installing:
unbound x86_64 1.4.20-28.el7 InstallMedia 474 k

Transaction Summary
===========================================================================
Install 1 Package

Total download size: 474 k
Installed size: 1.6 M
Downloading packages:
Running transaction check
Running transaction test
Transaction test succeeded
Running transaction
Installing : unbound-1.4.20-28.el7.x86_64 1/1
Verifying : unbound-1.4.20-28.el7.x86_64 1/1

Installed:
unbound.x86_64 0:1.4.20-28.el7

Complete!
[root@labsystem1 ~]#

Una vez instalado el paquete vamos a contuniar iniciando el servicio y posteriormente con la configuracion del mismo. Para esto vamos a editar alguna lineas en el archivo “/etc/unbound/unbound.conf”

En este archivo las lineas que vamos a editar con las siguintes:

interface 192.168.4.60
access-control: 192.168.4.0/24 allow
domain-insecure: "home.cert.com"
forward-zone:
name: "."
forward-addr: 8.8.8.8

En este caso vamos a utilizar el DNS de google, esto es solo para propositos de entrenamiento, si usted tiene un DNS que pueda resolver las direcciones de las peticines de los clientes puede utilizarlo.

Ahora vamos a reiniciar el servicio y comprobar que este corriendo correctamente.

[root@labsystem1 ~]# systemctl restart unbound.service
[root@labsystem1 ~]# systemctl status -l unbound.service
● unbound.service - Unbound recursive Domain Name Server
Loaded: loaded (/usr/lib/systemd/system/unbound.service; enabled; vendor preset: disabled)
Active: active (running) since Fri 2017-03-24 23:22:51 PDT; 5s ago
Process: 4393 ExecStartPre=/usr/sbin/unbound-anchor -a /var/lib/unbound/root.key -c /etc/unbound/icannbundle.pem (code=exited, status=0/SUCCESS)
Process: 4391 ExecStartPre=/usr/sbin/unbound-checkconf (code=exited, status=0/SUCCESS)
Main PID: 4400 (unbound)
CGroup: /system.slice/unbound.service
└─4400 /usr/sbin/unbound -d

Mar 24 23:22:50 labsystem1.home.cert.com systemd[1]: Starting Unbound recursive Domain Name Server...
Mar 24 23:22:50 labsystem1.home.cert.com unbound-checkconf[4391]: unbound-checkconf: no errors in /etc/unbound/unbound.conf
Mar 24 23:22:51 labsystem1.home.cert.com systemd[1]: Started Unbound recursive Domain Name Server.
Mar 24 23:22:51 labsystem1.home.cert.com unbound[4400]: Mar 24 23:22:51 unbound[4400:0] warning: increased limit(open files) from 1024 to 8266
Mar 24 23:22:51 labsystem1.home.cert.com unbound[4400]: [4400:0] notice: init module 0: validator
Mar 24 23:22:51 labsystem1.home.cert.com unbound[4400]: [4400:0] notice: init module 1: iterator
Mar 24 23:22:51 labsystem1.home.cert.com unbound[4400]: [4400:0] info: start of service (unbound 1.4.20).
[root@labsystem1 ~]#

Al parecer todo esta perfecto, entonces vamos a realizar otra verificacion para estar doblemente seguros:

[root@labsystem1 ~]# unbound-control status
version: 1.4.20
verbosity: 1
threads: 2
modules: 2 [ validator iterator ]
uptime: 82 seconds
unbound (pid 4400) is running...
[root@labsystem1 ~]#

Tambien podemos comprobar si el archivo esta bien configurado:

[root@labsystem1 ~]# unbound-checkconf
unbound-checkconf: no errors in /etc/unbound/unbound.conf
[root@labsystem1 ~]#

Otro dato es que podemos realizar un dump a la cache:

[root@labsystem1 ~]# unbound-control dump_cache
START_RRSET_CACHE
END_RRSET_CACHE
START_MSG_CACHE
END_MSG_CACHE
EOF
[root@labsystem1 ~]#

Como ven tenemos varios comandos utiles para trabajar, pero ahora vamos a proceder con la configuracion del firewall para que este servicio pueda ser utilizado por el cliente 2;

[root@labsystem1 ~]# firewall-cmd --permanent --add-service=dns ; firewall-cmd --reload
success
success
[root@labsystem1 ~]# netstat -tlpnu | grep 53
tcp 0 0 192.168.4.60:53 0.0.0.0:* LISTEN 4400/unbound
tcp 0 0 192.168.122.1:53 0.0.0.0:* LISTEN 1487/dnsmasq
tcp 0 0 127.0.0.1:8953 0.0.0.0:* LISTEN 4400/unbound
tcp 0 0 127.0.0.1:25 0.0.0.0:* LISTEN 1535/master
tcp6 0 0 ::1:8953 :::* LISTEN 4400/unbound
tcp6 0 0 ::1:25 :::* LISTEN 1535/master
udp 0 0 0.0.0.0:5353 0.0.0.0:* 671/avahi-daemon: r
udp 0 0 192.168.4.60:53 0.0.0.0:* 4400/unbound
udp 0 0 192.168.122.1:53 0.0.0.0:* 1487/dnsmasq
[root@labsystem1 ~]# ss -tlpnu | grep 53
udp UNCONN 0 0 *:5353 *:* users:(("avahi-daemon",pid=671,fd=13))
udp UNCONN 0 0 192.168.4.60:53 *:* users:(("unbound",pid=4400,fd=3))
udp UNCONN 0 0 192.168.122.1:53 *:* users:(("dnsmasq",pid=1487,fd=5))
tcp LISTEN 0 5 192.168.4.60:53 *:* users:(("unbound",pid=4400,fd=4))
tcp LISTEN 0 5 192.168.122.1:53 *:* users:(("dnsmasq",pid=1487,fd=6))
tcp LISTEN 0 5 127.0.0.1:8953 *:* users:(("unbound",pid=4400,fd=6))
tcp LISTEN 0 100 127.0.0.1:25 *:* users:(("master",pid=1535,fd=14))
tcp LISTEN 0 5 ::1:8953 :::* users:(("unbound",pid=4400,fd=5))
tcp LISTEN 0 100 ::1:25 :::* users:(("master",pid=1535,fd=15))
[root@labsystem1 ~]#

Y como ven, comprobamos que el cliente 1 tenga los puestos abiertos corectamente. Ahora vamos a logearnos en el cliente 2 y comenzar los cambios pertinentes para que utiliza este servidor como DNS. El cambio lo puede realizar permanentemente editando la configuracion del DNS, o si solo quiere realizar la prueba, puede editar el erchivo “/etc/resolv.conf”, pero recuerden que no recomiento editar este de forma manual.

Como ven en la imagen, el cambio fue aplicado ahora vamos a comprobar que podamos acceder a internet a travez del cliente 1. Para esto podemos abrir el navegador firefox y comprobar que tenemos acceso a alguna web

Tambien podemos realizar otras verificaciones en el cliente 2 como las siguientes:

[root@labsystem2 ~]# dig redhat.com

; <<>> DiG 9.9.4-RedHat-9.9.4-37.el7 <<>> redhat.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 48855
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;redhat.com. IN A

;; ANSWER SECTION:
redhat.com. 3488 IN A 209.132.183.105

;; Query time: 90 msec
;; SERVER: 192.168.4.60#53(192.168.4.60)
;; WHEN: Mon Jun 26 10:47:00 PDT 2017
;; MSG SIZE rcvd: 55

[root@labsystem2 ~]# dig usuarioroot.com

; <<>> DiG 9.9.4-RedHat-9.9.4-37.el7 <<>> usuarioroot.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 14896
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;usuarioroot.com. IN A

;; ANSWER SECTION:
usuarioroot.com. 435 IN A 23.229.240.0

;; Query time: 0 msec
;; SERVER: 192.168.4.60#53(192.168.4.60)
;; WHEN: Mon Jun 26 10:47:07 PDT 2017
;; MSG SIZE rcvd: 60

[root@labsystem2 ~]#

Entonces del lado del cliente 1, comprobamos de la siguiente forma:

[root@labsystem1 ~]# dig @localhost usuarioroot.com

; <<>> DiG 9.9.4-RedHat-9.9.4-37.el7 <<>> @localhost usuarioroot.com
; (2 servers found)
;; global options: +cmd
;; connection timed out; no servers could be reached
[root@labsystem1 ~]# dig @192.168.4.60 usuarioroot.com

; <<>> DiG 9.9.4-RedHat-9.9.4-37.el7 <<>> @192.168.4.60 usuarioroot.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 62977
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;usuarioroot.com. IN A

;; ANSWER SECTION:
usuarioroot.com. 236 IN A 23.229.240.0

;; Query time: 0 msec
;; SERVER: 192.168.4.60#53(192.168.4.60)
;; WHEN: Mon Jun 26 10:50:26 PDT 2017
;; MSG SIZE rcvd: 60

[root@labsystem1 ~]#
[root@labsystem1 ~]# dig @192.168.4.60 redhat.com

; <<>> DiG 9.9.4-RedHat-9.9.4-37.el7 <<>> @192.168.4.60 redhat.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 50298
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;redhat.com. IN A

;; ANSWER SECTION:
redhat.com. 3251 IN A 209.132.183.105

;; Query time: 0 msec
;; SERVER: 192.168.4.60#53(192.168.4.60)
;; WHEN: Mon Jun 26 10:50:57 PDT 2017
;; MSG SIZE rcvd: 55

[root@labsystem1 ~]#

Como ven todo esta funcionando a la perfeccion. Aclaro nuevamente que este es un tema bien facil, y no creo que tenga un valor importante para el examen ya que hay otros objetivos mas importantes. Pero como futuro ingeniero usted debe saber como enfrentarse a este objetivo.

Leave a Reply

Your email address will not be published. Required fields are marked *