[opensuse-es] Consultas DNS mediante TCP
Hola a tod@s: Por lo general, las consultas DNS se realizan mediante protocolo UDP, pero debido a unos requerimientos que tengo para una aplicación que funciona en red, necesito que dichas consultas se hagan OBLIGATORIAMENTE mediante protocolo TCP, para ello he echado mano de éste programa: http://www.phys.uu.nl/~rombouts/pdnsd.html Pero lo que veo es que cuando hago una consulta de dominio (dig www.google.com) la petición se hace mediante UDP y me da respuestas indeseadas, pero si ajusto la consulta (dig +vc www.google.com) me da las respuestas que necesito. Mi gran preguntas es: "¿Cómo puedo lograr que las consultas al servidor DNS que uso, se realicen EXCLUSIVAMENTE por protocolo TCP?". Quedo atento a sus comentarios/indicaciones/sugerencias. Cordialmente, Cuervo Linuxero -- No recibo/envío información elaborados en/para M$-Word, M$-Excel, M$-PowerPoint, M$-Outlook o formatos privativos similares. Le invito a leer mis razones: http://www.gnu.org/philosophy/no-word-attachments.es.html -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2009-02-26 a las 21:46 -0500, RŌNIN escribió:
Por lo general, las consultas DNS se realizan mediante protocolo UDP, pero debido a unos requerimientos que tengo para una aplicación que funciona en red, necesito que dichas consultas se hagan OBLIGATORIAMENTE mediante protocolo TCP, para ello he echado mano de éste programa: http://www.phys.uu.nl/~rombouts/pdnsd.html
Pero lo que veo es que cuando hago una consulta de dominio (dig www.google.com) la petición se hace mediante UDP y me da respuestas indeseadas, pero si ajusto la consulta (dig +vc www.google.com) me da las respuestas que necesito.
Mi gran preguntas es: "¿Cómo puedo lograr que las consultas al servidor DNS que uso, se realicen EXCLUSIVAMENTE por protocolo TCP?".
Quedo atento a sus comentarios/indicaciones/sugerencias.
Que yo sepa, el protocolo especifica que se usará udp excepto si el tamaño de la respuesta excede el limite de la mayor respuesta posible via udp. Creo que la consulta se inicia mediante udp, falla, y entonces se repite mediante tcp. No creo que puedas forzar el tipo de respuesta que te den los servidores a tí. ¿Porqué quieres hacerlo siempre con tcp? http://en.wikipedia.org/wiki/Domain_Name_System Protocol details DNS primarily uses UDP on port 53 [8] to serve requests. Almost all DNS queries consist of a single UDP request from the client followed by a single UDP reply from the server. TCP comes into play only when the response data size exceeds 512 bytes, or for such tasks as zone transfer. Some operating systems such as HP-UX are known to have resolver implementations that use TCP for all queries, even when UDP would suffice. - -- Saludos Carlos E.R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkmnV/YACgkQtTMYHG2NR9XGagCdGwsoHJWJACGfasPo5ZPxW4jg mVcAnRsgdZCThk7dW8DyIxydGVBIjRWa =W7YZ -----END PGP SIGNATURE-----
El 2009-02-26 a las 21:46 -0500, RŌNIN escribió:
Por lo general, las consultas DNS se realizan mediante protocolo UDP, pero debido a unos requerimientos que tengo para una aplicación que funciona en red, necesito que dichas consultas se hagan OBLIGATORIAMENTE mediante protocolo TCP, para ello he echado mano de éste programa: http://www.phys.uu.nl/~rombouts/pdnsd.html
Pero lo que veo es que cuando hago una consulta de dominio (dig www.google.com) la petición se hace mediante UDP y me da respuestas indeseadas, pero si ajusto la consulta (dig +vc www.google.com) me da las respuestas que necesito.
Mi gran preguntas es: "¿Cómo puedo lograr que las consultas al servidor DNS que uso, se realicen EXCLUSIVAMENTE por protocolo TCP?".
Se supone que ese programa puede ejecutar consultas mediante el protocolo especificado. Pero ojo, es el mismo programa quien ejecuta la consulta mediante tcp (según lo definas). Dig seguirá utilizando el protocolo predeterminado. Así lo veo: dig (udp/53) -> pdnsd (tcp/53) -> resolución Según el manual, se puede hacer de dos formas: - Definirlo en el valor "query_method" http://www.phys.uu.nl/~rombouts/pdnsd/doc.html#querymethod - Lanzar el programa con el modificador "-mto" <http://www.phys.uu.nl/~rombouts/pdnsd/doc.html#querymethodcommandlineopt ion> Una vez configurado y funcionando, lanza un tcpdump cuando ejecutes alguna consulta para comprobar que lo está haciendo correctamente. Si tiene algún registro que puedas consultar, revísalo. Hum... me pregunto si bind9 tendrá alguna opción similar :-? Saludos, -- Camaleón -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
El día 26 de febrero de 2009 22:03, Carlos E. R. escribió:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Que yo sepa, el protocolo especifica que se usará udp excepto si el tamaño de la respuesta excede el limite de la mayor respuesta posible via udp. Creo que la consulta se inicia mediante udp, falla, y entonces se repite mediante tcp.
Tengo entendido que cambia de UDP a TCP cuando la respuesta excede los 512 bits.
No creo que puedas forzar el tipo de respuesta que te den los servidores a tí.
¿Porqué quieres hacerlo siempre con tcp?
Disculpa si me equivoco en la afirmación, pero creo que no es tanto la respuesta del servidor como la consulta al servidor DNS, la que quiero enviar por protocolo TCP; esto porque he agregado una línea en el archivo /etc/sysctl.conf (net.ipv4.tcp_syn_retries = 2), para modificar los tiempos de espera de red para una aplicación que utilizo en modo cliente/servidor. Dichos tiempos están puestos a 180 segundos de manera predeterminada (net.ipv4.tcp_syn_retries = 5, se puede ver consultando en /proc/sys/net/ipv4/tcp_syn_retries), pero al cambiar el valor como lo he hecho, he logrado reducir los tiempos a 20 segundos. Según lo que entiendo, esta modificación solo aplica al tráfico/peticiones TCP y si tomamos en cuenta que las consultas DNS se hacen por UDP, los tiempos que requiero pasan de 20 segundos a 40 segundos ... y ahí se me genera el problema que trato de resolver. Aunque también encontré que por seguridad, es recomendable hacer consultas DNS usando protocolo TCP (http://www.securitybydefault.com/2008/07/dns-pasat-al-tcp.html). Esas serían mis razones para querer realizar las consultas DNS mediante procolo TCP (pero aún no estoy seguro de cómo lograrlo), gracias por tu tiempo e interés. Quedo a la espera de sus comentarios/indicaciones/sugerencias. Cordialmente, Cuervo Linuxero -- No recibo/envío información elaborados en/para M$-Word, M$-Excel, M$-PowerPoint, M$-Outlook o formatos privativos similares. Le invito a leer mis razones: http://www.gnu.org/philosophy/no-word-attachments.es.html -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
2009/2/27 RŌNIN
El día 26 de febrero de 2009 22:03, Carlos E. R. escribió:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
[....]
Disculpa si me equivoco en la afirmación, pero creo que no es tanto la respuesta del servidor como la consulta al servidor DNS, la que quiero enviar por protocolo TCP; esto porque he agregado una línea en el archivo /etc/sysctl.conf (net.ipv4.tcp_syn_retries = 2), para modificar los tiempos de espera de red para una aplicación que utilizo en modo cliente/servidor.
modificar tiempos de espera ?? "net.ipv4.tcp_syn_retries" sirve para configurar "cuantas reintentos" se hara para intentar establecer una conexcion... ojo... que esto se aplica a "todo" el trafico tcp y no solamente para las consultas DNS o otra en particular.. [...]
Según lo que entiendo, esta modificación solo aplica al tráfico/peticiones TCP y si tomamos en cuenta que las consultas DNS se hacen por UDP, los tiempos que requiero pasan de 20 segundos a 40 segundos ... y ahí se me genera el problema que trato de resolver. Aunque también encontré que por seguridad, es recomendable hacer consultas DNS usando protocolo TCP (http://www.securitybydefault.com/2008/07/dns-pasat-al-tcp.html).
Esas serían mis razones para querer realizar las consultas DNS mediante procolo TCP (pero aún no estoy seguro de cómo lograrlo), gracias por tu tiempo e interés.
Quedo a la espera de sus comentarios/indicaciones/sugerencias.
pero que demonios estas intentando hacer exactamente ?? - por que no te sirven exactamente el UDP ??' - comentas en el primer correo que con UDP te da una respuesta y con TCP te da otra respuesta ??? de que hablas ?? si estas consultando al mismo servidor.. la respuesta debería de ser la misma (independiente si es TCP o UDP) - se lo que buscas es tiempo de respuesta mas rápido (por los cambios que hiciste en la configuracion TCP y que creo te ira generar mayores problemas)...entonces: 1 - vas por el camino mas equivocado utilizando TCP al inves de UDP... 2 - puedes poner un servidor DNS cache mas cercano a tu aplicacion 3 - a no ser que los registros DNS se cambien a cada 30 segundos.. puedes aumentar el TTL de los registros y asi la informacion quedara en la cache de los clientes (aca., tu aplicaron) mucho mas tiempo y hará menos consulta al servidor DNS. la verdad es que no explica bien que quieres y/o el problema que tienes y intenta soluciones "extranas" para problemas que podrian ser muy sencillos.. recomiendo que explique detalladamente tu situacion. salu2 y suerte. -- -- Victor Hugo dos Santos Linux Counter #224399 -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
Hola a tod@s: El día 27 de febrero de 2009 12:20, Victor Hugo dos Santos escribió: Hay que ver lo que la prisa de la mañana y el cansancio de una mala noche logran cuando tratas de expresar tus ideas y todo se confunde, espero que con éste mensaje todo sea más sencillo.
modificar tiempos de espera ?? "net.ipv4.tcp_syn_retries" sirve para configurar "cuantas reintentos" se hara para intentar establecer una conexcion... ojo... que esto se aplica a "todo" el trafico tcp y no solamente para las consultas DNS o otra en particular..
Bien, esto es así: la aplicación que comento, trabaja en modo cliente/servidor y cuando pierde la conexión con la red o pierde contacto con los servidores (por caída del DNS, por ejemplo), tarda 40 segundos (o hasta más) en notificar al operador de la computadora que va a pasar a funcionar en modo off-line. He notado que la alerta de notificación opera en función de los reintentos (por eso reajusté el valor predeterminado) y necesito que la alerta se active en el menor tiempo posible (Otorgarle más tiempo me dilata otros procesos y la acumulación de tiempos me entorpece la operación).
pero que demonios estas intentando hacer exactamente ??
Trato que el sistema operativo le informe a la aplicación que ha perdido contacto con el servidor ... en el menor tiempo posible.
- por que no te sirven exactamente el UDP ??'
Porque hasta donde he ensayado, sólo reduciendo la cantidad de reintentos de TCP logro reducir los tiempos en que el sistema operativo informa que no puede contactar a una computadora en especial (que por lo general es de 40 segundos).
- comentas en el primer correo que con UDP te da una respuesta y con TCP te da otra respuesta ??? de que hablas ?? si estas consultando al mismo servidor.. la respuesta debería de ser la misma (independiente si es TCP o UDP)
Aquí metí la pata, por respuesta no quise que entendieran datos, sino tiempos. Veamos: si hago una consulta normal al servidor, teniendo la computadora desconectada de la red (dig miservidor.midominio.com), el mensaje de fallo tarda 40 segundos en aparecer; si la hago con la computadora desconectada y teniendo instalado el programa pdnsd (del cual hablé en mi primer mensaje - dig +vc miservidor.midominio.com), el mensaje de fallo tarda 15 segundos en aparecer.
- se lo que buscas es tiempo de respuesta mas rápido (por los cambios que hiciste en la configuracion TCP y que creo te ira generar mayores problemas)...entonces: 1 - vas por el camino mas equivocado utilizando TCP al inves de UDP... 2 - puedes poner un servidor DNS cache mas cercano a tu aplicacion 3 - a no ser que los registros DNS se cambien a cada 30 segundos.. puedes aumentar el TTL de los registros y asi la informacion quedara en la cache de los clientes (aca., tu aplicaron) mucho mas tiempo y hará menos consulta al servidor DNS.
la verdad es que no explica bien que quieres y/o el problema que tienes y intenta soluciones "extranas" para problemas que podrian ser muy sencillos.. recomiendo que explique detalladamente tu situacion.
Espero haberme explicado mejor ésta vez, si no lo he logrado, sólo dímelo y lo intento nuevamente. Y si has logrado entender lo que quiero y tienes una mejor manera de hacerlo que como lo vengo haciendo, estaré más agradecido. Gracias por tu tiempo e interés. Quedo a la espera de sus sugerencias, comentarios, indicaciones. Cordialmente, Cuervo Linuxero -- No recibo/envío información elaborados en/para M$-Word, M$-Excel, M$-PowerPoint, M$-Outlook o formatos privativos similares. Le invito a leer mis razones: http://www.gnu.org/philosophy/no-word-attachments.es.html -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
2009/2/27 RŌNIN
Hola a tod@s:
[...]
Bien, esto es así: la aplicación que comento, trabaja en modo cliente/servidor y cuando pierde la conexión con la red o pierde contacto con los servidores (por caída del DNS, por ejemplo), tarda 40 segundos (o hasta más) en notificar al operador de la computadora que va a pasar a funcionar en modo off-line. He notado que la alerta de notificación opera en función de los reintentos (por eso reajusté el valor predeterminado) y necesito que la alerta se active en el menor tiempo posible (Otorgarle más tiempo me dilata otros procesos y la acumulación de tiempos me entorpece la operación).
mmmm.. entiendo tu problema ahora.. pero la verdad es que todo parece muy extrano !!!! que tipo de conexciones tienes ??? como estas comprobando que no existe conexcion ?? haces un dig ?? un ping ?? la aplicacion la hizo usted ?? tienes los codigos ?? puedes modificarla ?? por que esto del timeout/desconexcion deberia de ser configurable en la aplicacion y no en el sistema operativo.. creame cuando te digo, que si vas a jugar con la configuracion del TCP/UDP tendras muchos mas problemas que solucciones !!! creame !!:D entonces, deberias de ver como modificar la "applicacion" para detectar que no hay conexcion !! yo intentaria con un simples ping (ver los parametros "-W" y "-c" en el man) por cierto.. que tu dig ya presenta algo malo !!! por defecto los valores en dig son: ========= +time=T Sets the timeout for a query to T seconds. The default timeout is 5 seconds. An attempt to set T to less than 1 will result in a query timeout of 1 second being applied. +tries=T Sets the number of times to try UDP queries to server to T instead of the default, 3. If T is less than or equal to zero, the number of tries is silently rounded up to 1. +retry=T Sets the number of times to retry UDP queries to server to T instead of the default, 2. Unlike +tries, this does not include the initial query. ========= o sea.. en el peor de los casos deberia tener un timeout a los 15 segundos, por ejemplo: ========= time dig @208.69.39.2 +time=1 google.com +short ; <<>> DiG 9.5.1-P1 <<>> @208.69.39.2 +time=1 google.com +short ; (1 server found) ;; global options: printcmd ;; connection timed out; no servers could be reached real 0m3.009s user 0m0.004s sys 0m0.008s $ time dig @208.69.39.2 +time=5 google.com +short ; <<>> DiG 9.5.1-P1 <<>> @208.69.39.2 +time=5 google.com +short ; (1 server found) ;; global options: printcmd ;; connection timed out; no servers could be reached real 0m15.009s user 0m0.004s sys 0m0.008s ========= como puedes ver.. en el primer ejemplo..se demora 3 segundos y en el segudo (que es el valor por defecto) se demora 15 segundos.
pero que demonios estas intentando hacer exactamente ??
Trato que el sistema operativo le informe a la aplicación que ha perdido contacto con el servidor ... en el menor tiempo posible.
Insisto.. esto es algo que la aplicacion deberia de hacer.. pero explicanos como comprobas que la red esta abajo .. y en una de estas (caso no puedas modificar la aplicacion) la solucion es tan simples como crear un alias para el comando que comproba la conexcion, por ejemplo: si comprobas con ping: alias ping="ping -c 1 -W1" si comprobas con dig: alias dig="dig +time=1 +retry=1" salu2 -- -- Victor Hugo dos Santos Linux Counter #224399 -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
El día 27 de febrero de 2009 15:43, Victor Hugo dos Santos escribió:
mmmm.. entiendo tu problema ahora.. pero la verdad es que todo parece muy extrano !!!!
que tipo de conexciones tienes ??? como estas comprobando que no existe conexcion ?? haces un dig ?? un ping ?? la aplicacion la hizo usted ?? tienes los codigos ?? puedes modificarla ??
Conexiones: WAN corporativa ... Comprobación: la aplicación abre un socket para enviar información a un servidor central, si por alguna razón (conexión de red interrumpida, DNS fuera de servicio, etc) no logra contactar con el servidor, aparece una alerta en pantalla que indica al operador que va a continuar trabajando en modo off-line (Hasta que logre contactar nuevamente con el servidor). El dig y el ping lo hago solo durante las pruebas de ajuste, para comprobar cuánto demora en indicarme que el servidor que busco, no está disponible (Lo hago desconectando la computadora desde donde hago la prueba, ésta desconexión la hago intencionalmente). Podría modificar la aplicación, pero no veo el sentido ... sencillamente, ella espera una respuesta del sistema operativo y activa el evento de la alarma, creo que hasta ahí todo está bien; lo que requiero es que la respuesta del sistema operativo sea igual o inferior a 20 segundos.
por que esto del timeout/desconexcion deberia de ser configurable en la aplicacion y no en el sistema operativo.. creame cuando te digo, que si vas a jugar con la configuracion del TCP/UDP tendras muchos mas problemas que solucciones !!! creame !!:D
Así es, tengo timeouts en cada evento de la aplicación que se relaciona con la red ... pero igual, las reacciones siguen basándose en las respuestas (y la celeridad de las mismas) del sistema operativo.
entonces, deberias de ver como modificar la "applicacion" para detectar que no hay conexcion !! yo intentaria con un simples ping (ver los parametros "-W" y "-c" en el man)
No me basta un ping, pues comprenderás que si lo hago permanente, saturo la red y si los programo y llega a interrumpirse la conexión en algún intervalo no previsto, no me serán de mucha utilidad.
por cierto.. que tu dig ya presenta algo malo !!! por defecto los valores en dig son:
[...]
como puedes ver.. en el primer ejemplo..se demora 3 segundos y en el segudo (que es el valor por defecto) se demora 15 segundos.
Es cierto, como las consultas que hago se refieren a dominios internos, ahora me surge la duda si el problema está en el DNS, en el protocolo, o en la red ... menudo lío !!!.
Insisto.. esto es algo que la aplicacion deberia de hacer.. pero explicanos como comprobas que la red esta abajo .. y en una de estas (caso no puedas modificar la aplicacion) la solucion es tan simples como crear un alias para el comando que comproba la conexcion, por ejemplo:
No, no hay comando que compruebe si la conexión está activa, sencillamente si la aplicación no puede contactar al servidor para enviar/recibir datos, existe un evento que espera que el sistema operativo le informe que no hay contacto con el servidor requerido (lo que me está tardando 40 segundos y requiero que me tarde la mitad de ese tiempo, o menos) y al recibir ese informe, muestra un aviso al operador, que pasará a operar en modo off-line y se activa otro evento que queda a la espera que el sistema operativo le informe que ha podido contactar con el servidor principal, luego de lo cual, la aplicación procederá a transmitir la información almacenada durante el tiempo que estuvo operando en modo off-line. Espero con ésto, haber dado más claridad a lo que requiero hacer, para enfocar mejor la ayuda. Gracias por tu tiempo e interés. Quedo a la espera de sus comentarios/sugerencias/indicaciones. Cordialmente, Cuervo Linuxero -- No recibo/envío información elaborados en/para M$-Word, M$-Excel, M$-PowerPoint, M$-Outlook o formatos privativos similares. Le invito a leer mis razones: http://www.gnu.org/philosophy/no-word-attachments.es.html -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
2009/2/27 RŌNIN
El día 27 de febrero de 2009 15:43, Victor Hugo dos Santos escribió:
[...]
Podría modificar la aplicación, pero no veo el sentido ... sencillamente, ella espera una respuesta del sistema operativo y activa el evento de la alarma, creo que hasta ahí todo está bien; lo que requiero es que la respuesta del sistema operativo sea igual o inferior a 20 segundos.
mmm.. claro que hay sentido... se puedes modificar la aplicacion, entonces puedes especificar el valor del timeouy.. en que esta programada (perl, c, phyton) ?? como abres el socket ??? [...]
No me basta un ping, pues comprenderás que si lo hago permanente, saturo la red y si los programo y llega a interrumpirse la conexión en algún intervalo no previsto, no me serán de mucha utilidad.
no necesariamente... puedes programar un ping de un solo paquete a cada 10 segundos por ejemplo..en caso de fallo se disminui a 5... y enviar un paquete echo requeste por la red (mismo en una WAN) no es un consumo que deberia de preocuparte, hay cuellos de botella peores.
Es cierto, como las consultas que hago se refieren a dominios internos, ahora me surge la duda si el problema está en el DNS, en el protocolo, o en la red ... menudo lío !!!.
pasa en todo los equipos ??? ya probaste desde un puesto distinto en la WAN ?? tambien puedes probar con el parametro +trace para ver donde esta el cuello de botella/problema.
No, no hay comando que compruebe si la conexión está activa, sencillamente si la aplicación no puede contactar al servidor para enviar/recibir datos, existe un evento que espera que el sistema operativo le informe que no hay contacto con el servidor requerido (lo que me está tardando 40 segundos y requiero que me tarde la mitad de ese tiempo, o menos) y al recibir ese informe, muestra un aviso al operador, que pasará a operar en modo off-line y se activa otro evento que queda a la espera que el sistema operativo le informe que ha podido contactar con el servidor principal, luego de lo cual, la aplicación procederá a transmitir la información almacenada durante el tiempo que estuvo operando en modo off-line.
envianos los codigos estes (lo que establece la conexcion) y lo damo una mirada.. demas que por aca, alguien podra darte una idea de como soluccionar el tema.
Espero con ésto, haber dado más claridad a lo que requiero hacer, para enfocar mejor la ayuda. Gracias por tu tiempo e interés.
si..ahora ya se entiende mucho mejor.. salu2 -- -- Victor Hugo dos Santos Linux Counter #224399 -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
Hola Tengo un Compaq proliant 2500 con 2 micros y 750 mb de ram. No logro hacer una instalación con suse 11.1, no dido q las otras distro sean buenas, pero hace 6 años q uso linux y no quiero cambiarla. Saludos desde Argentina Ariel Garcia Traba, Ariel H -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
El 2009-02-28 a las 15:19 -0200, Gerencia - Trading New Technologies S.A. escribió:
Tengo un Compaq proliant 2500 con 2 micros y 750 mb de ram. No logro hacer una instalación con suse 11.1, no dido q las otras distro sean buenas, pero hace 6 años q uso linux y no quiero cambiarla.
Si no dices qué te sucede exactamente, poco podremos hacer :-) Saludos, -- Camaleón -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
RŌNIN escribió:
pero debido a unos requerimientos que tengo
Que tal si arreglas los requerimientos ? -- "If this is the best God can do, I am not impressed" -George Carlin (1937-2008) Cristian Rodríguez R. Software Developer Platform/OpenSUSE - Core Services SUSE LINUX Products GmbH Research & Development http://www.opensuse.org/
El Viernes, 27 de Febrero de 2009, RŌNIN escribió:
Hola a tod@s:
Por lo general, las consultas DNS se realizan mediante protocolo UDP, pero debido a unos requerimientos que tengo para una aplicación que funciona en red, necesito que dichas consultas se hagan OBLIGATORIAMENTE mediante protocolo TCP, para ello he echado mano de éste programa: http://www.phys.uu.nl/~rombouts/pdnsd.html
Pero lo que veo es que cuando hago una consulta de dominio (dig www.google.com) la petición se hace mediante UDP y me da respuestas indeseadas, pero si ajusto la consulta (dig +vc www.google.com) me da las respuestas que necesito.
Mi gran preguntas es: "¿Cómo puedo lograr que las consultas al servidor DNS que uso, se realicen EXCLUSIVAMENTE por protocolo TCP?".
* Tcp se utiliza para las transferencias de zonas y excepcionalmente para tamaños de trama lo que evita consultas a los root servers, es decir es "obligatorio" tenerlo disponible, actualmente se esta obligando a este tipo de consulta, como medida de seguridad ante el problema, recientemente descubierto, en el protocolo. * Cierra en el cortafuegos del servidor UDP 53 y abre el tcp 53 , borra de /etc/services la linea domain para UDP, sobre todo en los clientes.
2009/3/3 jose maria
* Tcp se utiliza para las transferencias de zonas y excepcionalmente para tamaños de trama lo que evita consultas a los root servers, es decir es "obligatorio" tenerlo disponible, actualmente se esta obligando a este tipo de consulta, como medida de seguridad ante el problema, recientemente descubierto, en el protocolo.
* Cierra en el cortafuegos del servidor UDP 53 y abre el tcp 53 , borra de /etc/services la linea domain para UDP, sobre todo en los clientes.
nooo.. no funciona asi !!! :-( vea: en el servidor bloqueo el puerto 53 udp para mi IP (segunda linea) ============= $sudo iptables -L -n | grep "dpt:53" REJECT udp -- 172.16.100.150 0.0.0.0/0 udp dpt:53 reject-with icmp-port-unreachable allowed tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:53 ACCEPT udp -- 0.0.0.0/0 0.0.0.0/0 udp dpt:53 ============= ahora, comento la linea que mencionas en /etc/services (en mi equipo) ============= $ cat /etc/services | grep domain domain 53/tcp # name-domain server #domain 53/udp ============= y hago una consulta al dominio: ============= $ dig @10.0.0.98 www.google.com ; <<>> DiG 9.5.1-P1 <<>> @10.0.0.98 www.google.com ; (1 server found) ;; global options: printcmd ;; connection timed out; no servers could be reached ============= se "especifico" que la consulta sea por TCP, entonces funciona: ============= $ dig @10.0.0.98 www.google.com +vc +short www.l.google.com. 209.85.195.104 209.85.195.99 ============= o sea: el cliente utiliza TCP una vez que el servidor indica que la respuesta a su consulta debe de ir por TCP porque el tamano maximo permitido supera el limite por UDP... pero el cliente antes necesita conectarse por UDP al servidor (a no ser que se especifique el contrario, como en el segun ejemplo).. pero solamente bloquear el UDP en el cortafuegos "no" funciona. salu2 -- -- Victor Hugo dos Santos Linux Counter #224399 -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
El 2009-03-03 a las 11:05 -0300, Victor Hugo dos Santos escribió:
2009/3/3 jose maria:
* Cierra en el cortafuegos del servidor UDP 53 y abre el tcp 53 , borra de /etc/services la linea domain para UDP, sobre todo en los clientes.
nooo.. no funciona asi !!! :-(
¿Y no es posible configurar el servidor dns para solicitar al cliente la consulta mediante tcp en el caso de que falle por udp? :-? Saludos, -- Camaleón -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2009-03-03 a las 16:00 +0100, Camaleón escribió:
El 2009-03-03 a las 11:05 -0300, Victor Hugo dos Santos escribió:
2009/3/3 jose maria:
* Cierra en el cortafuegos del servidor UDP 53 y abre el tcp 53 , borra de /etc/services la linea domain para UDP, sobre todo en los clientes.
nooo.. no funciona asi !!! :-(
¿Y no es posible configurar el servidor dns para solicitar al cliente la consulta mediante tcp en el caso de que falle por udp? :-?
Eso es lo que hace automáticamente. El proceso es (creo): - el cliente pregunta via udp. - el servidor le indica que por udp no puede, o que no cabe, no se exactamente; pero vaya, que falla. - el cliente repite la pregunta por tcp. - -- Saludos Carlos E.R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkmtTLcACgkQtTMYHG2NR9XCWgCdGhbUwGqEyRHimwaWTPXPag5Z eMEAniZgw3KF5M1X23DzfJsQNH45coyN =iBgA -----END PGP SIGNATURE-----
2009/3/3 Camaleón
El 2009-03-03 a las 11:05 -0300, Victor Hugo dos Santos escribió:
[...]
¿Y no es posible configurar el servidor dns para solicitar al cliente la consulta mediante tcp en el caso de que falle por udp? :-?
Desde la lista de bind =============
"Joe Baptista"
writes: Are there any configuration changes that can be made to BIND to force it to use TCP exclusively and never use UDP? Possible?
no. -- Paul Vixie =============
el hilo completo (son como 9) esta aca: https://lists.isc.org/pipermail/bind-users/2008-August/072099.html salu2 -- -- Victor Hugo dos Santos Linux Counter #224399 -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
El 2009-03-03 a las 12:33 -0300, Victor Hugo dos Santos escribió:
2009/3/3 Camaleón:
¿Y no es posible configurar el servidor dns para solicitar al cliente la consulta mediante tcp en el caso de que falle por udp? :-?
Desde la lista de bind
=============
"Joe Baptista"
writes: Are there any configuration changes that can be made to BIND to force it to use TCP exclusively and never use UDP? Possible?
no. -- Paul Vixie =============
el hilo completo (son como 9) esta aca: https://lists.isc.org/pipermail/bind-users/2008-August/072099.html
Pero no me refiero a eso. No se trata de forzar a bind a que use "sólo" un protocolo (eso iría en contra de su propia especificación), sino que cuando falle uno (udp) acepte el otro (tcp) en lugar de "cortar", que no es lo mismo. Estaba pensando en si la extesión edns (del mismo autor que citas) lo contemplaba: http://en.wikipedia.org/wiki/EDNS Saludos, -- Camaleón -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
2009/3/3 Camaleón
El 2009-03-03 a las 12:33 -0300, Victor Hugo dos Santos escribió:
2009/3/3 Camaleón:
¿Y no es posible configurar el servidor dns para solicitar al cliente la consulta mediante tcp en el caso de que falle por udp? :-?
[...]
Pero no me refiero a eso. No se trata de forzar a bind a que use "sólo" un protocolo (eso iría en contra de su propia especificación), sino que cuando falle uno (udp) acepte el otro (tcp) en lugar de "cortar", que no es lo mismo.
no te entiendo... cuando se supone que bind deberia de considerar que una consulta DNS fallo ??? - si hay un cortafuegos entre medio que bloquea el UDP, entonces bind nunca se enterara de ello. - si se configura BIND para que "indique" a los clientes que utilizen TCP al inves de UDP, entonces, seria despercio de tiempo/bytes, por que: 1 - cliente envia una solicitud UDP 2 - bind contesta que realize la consulta nuevamente por TCP 3 - cliente envia solicitudes TCP 4 - bind la contesta. en el paso 2.. ya deberia de ir la respuesta a la consulta que hizo el cliente... no hay sentido (al menos yo no lo veo) de indicarle al cliente que vaya por TCP siendo que la comunicacion UDP funciona.
Estaba pensando en si la extesión edns (del mismo autor que citas) lo contemplaba:
mmm. no la conocia.. pero lo que veo en el sitio que enviaste.. es que EDNS "aumenta" la utilizacion de UDP y no al reves. salu2 -- -- Victor Hugo dos Santos Linux Counter #224399 -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
El 2009-03-03 a las 14:17 -0300, Victor Hugo dos Santos escribió:
2009/3/3 Camaleón:
Pero no me refiero a eso. No se trata de forzar a bind a que use "sólo" un protocolo (eso iría en contra de su propia especificación), sino que cuando falle uno (udp) acepte el otro (tcp) en lugar de "cortar", que no es lo mismo.
no te entiendo... cuando se supone que bind deberia de considerar que una consulta DNS fallo ???
- si hay un cortafuegos entre medio que bloquea el UDP, entonces bind nunca se enterara de ello. - si se configura BIND para que "indique" a los clientes que utilizen TCP al inves de UDP, entonces, seria despercio de tiempo/bytes, por que: 1 - cliente envia una solicitud UDP 2 - bind contesta que realize la consulta nuevamente por TCP 3 - cliente envia solicitudes TCP 4 - bind la contesta.
La idea es que se le pueda decir al cliente que repita de nuevo en tcp, sí. Sí, es una pérdida de tráfico/tiempo pero a alguien le puede interesar (en un entorno contolado de lan, para pruebas, etc...). Sería una opción más.
en el paso 2.. ya deberia de ir la respuesta a la consulta que hizo el cliente... no hay sentido (al menos yo no lo veo) de indicarle al cliente que vaya por TCP siendo que la comunicacion UDP funciona.
La comunicación funciona, vale, pero no es la esperada por el servidor dns :-)
Estaba pensando en si la extesión edns (del mismo autor que citas) lo contemplaba:
mmm. no la conocia.. pero lo que veo en el sitio que enviaste.. es que EDNS "aumenta" la utilizacion de UDP y no al reves.
Aumenta el uso del udp si es lo que se quiere. Lo interesante es que admita la configuración de los marcadores (flags) para configurar la respuesta del servidor dns al cliente. La maldad que tengo en mente sería, por ejemplo, poder configurar el servidor dns para que tratara todos los paquetes (independientemente de su tamaño) para responder a través de TCP (forzando un flag TC ==> 1). Es decir, lo que ahora es un "SHOULD" en el RCF, convertirlo en "MUST" >:-) Saludos, -- Camaleón -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
Hola Tengo un Compaq proliant 2500 con 2 micros y 750 mb de ram. No logro hacer una instalación con suse 11.1, no dido q las otras distro sean buenas, pero hace 6 años q uso linux y no quiero cambiarla. Saludos desde Argentina Ariel Garcia Traba, Ariel H -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
Hola :) El Wednesday 04 March 2009, Gerencia - Trading New Technologies S.A. escribió:
Hola Tengo un Compaq proliant 2500 con 2 micros y 750 mb de ram. No logro hacer una instalación con suse 11.1, no dido q las otras distro sean buenas, pero hace 6 años q uso linux y no quiero cambiarla.
¿Qué problemas estas teniendo? ¿Qué es lo que no detecta? ¿Dónde se queda? ¿Mensajes de error? Rafa -- "We cannot treat computers as Humans. Computers need love." rgriman@skype.com -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
2009/3/4 Gerencia - Trading New Technologies S.A.
Hola Tengo un Compaq proliant 2500 con 2 micros y 750 mb de ram. No logro hacer una instalación con suse 11.1, no dido q las otras distro sean buenas, pero hace 6 años q uso linux y no quiero cambiarla. Saludos desde Argentina Ariel
No cuesta nada dar un poco más de información, no? Estoy seguro que ninguno de los que participa de la lista tiene los suficientes poderes de adivinación para saber que problema tenes ;-) -- Kind Regards -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
Si a ver... Mmmmmm !!!! Heeeeee !!!! AAAARRRRGGGGGHHHHH !!!!
Si si ya veo tu problema !!! Es el SysAdmin que no tiene idea de nada !!!
jajajajajjajajaj
Ahora fuera de broma, si no das mas datos como pretendes que te ayudemos ????
Saludos ! (Desde Argentian tambien) :-P
El día 4 de marzo de 2009 16:07, Gerencia - Trading New Technologies
S.A.
Hola Tengo un Compaq proliant 2500 con 2 micros y 750 mb de ram. No logro hacer una instalación con suse 11.1, no dido q las otras distro sean buenas, pero hace 6 años q uso linux y no quiero cambiarla. Saludos desde Argentina Ariel
Garcia Traba, Ariel H
-- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
-- Andrés (LuCkUnDeAd) Dobie Administrador de Redes y Sistemas A.M.C.C.E.J.B.P.B.A. Balcarce 302 Capital Federal andres.dobie@provebpba.com.ar luckundead@provebpba.com.ar andres.dobie@gmail.com -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
Mas datos La instalacion normal no funciona Hay que hacer "linux mem=exactmap mem=640k@0 mem=767m@1M " ya que es la totalidad de ram - 1 mega Así comienza aunque luego se freeza mientras otras distro continuan y se instalan Saludos A ------------------------ Hola Tengo un Compaq proliant 2500 con 2 micros y 750 mb de ram. No logro hacer una instalación con suse 11.1, no dido q las otras distro sean buenas, pero hace 6 años q uso linux y no quiero cambiarla. Saludos desde Argentina Ariel Garcia Traba, Ariel H -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
Hola :) El Wednesday 04 March 2009, Gerencia - Trading New Technologies S.A. escribió:
Mas datos La instalacion normal no funciona Hay que hacer "linux mem=exactmap mem=640k@0 mem=767m@1M " ya que es la totalidad de ram - 1 mega Así comienza aunque luego se freeza mientras otras distro continuan y se instalan Saludos
¿Y en qué punto se para? ¿Detección de discos? ¿Detección de la red? Haz una cosa, igual que le has pasado las opciones de memoria, pásale la opción: vga=normal Así, te aparecerá en pantalla todo lo que está haciendo el kernel y podrás decirnos el error que da o el punto en el que no continua. Otra opciones que pueden ser útiles son: acpi=off pci=nobios HTH Rafa
------------------------ Hola Tengo un Compaq proliant 2500 con 2 micros y 750 mb de ram. No logro hacer una instalación con suse 11.1, no dido q las otras distro sean buenas, pero hace 6 años q uso linux y no quiero cambiarla. Saludos desde Argentina Ariel
Garcia Traba, Ariel H
-- "We cannot treat computers as Humans. Computers need love." rgriman@skype.com -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
El Martes, 3 de Marzo de 2009, Victor Hugo dos Santos escribió:
2009/3/3 jose maria
: [...]
* Tcp se utiliza para las transferencias de zonas y excepcionalmente para tamaños de trama lo que evita consultas a los root servers, es decir es "obligatorio" tenerlo disponible, actualmente se esta obligando a este tipo de consulta, como medida de seguridad ante el problema, recientemente descubierto, en el protocolo.
* Cierra en el cortafuegos del servidor UDP 53 y abre el tcp 53 , borra de /etc/services la linea domain para UDP, sobre todo en los clientes.
nooo.. no funciona asi !!! :-( vea:
en el servidor bloqueo el puerto 53 udp para mi IP (segunda linea) ============= $sudo iptables -L -n | grep "dpt:53" REJECT udp -- 172.16.100.150 0.0.0.0/0 udp dpt:53 reject-with icmp-port-unreachable allowed tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:53 ACCEPT udp -- 0.0.0.0/0 0.0.0.0/0 udp dpt:53 =============
* 1.- Entonces no lo bloqueas bien, o en /etc/named.conf NO estas obligando a Dns a escuchar obligatoriamente en el 53, aqui y en sebastopol si en udp 53 no hay nada no se contesta nada.
ahora, comento la linea que mencionas en /etc/services (en mi equipo) ============= $ cat /etc/services | grep domain domain 53/tcp # name-domain server #domain 53/udp =============
y hago una consulta al dominio: ============= $ dig @10.0.0.98 www.google.com
; <<>> DiG 9.5.1-P1 <<>> @10.0.0.98 www.google.com ; (1 server found) ;; global options: printcmd ;; connection timed out; no servers could be reached =============
se "especifico" que la consulta sea por TCP, entonces funciona: ============= $ dig @10.0.0.98 www.google.com +vc +short www.l.google.com. 209.85.195.104 209.85.195.99 =============
* 2.- Dig es una herramienta y por tanto hace lo que le dices y si no le dices nada consulta a UDP primero, firefox no usa dig , pregunta al S.O. y este lee /etc/services ve cual es el protocolo "comunmente conocido" lee /etc/host.conf y si el orden es dns, files pues primero dns y luego /etc/hosts e ira al 53 tcp si la aplicacion no tiene implementado en su codigo la consulta dns, si lo tiene lo tendra segun el standard y alli en el udp 53 NO habra nada.
El Jueves, 5 de Marzo de 2009, jose maria escribió:
El Martes, 3 de Marzo de 2009, Victor Hugo dos Santos escribió:
* En pdnsd, ./configure --with-query-method=tcponly * Si quieres que tu servidor solo haga consultas por tcp (mala idea los otros pueden no admitir tcp) ./configure --disable-udp-queries
El Miércoles, 4 de Marzo de 2009, Gerencia - Trading New Technologies S.A. escribió:
Hola Tengo un Compaq proliant 2500 con 2 micros y 750 mb de ram. No logro hacer una instalación con suse 11.1, no dido q las otras distro sean buenas, pero hace 6 años q uso linux y no quiero cambiarla. Saludos desde Argentina Ariel
* En la seleccion de software prueba con el kernel-default y no el pae, que este no se que le pasa pero pae-ce que tiene diversas incompatibilidades, me ha dado problemas en varios servidores, entiendo que "750 mb" de ram es lo que querias decir y no 7500.
participants (10)
-
Andres Alejandro Dobie
-
Camaleón
-
Carlos E. R.
-
Cristian Rodríguez
-
Gabriel
-
Gerencia - Trading New Technologies S.A.
-
jose maria
-
Rafa Grimán
-
RŌNIN
-
Victor Hugo dos Santos