none
Rotación de DNS RRS feed

  • Pregunta

  • Me presento ya que es la primera vez que posteo en el Foro.

    Buenos días,

    Estuve leyendo y buscando por varios lados lo cual me llevó a comentar mi problema acá.

    El problema trata de el Round Robin y Subnet Prioritization.

    Bien, paso a explicar:

    Los servidores se encuentran en una red 10.x.1.1, el problema está que desde la pc cliente (xp,vista,7,2003) que se encuentran en la red 130.X.x.x.

    Cuando uno consulta con el nslookp al nombre del root domain me responde de la siguiente manera:

    1ra Consulta

    Addresses:  10.221.1.1, 10.130.1.1, 10.60.1.1, 10.10.1.1
              10.70.1.1, 10.130.1.2, 10.221.1.2, 10.60.1.2, 10.70.1.2
              10.10.1.2

    2da Consulta

    Addresses:  10.130.1.1, 10.60.1.1, 10.10.1.1, 10.70.1.1
              10.130.1.2, 10.221.1.2, 10.60.1.2, 10.70.1.2, 10.10.1.2
              10.221.1.1
    Y así sucesivamente. Allí está detallado el problema. Esas ips son los controladores de dominio+dns integrados al AD. Por lo cual tenémos 2 DC's por locación.

    Las locaciones son por todas partes de argentina, por lo cual si un cliente quiere consultar por ejemplo los links en dfs o lo que sea, pasa siempre por el que aparece primero en la lista y no nunca por su locacion.

    Por ejemplo mi ip es 130.1.x.x, se supone que me tendría que traer siempre al 10.10.1.1 y al 10.10.1.2 (son los dc's+dns servers de mi locación). Pero nó, no hace esto. Al parecer el problema viene por la mascara de subred, ya que si yo realizo un nslookup desde algún servidor o alguna ip 10.x.x.x me responde de manera correcta.

    1ra Consulta:

    Addresses:  10.10.1.1
              10.10.1.2
              10.130.1.1
              10.60.1.1
              10.221.1.1
              10.70.1.1
              10.130.1.2
              10.221.1.2
              10.60.1.2
              10.70.1.2

    2da Consulta:

    Addresses:  10.10.1.2
              10.10.1.1
              10.221.1.1
              10.130.1.1
              10.60.1.1
              10.70.1.2
              10.70.1.1
              10.130.1.2
              10.221.1.2
              10.60.1.2

    Bueno, espero que esté bien detallado el problema.

    Agradesco y felicito tanto al sitio como a la gente que compone esta comunidad.

     

    Saludos atte. Santiago.

    miércoles, 8 de junio de 2011 15:42

Todas las respuestas

  • Hola Santiago,

     

    Nos puedes comentar si tienes differentes sites a nivel de directorio activo en los lugares donde hay domain controllers? En organizaciones con sedes geográficas y domain controllers por sedes, es importante la utilización de los sites y sus respectivas subredes.

    Puedes ver información de SItes en este link

     

    Eso sería con respecto a logón de usuarios y DFS, con respecto a Round Robin se puede especificar el peso de los registros SRV y la prioridad, a menor peso más prioridad.

    Aquí tienes muchisima información acerca de DNS http://technet.microsoft.com/es-es/library/cc759550(WS.10).aspx 

    Y como cambiar la prioridad http://support.microsoft.com/kb/232025 

     

    SRV Record Field Description

    Priority

    The priority of the server. Clients attempt to contact the server with the lowest priority.

    Weight

    A load-balancing mechanism that is used when selecting a target host from those that have the same priority. Clients randomly choose SRV records that specify target hosts to be contacted, with probability proportional to the weight.

    Port number

    The port where the server is listening for this service.

    Target

    The fully qualified domain name of the host computer.


    Salu2!, Dani Gracia MCSA/MCSE 2003 Security MCITP: Enterprise Administrator (Windows Server 2008) MCTS: System Center Operations Manager 2005 MVA: Microsoft Virtual Academy MAP: Microsoft Active Professional (2010/2011)
    miércoles, 8 de junio de 2011 16:34
  • Hola Santiago,

     

    Nos puedes comentar si tienes differentes sites a nivel de directorio activo en los lugares donde hay domain controllers? En organizaciones con sedes geográficas y domain controllers por sedes, es importante la utilización de los sites y sus respectivas subredes.

    Puedes ver información de SItes en este link

     

    Eso sería con respecto a logón de usuarios y DFS, con respecto a Round Robin se puede especificar el peso de los registros SRV y la prioridad, a menor peso más prioridad.

    Aquí tienes muchisima información acerca de DNS http://technet.microsoft.com/es-es/library/cc759550(WS.10).aspx 

    Y como cambiar la prioridad http://support.microsoft.com/kb/232025 

     

    SRV Record Field Description

    Priority

    The priority of the server. Clients attempt to contact the server with the lowest priority.

    Weight

    A load-balancing mechanism that is used when selecting a target host from those that have the same priority. Clients randomly choose SRV records that specify target hosts to be contacted, with probability proportional to the weight.

    Port number

    The port where the server is listening for this service.

    Target

    The fully qualified domain name of the host computer.


    Salu2!, Dani Gracia MCSA/MCSE 2003 Security MCITP: Enterprise Administrator (Windows Server 2008) MCTS: System Center Operations Manager 2005 MVA: Microsoft Virtual Academy MAP: Microsoft Active Professional (2010/2011)


    Gracias ante todo Dani,

    Sites no tenemos; el tema es que debería trabajar con la máscara de subred verdad? el problema está en las direcciones ip de los servidores dns y la de los clientes. El cliente no está adquiriendo el rango asignado por su servidor (de la localidad).

    Ej: Capital federal (10.10.1.1 y 10.10.1.2)

    Lugano (10.60.1.1 y 10.60.1.2)

    Entonces con el rango de ip 130."1".x.x aca en Capital federal tendria que traerme como primera consulta los dns 10.10.1.1 y 1.2. Demás esta decir que estos dc's+dns integrado al ad son los dcs principales.

    Yo si tuviera sites creados podria asignar los dns autoritativos para cada zona y por lo tanto el usuario cuando se logea, o enciende el equipo o consulta a la red, no tendria que pasar por el primer dns que se le prenseta en la lista.

    Imaginate que tenemos gente en la patagonia que relativamente ocupa espacio en el enlace y tranquilamente podría hacerlo desde su dns local y no por el primero que traiga de la lista.

    ese es el problema con todas las locaciones, capaz que el error fué no haber creado sites para cada locación y asignarles una subnet a cada site.

    En la consola de DNS solo tenemos el nombre del root domain y allí se encuentran todos los registros (A, NS, CNAME, etc).

    Yo me he dado cuenta que los registros que varian son los que tienen entre parentesís (Same as parent folder), o algo por el estilo.

    Gracias, Dani.

    Un gusto, Saludos Cordiales.


    EDIT: En cada localidad tienen 2 Dc's que son a su vez dns integrados al AD. Por eso te comentaba que lo mejor sería con sites para que ahí sí puedan consultar a sus dns y si no puede resolver recién ahí elevar la consulta.

    miércoles, 8 de junio de 2011 17:48
  • Efectivamente deberiais trabajar con másca de red.

    Todos los clientes estén en la ubicación que estén comparten el rango 130.1.x.x  ?


    Salu2!, Dani Gracia MCSA/MCSE 2003 Security MCITP: Enterprise Administrator (Windows Server 2008) MCTS: System Center Operations Manager 2005 MVA: Microsoft Virtual Academy MAP: Microsoft Active Professional (2010/2011)
    miércoles, 8 de junio de 2011 18:03
  • Solo los de Capital federal.

    Por ejemplo en Lugano tienen el rango 130.6.x.x que corresponde a los DNS 10.60.1.1 10.60.1.2

    en la Patagonia tienen varias locaciones que tienen el siguiente rango:

    130.3.x.x que corresponden a los dns servers 10.221.1.1 y 10.221.1.2

    otra locación en la patagonia:

    130.2.x.x y tienen los servidores dns 10.130.1.1 y 10.130.1.2 .

    Por lo cual comparten todos la misma mascara de subred, entonces definitivamente "creo yo" que no va a elegir cual sería mejor para consultar, ya que ni tienen un site asignado y menos una subnet mask.

    Saludos Cordiales y gracias por tu tiempo. "I need help" jajaja 

    EDIT: Dani, los sites están creados y las subnets están asosiados a ellos. Pero sigue consultando cualquier servidor dns de cualquier locación y no está respetando la que debería.
    miércoles, 8 de junio de 2011 18:11
  • ventu10, debes trabajar con Sites, Subnets y Links, de otra forma no va a funcionar. Aunque estoy leyendo todo el hilo y hay cosas que no me quedan claras.

    A ver si puedes explicar algo, por un lado dices que:

    • Los servidores están en la red 10 ...
    • Los clientes están en la red 130 ...
    • Y que los clientes no contactan al DNS local
    • Y que hay dos servidores por Site

    ¿Está la red 10... repetida en todos los Sites? eso no va a funcionar... :-)

    Quizás puedas aclarar el tema

     

     


    Guillermo Delprato - Buenos Aires, Argentina
    Visite Notas Windows Server
    MVP-MCT-MCSE-MCSA MCITP: Enterprise/Server Administrator MCTS: Active Directory/Network/Applications Configuration
    Este mensaje se proporciona "como está" sin garantías de ninguna clase. Usted asume todos los riesgos.
    jueves, 9 de junio de 2011 12:21
    Moderador
  • Guillermo, gracias por tu respuesta.

    Te aclaro el tema:

    Los servidores se encuentran en la red 10.x.1.1 y 10.x.1.2.

    Los servidores de cada locación (2 por locación) estan dentro de la red 10.

    Por ejemplo:

    Capital federal (10."10".1.1 y 10."10".1.2)

    Lugano (10."60".1.1 y 10."60".1.2)

    Necochea (10."70".1.1 y 10."70".1.2)

    Bariloche (10."130".1.1 y 10."130".1.2)

    Ushuaia (10."221".1.1 y 10."221".1.2)

    Bien estos son los Servidores DCs y a la vez son servidores DNS integrado al Active Directory.

    Ahora LAS IP PRIVADAS A NIVEL CLIENTE Sería de esta manera:

    Capital federal (130."1".x.x)

    Lugano (130."6".x.x) 

    Necochea (130."7".x.x)

    Bariloche (130."3".x.x)

    Ushuaia (130."2".x.x)

    Bien, entonces en cada dc promovido de cada locación están en un SOLO DOMINIO (xxxxx); a su vez los dcs principales son los de Capital Federal (estos replican la información de dns y a su vez ad y demas cosas). Estamos bien hasta ahí?

    Desde cuaquier locación PC CLIENTE al verificar nos dimos cuenta que tardaban algunas consultas y demas cosas, por lo cual realizamos consulta nslookup en las pcs clientes. Y nos dieron la siguiente respuesta:

    Consulta Nº 1 (capital federal) (PC #1 - CLIENTE)

    Addresses:  10.10.1.1, 10.60.1.1, 10.130.1.1, 10.221.1.1
              10.10.1.2, 10.70.1.2, 10.60.1.2, 10.221.1.2, 10.130.1.2
              10.70.1.1

    Consulta Nº 2 (capital federal) (PC #1 - CLIENTE)

    Addresses:  10.221.1.1, 10.10.1.2, 10.70.1.2, 10.60.1.2
              10.221.1.2, 10.130.1.2, 10.70.1.1, 10.10.1.1, 10.60.1
              10.130.1.1

    Consulta Nº 3 (Capital Federal) (PC #1 - CLIENTE)

    Addresses:  10.10.1.2, 10.70.1.2, 10.60.1.2, 10.221.1.2
              10.130.1.2, 10.70.1.1, 10.10.1.1, 10.60.1.1, 10.130.1
              10.221.1.1

    Esto pasa en todas las locaciones, pero al realizar un nslookup desde la red 10."x".x.x (servidores) no varian, solo rotan por locación y nó toda la lista. Como tendría que ser.

    Imaginate que cualquier usuario por ejemplo de Ushuaia realiza una consulta y depende del servidor dns que lo atiente (ejemplo si lo atiende el de la locacion capital federal) el tipo esta viajando por el enlace hasta buenos aires y vuelve para allá. Sabiendo que solo tendría que consultar SU DNS (Ushuaia), y con las demas locaciones lo mismo. Cada una tendria que consultar con sus dns de la locación.

    Los sites y las subnets estan generadas; cada subnet pertenece a su site. Pero solo hay una zona de DNS, esta zona de dns pertenece al nombre del root domain. Tenémos concentrado todo en un solo dominio las distintas locaciones y desde acá (capital federal) se administra todo.

    Entonces:

    Como haría para que nosotros de CAPITAL FEDERAL con una red cliente 130."1".x.x consultemos solo los DNS SERVERS (10."10".1.1 Y 10."10".1.2, que son los domain controles y a su vez los servidores dns de capital federal)

    Y así lo mismo con las diferentes locaciones.

    Lugano (130."6".x.x) (10."60".1.1 y 10."60".1.2)

    Necochea (130."7".x.x) (10."70".1.1 y 10."70".1.2)

    Bariloche (130."3".x.x) (10."130".1.1 y 10."130".1.2)

    Ushuaia (130."2".x.x) (10."221".1.1 y 10."221".1.2)

    Espero que ahora se haya entendido.

    Saludos y muchas gracias a todos, de verdad agradezco su atención.



    El Round Robin está activado y la ordenación por mascara de red también.
    • Editado Santi Ventura jueves, 9 de junio de 2011 13:40 Corrección de Caractéres
    jueves, 9 de junio de 2011 13:33
  • Está claro el tema, se le hace imposible distinguir para que red que servidor consultar. En los sites estan las subnets y de todas maneras no prioriza cual para cual.

    No se que pasará si lo desactivo, pero así como está ahora genera trafico y responde como quiere.

    Lo que sí note en un Lab que modificando la prioridad de los registros A y sacando el weigth, podría ordenarlos.

    Gracias nuevamente por su atención.

    jueves, 9 de junio de 2011 15:18
  • Modificando el weight efectivamente puedes ordenarlos pero el orden es el mismo para todas las oficinas ya que tu zona DNS es la misma, pero esa solución es un parche al problema que tienes con las redes.

    Si puedes plantearte como un proyecto la restructuración de las redes y sites te hará la administración del entorno más eficiente.

     

     

     


    Salu2!, Dani Gracia MCSA/MCSE 2003 Security MCITP: Enterprise Administrator (Windows Server 2008) MCTS: System Center Operations Manager 2005 MVA: Microsoft Virtual Academy MAP: Microsoft Active Professional (2010/2011)
    jueves, 9 de junio de 2011 17:12
  • [Guillermo] Voy respondiendo sobre tu escrito para no perdernos

     

    Guillermo, gracias por tu respuesta.

    Te aclaro el tema:

    Los servidores se encuentran en la red 10.x.1.1 y 10.x.1.2.

    Los servidores de cada locación (2 por locación) estan dentro de la red 10.

    [Guillermo] ¿Y la máscara de subred? Supongo que 255.255.0.0 ¿si?

     

    Por ejemplo:

    Capital federal (10."10".1.1 y 10."10".1.2)

    Lugano (10."60".1.1 y 10."60".1.2)

    Necochea (10."70".1.1 y 10."70".1.2)

    Bariloche (10."130".1.1 y 10."130".1.2)

    Ushuaia (10."221".1.1 y 10."221".1.2)

    Bien estos son los Servidores DCs y a la vez son servidores DNS integrado al Active Directory.

    Ahora LAS IP PRIVADAS A NIVEL CLIENTE Sería de esta manera:

    Capital federal (130."1".x.x)

    Lugano (130."6".x.x) 

    Necochea (130."7".x.x)

    Bariloche (130."3".x.x)

    Ushuaia (130."2".x.x)

    [Guillermo] ¿Y la máscara de subred? Supongo que 255.255.0.0 ¿si?

     

    Bien, entonces en cada dc promovido de cada locación están en un SOLO DOMINIO (xxxxx);

    [Guillermo] O sea que hay un único dominio en toda la red ¿si?

     

     a su vez los dcs principales son los de Capital Federal (estos replican la información de dns y a su vez ad y demas cosas). Estamos bien hasta ahí?

    [Guillermo] Más o menos :-) Los puedes llamar principales porque alguno tenga los FSMO Roles, o porque están en la central, pero funcionalemente no existe eso. Cualquier DC aceptará cambios (salvo que sean RODCs)

     

    Desde cuaquier locación PC CLIENTE al verificar nos dimos cuenta que tardaban algunas consultas y demas cosas, por lo cual realizamos consulta nslookup en las pcs clientes. Y nos dieron la siguiente respuesta:

    Consulta Nº 1 (capital federal) (PC #1 - CLIENTE)

    Addresses:  10.10.1.1, 10.60.1.1, 10.130.1.1, 10.221.1.1
              10.10.1.2, 10.70.1.2, 10.60.1.2, 10.221.1.2, 10.130.1.2
              10.70.1.1

    Consulta Nº 2 (capital federal) (PC #1 - CLIENTE)

    Addresses:  10.221.1.1, 10.10.1.2, 10.70.1.2, 10.60.1.2
              10.221.1.2, 10.130.1.2, 10.70.1.1, 10.10.1.1, 10.60.1
              10.130.1.1

    Consulta Nº 3 (Capital Federal) (PC #1 - CLIENTE)

    Addresses:  10.10.1.2, 10.70.1.2, 10.60.1.2, 10.221.1.2
              10.130.1.2, 10.70.1.1, 10.10.1.1, 10.60.1.1, 10.130.1
              10.221.1.1

    Esto pasa en todas las locaciones, pero al realizar un nslookup desde la red 10."x".x.x (servidores) no varian, solo rotan por locación y nó toda la lista. Como tendría que ser.

    [Guillermo] Una aclaración importante acá: no es lo mismo el componente "cliente DNS" (llamado Resolver), que NSLOOKUP que es una aplicación aparte.

     

    Imaginate que cualquier usuario por ejemplo de Ushuaia realiza una consulta y depende del servidor dns que lo atiente (ejemplo si lo atiende el de la locacion capital federal) el tipo esta viajando por el enlace hasta buenos aires y vuelve para allá. Sabiendo que solo tendría que consultar SU DNS (Ushuaia), y con las demas locaciones lo mismo. Cada una tendria que consultar con sus dns de la locación.

    [Guillermo] Acá comienzo a confundirme :-( la PC cliente va a preguntar al DNS que tenga configurado en las propiedades de TCP/IP. Esto hay que configurarlo en cada cliente.
    Otro tema es cuando el cliente pregunta a los DNS por un DC de "su dominio" en "su sitio"

     

    Los sites y las subnets estan generadas; cada subnet pertenece a su site. Pero solo hay una zona de DNS, esta zona de dns pertenece al nombre del root domain. Tenémos concentrado todo en un solo dominio las distintas locaciones y desde acá (capital federal) se administra todo.

    Entonces:

    Como haría para que nosotros de CAPITAL FEDERAL con una red cliente 130."1".x.x consultemos solo los DNS SERVERS (10."10".1.1 Y 10."10".1.2, que son los domain controles y a su vez los servidores dns de capital federal)

    [Guillermo] Como puse antes, eso hay que configurarlo en las propiedades de TCP/IP de cada cliente, manualmente o por DHCP

     

    Y así lo mismo con las diferentes locaciones.

    Lugano (130."6".x.x) (10."60".1.1 y 10."60".1.2)

    Necochea (130."7".x.x) (10."70".1.1 y 10."70".1.2)

    Bariloche (130."3".x.x) (10."130".1.1 y 10."130".1.2)

    Ushuaia (130."2".x.x) (10."221".1.1 y 10."221".1.2)

    Espero que ahora se haya entendido.

    Saludos y muchas gracias a todos, de verdad agradezco su atención.



    El Round Robin está activado y la ordenación por mascara de red también.


    Guillermo Delprato - Buenos Aires, Argentina
    Visite Notas Windows Server
    MVP-MCT-MCSE-MCSA MCITP: Enterprise/Server Administrator MCTS: Active Directory/Network/Applications Configuration
    Este mensaje se proporciona "como está" sin garantías de ninguna clase. Usted asume todos los riesgos.
    jueves, 9 de junio de 2011 18:46
    Moderador
  • Guillermo, muchas gracias por tu tiempo.

    El problema está cuando se consulta \\mydominio .Es ahí el problema que surge con las consultas a los dns y más si uno utiliza los links de DFS.

    Si no están publicados en todos lados, la lista a mostrar depende de cual te responda. Espero que me haya explicado bien.

    [Guillermo] ¿Y la máscara de subred? Supongo que 255.255.0.0 ¿si?

    (Santiago) Sí.

    [Guillermo] O sea que hay un único dominio en toda la red ¿si?

    (Santiago) Sí.

    Todo lo demás no aplica.

    Saludos Cordiales.
    jueves, 9 de junio de 2011 19:51
  • \\mydominio es NetBIOS, no es FQDN. Normalmente debería probar primero los métodos de resolución NetBIOS, y recién luego usar los de FQDN como DNS

    En ese caso el que decide qué sufijo de dominio agregarle al hostname es la configuración de TCP/IP en el cliente. Sin no se ha cambiado nada, por omisión, utiliza su propio sufijo de dominio.

    Para definir a qué DNS y en qué orden va a preguntar el cliente, se configura en las propiedades de TCP/IP del mismo, no usa Sites.
    Con que el cliente tenga configurado para usar como DNSs a los dos de su sitio ya está solucionado el problema de a quién le pregunta.

    Para DFS o en realidad para el servicio que sea, siempre conviene usar FQDNs y no NetBIOS porque de esa forma uno se asegura que use DNS, y además pensando a futuro eliminar NetBIOS sobre TCP/IP

     

     


    Guillermo Delprato - Buenos Aires, Argentina
    Visite Notas Windows Server
    MVP-MCT-MCSE-MCSA MCITP: Enterprise/Server Administrator MCTS: Active Directory/Network/Applications Configuration
    Este mensaje se proporciona "como está" sin garantías de ninguna clase. Usted asume todos los riesgos.
    jueves, 9 de junio de 2011 21:07
    Moderador
  • Guillermo,

    llegué a resolver el problema de la rotación de los dsn servers. Pero es imposible si tenes la red de servidores serapadas de las pcs.

    Por lo menos yó no encontré forma de decirle a la pc cliente con ip 130.1.x.x, que cuando consulta al \\dominio.com que solamente le responda la 10.10.1.1 y nó el servidor de ushuaia con ip 10.10.221.1.

    Si yo genero un registro de dns en el mismo rango de ip que los clientes, de esa forma funciona correctamente.

    Saludos cordiales y muchas gracias.

     

    martes, 14 de junio de 2011 13:59
  • Me alegra que lo consideres resuelto. El que todavía no comprende muy bien soy yo :-)

    Porque el cliente no accede normalmente a \\dominio.com salvo con un DFS. Lo normal es que cuando un cliente necesita un servicio de red, sea desde la autenticación, a cualquier servicio que sea "site-aware", primero que nada le pregunta al DNS que tenga configurado en su interfaz de red; éste es el que le responde con el nombre/dirección del servidor que anotó el servicio en el site del cliente.

    Por ejemplo autenticación. Inicialmente el cliente no sabe en qué Site está, así que pregunta al DNS por la lista de DCs de su Dominio. Trata de contactar a todos, usa el primero que responde.
    Este DC que le responde verifica si cliente y DC están en el mismo Site, si están sigue adelante, sinó le informa al cliente en qué Site se encuentra y el cliente "cachea" localmente su Site, y finalmente el cliente pregunta al DNS por la lista de DCs en su Dominio, y en *su Site*

    Por eso es que no termino de comprender cuando dices que le pregunta a otro DNS en otro Site.

    No te preocupes, quizás soy yo :-)

     


    Guillermo Delprato - Buenos Aires, Argentina
    Visite Notas Windows Server
    MVP-MCT-MCSE-MCSA MCITP: Enterprise/Server Administrator MCTS: Active Directory/Network/Applications Configuration
    Este mensaje se proporciona "como está" sin garantías de ninguna clase. Usted asume todos los riesgos.
    martes, 14 de junio de 2011 18:29
    Moderador
  • Es fácil Guillermo,

    Yo tengo DFS instalado verdad? Bueno este responde al nombre ej: mydomain.com. Bien por lo cual nosotros nó tenemos publicados links para todas las locaciones. Vamos bien hasta ahí? Quiero que entiendas que todos los links de dfs no estan publicados en todas las locaciones.

    Por lo cual si vos consultas \\mydomain.com "lo que te va aparecer depende del dns que me atendió". No se si me estás entendiendo.

    Por eso viene el tema del Round Robin, al hacerme rotar los dns la lista de LINKS DE DFS es la que muestra del que me respondió.

    Si me responde el de capital federal (me aparecén todos los links), si me contesta el de lugano (me aparece solo lo que hay compartido en lugano). Pensarás que hay un problema de replicación de dfs? No, porque está desactivada, yo si los publico en todos los servidores allí al consultar \\mydomain.com me aparece. Pero la lista de dns sigue rotando atravez del NSLOOKUP.

    Yo lo que noté en el laboratorio fué que: si al servidor dns le agrego una ip como si fuera un dns server (esta ip es fictícia) del mismo rango que la ip de la vlan (PCS DE LOS CLIENTES) no me rota el dns, por lo cual es como debería ser.

    Me leí artículos por todas partes, y determiné que nosotros tenemos las redes serparadas. Las de los servidores y las de pcs clientes.

    No tengo forma de que cuando yo quiera consultar el dfs root name \\mydomain.com me atienda el servidor dns de mi locación. ¿Por qué? Simple, no tiene el mismo rango de ip.

    Ahora sí yo publico para todas las locaciones los links de dfs me aparecen en todas.

    Bueno muchas gracias por tu tiempo, posiblemente sigas sin entender. Haceme saber si necesitas mas explicaciones porque de verdad que necesito resolver esto.

    Saludos Cordiales Guillermo, muchas gracias.

    martes, 14 de junio de 2011 18:55
  • Ahora sí comprendo :-)

    No había leído, o no habías puesto (no me hagas leer todo nuevamente) lo del DFS

     


    Guillermo Delprato - Buenos Aires, Argentina
    Visite Notas Windows Server
    MVP-MCT-MCSE-MCSA MCITP: Enterprise/Server Administrator MCTS: Active Directory/Network/Applications Configuration
    Este mensaje se proporciona "como está" sin garantías de ninguna clase. Usted asume todos los riesgos.
    martes, 14 de junio de 2011 19:20
    Moderador
  • Hola Santiago y Guillermo.

    En uno de los clientes vi algo muy similar a lo que describe Santiago, pero por así decirlo (y sin ánimo de ofender) bien hecho, con bien hecho quiero decir que tanto los clientes como los servidores de cada oficina donde hay DFS tenían diferentes subredes asociadas a su site, los servidores y clientes de l aoficina 1 tenáin redes diferentes y pertenecian  su site, las de la oficina 2 idem, etc.

    En ese escenario es factible lo que planteas Santiago, porque automáticamente los clientes contactan con el DFS de su site, etc.

     

    Pero tal y como lo tienes ahora, creo que no puede funcionar bien.

    Y siempre será una loteria a que DFS te envíe el DNS por así decirlo.


    Salu2!, Dani Gracia - Madrid España MCSA/MCSE 2003 Security MCITP: Enterprise Administrator (Windows Server 2008) MCTS: System Center Operations Manager 2005 MVA: Microsoft Virtual Academy MAP: Microsoft Active Professional (2010/2011)
    martes, 14 de junio de 2011 19:33