Zona DNS inversa. ¿Qué es una zona inversa en DNS? ¿Qué es un registro PTR? Servicio DNS: Dominios y Zonas
Buenas tardes, queridos lectores y suscriptores habituales, sitio de blogs de TI. La última vez vimos qué es un servidor DNS, sus principios operativos, registros básicos y mucho más. Si te perdiste la nota, te aconsejo que la leas. En la publicación de hoy quiero considerar la cuestión de las zonas inversas y su aplicación.
Atrás consulta DNS - una zona de dominio especial diseñada para determinar el nombre de un host por su dirección IPv4 mediante un registro PTR. La dirección de nodo AAA.BBB.CCC.DDD se traduce en notación inversa y se convierte en DDD.CCC.BBB.AAA.in-addr.arpa. Gracias a modelo jerárquico gestión de nombres, es posible delegar la gestión de zonas al propietario de un rango de direcciones IP. Para hacer esto, los registros del servidor DNS autorizado indican que un servidor separado es responsable de la zona CCC.BBB.AAA.in-addr.arpa (es decir, la red AAA.BBB.CCC.000/24).
Un registro PTR (del inglés pointer - pointer) asocia la IP de un host con su nombre canónico. Solicitud en el dominio in-addr.arpa a la IP del host en forma inversa devolverá el nombre de este anfitrión. Por ejemplo, (en el momento de escribir este artículo), para la dirección IP 192.0.34.164: una solicitud de registro PTR 164.34.0.192.in-addr.arpa devolverá su nombre canónico referidos.icann.org.in-addr.arpa
in-addr.arpa es una zona de dominio especial diseñada para determinar un nombre de host por su dirección IPv4 mediante un registro PTR. La dirección del host AAA.BBB.CCC.DDD se traduce en notación inversa y se convierte en DDD.CCC.BBB.AAA.in-addr.arpa. Gracias al modelo de gestión de nombres jerárquico, es posible delegar la gestión de zonas al propietario de un rango de direcciones IP. Para hacer esto, los registros del servidor DNS autorizado indican que un servidor separado es responsable de la zona CCC.BBB.AAA.in-addr.arpa (es decir, la red AAA.BBB.CCC/24).
Uso
Para reducir el volumen de indeseados correspondencia postal(spam) muchos servidores destinatarios correo electrónico Puede comprobar la presencia de un registro PTR para el host desde el que se realiza el envío. En este caso, el registro PTR de la dirección IP debe coincidir con el nombre del servidor de correo emisor al que se presenta durante la sesión SMTP.
Lo esencial
¿Qué es un registro de zona DNS inverso?
Las consultas DNS normales identifican una dirección IP desconocida para nombre famoso hosta Esto es necesario cuando, por ejemplo, el navegador necesita establecer una conexión TCP con el servidor utilizando la URL ingresada en el campo de dirección.
Foro.hetzner.de --> 213.133.106.33
El DNS inverso funciona en la otra dirección: la consulta determina el nombre de host que pertenece a la dirección IP.
213.133.106.33 --> dedi33.tu-servidor.de
Como puede ver, los nombres de host para solicitudes directas e inversas no tienen por qué ser los mismos.
¿Cuál es el propósito de un registro de zona DNS inverso?
- traceroute muestra no sólo direcciones IP, sino también nombres de host legibles por humanos. Esto hace que sea mucho más fácil diagnosticar errores.
- Una gran cantidad de servidores de correo solo aceptan mensajes si la dirección IP del remitente tiene un registro DNS inverso.
- Los registros DNS inversos se pueden utilizar en registros SPF (Sender Policy Framework; una tecnología que evita que se envíen spam y virus desde direcciones de correo electrónico falsas).
¿Cómo funciona técnicamente la búsqueda inversa en servidores DNS?
Práctica
¿Cómo puedo asignar varios nombres a mi dirección IP si hay diferentes dominios alojados en mi servidor?
Esto es imposible. Sólo se asigna un nombre a cada dirección IP.
Además, no importa qué zonas inversas estén registradas para el servidor. Para acceder al sitio, el navegador sólo necesita mantener presionado conversión directa(Nombre -->IP). Por supuesto, puede haber varios nombres, como varios registros A o varios registros CNAME que apunten a un registro A.
Para que los servidores de correo funcionen, no es necesario tener varios nombres de host por dirección IP. Registro DNS inverso debe coincidir con el nombre de host del servidor SMTP (consulte la configuración del servidor SMTP correspondiente).
Si se administran varios dominios a través de una dirección IP (un caso bastante común), puede usar un nombre neutral que no esté asociado con los dominios de los usuarios. Los filtros de spam simplemente verifican si el registro DNS inverso coincide con el nombre en la respuesta al comando HELO. Esto no afecta a los nombres de dominio de ninguna manera y direcciones postales en cartas enviadas.
- El registro DNS inverso debe coincidir con el nombre del servidor de correo o basarse en la dirección IP.
- El registro DNS inverso también debe resolver "reenviar" a la misma dirección IP.
- El registro DNS inverso no debería parecerse a uno generado automáticamente, como por ejemplo "162-105-133-213-static.hetzner.de", ya que estos nombres suelen ser valorados negativamente por los filtros de spam.
- El nombre de pila debe existir. No utilice nombres de dominio inexistentes.
Ejemplo de una buena entrada:
Srv01.grossefirma.de --> 213.133.105.162 213.133.105.162 --> srv01.grossefirma.de > telnet 213.133.105.162 25 220 srv01.grossefirma.de ESMTP listo
Configuré PTR en mi servidor DNS. ¿Por qué esto no funciona?
Su servidor DNS sólo es responsable de la resolución directa.
El propietario del bloque de direcciones IP (p. ej., Hetzner Online GmbH) es responsable del mantenimiento de servidores DNS autorizados para entradas inversas.
Los registros DNS inversos solo se pueden crear usando la función correspondiente del panel Robot ( menú izquierdo-> "Servidores" -> haga clic en servidor -> "IP" -> haga clic en campo de texto junto a la dirección IP).
La reescritura de mi servidor es diferente del HELO de mi servidor de correo. ¿Es esto un problema?
Ejemplo: registro DNS inverso para la dirección IP del servidor "www.grossefirma.de". Al comando HELO, el servidor de correo responde con "mail.grossefirma.de".
Algunos filtros de spam clasifican los correos electrónicos de dichos remitentes como "spam". Estas inconsistencias deben corregirse. El registro DNS inverso y el nombre del servidor de correo deben ser iguales. En el ejemplo anterior podrían ser, por ejemplo, "srv01.grossefirma.de". El nombre "www.grossefirma.de" se puede redirigir a srv01.grossefirma.de sin consecuencias utilizando un registro CNAME.
Se pueden realizar pruebas detalladas de los registros DNS utilizando
El Sistema de Nombres de Dominio es la base internet moderno. La gente no quiere molestarse en recordar el conjunto de números 63.245.217.105, sino que quiere que la computadora los conecte al nodo especificado usando el nombre mozilla.org. Esto es lo que hacen los servidores DNS: traducen las solicitudes de las personas en algo que pueden entender. formato digital. Sin embargo, en algunos casos, es posible que se requiera una dirección IP inversa → conversión de nombre DNS. Estos nombres se analizarán a continuación.
¿Para qué es?
Tener una dirección rDNS correctamente configurada es absolutamente necesario para enviar mensajes desde su servidor propio correo corporativo. Casi todos los servidores de correo rechazarán el mensaje al inicio de la sesión si la dirección IP de su servidor no tiene una entrada en la zona DNS inversa. El motivo del fallo del servidor de correo remoto probablemente se indicará de la siguiente manera:
550-"La dirección IP no tiene registro PTR (dirección a nombre) en el DNS, o cuando el registro PTR no lo tiene no tengo un registro A (nombre a dirección) coincidente. Por favor verifique y corrija su registro DNS."
o
550-No hay PTR correspondiente para tu Dirección IP (dirección IP), que es 550 requerida. Lo siento, adiós.
o simplemente
550 Tu IP no tiene Registro PTR
Número 550 en total tres casos es código estándar postal servidor SMTP un informe sobre error crítico, lo que impide insuperablemente trabajo adicional dentro de esta sesión de correo. Hay que decir que en general todos los errores de la serie 500 son críticos y es imposible seguir enviando correo después de que aparecen. El texto explica el motivo del rechazo con más detalle y afirma que el administrador del servidor de correo del destinatario lo ha configurado para comprobar si el servidor de correo emisor tiene una entrada en la zona DNS inversa (rDNS) y, si está ausente, el destinatario El servidor está obligado a rechazar la conexión al remitente (errores de la serie SMTP-5XX).
¿Cómo configurar y utilizar?
Derechos para configurar el reverso zonas DNS(DNS inverso) es propiedad únicamente del propietario del correspondiente bloque de direcciones IP al que corresponde esta zona. Este propietario suele ser el proveedor, que posee su propio sistema autónomo. Obtenga más información sobre cómo registrar su sistema autónomo(AS) y el bloque de direcciones IP se pueden leer en este artículo. En resumen, para registrar una zona DNS inversa, el operador de un bloque de direcciones IP debe registrarse en su cuenta personal en el sitio web de RIPE, un objeto de tipo "dominio", especifique la dirección de los servidores DNS que admitirán la zona rDNS y configure el soporte para una zona como 3.2.1.in-addr.arpa en ellos. Un puntero, un registro PTR, es responsable de los recursos en la zona inversa. Aquí es donde van las solicitudes para resolver la dirección IP en un nombre de host.
Si no es el feliz propietario de un sistema autónomo, la configuración de rDNS para una dirección IP o direcciones de servidor de correo comienza y termina con una solicitud al servicio de soporte del proveedor o proveedor de alojamiento. En ambos casos, el nombre de la dirección IP del servidor de correo, y especialmente del servidor de correo corporativo, debe indicarse de forma significativa.
Ejemplos de buenos nombres para un servidor de correo:
correo.dominio.ru
mta.dominio.ru
dominio.mx.ru
Ejemplos de malos nombres:
host-192-168-0-1.dominio.ru
cliente192-168-0-1.dominio.ru
vpn-dailup-xdsl-clients.dominio.ru
y similares. Es muy probable que dichos nombres se filtren como asignados. computadoras cliente, en los que no se puede instalar un servidor de correo, por lo que desde ellos se envía spam.
Puede y debe utilizar consultas con éxito para revertir zonas DNS inmediatamente después de iniciar el servidor de correo. Para hacer esto, sólo necesita realizar algunos ajustes menores en el software. En diferentes servidores de correo, la configuración de la verificación rDNS se realiza de manera diferente:
rechazar_cliente_desconocido
verificar = búsqueda_host_inversa
En el complemento Exgange Server, vaya a la sección Servidores, luego seleccione el servidor en la lista expandida, seleccione Protocolos y luego protocolo SMTP, en la ventana derecha, seleccione el servidor SMTP y haga clic derecho y seleccione de la lista Propiedades. Siguiente, pestaña Entrega → Realizar búsqueda DNS inversa en mensajes entrantes
Ahora todos los mensajes provenientes de direcciones IP que no tengan un registro DNS inverso (registros tipo PTR) serán rechazados y el flujo de spam se reducirá significativamente. Quizás este sea el método de filtrado de spam más sencillo, más eficaz y que consuma menos recursos: la comprobación inversa de DNS rechaza la gran mayoría del spam enviado desde ordenadores infectados. usuarios comunes, creando botnets de spammers.
Al volver a publicar un artículo, es necesario instalar un hipervínculo indexado activo al sitio fuente.
Continuando con el tema de la creación de sitios web, hablemos de esto. aspecto importante¿Cómo funciona el Sistema de Nombres de Dominio (DNS)? Muchas cuestiones relacionadas con la colocación inicial, así como con la transferencia de sitios entre diferentes servidores y hospedaje. Comprender cómo funciona el sistema de nombres de dominio facilita la administración de sus propios dominios y sitios asociados y otros servicios.
Qué ha pasado nombre de dominio? Para muchos, esto es sinónimo de la dirección de un sitio web, por ejemplo, www.sitio. Al escribir esta dirección, tiene la firme confianza de que terminará en este sitio y no en otro lugar. Al mismo tiempo, un nombre de dominio puede designar no solo un sitio web, sino también un correo electrónico, un servidor de intercambio. mensajes cortos u otro otro servicio de red e Internet. Los nombres de dominio se incluyen en zonas de dominio, que se encuentran una dentro de otra en orden jerárquico.
EN comprensión general Un dominio es un nombre simbólico que le permite dirigirse de forma única a un dominio autónomo de nombres en Internet. Y no sólo direccionar, sino también permitir que cualquier cliente pueda encontrar rápidamente el nodo requerido, sin siquiera tener la más mínima idea de su ubicación. No es exagerado decir que el sistema DNS es la base red moderna Internet en la forma en que todos lo conocemos y estamos acostumbrados.
El sistema DNS es global y tiene una jerarquía estricta. Considere el siguiente diagrama:
El nivel superior de la jerarquía es el dominio raíz, indicado por un punto, que contiene información sobre los dominios de primer nivel, p. ru, com, organización etc. El funcionamiento de la zona raíz está garantizado por 13 servidores raíz ubicados en todo el mundo y que replican constantemente sus datos entre ellos. De hecho, hay más servidores raíz, pero las características del protocolo le permiten especificar solo 13 nodos. nivel superior Por lo tanto, la escalabilidad y la tolerancia a fallos del sistema están garantizadas por los espejos de cada servidor raíz.
Los dominios de primer nivel nos son familiares zonas de dominio y pueden ser gestionados por organismos tanto nacionales como internacionales y tener sus propios términos de uso. Cada zona de dominio de primer nivel le permite colocar cantidad ilimitada dominios de segundo nivel, que todos los usuarios de Internet conocen como direcciones de sitios web.
A su vez, los dominios de segundo nivel también son zonas de dominio y permiten colocar dominios de tercer nivel, en los que, como en una muñeca rusa, se pueden colocar dominios del cuarto, quinto, etc. niveles. Para poder determinar sin ambigüedades los nodos ubicados en diferentes zonas, se introdujo el concepto nombre de dominio completo (FQDN, totalmente calificado Nombre de dominio ), que incluye todos los nombres de dominio principales en la jerarquía DNS. Por ejemplo, para nuestro sitio el FQDN será: sitio web. Exactamente así, terminando con un punto que indica la zona de la raíz.
esto es muy punto importante. EN uso diario Es habitual descartar el período final, pero en los registros DNS la ausencia último punto significa que este nombre de dominio pertenece a la zona de dominio actual, es decir El servidor DNS agregará a este nombre su propia zona de dominio y todas las zonas de nivel superior hasta la raíz.
Por ejemplo, en nuestro servidor en la zona. sitio web agregamos un registro tipo CNAME que apuntará a servidor de terceros, digamos, correo Yandex. La entrada correcta debería verse así:
Correo EN CNAMEdominio.mail.yandex.net.
EN en este caso nombre correo no es un FQDN y se ampliará a correo.sitio., si olvidamos poner un punto al final del nombre de dominio de Yandex, este nombre tampoco se percibirá como un FQDN y deberá completarse con el nombre de dominio completo. La siguiente es una entrada incorrecta:
Correo EN CNAME dominio.mail.yandex.net
Es difícil notar la diferencia para un ojo inexperto, pero en lugar de la interfaz web de correo de Yandex, este diseño nos enviará a una dirección inexistente: dominio.mail.yandex.net.site.
Una cosa más. Todos los registros de una zona de dominio los ingresan los administradores de zona en sus propios servidores DNS. ¿Cómo llegan a ser conocidos estos registros por el sistema DNS? Después de todo, no notificamos a los servidores DNS de nivel superior que hemos cambiado ningún registro.
Cualquier zona DNS contiene registros solo sobre sus nodos miembros y zonas secundarias. La información sobre los nodos en una zona descendente se almacena en sus propios servidores. Esto se llama delegación y le permite reducir la carga en los servidores raíz y brindar la autonomía necesaria a los propietarios de las zonas de dominio secundario.
Entonces compraste un dominio, digamos ejemplo.org, después de lo cual debes delegarlo, es decir. especifique los servidores de nombres (servidores DNS) que contendrán registros para esta zona de archivos. Pueden ser sus propios servidores o servicios públicos, por ejemplo, Yandex DNS.
En este caso, en la zona de dominio. organización se agregará una entrada:
Ejemplo EN NS dns1.yandex.net.
Lo que indicará que todos los registros de esta zona se encuentran en el servidor. dns1.yandex.net. Según las reglas, cada zona de dominio debe tener al menos dos servidores NS ubicados en subredes diferentes. En la práctica, a menudo se conforman con un servidor y le compran dos direcciones IP de diferentes rangos.
Ahora veamos cómo se produce la búsqueda del registro DNS que necesitamos y por qué el registro realizado en su servidor permite que visitantes de cualquier parte del mundo accedan a su sitio.
Digamos que un usuario quiere visitar el popular recurso Yandex Market, escribe barra de direcciones navegador correspondiente al nombre del sitio y presiona el botón Enter. Para mostrar el contenido de una página al usuario, el navegador debe enviar una solicitud al servidor web que atiende el sitio, y para ello es necesario conocer su dirección IP. Por lo tanto, el navegador contacta al cliente DNS para averiguar qué dirección coincide con el nombre de dominio ingresado por el usuario.
A su vez, el cliente DNS verifica las entradas en el archivo de hosts, luego en el caché local y, al no encontrarlas allí registros necesarios, envía la solicitud al especificado en configuración de red Servidor DNS. Lo más probable es que sea un proxy DNS de almacenamiento en caché local, como dnsmasq o un servidor DNS empresarial local. Estas soluciones no suelen ser servidores completos. sistema global DNS y no están incluidos en él, atienden solo la zona local y almacenan en caché las solicitudes de DNS, por lo que dicha solicitud, si los datos no están en el caché, se transfiere a un servidor DNS de nivel superior, generalmente el servidor del proveedor.
Una vez recibida la solicitud, el servidor del proveedor comprobará grabaciones propias, luego su propio caché y, si se encuentra el resultado, lo informará al cliente; de lo contrario, el servidor se verá obligado a recurrir a recursividad- buscar en el sistema DNS global. Para comprender mejor el mecanismo de este proceso, hemos preparado el siguiente diagrama:
Entonces, el cliente envía una solicitud DNS al servidor del proveedor para averiguar la dirección del dominio. mercado.yandex.ru, el servidor del proveedor no tiene dicha información, por lo que contacta con uno de los servidores raíz y le pasa la solicitud. El servidor raíz tampoco tiene los registros necesarios, pero responde que conoce el servidor responsable de la zona. ru - a.dns.ripn.net. Junto con este nombre, el servidor raíz puede informar inmediatamente su dirección IP (y en la mayoría de los casos lo hará), pero es posible que no lo haga si no tiene dicha información, en cuyo caso, antes de comunicarse con este servidor, deberá Haga más una consulta recursiva, solo para determinar su nombre.
Habiendo descubierto la dirección del servidor responsable de la zona ru, el servidor del proveedor le transferirá la solicitud, pero este servidor Tampoco tiene los registros necesarios, pero te dirá en qué zona se encuentra. Yandex el servidor responde ns1.yandex.ru Y Necesariamente dará su dirección. De lo contrario, la recursividad no podrá completarse, ya que la zona Yandex el servidor ubicado en la zona responde Yandex. Para ello, en la zona superior, además del registro NS sobre los servidores de nombres que dan servicio a la zona, se registro A "vinculado", que le permite averiguar la dirección de dicho servidor.
Finalmente, enviando una solicitud al servidor que atiende la zona Yandex, el servidor del proveedor recibirá la dirección del dominio requerido y se lo informará al cliente. También colocará el resultado resultante en caché durante el tiempo especificado por el valor TTL en el registro SOA de este dominio. En la práctica, dado que las consultas recursivas son muy costosas, el tiempo récord de almacenamiento en caché para los proveedores puede ignorar los valores TTL del dominio y alcanzar valores que van desde dos a cuatro horas hasta varios días o incluso una semana.
Ahora veamos un punto más. Las consultas pueden ser recursivas o no recursivas. Una solicitud recursiva permite obtener una respuesta ya preparada, es decir Direcciones IP o mensajes de que el dominio no existe, no está delegado, etc. Una solicitud no recursiva proporciona una respuesta solo sobre la zona de la que es responsable el servidor determinado o devuelve un error.
Dado que las consultas recursivas consumen muchos recursos, la mayoría de los servidores Redes DNS procesar consultas recursivas de forma no recursiva. O pueden hacerlo de forma selectiva, por ejemplo, los servidores DNS del proveedor realizan consultas recursivas solo para sus clientes y el resto de forma no recursiva.
En nuestro caso, el cliente envió una solicitud recursiva al servidor del proveedor, quien, a su vez, envió secuencialmente solicitudes no recursivas hasta encontrar el servidor requerido, que dio la respuesta requerida. Al mismo tiempo, no solo los resultados de la solicitud del usuario, sino también los resultados de las solicitudes intermedias se colocan en la caché del servidor del proveedor, lo que permite ejecutar las siguientes solicitudes de forma no recursiva o con un número mínimo de solicitudes. .
Por ejemplo, si un usuario, después de visitar Yandex Market, decide utilizar servicio postal, entonces el servidor enviará inmediatamente la solicitud a ns1.yandex.ru, ya que ya sabe qué servidor contiene registros para la zona Yandex.
De la teoría a la práctica
Cuando compras un dominio a un registrador, se te pedirá que lo delegues, es decir, especifique los servidores DNS en los que se ubicará la zona de dominio. Estos pueden ser servidores de registro (generalmente gratuitos), servidores de alojamiento, servicios DNS públicos o sus propios servidores de nombres, si están ubicados en la misma zona de dominio, también deberá especificar las direcciones IP; Por ejemplo, así es como se ve la ventana de delegación de dominio en un registrador conocido:
¿Qué debería poner exactamente ahí? Depende de dónde y cómo alojará su sitio. Si usa hosting compartido, entonces todo registros necesarios son creados automáticamente por el proveedor de alojamiento, cuando agrega su sitio al panel de control de alojamiento, todo lo que necesita es delegar el dominio al servidor NS del proveedor de alojamiento, es decir. indíquelos en esta ventana. Este método es muy adecuado para principiantes debido a su simplicidad, pero también existen reverso, la capacidad del usuario para administrar la zona DNS está ausente o es mínima. Además, sobre alojamiento virtual Los administradores pueden cambiar la dirección IP del sitio sin notificar al usuario, por lo que si no desea utilizar el servidor NS del proveedor de alojamiento, definitivamente debe discutir este problema con el soporte técnico.
Si está transfiriendo un sitio a otro proveedor de alojamiento, deberá transferir el sitio y cambiar los servidores de nombres del proveedor de alojamiento anterior a los servidores del nuevo en el registrador. Pero tenga en cuenta que la información en el caché de los servidores DNS no se actualiza instantáneamente, sino al menos después de que el valor del dominio TTL haya expirado, por lo que durante algún tiempo es posible que aún se pueda acceder a su sitio en la dirección anterior. Si necesita trabajar con él con urgencia, puede, sin esperar a que se actualice la caché DNS de su proveedor, agregarlo al archivo anfitriones entrada con el siguiente contenido:
1.2.3.4 ejemplo.com
Dónde 1.2.3.4 Y ejemplo.com en consecuencia, la nueva dirección IP y su nombre de dominio.
Si tienes tu propio VPS o quieres controlar completamente la zona del dominio, entonces debes utilizar los servidores o servicios públicos del registrador. En nuestra opinión, crear su propio servidor de nombres no es una idea que valga la pena a menos que tenga su propio hosting.
En este caso, debe crear al menos dos registros A que apuntarán al servidor web que presta servicio al sitio en este dominio:
@ EN UN 1.2.3.4
www EN UN 1.2.3.4
El carácter de perro en los registros DNS denota el dominio en sí, y también debes crear un registro para el subdominio www para que los usuarios que escriben la dirección del sitio con www también puedan acceder a él.
No consideraremos agregar entradas para el correo electrónico; puede leer sobre esto en nuestro artículo:
Al migrar un sitio, solo necesitará cambiar las direcciones IP en A-records y esperar la actualización información DNS. Por lo general, este es el momento más desagradable: todo parece estar hecho, pero no se puede cambiar nada, sólo se puede esperar. Pero si sigues algunas recomendaciones, entonces este proceso puede llevarse a cabo de la forma más indolora y desapercibida posible para los visitantes.
En primer lugar, cambie el valor TTL en el registro SOA. De forma predeterminada, equivale a varias horas y ese es el tiempo que tendrá que esperar para que se actualice su entrada en la caché del servidor DNS. Para conocer el valor TTL actual, puede ejecutar el comando especificando el nombre de dominio deseado:
Nslookup -typr=sitio soa
En nuestro caso son 4 horas: 
Por lo tanto, al menos 4 horas (valor TTL anterior) antes de la transferencia planificada, cambie el valor TTL a un valor más bajo, por ejemplo, 900 (15 minutos). Luego configure su sitio en modo de solo lectura y migrelo a nuevo servidor. El sitio no debe cerrarse ni transferirse para mantenimiento; puede y debe permanecer accesible. Pero debes evitar que los usuarios cambien y agreguen información, es decir. prohibir registrarse, comentar, realizar pedidos, etc. Además, asegúrese de publicar un aviso en un lugar visible sobre trabajo técnico y fecha aproximada de finalización.
Para trabajar con el nuevo servidor sin cambiar los registros DNS, agregue la línea deseada V archivo de hosts. Habiendo colocado el sitio en un sitio nuevo y asegurándose de que sea funcionamiento normal cambie los registros DNS, ahora dentro de 15 minutos los primeros usuarios comenzarán a visitar su sitio en el nuevo servidor. La funcionalidad del servidor antiguo debe mantenerse durante algún tiempo más, idealmente hasta una semana, ya que no todos los proveedores utilizan el valor TTL del registro SOA para actualizar el caché; se puede utilizar su propia configuración para reducir la carga en el; equipo.
Después de una transferencia exitosa, el valor TTL debe aumentarse a valores anteriores, para no crear una carga innecesaria en los servidores de nombres.
Hemos considerado lo más diagrama simple, pero en la práctica, además del sitio, suele haber también red de oficinas, muchos de cuyos recursos también deben estar disponibles externamente. Considere el siguiente diagrama:
Tenemos servidores publicos para el sitio web y la red de correo electrónico y oficina, para los cuales hemos asignado un subdominio oficina. Si no hay problemas especiales con el servidor de correo y web, entonces existen opciones con el área de oficina. Generalmente zona local es atendido por su propio DNS y no está conectado de ninguna manera a la zona madre. Para todo el mundo sistemas DNS zona oficina.ejemplo.com no existe, pero sí el host del mismo nombre. Esto se justifica si la red empresarial está detrás de NAT y sus nodos solo tienen direcciones grises, y el acceso desde el exterior se realiza solo a la puerta de enlace a la que se reenvían los puertos correspondientes de los nodos internos.
En este caso, los registros DNS de la zona ejemplo.com puede verse así:
@ EN UN 1.2.3.4
www EN UN 1.2.3.4
correo EN A 1.2.3.5
oficina EN A 5.6.7.8
Pero surge cierta complejidad; dentro de la red, los clientes recurren a ella. servicios de red por nombres internos: corp.office.ejemplo.com o rdp.office.ejemplo.com, que apuntan a direcciones internas "grises". Sin embargo, fuera red local No es posible resolver la dirección IP de dichos nombres porque no existe una zona DNS global que los contenga. De esta situación permite salir de esta situación un mecanismo llamado Split-DNS, que permite dar diferentes resultados dependiendo de la posición del cliente.
En la red local, las solicitudes DNS de los clientes son atendidas por servidor local, que tiene registros correspondientes, las solicitudes fuera de él se enviarán al servidor que atiende la zona ejemplo.com. Al mismo tiempo, todo recursos corporativos, que están representados por varios servidores en la red local, son accesibles desde el exterior en una única dirección: oficina.ejemplo.com. Por tanto, es hora de recordar el apodo o registro CNAME. Esta entrada permite asociar nombres mnemotécnicos o alias adicionales con el nombre de host real. Tenga en cuenta que el uso de alias en otras entradas es inaceptable. En nuestro caso, deberíamos agregar las siguientes entradas:
Corp.oficina EN CNAME oficina.ejemplo.com.
rdp.office EN CNAME office.example.com.
Ahora un cliente, independientemente de su ubicación, puede utilizar el mismo nombre para acceder a los recursos, pero los resultados serán diferentes. En la red local recibirá dirección real servidor y se conectará directamente, y fuera será dirigido a la puerta de enlace de la red.
Además, los registros de tipo CNAME se pueden utilizar para redirigir fuera de la zona de dominio aceptada. La condición principal es Registro CNAME debe apuntar a un nombre real en formato FQDN.
Otro uso de los alias es acortar una dirección. Digamos, como servidor de correo para todo el dominio. ejemplo.com queremos utilizar un servidor que esté ubicado en la oficina de Moscú y tenga la dirección correo.office.msk.ejemplo.com, debes admitir, no parece muy atractivo. Sería mucho más conveniente tener una dirección como correo.ejemplo.com, no hay nada más sencillo, añade la siguiente entrada:
Correo EN CNAME mail.office.msk.example.com.
Pero recuerda que en el resto registros de recursos solo debe usarse nombres reales, por lo que esta entrada será incorrecta:
Ejemplo.com. EN MX 10 correo
La forma correcta sería:
Ejemplo.com. EN MX 10 correo.office.msk
Finalmente, hablemos de la delegación de zonas de dominio. En el ejemplo anterior, observamos una situación en la que dentro de un dominio a diferentes divisiones se les asignan sus propios subdominios, dado que cada división tiene su propia infraestructura, tiene sentido delegarles la gestión de sus propias zonas de dominio. Para ello en la zona ejemplo.com Se debe colocar un registro NS y A asociado para cada zona. Por ejemplo:
Msk IN NS ns1.msk.example.com.
msk EN NS ns2.msk.example.com.
ns1.msk EN UN 1.2.3.4
ns2.msk EN UN 5.6.7.8
Ahora, al acceder a una dirección, digamos correo.office.msk.ejemplo.com servidores de nombres de zona ejemplo.com mostrará el nombre y la dirección del servidor que sirve a la zona msk.ejemplo.com. Esto permite a los administradores de zona ingresar de forma independiente cambios necesarios, sin afectar el funcionamiento de la zona superior y sin contactar a sus administradores sobre cualquier tema que requiera cambios en los registros.
Etiquetas:
El sistema de nombres de dominio es la base de la Internet moderna. La gente no quiere molestarse en recordar el conjunto de números 63.245.217.105, sino que quiere que la computadora los conecte al nodo especificado usando el nombre mozilla.org. Esto es lo que hacen los servidores DNS: traducen las solicitudes de las personas a un formato digital que puedan entender. Sin embargo, en algunos casos, es posible que se requiera una dirección IP inversa → conversión de nombre DNS. Estos nombres se analizarán a continuación.
¿Para qué es?
Tener una dirección rDNS correctamente configurada es absolutamente necesario para enviar mensajes desde su propio servidor de correo electrónico corporativo. Casi todos los servidores de correo rechazarán el mensaje al inicio de la sesión si la dirección IP de su servidor no tiene una entrada en la zona DNS inversa. El motivo del fallo del servidor de correo remoto probablemente se indicará de la siguiente manera:
550-"La dirección IP no tiene un registro PTR (dirección a nombre) en el DNS, o cuando el registro PTR no tiene un registro A (nombre a dirección) coincidente. Verifique y corrija su registro DNS".
o
550-No hay un PTR correspondiente para su dirección IP (dirección IP), que es 550 requerido. Lo siento, adiós.
o simplemente
550 Tu IP no tiene Registro PTR
El número 550 en los tres casos es el código estándar del servidor de correo SMTP, que informa un error crítico que impide de manera irreparable seguir trabajando dentro de esta sesión de correo. Hay que decir que en general todos los errores de la serie 500 son críticos y es imposible seguir enviando correo después de que aparecen. El texto explica el motivo del rechazo con más detalle y afirma que el administrador del servidor de correo del destinatario lo ha configurado para comprobar si el servidor de correo emisor tiene una entrada en la zona DNS inversa (rDNS) y, si está ausente, el destinatario El servidor está obligado a rechazar la conexión al remitente (errores de la serie SMTP-5XX).
¿Cómo configurar y utilizar?
Sólo el propietario del correspondiente bloque de direcciones IP al que corresponde esta zona tiene derechos para configurar una zona DNS inversa. Este propietario suele ser el proveedor, que posee su propio sistema autónomo. Puede leer más sobre cómo registrar su sistema autónomo (AS) y el bloque de direcciones IP en este artículo. En resumen, para registrar una zona DNS inversa, el operador de un bloque de direcciones IP debe registrar un objeto del tipo "dominio" en su cuenta personal en el sitio web de RIPE, indicar la dirección de los servidores DNS que admitirán la zona rDNS y configure el soporte para una zona del tipo 3.2.1.in -addr.arpa en ellos. Un puntero, un registro PTR, es responsable de los recursos en la zona inversa. Aquí es donde van las solicitudes para resolver la dirección IP en un nombre de host.
Si no es el feliz propietario de un sistema autónomo, la configuración de rDNS para una dirección IP o direcciones de servidor de correo comienza y termina con una solicitud al servicio de soporte del proveedor o proveedor de alojamiento. En ambos casos, el nombre de la dirección IP del servidor de correo, y especialmente del servidor de correo corporativo, debe indicarse de forma significativa.
Ejemplos de buenos nombres para un servidor de correo:
correo.dominio.ru
mta.dominio.ru
dominio.mx.ru
Ejemplos de malos nombres:
host-192-168-0-1.dominio.ru
cliente192-168-0-1.dominio.ru
vpn-dailup-xdsl-clients.dominio.ru
y similares. Es muy probable que estos nombres se filtren como asignados a equipos cliente en los que no se puede instalar un servidor de correo y, por tanto, desde ellos se envía spam.
Puede y debe utilizar consultas con éxito para revertir zonas DNS inmediatamente después de iniciar el servidor de correo. Para hacer esto, sólo necesita realizar algunos ajustes menores en el software. En diferentes servidores de correo, la configuración de la verificación rDNS se realiza de manera diferente:
rechazar_cliente_desconocido
verificar = búsqueda_host_inversa
En el complemento Servidor Exgange, vaya a la sección Servidores, luego seleccione el servidor en la lista expandida, seleccione Protocolos, luego el protocolo SMTP, seleccione el servidor SMTP en la ventana derecha y haga clic derecho y seleccione en la lista Propiedades. Siguiente, pestaña Entrega → Realizar búsqueda DNS inversa en mensajes entrantes
Ahora todos los mensajes provenientes de direcciones IP que no tengan un registro DNS inverso (registros tipo PTR) serán rechazados y el flujo de spam se reducirá significativamente. Quizás este sea el método de filtrado de spam más simple, efectivo y que consume menos recursos: la verificación inversa de DNS elimina la gran mayoría del spam enviado desde computadoras infectadas de usuarios comunes que conforman las botnets de los spammers.
Al volver a publicar un artículo, es necesario instalar un hipervínculo indexado activo al sitio fuente.
