Leer conn y dns

Cada fila del registro de conversaciones lleva un campo, conn_state, que resume cómo terminó. Los tres valores que más se encuentran en un caso son: SF (la conexión se estableció y terminó con normalidad), S0 (se vio el intento de abrir la conexión y no hubo respuesta) y REJ (el intento fue rechazado de forma explícita por el destino).

Leer este campo evita dos errores. Uno, creer que un equipo «habló» con un destino con el que solo intentó hablar. Otro, descartar un intento fallido: un equipo que insiste contra destinos que no contestan también es información.

Fíjate además en que orig_bytes y resp_bytes cuentan la carga que envió cada lado, y que una conversación con ceros no intercambió datos de aplicación.

Un respondedor casi nunca lee una fila: lee un conjunto. La pregunta «cuánto salió hacia ese destino» se contesta sumando orig_bytes de todas las conversaciones del mismo origen hacia el mismo destino y puerto. Es una suma de hechos escritos, no una estimación.

Cuida que el origen y el destino sean exactamente los que pide la pregunta: una conversación hacia el mismo servidor por otro puerto es otra cosa. El extracto trae conversaciones de varios equipos y de varios destinos mezcladas.

El registro de conversaciones habla de direcciones; las personas hablan de nombres. El registro de nombres guarda la consulta (query), el tipo y la respuesta (answers), y es lo que permite pasar de «el equipo se conectó a esa dirección» a «el equipo pidió ese nombre y le contestaron esa dirección».

Ese paso tiene un límite que conviene recordar: muestra qué nombre pidió el equipo y qué le respondió el servidor de nombres, no que el destino sea quien dice su nombre.

La consulta de nombres es, ella misma, una conversación (por el puerto 53) y tiene su propio uid en el registro de conversaciones. La conexión que el equipo abre después hacia la dirección que le contestaron es otra conversación con otro uid: los dos registros no comparten identificador entre la consulta y lo que viene después.

Lo que sí une las dos cosas es lo que cada registro escribió: quién preguntó, a qué hora, y a qué dirección contestó el servidor de nombres. Con esos tres datos se encuentra la conversación posterior, y se comprueba que la hora tenga sentido (la consulta va antes).