none
Error resolviendo DNS de dos maquinas es redes distintas. RRS feed

  • Pregunta

  • Buenos días tengo un problema igual es algún error de concepto.

    Tendo dos centros con dos rangos de ips disintos y nombres de DOMINIOS DISTINTOS,  en cada sede hay sus respectivos servidores DNS que funcionan perfectamente,

    a nivel fisico las ips de los servidores DNS entre sede se ven perfectamente con un ping, al igual que todas la maquinas.

    lo primero que he hecho es:

      en los servididores DNS de cada sede he puesto como reenviador la ip  del servidor dns de la sede a la que quiero que resuelvan.  ( aunque parece que no identifica esa ip como un servidor dns)

    luego tiro a resolver con calificadores completos nombres de maquinas de la sede remota y no funciona.

    luego he hecho las siguientes pruebas

    1) en un pc local de una sede he puesto como dns primaria la suya ( la del sevidor dns local=

    como dns secundaria la del servidor DNS de la sede remota.  ( no funciona)

    2) si quito como dns primaria la local y pongo dns de la sede remota y como secundaria la local ( con calificades completos resuelve nombres de la sede remota pero no locales)

    En fin estoy un poco mareado, no se si al tratarse de servidores DNS de distintos dominios tengo que crear alguna relación de confianza entre ellos para que se puedan comunicar.

    Agradezco desde ya vuestra ayuda.!!

    miércoles, 20 de septiembre de 2017 9:58

Respuestas

  • No, no afecta al tema si creas zonas secundarias o "stub", porque depende del cliente, no de los servidores

    El DNS resuelve FQDNs. El cliente utiliza, por omisión, su propio sufijo de Dominio en la pregunta; lo puedes ver con un IPCONFIG /ALL

    Se podría quizás resolver lo que propones, pero bajaría el rendimiento. En las propiedades avanzadas de TCP/IPv4, ficha DNS, se pueden poner los sufijos de búsqueda que usará el cliente, se pueden agregar varios, y además el propio, pero eso hace que el cliente debe hacer varias veces la misma pregunta al DNS hasta que encuentre el correcto. Además no debería haber concidencia de "hostnames" porue en ese caso el cliente no tiene forma de resolver cuál es que el usuario quiere realmente

    Que no sean vagos y escriban los FQDNs :D

     


    Guillermo Delprato
    Buenos Aires, Argentina
    El Blog de los paso a paso

    MVP - MCSE - MCSA2012
    MCITP: Enterprise Administrator / Server Administrator
    MCTS: Active Directory/Network Configuration/Applications Configuration/Server Virtualization/Windows 7 Configuration/Windows 7 & Office 2010 Deployment/Vista Configuration

    Este mensaje se proporciona "como está" sin garantías de ninguna clase. Usted asume todos los riesgos.

    miércoles, 20 de septiembre de 2017 21:48
    Moderador

