Re: [OFF-TOPIC] Comando para hacer discovery dns en la red
El día 8 de abril de 2014, 15:14, Camaleón <noelamac@gmail.com> 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 <noelamac@gmail.com>
>> 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 192.168.1.33
;; Query time: 2 msec
;; SERVER: 192.168.1.200#53(192.168.1.200)
;; WHEN: Tue Apr 8 15:23:07 2014
;; MSG SIZE rcvd: 50
>
>> Seguiré investigando, gracias Camaleón por todo.
>
> Ya contarás.
>
> Saludos,
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.
>
> --
> Camaleón
Gracias.
Saludos.
>
>
> --
> To UNSUBSCRIBE, email to debian-user-spanish-REQUEST@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
> Archive: pan.2014.04.08.13.14.43@gmail.com">https://lists.debian.org/pan.2014.04.08.13.14.43@gmail.com
>
Reply to: