Prefacio: no soy administrador de Windows. Soy administrador de Linux.
Tengo un servidor Windows 2016 con AD DNS que maneja búsquedas directas e inversas de DNS internas.
En algún lugar, de alguna manera, algún proceso está agregando automáticamente registros de búsqueda inversa PTR para CNAME. Esto está rompiendo nuestra autenticación Kerberos para SSH entre servidores, ya que la búsqueda canónica de un host que tiene CNAME devolverá demasiados FQDN y Kerberos se resiste.
El problema de Kerberos SSH se resolvió cuando eliminé las búsquedas inversas de CNAME.
Luego, al día siguiente, ¡listo! todas las entradas PTR -> CNAME estaban nuevamente en AD DNS
Ejemplo, desde arriba (he cambiado los nombres para que sean genéricos, pero la configuración general es la misma):
Un par de cuadros de operaciones de red que ejecutan SMTP y proxy Squid tienen registros A
netops01.example.com -> 10.1.2.3
netops02.example.com -> 10.4.5.6
Y este mismo cuadro tiene CNAME.
netops
proxy
mailserver
Por alguna razón, hay entradas de búsqueda inversa en AD DNS como estas:
3.2.1.10.in-addr.arpa. 3600 IN PTR netops.example.com
3.2.1.10.in-addr.arpa. 3600 IN PTR proxy.example.com
3.2.1.10.in-addr.arpa. 3600 IN PTR mailserver.example.com
3.2.1.10.in-addr.arpa. 3600 IN PTR netops01.example.com
La última entrada es el registro A de este host. Todos los demás son CNAME para ese registro A + otro registro A para el segundo host.
Ni yo ni el otro administrador que maneja las operaciones los creamos. Tampoco configuramos ninguna tarea programada para recrear búsquedas inversas. Tampoco puedo imaginar una buena razón para tener un punto de búsqueda inversa de CNAME o de múltiples resultados. (¿Quizás haya una buena razón? Aunque nunca había hecho esto antes)
Entonces, eliminé todas las búsquedas inversas excepto la del registro A. ¡Kerberos SSH funciona!
Al día siguiente, todos los registros regresaron.
Ni siquiera estoy seguro de cómo solucionar problemas en Windows (de ahí mi prefacio en la parte superior)
- ¿Cómo puedo encontrar en los registros de Windows qué realizó esta acción?
- ¿Hay algo en el DNS de Windows que haga esto automáticamente? (Crear PTR para CNAME)
- ¿Hay alguna manera de desactivar eso?
- ¿Algo más que me falta?
Respuesta1
Respondiéndome a mí mismo
Encontré lo que me faltaba. Dos cosas:
De hecho, estos no eran CNAME. Eran registros A con múltiples hosts enumerados con el fin de equilibrar la carga.
Como eran registros A, tenían una casilla de verificación como "crear automáticamente un registro PTR relacionado".
Desmarqué eso para estos registros. En realidad, eso no pareció solucionar el problema descrito aquí: los registros PTR todavía se están reconstruyendo cada mañana.
Sin embargo, de todos modos esa no es la solución que estaba buscando. El problema subyacente era que Kerberos no funcionaba. Bueno, eso fue fácil de resolver agregando esta configuración "rdns" a /etc/krb5.conf
[libdefaults]
rdns = falso
Respuesta2
De forma predeterminada, Windows siempre intenta registrar búsquedas directas e inversas mediante DNS dinámico.
Puede desactivar esta funcionalidad en los clientes que se están registrando, en el servidor DNS o en ambos. La forma más rápida de resolver su problema inmediato sería deshabilitar la compatibilidad con DNS dinámico para las zonas de búsqueda inversa relevantes. A largo plazo, dependiendo de sus circunstancias, es posible que desee desactivarlo también en las zonas delanteras.
Encontré una captura de pantalla que muestra la configuración relevante en el servidor DNS.aquí. Quiere seleccionar "Ninguno".
Hay más información sobre cómo deshabilitar la actualización dinámica en los clientes.aquíyaquí. Esto no es esencial, pero de lo contrario los clientes generarán mensajes de registro de eventos periódicos porque el servidor rechaza las solicitudes de DNS dinámicas.
NÓTESE BIEN:No debe deshabilitar las actualizaciones dinámicas en los controladores de dominio de Active Directory ni en las zonas de Active Directory, como _msdcslas que utilizan los controladores de dominio para almacenar información sobre la infraestructura del dominio. Esto romperá Active Directory.