Todas las respuestas

  • Lo primero a controlar: que exista conectividad IP entre ambos servidores DNS, y que no exista algun cortafuegos de por medio que impida protocolos y puertos necesarios

    Con respecto a lo que comentas falta una aclaración, lo que has configurado en los DNSs es ¿Reenviadores? o ¿Reenviadores Condicionales? Si fueran estos últimos hay que configurar el nombre completo del otro Dominio, y la dirección IP del DNS del otro Dominio

    Todas las máquinas de un Dominio Active Directory deben apuntar como único DNS a los del propio Dominio, nunca a otro sea externo, interno o el Router

    El tema de cambiar el orden entre preferido y alternativo, no tiene mucho sentido, usará siempre el preferido, y sólo dirigirá peticiones a uno alternativo, si el preferido no responde. No poder resolver es una respuesta válida

    Revisa este enlace que tiene el paso a paso de la configuración y referencias a otras notas sobre el tema

    DNS: Resolución de Nombres Mediante Reenviadores Condicionales | WindowServer
    https://windowserver.wordpress.com/2014/02/11/dns-resolucin-de-nombres-mediante-reenviadores-condicionales/ 

     


    Guillermo Delprato
    Buenos Aires, Argentina
    El Blog de los paso a paso

    MVP - MCSE - MCSA2012
    MCITP: Enterprise Administrator / Server Administrator
    MCTS: Active Directory/Network Configuration/Applications Configuration/Server Virtualization/Windows 7 Configuration/Windows 7 & Office 2010 Deployment/Vista Configuration

    Este mensaje se proporciona "como está" sin garantías de ninguna clase. Usted asume todos los riesgos.

    miércoles, 20 de septiembre de 2017 11:01
    Moderador
  • Gracias por responder Guillermo. aclaro más el escenario:

    - Hay conectividad ip entre los servidores DNS de ambas sedes

    - los reenviadores NO son condicionales.

    - La configuración de las maquinas locales es tal y como tú comentas, pero con todo así

    no resuelven bien .

    una cosa que me llama la antención es que al poner la ip en la pestaña reenviadores del dns local,  en el FQDN pone <no se puede resolver>.

    Tambien he probado a añadirlo como sugerencias de raiz pero pasa lo mismo.

    miércoles, 20 de septiembre de 2017 13:40
  • Los Reenviadores no condicionales se utilizan para la resolución de nombres de Internet, es algo así como "todo lo que no sepas, pregúntale a ..." y por lo tanto la configuración que has hecho seguramente te afectará la resolución de nombres de Internet. Por lo tanto entre dos Dominios internos AD de Bosques diferentes hay que usar "Reenviadores condicionales", o Zonas Secundarias o "Stub Zones", la primera es la más sencilla de configurar

    ¿Qué estás usando para probar la resolución de nombres? recuerda que lo más confiable y que permite resolver problemas es NSLOOKUP porque no usa la "cache de hostnames" local

    Y además, cuando quieres ver la resolución de nombres entre Dominios diferentes, no alcanza con poner el nombre de máquina, hay que usar el FQDN (nombreMaquia.Dominio.sufijo) Y vale también para los Reenviadores Condicionales; lo importante es que esté bien la dirección IP

     


    Guillermo Delprato
    Buenos Aires, Argentina
    El Blog de los paso a paso

    MVP - MCSE - MCSA2012
    MCITP: Enterprise Administrator / Server Administrator
    MCTS: Active Directory/Network Configuration/Applications Configuration/Server Virtualization/Windows 7 Configuration/Windows 7 & Office 2010 Deployment/Vista Configuration

    Este mensaje se proporciona "como está" sin garantías de ninguna clase. Usted asume todos los riesgos.

    miércoles, 20 de septiembre de 2017 15:51
    Moderador
  • Gracias por tu valiosa información he ledido el articulo y me ha despejado todas las dudas, efectivamente no estaba usando los reenviadores condicionales, que como muy bien has dicho es la forma mas sencilla, al usarlos ha empezado a funcionar.

    una pregunta mas:

    si configuro los dos servidores con zonas Secundarias (en vez de con reenviadores cond)

    ¿me podria responder sin usar un FQDN?

    De todas formas me funciona perfectamente .

    Gracias nuevamente.!

    miércoles, 20 de septiembre de 2017 16:30
  • No, no afecta al tema si creas zonas secundarias o "stub", porque depende del cliente, no de los servidores

    El DNS resuelve FQDNs. El cliente utiliza, por omisión, su propio sufijo de Dominio en la pregunta; lo puedes ver con un IPCONFIG /ALL

    Se podría quizás resolver lo que propones, pero bajaría el rendimiento. En las propiedades avanzadas de TCP/IPv4, ficha DNS, se pueden poner los sufijos de búsqueda que usará el cliente, se pueden agregar varios, y además el propio, pero eso hace que el cliente debe hacer varias veces la misma pregunta al DNS hasta que encuentre el correcto. Además no debería haber concidencia de "hostnames" porue en ese caso el cliente no tiene forma de resolver cuál es que el usuario quiere realmente

    Que no sean vagos y escriban los FQDNs :D

     


    Guillermo Delprato
    Buenos Aires, Argentina
    El Blog de los paso a paso

    MVP - MCSE - MCSA2012
    MCITP: Enterprise Administrator / Server Administrator
    MCTS: Active Directory/Network Configuration/Applications Configuration/Server Virtualization/Windows 7 Configuration/Windows 7 & Office 2010 Deployment/Vista Configuration

    Este mensaje se proporciona "como está" sin garantías de ninguna clase. Usted asume todos los riesgos.

    miércoles, 20 de septiembre de 2017 21:48
    Moderador