@krocz | * krocz changes topic to 'UMeet'2005, next talk: 21:00 GMT Sebastian
Castro: "Operacion de un DNS" || #redes -> english transtation || #qc -> preguntas
y comentarios'
|
@krocz | Buenas tardes a toda la gente
|
@krocz | hemos llegado a la ultima charla de este año
|
@krocz | de Umeet'2005
|
@krocz | gracias a todos por asistir y colaborar
|
@krocz | desinteresadamente en este proyecto
|
@krocz | Nuestro siguiente exponente se llama Sebastian Castro
|
@krocz | El es profesor de Universidad de Chile y es uno de los
administradores de NIC Chile
|
@krocz | ha participado en numerosas conferencias y asiduo usuario de
software libre
|
@krocz | Ha sido el pionero de la adopcion, en Chile, de DNS Security
Extensions (DNSSEC)
|
@krocz | dejo con ustedes a Sebastian Castro
|
@krocz | Sebastian todo tuyo el canal
|
@Sebastian | perfecto, gracias por la introduccion
|
@Sebastian | con tantos pergaminos, no estoy seguro de que esten
hablando de mi
|
@Sebastian | voy a apoyar mi presentacion con un set de slides
|
@Sebastian | disponibles en http://www.requin.cl/Umeet2005-OperacionDN
S.pdf
|
@Sebastian | La idea de la presentacion es darnes un barniz mas o menos
profundo del protocolo de DNS
|
@Sebastian | desde el punto de vista tecnico
|
@Sebastian | y que veamos algunos elementos de operacion y diagnostico
|
@Sebastian | tuve problemas al preparar la charla en acotar los topicos
|
@Sebastian | por lo que sus consultas seran fundamentales para
enriquecer esta charla
|
@Sebastian | Vamos a partir con conceptos basicos y no tan basicos
|
@Sebastian | si algunos de uds creen que saben de DNS, puede ser que no
esten en lo correcto
|
@Sebastian | En el slide 3 podemos ver una definicion general del DNS
|
@Sebastian | es una base de datos, distribuida (no esta en un solo lugar(
|
@Sebastian | y cuyo concepto fundamental es la delegacion
|
@Sebastian | o sea, para que sea debilmente acoplada y distribuida,
requiere que sea delegada
|
@Sebastian | el elemento esencial es que porciones de la informacion del
DNS estan en diversas partes, y cada persona es responsable de su porcion.
|
@Sebastian | Eso es lo que hacen los NIC: delegar responsabilidad por una
"etiqueta" a otros
|
@Sebastian | en el sistema tenemos tres actores
|
@Sebastian | los clientes, que corresponde a las librerias de resolver de
cada sistema operativo
|
@Sebastian | responsables de las llamadas gethostbyname, gethostbyaddr
y asociados
|
@Sebastian | los servidores con autoridad, que publican la informacion en
el DNS
|
@Sebastian | y los cache, que son intermediarios entre resolvers y
servidores
|
@Sebastian | todo el protocolo de DNS esta basado en mensajes, en el
concepto de request/reply
|
@Sebastian | como transporte para esos mensajes se usa principalmente
UDP
|
@Sebastian | pero no exclusivamente
|
@Sebastian | tambien se requiere TCP (lo exige el protocolo)
|
@Sebastian | el puerto asignado por IANA para el DNS es el 53.
|
@Sebastian | Una curiosidad, que muchos desconocen, es que TCP si se
usa para consultas
|
@Sebastian | como vamos a ver mas adelante, existe un bit llamado TC, que
se incluye en una respuesta.
|
@Sebastian | para indicarle al servidor que pregunto, que dicha respuesta
excede los 512 bytes y debe ser reintentada usando TCP, para obtener
|
@Sebastian | toda la informacion.
|
@Sebastian | por ejemplo, si consultan por los servidores de correo de
hotmail.com o yahoo.com, se daran cuenta que sus respuestas estan muy
cercanas
|
@Sebastian | al limite que he mencionado
|
@Sebastian | para hacer esa consulta, utilicen el comando dig mx
hotmail.com
|
@Sebastian | y miren las ultimas dos lineas de la respuesta
|
@Sebastian | dicen ;; WHEN: Tue Dec 20 18:32:41 2005 ;; MSG SIZE rcvd:
511
|
@Sebastian | Ahora, ese limite esta definido en el RFC 1034, que delineo
originalmente el protocolo de DNS
|
@Sebastian | ahora, con la existencia de EDNS, se pueden hacer consultas
con respuestas mayores a 512 bytes, forzando el uso de UDP
|
@Sebastian | pero no esta ampliamente utilizado aun
|
@Sebastian | otro elemento que resulta util en la operacion de un DNS es
conocer la estructura del mensaje
|
@Sebastian | que pueden ver en el slide 5
|
@Sebastian | hay un Header, que indica a que corresponde el mensaje: si a
una pregunta o una respuesta
|
@Sebastian | la seccion de pregunta, la seccion de respuesta, la seccion de
autoridad y la seccion de adicionales
|
@Sebastian | las tres ultimas corresponden a una secuencia de RR (que
veremos luego a que corresponden)
|
@Sebastian | En el slide 6 podemos ver la estructura del header. Les
recomiendo que la vean con atencion, pues les servira para entender algunas
condiciones de error y diagnostico mas adelante
|
@Sebastian | alguna pregunta hasta el minuto?
|
@Sebastian | bien, sigo con la sensacion de estar hablando solo :-D
|
@Sebastian | El header del protocolo es bastante simple.
|
@Sebastian | la explicacion es bastante clara en el slide tambien
|
@krocz | @krocz> EDNS, es un nuevo protocolo para forzar a recibir
respuestas de
|
@krocz | mayores a 512 bytes por UDP?
> sebastian el canal esta moderado: solo los que tiene @ pueden escribir
aqui. POr eso da la senacion de estar solo. Pero los demas leemos (y
preguntamos en otro canal)
|
@Sebastian | entiendo
|
@Sebastian | con la creacion de DNSSEC, las respuestas superaran el
limite de los 512 bytes facilmente
|
@Sebastian | y nadie quiere que el DNS utilice TCP por los costos
asociados al establecimiento de una sesion
|
@Sebastian | por lo que se creo la extension EDNS, que permite definir un
buffer UDP de mas de 512 bytes
|
@Sebastian | Ahora nos movemos a otro componente del DNS, que es la
estructura de la informacion
|
@Sebastian | el DNS es jerarquico, dependiendo de una raiz
|
@Sebastian | probablemente todos los sabes
|
@Sebastian | los hijos de la raiz se llaman TLD (Top Level Domain)
|
@Sebastian | existen tres tipos: probablemente uds conocen solo dos
|
@Sebastian | los ccTLD (country code TLD) y los gTLD (generic TLD)
|
@Sebastian | pero desde hace un par de a~nos existen los sTLD
(sponsored TLD)
|
@Sebastian | que son TLD cerrados y creados por grupos de
organizaciones con intereses creados sobre ellos
|
@Sebastian | por ejemplo, .aero creado por las lineas areas y otras
compa~nias asociadas.
|
@Sebastian | otro elemento importante son los root servers, o servidores
con autoridad para la etiqueta "."
|
@Sebastian | ellos permiten resolver cualquier nombre y son 13 por
restricciones de protocolo
|
@Sebastian | 512 bytes)
|
@Sebastian | (la misma razon del os 512 bytes)
|
@Sebastian | para quienes se preguntan por que Chile es .CL y no .CH, la
respuesta la tiene la ISO, quien definio la norma de los codigos de los paises
|
@Sebastian | (Entre parentesis, CH los tiene Suiza, pues su nombre original
es Comunidade Helvetica)
|
@Sebastian | del slide 8, lo mas importante es la diferencia entre un dominio
y una zona
|
@Sebastian | un dominio es todo lo que depende de un nodo
|
@Sebastian | una zona describe el contenido de un nodo
|
@Sebastian | o sea, el dominio CL es el nodo CL en el arbol, mas todos los
nodos que dependen de el
|
@Sebastian | acabo de ver la pregunta
|
@krocz | damage> Sebastian: cuales son los requisitos para que un pais
tenga su
|
@krocz | propio TLD, hay alguna organizacion acargo de esto?, el
tramite
|
@krocz | lo realiza la organizacion o el pais?
|
@Sebastian | la definicion de que pais tiene un TLD esta en manos de
ICANN, que es una organizacion coordinadora, principalmente politica
|
@Sebastian | que dicta las normas de funcionamiento de los dominios de
primer nivel
|
@Sebastian | dentro de la historia, pocos TLD se han creado por el
nacimiento de paises
|
@Sebastian | por ejemplo, existe .pa que corresponde a Palestina
|
@Sebastian | cuando fue reconocido como estado
|
@Sebastian | al suceder eso, ICANN recibio la solicitud de creacion del TLD
.pa de parte de organizaciones asociadas al estado palestino
|
@Sebastian | que tuvieron que validar su vinculacion
|
@Sebastian | en este punto, muchos de los chilenos se preguntan "porque
la Universidad de Chile administra el punto CL"?
|
@Sebastian | porque no lo hace otra organizacion?
|
@Sebastian | esa pregunta tiene su respuesta en la historia
|
@Sebastian | como fue la Universidad de Chile una de las primeras
organizaciones en conectarse a Internet, via UUCP
|
@Sebastian | y el objetivo de la coneccion era tener correo electronico, la
gente en Estados Unidos dijo
|
@Sebastian | para que Uds puedan tener una direccion de correo, deben
tener alguien que se encargue del country code que les corresponde
|
@Sebastian | quieren ser uds/
|
@Sebastian | y como veran, la respuesta fue afirmativa
|
@krocz | DIGI-TECK> Sebastian: cuales son lo requisitos de ICANN para
poder
|
@krocz | tener un dominio de primer nivel.
|
@Sebastian | uf! no sabria decirte con precision cuales son
|
@Sebastian | pero no es que cualquier organizacion decida tener un
dominio de primer nivel
|
@Sebastian | dependiendo del tipo de TLD, siguen caminos diferentes
|
@Sebastian | si es un ccTLD, tiene que existir un estado o nacion
reconocida por Naciones Unidas
|
@Sebastian | luego recibir su country code de parte de la ISO
|
@Sebastian | y luego demostrar que quien solicita su administracion esta
relacionado con el dominio
|
@Sebastian | si es un gTLD, pasa por a~nos de discusion en los comites de
gobernabilidad y otros (y finalmente pasa por la aprobacion del Departamento de
Comercio del gobierno de Estados Unidos)
|
@Sebastian | si un sTLD, existen las instrucciones para que organizaciones
puedan solicitar sus TLD
|
@Sebastian | pueden mirar en http://www.icann.org/topics/gtld-strategy-area
.html
|
@Sebastian | y en http://www.icann.org/tlds/stld-apps-19mar04/
|
@Sebastian | con respecto a las instrucciones precisas.
|
@Sebastian | bueno, continuemos
|
@Sebastian | en el slide 10 podemos ver como componente esencial del
protocolo de DNS, como son los RR
|
@Sebastian | toda la informacion de DNS se describe usandolos
|
@Sebastian | por lo que entender su estructura es de gran utilidad
|
@Sebastian | Cada RR tiene una etiqueta o nombre, una clase, un tipo, un
TTL y data
|
@Sebastian | la data depende del tipo.
|
@Sebastian | probablemente conocen uds algunos tipos de registros,
como el SOA, NS, MX, A, PTR, CNAME, TXT
|
@alejandro | if you are a ccTLD, it needs to exist a state or nation
recognized in the United Nations
|
@alejandro | later receive the country code from the ISO
|
@alejandro | and later demonstrate who asks for is related with the domain
|
@alejandro | disculpa Sebastian.
|
@krocz | canal equivocado :)
|
@Sebastian | para quien pregunto, .tk corresponde a Tokelau, una
peque~na isla polinesica ubicada en el Pacifico Sur
|
@Sebastian | eso esta cerca de .TV (Tivalu) y de .TO (Tongo)
|
@Sebastian | ;-D
|
@Sebastian | siguiendo con el slide 10, mas de alguno no habia escuchado
hablar de las clases HS o CH
|
@Sebastian | que fueron creadas por la gente de MIT por motivos
experimentales
|
@Sebastian | la clase CH se usa para motivos de informacion en algunas
implementaciones de DNS
|
@Sebastian | conocida es la consulta dig version.bind CHAOS TXT
@ns.nic.cl +short
|
@Sebastian | que devuelve "BIND 9, NIC Chile"
|
@Sebastian | en ese caso
|
@Sebastian | en el canal de preguntas dice "Como se consigue un dominio
.int"
|
@Sebastian | los dominios .int son escasos y asignados con lupa, a
organizaciones reconocidas internacionalmente como Naciones Unidas, WIPO y
otras
|
@Sebastian | por lo que la delegacion de dominios bajo esa jerarquia es
casi cerrada
|
@Sebastian | en el slide 11 propuse una revision del registro SOA.
|
@Sebastian | dicho registro es especial, pues debe estar presente en cada
zona.
|
@Sebastian | y define parametros de operacion de un dominio.
|
@Sebastian | parte de la correcta operacion de un dominio esta dado por
esos valores
|
@Sebastian | por lo mismo hay una seccion de numeros recomendados
mas adelante
|
@Sebastian | La correctitud de los parametros la discutiremos mas adelante
|
@Sebastian | El slide 12 muestra la correctitud de una pregunta de DNS
|
@Sebastian | la coloque solo por fines academicos
|
@Sebastian | com oestoy haciendo mi tesis de maestria relacionado con el
DNS, tengo que aprovechar de educar un poco
|
@Sebastian | El slide 13 es mucho mas interesante, pues muestra los
elementos a distinguir en una respuesta a una consulta de DNS
|
@Sebastian | entre ellos, como interpretar los flags de la respuesta
|
@Sebastian | en particular, puede resultarles interesante los codigos de
error y que significan cada uno
|
@Sebastian | cual es la duracion esperada de esta charla?
|
@krocz | Sebastian: dale no mas :)
|
@krocz | no hay horarios fijos
|
@Sebastian | ok
|
@Sebastian | en el slide 14, como mencionamos antes, se definen tres
actores para el sistema de DNS
|
@Sebastian | no may mucho que profundizar con respecto a los clientes
resolvers
|
@Sebastian | los servidores de cache son parte esencial, interactuar con
clientes y servidores con autoridad
|
@Sebastian | guardan copia de lo que averiguan, por razones de eficiencia
|
@Sebastian | y finalmente los servidores con autoridad, que son aquellos
que obtienen la informacion de una zona de una fuente confiable
|
@Sebastian | tambien se les llama servidores autoritativos, que es una mala
traduccion del ingles "authoritative server".
|
@Sebastian | los servidores con autoridad son claves en todo esto
|
@Sebastian | pues publican la informacion original.
|
@Sebastian | entre ellos, hay tres tipos: el primario, que tiene la copia
original de la zona
|
@Sebastian | el secundario, que obtiene una copia de la zona a partir del
primario
|
@Sebastian | y los stealth, que son aquellos servidores que tienen una
copia de la zona, pero que no son parte de la delegacion de un dominio
|
@Sebastian | o sea, no estan en la lista de NS de un dominio
|
@Sebastian | los secundarios se sincronizan con el primario usando las
transferencias de zona
|
@Sebastian | la frecuencia de las transferencias esta dada por la frecuencia
de actualizacion de la zona
|
@Sebastian | cada secundario, antes de transferir, verifica el registro SOA
de la zona en cuestion y revisa si el numero serial es mayor al que el posee
|
@Sebastian | si es mayor, se programa la transferencia (en un servidor
desocupado, se inicia de inmediato; en uno ocupado, puede tomar su tiempo)
|
@Sebastian | Si nos movemos al slide 16
|
@krocz | Borges> cual seria el objetivo de tener un dns stealth ? una suerte
de
|
@krocz | respaldo?
|
@Sebastian | veremos un par de conceptos muy importantes en el DNS,
que tiene que ver con los caches
|
@Sebastian | el objetivo de un stealth generalmente es eficiencia
|
@Sebastian | por ejemplo, en el caso del dominio CL, nosotros podriamos
querer que todos los ISP tuvieran una copia de la zona CL, pero sin recibir la
delegacion por el dominio
|
@Sebastian | nosotros les dariamos acceso a una copia de la zona, para
que puedan consultar localmente por esos nombres, en vez de salir de su red e ir
a otro servidor a hacer la misma consulta
|
@Sebastian | en un cache basado en BIND, por ejemplo, se puede redirigir
directamente una consulta a un servidor de tu preferencia para una zona dada,
usando los forwarders
|
@Sebastian | bueno, con respecto al caching, hay dos elementos
importantes
|
@Sebastian | el primero es el que todos conocen. Un servidor de cache
memoriza las respuestas que averigua, durante cierta cantidad de segundos
|
@Sebastian | esa cantidad de segundos es el TTL asociado a cada registro
|
@Sebastian | el otro concepto, que no es tan conocido, se refiere al
negative caching
|
@Sebastian | que consiste en memorizar las respuestas que no existen
|
@Sebastian | por ejemplo, si pregunto por el dominio "noexiste.cl" en NIC,
el servidor me devuelve dos cosas
|
@Sebastian | un codigo de retorno NXDOMAIN
|
@Sebastian | y el registro SOA de la zona CL
|
@Sebastian | si un cache pregunta por eso, recibira el codigo de retorno y
el registro SOA
|
@Sebastian | memorizando por los segundos de TTL especificados en el
registro SOA que ese registro no existe
|
@Sebastian | despues de la revision de conceptos, nos movemos a
recomendaciones operativas
|
@Sebastian | estoy seguro que lo incluido en las diapositivas no saciara la
curiosidad de todos, por lo que hagan sus consultas.
|
@Sebastian | para empezar, que software hay de DNS?
|
@Sebastian | BIND es ampliamente conocido
|
@Sebastian | pero tambien existen NSD y PowerDNS (para indicar los con
mas presencia)
|
@Sebastian | dentro del ambiente propietario, existe ATLAS, UltraDNS
|
@Sebastian | Nosotros usamos BIND 8, BIND 9 y NSD.
|
@Sebastian | los root server usando BIND y NSD
|
@Sebastian | los TLD servers usan todos los mencionados
|
@Sebastian | a TinyDNS o DJBDNS, no me voy a referir
|
@krocz | Borges> hay alguna cosa en especial que los ate a Bind8?
|
@Sebastian | en el slide 18 hablamos de recomendaciones generales al
configurar una zona
|
@krocz | Borges> versus Bind9
|
@Sebastian | bueno, BIND8 y BIND9 fueron desarrollados por equipos
diferentes
|
@Sebastian | por lo que no deberian compartir codigo
|
@Sebastian | (al menos eso me han asegurado todos los desarrolladores
de BIND9 que conozco, incluso el mismo jefe de proyecto)
|
@Sebastian | la idea de BIND8 no es por "preferencia", sino por
recomendacion operativa
|
@Sebastian | no es bueno tener todos los huevos en la misma canasta.
|
@Sebastian | en un principio teniamos todos los servidores con BIND9,
pero se detecto una vulnerabilidad seria
|
@Sebastian | asi que se empezo a recomendar usar variedad de software
|
@Sebastian | BIND8 no tiene bugs graves y tampoco se desarrolla mas,
pero todavia sirve para los propositos de un servidor con autoridad
|
@Sebastian | yo mismo he descubierto dos bugs en BIND9 que seran
corregidos en la proxima version (BIND 9.3.2)
|
@Sebastian | al terminar la charla voy a dejar una version legible de las
diapositivas
|
@Sebastian | se me ocurrio hacer un cambio de formato a ultimo momento
que no favorece la lectura
|
@Sebastian | si nos movemos al slide 19
|
@Sebastian | podemos ver un elemento importante de configuracion
|
@Sebastian | que tiene que ver con la eleccion de los parametros del SOA
|
@Sebastian | lo escrito es recomendacion del RFC 1912
|
@Sebastian | y si estan familiarizados con el servicio DNS Reporter, lo
recordara
|
@Sebastian | ahora, en discusion con otros operadores y en vista de otros
documentos
|
@Sebastian | se considera al RFC 1912 como demasiado viejo
|
@Sebastian | (alrededor de 1999)
|
@Sebastian | los dominios con letras extra~nas se llaman IDN
(Internationalized Domain Names)
|
@krocz | krocz> Sebastian: con respecto a los dominios con letras
"extrañas" á é
|
@krocz | ... ú ñ estos ya estan soportados por nic? ha habido algun
|
@krocz | problema con esta implementacion?? se necesita un
parche
|
@krocz | especial en los demonios bind?
|
@Sebastian | y la tecnologia que los hace posible se llama IDNA (IDN for
Applications)
|
@Sebastian | las aplicaciones convierten el dominio con caracteres
extendidos
|
@Sebastian | en una etiqueta permitida por el protocolo
|
@Sebastian | mediante un mecanismo llamado ACE
|
@Sebastian | bien, tengo que focalizarme en la nata de la presentacion
|
@Sebastian | estamos pasados en el tiempo
|
@Sebastian | que recomendaciones operativas destacaria de la
presentacion:
|
@Sebastian | 1. asegurarse de que la zona es correcta antes de cargarla
|
@Sebastian | instrucciones en el slide 20
|
@Sebastian | 2. elegir bien los secundarios (slide 22).
|
@Sebastian | que no dependan todos de la misma fuente de poder, enlace o
red.
|
@Sebastian | incluso es mas, hay algunos TLD que exigen que esten en
sistemas autonomos diferentes
|
@Sebastian | 3. prefiera la diversidad de software/plataforma/hardware
|
@Sebastian | y sistema operativo: nosotros usando Linux, FreeBSD, HP/UX
entre nuestros servidores para .CL
|
@Sebastian | si le importa su dominio, monitoree
|
@Sebastian | que respondan con autoridad, tiempo de convergencia
despues de los cambios, etc.
|
@Sebastian | Seguridad: Uso de ACL
|
@Sebastian | en el slide 25 se hace referencia a un material muy interesante
para "blindar" un BIND
|
@Sebastian | uso de TSIG
|
@Sebastian | la validar las transferencias de zonas. Asi pueden restringir el
acceso a la zona no por IP, sino por llaves criptograficas.
|
@Sebastian | slide 26 y 27 al respecto
|
@Sebastian | con respecto a que TLD's exigen que los servidores esten en
diferentes redes y ASN, lo exigen los alemanes y los franceses.
|
@Sebastian | Otro elemento util de operacion son los notify
|
@Sebastian | que permiten reducir el tiempo que pasa entre que el primario
hace un cambio y los secundarios tienen la copia nueva.
|
@Sebastian | junto con el mecanismo de IXFR, que permite transferir solo
las diferencias de la zona, no la zona completa.
|
@Sebastian | nosotros utilizamos durante un tiempo IXFR para la zona CL,
y redujimos el tiempo de convergencia en mas de un 90%
|
@Sebastian | Finalmente, con lo que respecta a diagnostico de problemas
|
@Sebastian | en el slide 30 podemos ver que yo recomiendo para
diagnosticar y que no
|
@Sebastian | me gustaria aclarar los "porque no"
|
@Sebastian | nslookup hace cosas que nadie le pide hacer (como resolver
si los servidores de nombre tienen reversos)
|
@Sebastian | e interpreta las respuesta de manera incorrecta
|
@Sebastian | en alguna version de BIND trataron de sacarlo de la
distribucion, pero fue tanta la presion, que no pudieron
|
@Sebastian | DNS Report tambien reporta errores de manera antojadiza,
como por ejemplo, cuando los parametros del SOA no calzan con lo indicado por
el RFC 1912
|
@Sebastian | o, en el caso de los TLD, cuando un servidor de nombres no
devuelve las IP de todos los registros NS de un dominio, tambien reclama
|
@Sebastian | situacion que es, definitivamente y ampliamente
consensuada, incorrecta
|
@Sebastian | a mi personalmente me gusta mucho la herramienta utilizada
por el NIC de Francia (zonecheck.fr)
|
@Sebastian | y esperamos llegar a ese nivel de calidad con nuestra propia
herramienta (doctorDNS)
|
@Sebastian | las ultimas tres diapositivas se dedican a explicar como usar
DIG y entender el output que produce.
|
@Sebastian | del slide 32, lo importante es distinguir los flags, o bits que
indican el tipo de respuesta obtenida.
|
@Sebastian | preguntan "nslookup no esta descontinuado"?
|
@Sebastian | esa fue la idea, pero no les resulto
|
@Sebastian | del slide 33, es importante notar que los registros devueltos
tienen diferentes TTL
|
@Sebastian | si Uds le preguntan a un servidor de nombre por algo que
deberia conocer, el TTL no va a cambiar
|
@Sebastian | si le preguntan a un cache por algo que no deberia saber, la
primera vez lo averiguara
|
@Sebastian | cualquier consulta subsecuente, entregara lo averiguado, con
un TTL decrementado (hagan la prueba)
|
@Sebastian | el ultimo slide (34)
|
@Sebastian | muestra algunas opciones interesantes de DIG, que sirven
para diagnostico
|
@Sebastian | por ejemplo, para verificar si un servidor de DNS esta
respondiendo por TCP, le indican la opcion +tcp
|
@Sebastian | en mas de alguna ocasion me ha tocado encontrar servidores
que, al preguntarles por UDP, contestan una informacion, y al preguntarles por
TCP, contestan otra
|
@Sebastian | la otra opcion util es +trace, que replica la secuencia de
resolucion.
|
@Sebastian | Eso es util para diagnosticar problemas no evidentes, como
errores en la delegacion, nombres mal escritos o que no se pueden resolver, etc.
|
@Sebastian | particularmente util para responder la pregunta "y de donde
averiguo mi cache esta informacion?"
|
@Sebastian | bueno se~nores
|
@Sebastian | eso es parte de lo que puedo decir
|
@Sebastian | probablemente necesitaria un dia entero para contarles todo
lo relacionado con DNS
|
@Sebastian | asi que ahora entrego el mando a los organizadores
|
@krocz | Gracias Sebastian
|
@alejandro | Muchas gracias Sebastian, una charla verdaderamente
interesante.
|
@krocz | Gracias a toda la gente por estar viendo y aprendiendo sobre DNS
|
@krocz | creo que es un broche de oro para esta Umeet 2005
|
@Sebastian | el proximo a~no hacemos la segunda parte :-D
|
@krocz | o mas temprano, la gente de Europa ya esta durmiendo a esta hora
|
@Sebastian | definitivamente
|
@Sebastian | especialmente con lo aburrido que soy :-|
|
@krocz | no Sebastian tranquilo han habido peores :)
|
@krocz | a continuacion para finalizar esta version de umeet
|
@Sebastian | que tranquilizante
|
@krocz | y manera de resumir lo que ha sido este año
|
@krocz | la umeet 2005
|
@krocz | dejo con uds a alejandro
|
@alejandro | Buenas noches a todos.
|
@krocz | primero que nada, quiero felicitar a alejandro que llevo la
traduccion casi en tiempo real en el canal #redes
|
@alejandro | Se que para muchos de vosotros es tarde, pero que finalizar
ahora con la clausura de la Unix Meeting
|
@alejandro | Ha sido un año muy interesante, en el que el software libre no
ha parado de crecer.
|
@alejandro | Creo sinceramente que ha sido un buen año para el
escritorio, cada vez existen mucho más soluciones para el usuario final
|
@alejandro | Y muchas de las charlas que hemos tenido este año han
reflejado la calidad y el desarrollo que se ha estado haciendo.
|
@alejandro | Charlas como las de OpenOffice, Mono, GNOME o KDE,
plantean un buen año próximo para el escritorio.
|
@alejandro | Luego otras charlas que también me llegan de orgullo
relacionadas con seguridad, redes o sistemas operativos, aportan que el
software libre es software tecnicamente bueno y que puede ser usado en el dÃa
a dÃa.
|
@alejandro | Esperemos que con el rechazo de las patentes, el uso cada
vez más en la Administración y el giro que pueda dar el escritorio, consigamos
que se acerque a muchos más.
|
@alejandro | Estoy seguro que el 2006 vamos a poder ver reflejado el
trabajo de muchos de nosotros.
|
@alejandro | Quiero dar gracias a toda la organización de la Unix Meeting
por traernos un año más estas fantasticas conferencias trayendo a
desarrolladores de una gran calidad.
|
@alejandro | Y quiero agradecer a vosotros vuestra asistencia un año
más, que hacen gracias a vosotros, unas conferencias interesantes donde se
puede aprender mediante la divulgación de charlas.
|
@alejandro | La Unix Meeting, un año más ha sido un centro de reunión
tan bueno como en otras conferencias, permitiendonos a muchos
desarrolladores juntarnos de manera online.
|
@alejandro | Doy por terminada la Umeet 05, esperando que el próximo
año hayan charlas al menos del mismo nivel técnico que este año.
|
@alejandro | Muchas gracias a todos.
|
@krocz | Gracias a todos
|
@krocz | fin de la Umeet 2005 :)
|
@krocz | todos durmiendo parece :P
|
VikoSV | muchas gracias a los organizadores
|
VikoSV | desde ya me quedo en espera umeet'2006
|
VikoSV | :)
|
@alejandro | :)
|
@krocz | gracias a todos por hacerla posible
|
@krocz | este año nos costo bastante por que gente importante de la
organizacion no pudo estar este año
|
@alejandro | faltó la charla este año de krocz :-)
|
@krocz | jejeje
|
@alejandro | por eso no os perdais la siguiente!
|
VikoSV | es hora pasar al cocktel ¿?
|
@krocz | creo que sera para mañana, alejandro ya esta durmiendo :)
|
@alejandro | ;-)
* alejandro se va a descansar.
|
VikoSV | bueno es la ventaja de tener un horario GMT -6 (para mi la
noche aun no llega) ;)
|
VikoSV | hasta la proxima
|
@alejandro | * alejandro (alejandro@78.Red-80-35-162.staticIP.rima-tde.net) Quit
(Quit: Leaving) |
---|
@Sebastian | * Sebastian (w200112312@mar.uninet.edu) Quit (Quit: quit) |