Saludos amigos, hoy os vengo a contar un poco más acerca de dnscache, el nuevo servicio que Zimbra Collaboration incluye desde la versión 8.5. Se suele recomendar deshabilitar este servicio por desconocimiento o porque ya tenemos un servidor DNS ejecutándose en el mismo servidor, también puede simplemente no interesarnos en nuestra Infraestructura, aunque desde Zimbra, los Ingenieros lo recomiendan encarecidamente. Vamos con el menú de esta entrada:
- ¿Qué es dnscache?
- ¿Dónde se recomienda su instalación?
- ¿Cómo funciona?
- ¿Cómo instalarlo/habilitarlo?
- Realizando un test de DNS caching service (dnscache)
- Contenido adicional
¿Qué es dnscache?
Zimbra dnscache es un servicio basado 100% en Unbound, y se trata de un pequeño servidor DNS que almacena las peticiones DNS que realizamos, de tal forma que la primera vez que se consulta el DNS de un dominio se pregunta al server o servers DNS que dnscache tiene configurados, y las siguientes peticiones sobre el mismo dominio se realizarán sobre el propio server de dnscache.
¿Dónde se recomienda su instalación?
dnscache está especialmente recomendado para los nodos de MTA, y puede ser perfecto también para los entornos de Single-Server que no estén ejecutando ya Bind, dnsmasq, u otros similares.
Zimbra hace un uso intensivo de peticiones DNS especialmente para consultar las siguientes tecnologías, entre otras:
- Verificación DKIM
- Score de SpamAssassin
- Postfix RBLs para bloquear SPAM
Si tenemos Single-Server y bind instalado, bind por defecto también hace cache de las peticiones DNS, por lo qué quizás queramos seguir usando bind en este caso.
De todas formas en servidores de MTA que no están usando un servidor de DNS interno es muy recomendable instalar dnscache. Si por el contrario tenemos una o varias MTA que están haciendo uso de un DNS local basado en bind que ya hace cache, si instalamos dnscache en las MTA nos ahorraremos el tráfico local de peticiones DNS a nuestro servidor, en nuestra mano queda.
¿Se puede bloquear mi IP por alto tráfico de DNS?
La respuesta es afirmativa, se puede consultar el siguiente link oficial de Spamassasin donde lo comentan – https://wiki.apache.org/spamassassin/DnsBlocklists
- Por ejemplo URIBL bloquea desde 2007 cualquier IP desde donde se le pregunte mediante DNS más de 500.000 veces por día, este puede no ser el caso de un servidor con pocos usuarios, pero en caso de proveedores de servicio, etc. puede llegar a pasar.
- October 16th, 2007: ACLs placed on public DNS InfastructureUPDATE – Refusing queries on high traffic IPs just caused even more traffic to be generated. Because of the lack of negative caching when sending a refusal, this caused our mirrors to take on every query from IPs that are blocked. We have changed all REFUSED IP addresses over to simply returning NXDOMAIN to all the queries. By doing this, we at least benefit some from caching nameservers serving up the nxdomain for us, which reduces the amount of queries we have to handle from these high traffic hosts.URIBL has begun to block IPs hitting our public DNS mirrors with high volume. If you are sending anything close to 500k queries/day to our public dns, you queries may be refused already, or in the near future. If you would like to become a part of the public dns infastructure and give some queries back to the world, please contact [email protected]
- Otro ejemplo es 0spamDNBL que soporta 100 peticiones DNS por segundo o menos – http://0spam.fusionzero.com/
¿Cómo funciona?
Cómo creo que una imagen vale más que palabras, os dejo a continuación un diagrama de cómo funciona el flujo de correo y DNS de un entorno con dnscache y de un entorno sin dnscache.
Entorno con dnscache
Entorno sin dnscache
¿Cómo instalarlo/habilitarlo?
Para asegurarnos que nuestras MTA no entran en listas negras debido a las miles de peticiones de DNS que realizamos, se recomienda instalar dnscache en el rol de MTA, se puede instalar lanzando el proceso de instalación de la siguiente manera:
Answer [Y] to install zimbra-dnscache
When prompted, list the IP(s) of the sites local DNS servers El instalador va a cambiar por defecto la IP del DNS que resuelve el OS de manera interna por la del server de dnscache.
Si no introducimos ninguna IP para usar como DNSMaster, el valor por defecto es el DNS público de google 8.8.8.8.
Puedes hacer las siguientes acciones sobre el servicio start, stop, restart, reload o ver el status usando el siguiente comando zomo usuario Zimbra:
/opt/zimbra/bin/zmdnscachectlNota: dnscache no debe ser instalado en servidores donde ya están ejecutando otro servidor de DNS como bind, etc.
Comprobar el DNSMasterIP
Podemos comprobar la lista de servidores DNS que dnscache está usando para “alimentarse”:
zmprov getServer `zmhostname` | grep DNSMasterIP
zimbraDNSMasterIP: 8.8.8.8Añadir un DNSMasterIP
Siempre podemos añadir más servidores de DNS, internos o externos para que dnscache siga creciendo en su cache, para añadir un server de DNS ejecutaremos el siguiente comando:
zmprov ms `zmhostname` +zimbraDNSMasterIP 8.8.8.8Eliminar un DNSMasterIP
Si queremos eliminar un servidor de DNS de nuestra lista, porque ya no existe, o porque está fuera de servicio, etc, ejecutaremos el siguiente comando:
zmprov ms `zmhostname` -zimbraDNSMasterIP 8.8.8.8Realizando un test de DNS caching service (dnscache)
Por ejemplo, en este caso vamos a realizar una consulta de DNS sobre mail.google.com: La primera vez que lanzamos la petición tarda 62ms ya que el server de MTA pregunta a dnscache, y dnscache no tiene esta zona en su cache todavía por lo que pregunta al server DNS externo.
root@lab1:/home/oper# host -a mail.google.com
Trying "mail.google.com"
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 5818
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;mail.google.com. IN ANY
;; ANSWER SECTION:
mail.google.com. 21599 IN TXT "google-site-verification=PncXpRKRCAlDAdlesTtNFf6k9TvgxgcRfojdaKkEACY"
mail.google.com. 21599 IN CNAME googlemail.l.google.com.
Received 141 bytes from 127.0.0.1#53 in 62 msLa segunda consulta de DNS, utiliza solamente 0ms ya que la MTA pregunta a dnscache y dnscache ya tiene la zona cacheada, hemos ahorrado en bandwitdh y en peticiones que lanzamos al exterior de manera elegante:
root@lab1:/home/oper# host -a mail.google.com
Trying "mail.google.com"
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 52424
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;mail.google.com. IN ANY
;; ANSWER SECTION:
mail.google.com. 21593 IN TXT "google-site-verification=PncXpRKRCAlDAdlesTtNFf6k9TvgxgcRfojdaKkEACY"
mail.google.com. 21593 IN CNAME googlemail.l.google.com.
Received 141 bytes from 127.0.0.1#53 in 0 ms
Contenido adicional
- Se puede ojear la historia de esta funcionalidad en el siguiente Bug 83670.
- Usando además la Config Guide, vemos que Zimbra Collaboration ha añadido algunos nuevos valores referentes a DNS caching Service:
| ID | Name | Type | Since | Description |
|---|---|---|---|---|
| 1569 | zimbraDNSMasterIP | string | 8.5.0 | IP Address(es) of the root DNS servers to be used by the DNS cache service |
| 1584 | zimbraDNSUseTCP | enum | 8.5.0 | For zimbra dnscache, whether or not to use TCP. Defaults to yes |
| 1586 | zimbraDNSUseUDP | enum | 8.5.0 | For zimbra dnscache, whether or not to use UDP. Defaults to yes |
| 1597 | zimbraDNSTCPUpstream | enum | 8.5.0 | For zimbra dnscache, whether or not to only use TCP when talking to the upstream Master DNS servers. Defaults to no |
- Podéis ojear el Wiki en inglés también donde seguramente haya información más actualizada que en esta entrada de Blog – https://wiki.zimbra.com/wiki/DNS_caching_service_%28dnscache%29
Nada más amigos, espero que os haya gustado esta entrada y que os ayude a comprender este gran desconocido que es dnscache.
Un saludo
Un dato para quienes tienen configuraciones de servidores replicados con DRBD y Heartbeat es mejor no instalar esto ya que el servidor que queda como esclavo se queda sin servidores DNS a quien consultar y eso genera más de un problema. Es mejor instalar Bind9 configurado como dns-cache en ambos nodos para que corra siempre. Se obtiene el mismo resultado.
Saludos.
Buen comentario, no me habia percatado.
Un saludo
Una pregunta Jorge, los dns de los servidores de Zimbra que estoy montando tienen como DNS nuestros dns internos que estos hacen forwarding hacia los de google. Así los servidores pueden resolver el nombre de los otros servidores por dns. ¿Es una locura dejar como master dns los internos?.
Es lo recomendado, dejar un DNS interno que ademas pueda hacer cache local y asi en vez de lanzar 1000000 peticiones poir cada email que envias para chequear RBL, DNSBL, etc, chequeas a tu DNS local sin consumir trafico de internet y sin entrar en listas negras tu por tantas peticiones.
Un saludo