Re: [OFF-TOPIC] Comando para hacer discovery dns en la red
El día 8 de abril de 2014, 17:56, Camaleón escribió: > El Tue, 08 Apr 2014 17:33:13 +0200, Maykel Franco escribió: > >> El día 8 de abril de 2014, 15:49, Camaleón > escribió: > > (...) > >>> No hay inconveniente siempre que tengas MUY bien definido el tráfico >>> que sigue tu red y por dónde debe tirar cuando el tráfico es local y >>> cuando es remoto, establecer las prioridades de los servidores DNS (el >>> que caso de que haya varios), etc... >> >> Está definido, en la red local se asigna de dns una ip privada que es >> el dns 192.168.1.200, y es lo que digo que falla algunas veces...En >> vez de resolver por dentro, resuelve por fuera y se va a los dns de >> google... > > (...) > > Bien, pero alguien (algo) tiene que estar diciendo a los clientes de la > red qué servidor DNS usar y ese servidor DNS tiene que tener definida una > configuración que permita las resoluciones locales y remotas y además, > tiene que estar bien configurado en cuanto a prioridades (si resuelve el > dominio en local, que redirija al servidor web local y sólo si no lo > encuentra, que lo mande por el externo). > > Eso es lo que tienes que depurar y esa configuración la tienes que ver en > el servidor DNS local. > > Saludos, > > -- > Camaleón > > > -- > To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org > with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org > Archive: https://lists.debian.org/pan.2014.04.08.15.56...@gmail.com > Hace tiempo solucioné esto. Resulta que en el servidor dhcp tenía puesto que asignara el dns primero el interno y luego el de google, de tal forma, que dependiendo del cliente que uses y el SO, lo interpreta de una forma u otra. Por ejemplo en Mac o windows, cada 2 x 3 en vez de resolver con el dns interno, se iba al externo... y viceversa...En cambio, en linux siempre se iba a resolver al dns primario... Al final puse en el dhcp que sólo asignara el dns interno de la lan, y listo. En el servidor dns tengo puesto que lo que no pueda resolver él, lo pregunte fuera, por ejemplo a google y ya funciona perfecto. Eso sí, de la parte de los clientes, no se actualizará estos cambios del dhcp hasta la próxima petición dns. Saludos. -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/CAJ2aOA9yUhVqytx9sWTgQnVd=6w5+cuxqj26+xqalt526+0...@mail.gmail.com
Re: [OFF-TOPIC] Comando para hacer discovery dns en la red
El Tue, 08 Apr 2014 17:33:13 +0200, Maykel Franco escribió: > El día 8 de abril de 2014, 15:49, Camaleón escribió: (...) >> No hay inconveniente siempre que tengas MUY bien definido el tráfico >> que sigue tu red y por dónde debe tirar cuando el tráfico es local y >> cuando es remoto, establecer las prioridades de los servidores DNS (el >> que caso de que haya varios), etc... > > Está definido, en la red local se asigna de dns una ip privada que es > el dns 192.168.1.200, y es lo que digo que falla algunas veces...En > vez de resolver por dentro, resuelve por fuera y se va a los dns de > google... (...) Bien, pero alguien (algo) tiene que estar diciendo a los clientes de la red qué servidor DNS usar y ese servidor DNS tiene que tener definida una configuración que permita las resoluciones locales y remotas y además, tiene que estar bien configurado en cuanto a prioridades (si resuelve el dominio en local, que redirija al servidor web local y sólo si no lo encuentra, que lo mande por el externo). Eso es lo que tienes que depurar y esa configuración la tienes que ver en el servidor DNS local. Saludos, -- Camaleón -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/pan.2014.04.08.15.56...@gmail.com
Re: [OFF-TOPIC] Comando para hacer discovery dns en la red
El día 8 de abril de 2014, 15:49, Camaleón escribió: > El Tue, 08 Apr 2014 15:31:25 +0200, Maykel Franco escribió: > >> El día 8 de abril de 2014, 15:14, Camaleón > escribió: > > (...) > >>> A ver... ¿estás diciendo que el dominio "redmine.example.com" está >>> configurado para resolver en dos direcciones IP distintas, una local y >>> otra remota? Si es así, vas a tener problemas. >> >> Exacto. Problemas porque? Si estás dentro de la red y tienes un dns >> interno te resuelve por dentro sin salir hacia fuera(dns de google) y >> si estás fuera de la red local, te resuelve por fuera directamente y >> listo. No veo el inconveniente... > > No hay inconveniente siempre que tengas MUY bien definido el tráfico que > sigue tu red y por dónde debe tirar cuando el tráfico es local y cuando > es remoto, establecer las prioridades de los servidores DNS (el que caso > de que haya varios), etc... Está definido, en la red local se asigna de dns una ip privada que es el dns 192.168.1.200, y es lo que digo que falla algunas veces...En vez de resolver por dentro, resuelve por fuera y se va a los dns de google... > >>> Y vuelvo a preguntar ¿quién gestiona ese dominio, quién o quiénes -qué >>> servidor(es) DNS- se encarga(n) de sus zonas? >> >> El dns externo nos lo lleva una empresa externa nominalia(que >> administramos nosotros) y el dns interno lo gestionamos nosotros. > > ¡Por fin! :-) > > Vale, eso quiere decir que buscas una configuración dual del dominio > (local y remota). Ten en cuenta que los equipos de tu red permiten las > dos configuraciones (tráfico local y remoto), sólo tienes que determinar > la prioridad del tráfico, si quieres que la tenga tu servidor DNS local > (y que redirija a tus equipos hacia el servidor web "local") o que la > tenga el servidor DNS externo (y que envíe a los clientes al servidor web > desde fuera de la red). Mm en antiguas versiones de pfsense no he tenido que tocar nada, de echo no veo nada en pfsense para configurar la prioridad...Simplemente creas un dns interno sin más... > > Y recuerda que el servidor DNS local también puedes configurarlo para que > reenvíe las peticiones externas a un servidor DNS remoto. En fin, que el > escenario se puede complicar por eso conviene tener los conceptos muy > claros. Sí, gracias lo sé. > Es más, desde la consola con dig, nslookup, host , ping ... me resuelve perfectamente por dentro. Es decir, pfsense está dando ese error de rebinding porque en realidad chrome está saliendo por fuera a un dominio que tiene internamente... >>> >>> Bien, entonces prueba lo siguiente y manda los resultados (omitiendo > los >>> datos que quieras): >>> >>> dig @8.8.8.8 redmine.example.com >>> dig @dns_local redmine.example.com >> >> maykel-debian /home/maykel # dig @8.8.8.8 redmine.example.com > > (...) > >> maykel-debian /home/maykel # dig @192.168.1.200 redmine.example.com > > (...) > > Perfecto. > >> No entiendo nada... Además me acabo de dar cuenta que es aleatorio, a >> veces funciona bien y otras veces no funciona porque resuelve hacia >> fuera... Estoy flipando la verdad... No sé por donde cogerlo. > > Si el cliente usa el servidor DNS local como servidor DNS predeterminado, > tendría resolver el dominio "local" ya que debería tener prioridad aunque > tendría que consultar la documentación sobre este punto porque no estoy > del todo segura. Lo que sí me dado cuenta y tienes razón, es que con los dominios que sólo están definidos internamente, nunca pasa. Es decir, sólo pasa con los dominios que están en dual, tanto fuera(dns externo google por ejemplo) como dentro de la red(pfsense dnsmasq). > > Saludos, No sé donde mirar la verdad, además que es aleatorio y muchas veces cuesta reproducir el fallo...Es alucinante la verdad, de repente haces un nslookup o ping o host de ese dominio y resuelve por dentro, y alguna vez se va por fuera... Saludos. > > -- > Camaleón > > > -- > To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org > with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org > Archive: https://lists.debian.org/pan.2014.04.08.13.49...@gmail.com > -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/CAJ2aOA_A2EWrzcVe26XcNpPovHJsZG=rhxzxume9mdmdzst...@mail.gmail.com
Re: [OFF-TOPIC] Comando para hacer discovery dns en la red
El Tue, 08 Apr 2014 15:31:25 +0200, Maykel Franco escribió: > El día 8 de abril de 2014, 15:14, Camaleón escribió: (...) >> A ver... ¿estás diciendo que el dominio "redmine.example.com" está >> configurado para resolver en dos direcciones IP distintas, una local y >> otra remota? Si es así, vas a tener problemas. > > Exacto. Problemas porque? Si estás dentro de la red y tienes un dns > interno te resuelve por dentro sin salir hacia fuera(dns de google) y > si estás fuera de la red local, te resuelve por fuera directamente y > listo. No veo el inconveniente... No hay inconveniente siempre que tengas MUY bien definido el tráfico que sigue tu red y por dónde debe tirar cuando el tráfico es local y cuando es remoto, establecer las prioridades de los servidores DNS (el que caso de que haya varios), etc... >> Y vuelvo a preguntar ¿quién gestiona ese dominio, quién o quiénes -qué >> servidor(es) DNS- se encarga(n) de sus zonas? > > El dns externo nos lo lleva una empresa externa nominalia(que > administramos nosotros) y el dns interno lo gestionamos nosotros. ¡Por fin! :-) Vale, eso quiere decir que buscas una configuración dual del dominio (local y remota). Ten en cuenta que los equipos de tu red permiten las dos configuraciones (tráfico local y remoto), sólo tienes que determinar la prioridad del tráfico, si quieres que la tenga tu servidor DNS local (y que redirija a tus equipos hacia el servidor web "local") o que la tenga el servidor DNS externo (y que envíe a los clientes al servidor web desde fuera de la red). Y recuerda que el servidor DNS local también puedes configurarlo para que reenvíe las peticiones externas a un servidor DNS remoto. En fin, que el escenario se puede complicar por eso conviene tener los conceptos muy claros. >>> Es más, desde la consola con dig, nslookup, host , ping ... me >>> resuelve perfectamente por dentro. Es decir, pfsense está dando ese >>> error de rebinding porque en realidad chrome está saliendo por fuera a >>> un dominio que tiene internamente... >> >> Bien, entonces prueba lo siguiente y manda los resultados (omitiendo los >> datos que quieras): >> >> dig @8.8.8.8 redmine.example.com >> dig @dns_local redmine.example.com > > maykel-debian /home/maykel # dig @8.8.8.8 redmine.example.com (...) > maykel-debian /home/maykel # dig @192.168.1.200 redmine.example.com (...) Perfecto. > No entiendo nada... Además me acabo de dar cuenta que es aleatorio, a > veces funciona bien y otras veces no funciona porque resuelve hacia > fuera... Estoy flipando la verdad... No sé por donde cogerlo. Si el cliente usa el servidor DNS local como servidor DNS predeterminado, tendría resolver el dominio "local" ya que debería tener prioridad aunque tendría que consultar la documentación sobre este punto porque no estoy del todo segura. Saludos, -- Camaleón -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/pan.2014.04.08.13.49...@gmail.com
Re: [OFF-TOPIC] Comando para hacer discovery dns en la red
El día 8 de abril de 2014, 15:14, Camaleón escribió: > El Tue, 08 Apr 2014 13:52:04 +0200, Maykel Franco escribió: > >> El día 7 de abril de 2014, 18:50, Camaleón >> escribió: > > (...) > Eso es por el DNS rebinding que dice que básicamente lo detecta como un ataque de DNS pero eso es porque no resuelve bien internamente y como ese dominio esta también accesible por fuera esta configurado por defecto pfSense para bloquear ese tipo de conexión si se intenta acceder desde dentro y se va fuera para volver a entrar... >>> >>> Pues eso, que tienes que configurarlo, o bien decirle a pfsense que >>> omita una alerta para ese tipo de situaciones (ya que ahora mismo debe >>> de estar bloqueando el tráfico sobre el que detecta algo que no le >>> gusta) o bien configurar correctamente ese registro DNS para que no >>> haga saltar a las reglas de pfsense. Tú eliges. >> >> No es eso, ya he encontrado lo que pasa. Desde firefox funciona >> perfectamente y resuelve bien internamente, no falla. > > Pues asegúrate bien de que ese mensaje que te saca el pfsense sea > realmente inocuo y no esté llevando a cabo ninguna contramedida de > seguridad. Si te bloquea el tráfico tendrás problemas. > >> El problema es con chrome, chromium y derivados, que no hace caso al >> dns configurado por networkmanager y en vez de irse a 192.168.1.200 se >> va a 8.8.8.8 . > > Que yo sepa el navegador no tiene vida propia y los datos de la > configuración de la red los comanda el sistema operativo, no el > navegador ;-) > >> Desde chrome, metiendome en la url: >> chrome://net-internals/#dns >> >> Veo mi registro >> >> redmine.example.com como está cacheado a la ip externa en vez de a la >> interna. > > A ver... ¿estás diciendo que el dominio "redmine.example.com" está > configurado para resolver en dos direcciones IP distintas, una local y > otra remota? Si es así, vas a tener problemas. Exacto. Problemas porque? Si estás dentro de la red y tienes un dns interno te resuelve por dentro sin salir hacia fuera(dns de google) y si estás fuera de la red local, te resuelve por fuera directamente y listo. No veo el inconveniente... > > Y vuelvo a preguntar ¿quién gestiona ese dominio, quién o quiénes -qué > servidor(es) DNS- se encarga(n) de sus zonas? El dns externo nos lo lleva una empresa externa nominalia(que administramos nosotros) y el dns interno lo gestionamos nosotros. > >> Aún limpiándole la caché de hosts del navegador, y vuelvo a >> probarlo pasa exactamente lo mismo... Sin embargo con firefox resuelve >> por dentro perfectamente... > > Deja el navegador a un lado y saca la línea de comandos que es más > fiable. Ejecuta "dig redmine.example.com" y verifica que en cualquier > situación te devuelve los datos correctos (recuerda que con "dig > @ip_servidor_dns" puedes seleccionar el servidor dns sobre el que > ejecutar la consulta). Por linea de comandos me resuelve bien el dominio a la ip interna de la red local, incluso cuando el chrome resuelve por fuera en vez de por dentro. Aunque reconozco, que en otros equipos como windows o mac, cuando da error de rebinding es porque no está resolviendo internamente, sino externamente y por eso lo bloquea pfsense, pero en este caso no es así... Además según lo que he leído, cuando pfsense te bloquea con un rebinding, eso es porque él se cree que vas a entrar en su administración web a través de un dominio que no está autorizado. Normalmente se entra a pfsense con la dirección ip de la lan. > >> Es más, desde la consola con dig, nslookup, host , ping ... me >> resuelve perfectamente por dentro. Es decir, pfsense está dando ese >> error de rebinding porque en realidad chrome está saliendo por fuera a >> un dominio que tiene internamente... > > Bien, entonces prueba lo siguiente y manda los resultados (omitiendo los > datos que quieras): > > dig @8.8.8.8 redmine.example.com > dig @dns_local redmine.example.com maykel-debian /home/maykel # dig @8.8.8.8 redmine.example.com ; <<>> DiG 9.9.2-P2 <<>> @8.8.8.8 redmine.example.com ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 13128 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 512 ;; QUESTION SECTION: ;redmine.example.com. IN A ;; ANSWER SECTION: redmine.example.com. 850 IN A 82.14.14.14 ;; Query time: 27 msec ;; SERVER: 8.8.8.8#53(8.8.8.8) ;; WHEN: Tue Apr 8 15:22:58 2014 ;; MSG SIZE rcvd: 61 maykel-debian /home/maykel # dig @192.168.1.200 redmine.example.com ; <<>> DiG 9.9.2-P2 <<>> @192.168.1.200 redmine.example.com ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 63117 ;; flags: qr aa rd ra ad; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;redmine.example.com. IN A ;; ANSWER SECTION: redmine.example.com. 1 IN A 19
Re: [OFF-TOPIC] Comando para hacer discovery dns en la red
El Tue, 08 Apr 2014 13:52:04 +0200, Maykel Franco escribió: > El día 7 de abril de 2014, 18:50, Camaleón > escribió: (...) >>> Eso es por el DNS rebinding que dice que básicamente lo detecta como >>> un ataque de DNS pero eso es porque no resuelve bien internamente y >>> como ese dominio esta también accesible por fuera esta configurado por >>> defecto pfSense para bloquear ese tipo de conexión si se intenta >>> acceder desde dentro y se va fuera para volver a entrar... >> >> Pues eso, que tienes que configurarlo, o bien decirle a pfsense que >> omita una alerta para ese tipo de situaciones (ya que ahora mismo debe >> de estar bloqueando el tráfico sobre el que detecta algo que no le >> gusta) o bien configurar correctamente ese registro DNS para que no >> haga saltar a las reglas de pfsense. Tú eliges. > > No es eso, ya he encontrado lo que pasa. Desde firefox funciona > perfectamente y resuelve bien internamente, no falla. Pues asegúrate bien de que ese mensaje que te saca el pfsense sea realmente inocuo y no esté llevando a cabo ninguna contramedida de seguridad. Si te bloquea el tráfico tendrás problemas. > El problema es con chrome, chromium y derivados, que no hace caso al > dns configurado por networkmanager y en vez de irse a 192.168.1.200 se > va a 8.8.8.8 . Que yo sepa el navegador no tiene vida propia y los datos de la configuración de la red los comanda el sistema operativo, no el navegador ;-) > Desde chrome, metiendome en la url: > chrome://net-internals/#dns > > Veo mi registro > > redmine.example.com como está cacheado a la ip externa en vez de a la > interna. A ver... ¿estás diciendo que el dominio "redmine.example.com" está configurado para resolver en dos direcciones IP distintas, una local y otra remota? Si es así, vas a tener problemas. Y vuelvo a preguntar ¿quién gestiona ese dominio, quién o quiénes -qué servidor(es) DNS- se encarga(n) de sus zonas? > Aún limpiándole la caché de hosts del navegador, y vuelvo a > probarlo pasa exactamente lo mismo... Sin embargo con firefox resuelve > por dentro perfectamente... Deja el navegador a un lado y saca la línea de comandos que es más fiable. Ejecuta "dig redmine.example.com" y verifica que en cualquier situación te devuelve los datos correctos (recuerda que con "dig @ip_servidor_dns" puedes seleccionar el servidor dns sobre el que ejecutar la consulta). > Es más, desde la consola con dig, nslookup, host , ping ... me > resuelve perfectamente por dentro. Es decir, pfsense está dando ese > error de rebinding porque en realidad chrome está saliendo por fuera a > un dominio que tiene internamente... Bien, entonces prueba lo siguiente y manda los resultados (omitiendo los datos que quieras): dig @8.8.8.8 redmine.example.com dig @dns_local redmine.example.com > Seguiré investigando, gracias Camaleón por todo. Ya contarás. Saludos, -- Camaleón -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/pan.2014.04.08.13.14...@gmail.com
Re: [OFF-TOPIC] Comando para hacer discovery dns en la red
Bueno y tu dns interno te resuelve??.. has realizado pruebas... Enviado desde mi dispositivo android. -Original Message- From: Maykel Franco To: debian-user-spanish Sent: mar, 08 abr 2014 6:52 Subject: Re: [OFF-TOPIC] Comando para hacer discovery dns en la red El día 7 de abril de 2014, 18:50, Camaleón escribió: > El Mon, 07 Apr 2014 18:37:25 +0200, Maykel Franco escribió: > > (el html...) > >> El 07/04/2014 18:31, "Camaleón" escribió: > >>> > En cuanto he ido al navegador y he puesto redmine.example.com me ha >>> > dado error de "Potential DNS Rebind attack detected" >>> >>> >>> (...) >>> >>> DNS Rebinding Protections >>> https://doc.pfsense.org/index.php/DNS_Rebinding_Protections >>> >>> > Alguna sugerencia? >>> >>> Pues parece que se trata de alguna funcionalidad de seguridad de >>> pfsense que tendrás que ver cómo configurar para adecuarla a tu >>> configuración o en su defecto corregir para que no se active esa >>> alarma. >> >> Eso es por el DNS rebinding que dice que básicamente lo detecta como un >> ataque de DNS pero eso es porque no resuelve bien internamente y como >> ese dominio esta también accesible por fuera esta configurado por >> defecto pfSense para bloquear ese tipo de conexión si se intenta acceder >> desde dentro y se va fuera para volver a entrar... > > Pues eso, que tienes que configurarlo, o bien decirle a pfsense que omita > una alerta para ese tipo de situaciones (ya que ahora mismo debe de estar > bloqueando el tráfico sobre el que detecta algo que no le gusta) o bien > configurar correctamente ese registro DNS para que no haga saltar a las > reglas de pfsense. Tú eliges. No es eso, ya he encontrado lo que pasa. Desde firefox funciona perfectamente y resuelve bien internamente, no falla. El problema es con chrome, chromium y derivados, que no hace caso al dns configurado por networkmanager y en vez de irse a 192.168.1.200 se va a 8.8.8.8 . Desde chrome, metiendome en la url: chrome://net-internals/#dns Veo mi registro redmine.example.com como está cacheado a la ip externa en vez de a la interna. Aún limpiándole la caché de hosts del navegador, y vuelvo a probarlo pasa exactamente lo mismo... Sin embargo con firefox resuelve por dentro perfectamente... Es más, desde la consola con dig, nslookup, host , ping ... me resuelve perfectamente por dentro. Es decir, pfsense está dando ese error de rebinding porque en realidad chrome está saliendo por fuera a un dominio que tiene internamente... Seguiré investigando, gracias Camaleón por todo. Saludos. > >> pero no es relevante para que resuelva bien internamente durante 2 >> semanas y de repente ya no resuelve por dentro y se va por fuera... Me >> huele que puede ser un bug... Porque si me pasa también con una >> instalación desde 0... >> >> No se por donde tirar la verdad... > > Empieza por conseguir que pfsense no detecte ese tráfico como una amenaza > y corrige lo que haga falta. > > Saludos, > > -- > Camaleón > > > -- > To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org > with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org > Archive: https://lists.debian.org/pan.2014.04.07.16.50...@gmail.com > -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/caj2aoa_ed+y1suefvrf8hv8v3pvtiljsme5s6ronigls9sb...@mail.gmail.com
Re: [OFF-TOPIC] Comando para hacer discovery dns en la red
El día 7 de abril de 2014, 18:50, Camaleón escribió: > El Mon, 07 Apr 2014 18:37:25 +0200, Maykel Franco escribió: > > (el html...) > >> El 07/04/2014 18:31, "Camaleón" escribió: > >>> > En cuanto he ido al navegador y he puesto redmine.example.com me ha >>> > dado error de "Potential DNS Rebind attack detected" >>> >>> >>> (...) >>> >>> DNS Rebinding Protections >>> https://doc.pfsense.org/index.php/DNS_Rebinding_Protections >>> >>> > Alguna sugerencia? >>> >>> Pues parece que se trata de alguna funcionalidad de seguridad de >>> pfsense que tendrás que ver cómo configurar para adecuarla a tu >>> configuración o en su defecto corregir para que no se active esa >>> alarma. >> >> Eso es por el DNS rebinding que dice que básicamente lo detecta como un >> ataque de DNS pero eso es porque no resuelve bien internamente y como >> ese dominio esta también accesible por fuera esta configurado por >> defecto pfSense para bloquear ese tipo de conexión si se intenta acceder >> desde dentro y se va fuera para volver a entrar... > > Pues eso, que tienes que configurarlo, o bien decirle a pfsense que omita > una alerta para ese tipo de situaciones (ya que ahora mismo debe de estar > bloqueando el tráfico sobre el que detecta algo que no le gusta) o bien > configurar correctamente ese registro DNS para que no haga saltar a las > reglas de pfsense. Tú eliges. No es eso, ya he encontrado lo que pasa. Desde firefox funciona perfectamente y resuelve bien internamente, no falla. El problema es con chrome, chromium y derivados, que no hace caso al dns configurado por networkmanager y en vez de irse a 192.168.1.200 se va a 8.8.8.8 . Desde chrome, metiendome en la url: chrome://net-internals/#dns Veo mi registro redmine.example.com como está cacheado a la ip externa en vez de a la interna. Aún limpiándole la caché de hosts del navegador, y vuelvo a probarlo pasa exactamente lo mismo... Sin embargo con firefox resuelve por dentro perfectamente... Es más, desde la consola con dig, nslookup, host , ping ... me resuelve perfectamente por dentro. Es decir, pfsense está dando ese error de rebinding porque en realidad chrome está saliendo por fuera a un dominio que tiene internamente... Seguiré investigando, gracias Camaleón por todo. Saludos. > >> pero no es relevante para que resuelva bien internamente durante 2 >> semanas y de repente ya no resuelve por dentro y se va por fuera... Me >> huele que puede ser un bug... Porque si me pasa también con una >> instalación desde 0... >> >> No se por donde tirar la verdad... > > Empieza por conseguir que pfsense no detecte ese tráfico como una amenaza > y corrige lo que haga falta. > > Saludos, > > -- > Camaleón > > > -- > To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org > with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org > Archive: https://lists.debian.org/pan.2014.04.07.16.50...@gmail.com > -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/caj2aoa_ed+y1suefvrf8hv8v3pvtiljsme5s6ronigls9sb...@mail.gmail.com
Re: [OFF-TOPIC] Comando para hacer discovery dns en la red
El Mon, 07 Apr 2014 18:37:25 +0200, Maykel Franco escribió: (el html...) > El 07/04/2014 18:31, "Camaleón" escribió: >> > En cuanto he ido al navegador y he puesto redmine.example.com me ha >> > dado error de "Potential DNS Rebind attack detected" >> >> >> (...) >> >> DNS Rebinding Protections >> https://doc.pfsense.org/index.php/DNS_Rebinding_Protections >> >> > Alguna sugerencia? >> >> Pues parece que se trata de alguna funcionalidad de seguridad de >> pfsense que tendrás que ver cómo configurar para adecuarla a tu >> configuración o en su defecto corregir para que no se active esa >> alarma. > > Eso es por el DNS rebinding que dice que básicamente lo detecta como un > ataque de DNS pero eso es porque no resuelve bien internamente y como > ese dominio esta también accesible por fuera esta configurado por > defecto pfSense para bloquear ese tipo de conexión si se intenta acceder > desde dentro y se va fuera para volver a entrar... Pues eso, que tienes que configurarlo, o bien decirle a pfsense que omita una alerta para ese tipo de situaciones (ya que ahora mismo debe de estar bloqueando el tráfico sobre el que detecta algo que no le gusta) o bien configurar correctamente ese registro DNS para que no haga saltar a las reglas de pfsense. Tú eliges. > pero no es relevante para que resuelva bien internamente durante 2 > semanas y de repente ya no resuelve por dentro y se va por fuera... Me > huele que puede ser un bug... Porque si me pasa también con una > instalación desde 0... > > No se por donde tirar la verdad... Empieza por conseguir que pfsense no detecte ese tráfico como una amenaza y corrige lo que haga falta. Saludos, -- Camaleón -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/pan.2014.04.07.16.50...@gmail.com
Re: [OFF-TOPIC] Comando para hacer discovery dns en la red
El 07/04/2014 18:31, "Camaleón" escribió: > > El Mon, 07 Apr 2014 18:09:52 +0200, Maykel Franco escribió: > > > El día 7 de abril de 2014, 16:26, Camaleón > > escribió: > > (..) > > >> "Funciona bien" no vale. > >> > >> Necesitamos datos de los registros del dominio que devuelve distintos > >> resultados. Puedes omitir datos sensibles, como las direcciones IP > >> completas o los nombres de dominio pero manda "algo" para que podemos > >> ver cómo está configurado. > > (...) > > > Umm, que cosa más curiosa. He montado un dns en otra ip 192.168.1.200 > > (usando el firewall pfsense más actualizado 2.1.1) y he importado el xml > > de configuración de dns del dns pfsense actual que usamos(versión 2.1). > > Y me ha pasado exactamente lo mismo. > > > > En cuanto he ido al navegador y he puesto redmine.example.com me ha dado > > error de "Potential DNS Rebind attack detected" > > > (...) > > DNS Rebinding Protections > https://doc.pfsense.org/index.php/DNS_Rebinding_Protections > > > Alguna sugerencia? > > Pues parece que se trata de alguna funcionalidad de seguridad de pfsense > que tendrás que ver cómo configurar para adecuarla a tu configuración o > en su defecto corregir para que no se active esa alarma. Eso es por el DNS rebinding que dice que básicamente lo detecta como un ataque de DNS pero eso es porque no resuelve bien internamente y como ese dominio esta también accesible por fuera esta configurado por defecto pfSense para bloquear ese tipo de conexión si se intenta acceder desde dentro y se va fuera para volver a entrar... pero no es relevante para que resuelva bien internamente durante 2 semanas y de repente ya no resuelve por dentro y se va por fuera... Me huele que puede ser un bug... Porque si me pasa también con una instalación desde 0... No se por donde tirar la verdad... > > Saludos, > > -- > Camaleón Gracias. Saludos. > > > -- > To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org > with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org > Archive: https://lists.debian.org/pan.2014.04.07.16.31...@gmail.com >
Re: [OFF-TOPIC] Comando para hacer discovery dns en la red
El Mon, 07 Apr 2014 18:09:52 +0200, Maykel Franco escribió: > El día 7 de abril de 2014, 16:26, Camaleón > escribió: (..) >> "Funciona bien" no vale. >> >> Necesitamos datos de los registros del dominio que devuelve distintos >> resultados. Puedes omitir datos sensibles, como las direcciones IP >> completas o los nombres de dominio pero manda "algo" para que podemos >> ver cómo está configurado. (...) > Umm, que cosa más curiosa. He montado un dns en otra ip 192.168.1.200 > (usando el firewall pfsense más actualizado 2.1.1) y he importado el xml > de configuración de dns del dns pfsense actual que usamos(versión 2.1). > Y me ha pasado exactamente lo mismo. > > En cuanto he ido al navegador y he puesto redmine.example.com me ha dado > error de "Potential DNS Rebind attack detected" (...) DNS Rebinding Protections https://doc.pfsense.org/index.php/DNS_Rebinding_Protections > Alguna sugerencia? Pues parece que se trata de alguna funcionalidad de seguridad de pfsense que tendrás que ver cómo configurar para adecuarla a tu configuración o en su defecto corregir para que no se active esa alarma. Saludos, -- Camaleón -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/pan.2014.04.07.16.31...@gmail.com
Re: [OFF-TOPIC] Comando para hacer discovery dns en la red
El día 7 de abril de 2014, 16:26, Camaleón escribió: > El Mon, 07 Apr 2014 16:17:51 +0200, Maykel Franco escribió: > > (u... ese html...) > >> El 7 de abril de 2014, 15:39, Camaleón escribió: >> >>> El Mon, 07 Apr 2014 12:49:21 +0200, Maykel Franco escribió: >>> >>> > Hola buenas, quería saber si existe algún comando en linux para saber >>> > cuántos dns hay en una red. Hacer un discovery y ver los que hay. >>> > >>> > Esto me ha surgido porque en mi red local tenemos un dns que a veces >>> > no resuelve bien internamente y resuelve hacia fuera, por ejemplo: > > (...) > >>> > Pero claro, según las redes si a tí el dhcp te da una ip, con una >>> > gateway y con un dns en teoría debería de irse a ese dns asignado >>> > siempre para consultar, y aunque hubiera otro dns en la red, no >>> > tendría nada que ver ni interferir con el otro dns... >>> > >>> > Qué opináis?? >>> >>> Ejecuta "dig -t any example.com" desde todos los equipos que presenten >>> discrepancias en cuanto a los registros DNS de un mismo dominio. > >> Estoy de acuerdo, 2 dns no tienen colisión entre sí. Pero es muy >> extraño. > > Ni 2 ni millones de los que hay por ahí ;-) > >> Sí es verdad muchos de los dominios están tanto dentro accesibles como >> fuera, pero es que no tiene nada más... Funciona bien, resuelve por >> dentro y alomejor a las 2 semanas de repente vas a acceder y se va por >> fuera... y claro el firewall tiene bloqueada las conexiones que intentas >> acceder desde dentro y salen hacia afuera para volver a entrar... > > "Funciona bien" no vale. > > Necesitamos datos de los registros del dominio que devuelve distintos > resultados. Puedes omitir datos sensibles, como las direcciones IP > completas o los nombres de dominio pero manda "algo" para que podemos ver > cómo está configurado. > >> Además teniendo un dns en la red para que vas a salir por fuera y a >> volver a entrar si puedes hacerlo internamente?? Mejor hacerlo >> internamente, más seguro y más rápido. Y en cuanto reinicias la red del >> equipo, vuelve a funcionar, a veces le cuesta un poco más pero acaba >> resolviendo... Esto lleva pasando desde que hicimos un update de nuestro >> firewall. > > Bueno, y tengo configurado un dns local pero uso el de mi ISP en los > clientes. Las motivaciones para hacerlo así pueden ser varias. > > Y a veces, "salir por fuera para volver a entrar" también puede ser > necesario si se quieren hacer pruebas sobre un entorno real. > >> Voy a probar a montar un servidor dns desde 0, exportando en un xml >> todos los dns internos que tenemos e importándolos en el nuevo dns. Si >> sigue pasando está claro que hay algo raro, sino sigue pasando es que es >> el dns del firewall que a veces resuelve hacia fuera aún teniendo el >> dns apuntando a un host interno. > > Asegúrate de configurar los registros del DNS conforme a la normativa y > no duplicar los registros con datos que colisionen. > > Saludos, > > -- > Camaleón > > > -- > To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org > with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org > Archive: https://lists.debian.org/pan.2014.04.07.14.26...@gmail.com > Umm, que cosa más curiosa. He montado un dns en otra ip 192.168.1.200 (usando el firewall pfsense más actualizado 2.1.1) y he importado el xml de configuración de dns del dns pfsense actual que usamos(versión 2.1). Y me ha pasado exactamente lo mismo. En cuanto he ido al navegador y he puesto redmine.example.com me ha dado error de "Potential DNS Rebind attack detected" y me ido a la terminal de mi portátil y he ejecutado: dig -t any redmine.example.com y me ha devuelvo perfectamente la resolución a la ip correspondiente. Digamos que redmine.example.com apunta a 192.168.1.33 maykel-debian /home/maykel # dig -t any redmine.example.com ; <<>> DiG 9.9.2-P2 <<>> -t any redmine.example.com ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 48222 ;; flags: qr aa rd ra ad; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;redmine.example.com. IN ANY ;; ANSWER SECTION: redmine.example.com. 1 IN A 192.168.1.33 ;; Query time: 0 msec ;; SERVER: 192.168.1.200#53(192.168.1.200) ;; WHEN: Mon Apr 7 18:04:34 2014 ;; MSG SIZE rcvd: 50 maykel-debian /home/maykel # nslookup redmine.example.com Server: 192.168.1.200 Address:192.168.1.200#53 Name: redmine.example.com Address: 192.168.1.33 Que raro...Resuelve bien pero el navegador no lo interpreta bien...He limpiado cache del navegador en el historial de chrome y sigue igual...Esto es a lo que me refiero que al final tengo que reiniciar la red... Alguna sugerencia? Saludos. -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/CAJ2aOA-QEeM8oPSf800MMYDovk=v_hn9zypstipbapjnnng...@mail.gmail.com
Re: [OFF-TOPIC] Comando para hacer discovery dns en la red
El Mon, 07 Apr 2014 16:17:51 +0200, Maykel Franco escribió: (u... ese html...) > El 7 de abril de 2014, 15:39, Camaleón escribió: > >> El Mon, 07 Apr 2014 12:49:21 +0200, Maykel Franco escribió: >> >> > Hola buenas, quería saber si existe algún comando en linux para saber >> > cuántos dns hay en una red. Hacer un discovery y ver los que hay. >> > >> > Esto me ha surgido porque en mi red local tenemos un dns que a veces >> > no resuelve bien internamente y resuelve hacia fuera, por ejemplo: (...) >> > Pero claro, según las redes si a tí el dhcp te da una ip, con una >> > gateway y con un dns en teoría debería de irse a ese dns asignado >> > siempre para consultar, y aunque hubiera otro dns en la red, no >> > tendría nada que ver ni interferir con el otro dns... >> > >> > Qué opináis?? >> >> Ejecuta "dig -t any example.com" desde todos los equipos que presenten >> discrepancias en cuanto a los registros DNS de un mismo dominio. > Estoy de acuerdo, 2 dns no tienen colisión entre sí. Pero es muy > extraño. Ni 2 ni millones de los que hay por ahí ;-) > Sí es verdad muchos de los dominios están tanto dentro accesibles como > fuera, pero es que no tiene nada más... Funciona bien, resuelve por > dentro y alomejor a las 2 semanas de repente vas a acceder y se va por > fuera... y claro el firewall tiene bloqueada las conexiones que intentas > acceder desde dentro y salen hacia afuera para volver a entrar... "Funciona bien" no vale. Necesitamos datos de los registros del dominio que devuelve distintos resultados. Puedes omitir datos sensibles, como las direcciones IP completas o los nombres de dominio pero manda "algo" para que podemos ver cómo está configurado. > Además teniendo un dns en la red para que vas a salir por fuera y a > volver a entrar si puedes hacerlo internamente?? Mejor hacerlo > internamente, más seguro y más rápido. Y en cuanto reinicias la red del > equipo, vuelve a funcionar, a veces le cuesta un poco más pero acaba > resolviendo... Esto lleva pasando desde que hicimos un update de nuestro > firewall. Bueno, y tengo configurado un dns local pero uso el de mi ISP en los clientes. Las motivaciones para hacerlo así pueden ser varias. Y a veces, "salir por fuera para volver a entrar" también puede ser necesario si se quieren hacer pruebas sobre un entorno real. > Voy a probar a montar un servidor dns desde 0, exportando en un xml > todos los dns internos que tenemos e importándolos en el nuevo dns. Si > sigue pasando está claro que hay algo raro, sino sigue pasando es que es > el dns del firewall que a veces resuelve hacia fuera aún teniendo el > dns apuntando a un host interno. Asegúrate de configurar los registros del DNS conforme a la normativa y no duplicar los registros con datos que colisionen. Saludos, -- Camaleón -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/pan.2014.04.07.14.26...@gmail.com
Re: [OFF-TOPIC] Comando para hacer discovery dns en la red
El 7 de abril de 2014, 15:39, Camaleón escribió:
> El Mon, 07 Apr 2014 12:49:21 +0200, Maykel Franco escribió:
>
> > Hola buenas, quería saber si existe algún comando en linux para saber
> > cuántos dns hay en una red. Hacer un discovery y ver los que hay.
> >
> > Esto me ha surgido porque en mi red local tenemos un dns que a veces no
> > resuelve bien internamente y resuelve hacia fuera, por ejemplo:
> >
> > mail.example.com --> 192.168.1.33
> >
> > Pues algunas veces, pasa en los equipos aleatoriamente(tanto windows,
> > como linux como mac), que otras veces te saca por fuera a la ip pública:
> >
> > mail.example.com --> 82.14.55.33 (es un ejemplo con una ip ficticia)
> >
> > Y siempre pasa lo mismo, reinicias la red en el SO o quitas el cable y
> > vuelves a conectarlo y ya vuelve a resolver bienLimpiando muchas
> > veces la cache del navegador claro... Y a veces cuesta un montón que
> > vuelva a resolver bien internamente.
>
> Independientemente de tu pregunta, se debe corregir ese comportamiento ya
> que dudo mucho que venga por iniciativa del servidor DNS, más bien parece
> una mala configuración o colisión de los registros de algún dominio
> ("mail.example.com" está gestionado por vosotros, y es local o remoto y
> accesible desde Internet?).
>
> > Entonces creo que puede ser por 2 cosas, 1 que el dnsmasq a veces no
> > resuelva bien internamente
>
> Si no resuleve bien puede ser por un bug (que para la situación que
> comentas sería un poco raro) o por una mala configuración.
>
> > y 2 que haya otro dns por la red...
>
> Aún así. Ningún servidor DNS puede devolver una respuesta que no exista y
> si dos servidores DNS devuelven distintas respuestas para un mismo host
> es que existe una configuración errónea.
>
> > Pero claro, según las redes si a tí el dhcp te da una ip, con una
> > gateway y con un dns en teoría debería de irse a ese dns asignado
> > siempre para consultar, y aunque hubiera otro dns en la red, no tendría
> > nada que ver ni interferir con el otro dns...
> >
> > Qué opináis??
>
> Ejecuta "dig -t any example.com" desde todos los equipos que presenten
> discrepancias en cuanto a los registros DNS de un mismo dominio.
>
> Saludos,
>
> --
> Camaleón
>
>
> --
> To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact
> listmas...@lists.debian.org
> Archive: https://lists.debian.org/pan.2014.04.07.13.39...@gmail.com
>
>
Estoy de acuerdo, 2 dns no tienen colisión entre sí. Pero es muy extraño.
Sí es verdad muchos de los dominios están tanto dentro accesibles como
fuera, pero es que no tiene nada más... Funciona bien, resuelve por dentro
y alomejor a las 2 semanas de repente vas a acceder y se va por fuera... y
claro el firewall tiene bloqueada las conexiones que intentas acceder desde
dentro y salen hacia afuera para volver a entrar...
Además teniendo un dns en la red para que vas a salir por fuera y a volver
a entrar si puedes hacerlo internamente?? Mejor hacerlo internamente, más
seguro y más rápido. Y en cuanto reinicias la red del equipo, vuelve a
funcionar, a veces le cuesta un poco más pero acaba resolviendo... Esto
lleva pasando desde que hicimos un update de nuestro firewall.
Voy a probar a montar un servidor dns desde 0, exportando en un xml todos
los dns internos que tenemos e importándolos en el nuevo dns. Si sigue
pasando está claro que hay algo raro, sino sigue pasando es que es el dns
del firewall que a veces resuelve hacia fuera aún teniendo el dns
apuntando a un host interno.
Saludos.
Re: [OFF-TOPIC] Comando para hacer discovery dns en la red
El Mon, 07 Apr 2014 12:49:21 +0200, Maykel Franco escribió:
> Hola buenas, quería saber si existe algún comando en linux para saber
> cuántos dns hay en una red. Hacer un discovery y ver los que hay.
>
> Esto me ha surgido porque en mi red local tenemos un dns que a veces no
> resuelve bien internamente y resuelve hacia fuera, por ejemplo:
>
> mail.example.com --> 192.168.1.33
>
> Pues algunas veces, pasa en los equipos aleatoriamente(tanto windows,
> como linux como mac), que otras veces te saca por fuera a la ip pública:
>
> mail.example.com --> 82.14.55.33 (es un ejemplo con una ip ficticia)
>
> Y siempre pasa lo mismo, reinicias la red en el SO o quitas el cable y
> vuelves a conectarlo y ya vuelve a resolver bienLimpiando muchas
> veces la cache del navegador claro... Y a veces cuesta un montón que
> vuelva a resolver bien internamente.
Independientemente de tu pregunta, se debe corregir ese comportamiento ya
que dudo mucho que venga por iniciativa del servidor DNS, más bien parece
una mala configuración o colisión de los registros de algún dominio
("mail.example.com" está gestionado por vosotros, y es local o remoto y
accesible desde Internet?).
> Entonces creo que puede ser por 2 cosas, 1 que el dnsmasq a veces no
> resuelva bien internamente
Si no resuleve bien puede ser por un bug (que para la situación que
comentas sería un poco raro) o por una mala configuración.
> y 2 que haya otro dns por la red...
Aún así. Ningún servidor DNS puede devolver una respuesta que no exista y
si dos servidores DNS devuelven distintas respuestas para un mismo host
es que existe una configuración errónea.
> Pero claro, según las redes si a tí el dhcp te da una ip, con una
> gateway y con un dns en teoría debería de irse a ese dns asignado
> siempre para consultar, y aunque hubiera otro dns en la red, no tendría
> nada que ver ni interferir con el otro dns...
>
> Qué opináis??
Ejecuta "dig -t any example.com" desde todos los equipos que presenten
discrepancias en cuanto a los registros DNS de un mismo dominio.
Saludos,
--
Camaleón
--
To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/pan.2014.04.07.13.39...@gmail.com
Re: [OFF-TOPIC] Comando para hacer discovery dns en la red
El lun, 07-04-2014 a las 12:49 +0200, Maykel Franco escribió: > Hola buenas, quería saber si existe algún comando en linux para saber > cuántos dns hay en una red. Hacer un discovery y ver los que hay. > > Esto me ha surgido porque en mi red local tenemos un dns que a veces > no resuelve bien internamente y resuelve hacia fuera, por ejemplo: > > mail.example.com --> 192.168.1.33 > > Pues algunas veces, pasa en los equipos aleatoriamente(tanto windows, > como linux como mac), que otras veces te saca por fuera a la ip > pública: > > mail.example.com --> 82.14.55.33 (es un ejemplo con una ip ficticia) > > Y siempre pasa lo mismo, reinicias la red en el SO o quitas el cable y > vuelves a conectarlo y ya vuelve a resolver bienLimpiando muchas > veces la cache del navegador claro... Y a veces cuesta un montón que > vuelva a resolver bien internamente. > > Entonces creo que puede ser por 2 cosas, 1 que el dnsmasq a veces no > resuelva bien internamente y 2 que haya otro dns por la red... > > Pero claro, según las redes si a tí el dhcp te da una ip, con una > gateway y con un dns en teoría debería de irse a ese dns asignado > siempre para consultar, y aunque hubiera otro dns en la red, no > tendría nada que ver ni interferir con el otro dns... > > Qué opináis?? > > Saludos. > > nmap -p 53 192.168.1.0/24 (o la dirección de tu lan). De todas maneras, si hay otro dns escuchando, no debería ser historia a menos que le digas a una computadora que escuche en ese otro dns. O estén haciendo esto de dns poisoning Otra opción y me pasó una vez, fue que enchufaron un wifi... pero no conectaron en la boca "wan" de ese router, sino una de las lan, entonces el dhcp de ese wifi hizo desastres en la red, porque tenía dos dhcp respondiendo (el bueno, y el de ese router) -- (-.(-.(-.(-.(-.(-.-).-).-).-).-).-) -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1396875199.2447.3.ca...@eeepc.ucasal.ar
[OFF-TOPIC] Comando para hacer discovery dns en la red
Hola buenas, quería saber si existe algún comando en linux para saber cuántos dns hay en una red. Hacer un discovery y ver los que hay. Esto me ha surgido porque en mi red local tenemos un dns que a veces no resuelve bien internamente y resuelve hacia fuera, por ejemplo: mail.example.com --> 192.168.1.33 Pues algunas veces, pasa en los equipos aleatoriamente(tanto windows, como linux como mac), que otras veces te saca por fuera a la ip pública: mail.example.com --> 82.14.55.33 (es un ejemplo con una ip ficticia) Y siempre pasa lo mismo, reinicias la red en el SO o quitas el cable y vuelves a conectarlo y ya vuelve a resolver bienLimpiando muchas veces la cache del navegador claro... Y a veces cuesta un montón que vuelva a resolver bien internamente. Entonces creo que puede ser por 2 cosas, 1 que el dnsmasq a veces no resuelva bien internamente y 2 que haya otro dns por la red... Pero claro, según las redes si a tí el dhcp te da una ip, con una gateway y con un dns en teoría debería de irse a ese dns asignado siempre para consultar, y aunque hubiera otro dns en la red, no tendría nada que ver ni interferir con el otro dns... Qué opináis?? Saludos. -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/caj2aoa_gk+qlpfvg4fi-v3mc7hgft95iy3vn7d3qvzerfbe...@mail.gmail.com
