Articulo de referencia

IRCd

Un IRCd , abreviatura de Internet Relay Chat daemon , es un software de servidor que implementa el protocolo IRC , lo que permite a las personas hablar entre sí a través de Inte...

Un IRCd , abreviatura de Internet Relay Chat daemon , es un software de servidor que implementa el protocolo IRC , lo que permite a las personas hablar entre sí a través de Internet (intercambiar mensajes de texto en tiempo real). [ 1 ] [ 2 ] Es distinto de un bot de IRC que se conecta a un canal de IRC.

El servidor escucha las conexiones de los clientes IRC [ 3 ] en un conjunto de puertos TCP . [ 4 ] Cuando el servidor forma parte de una red IRC, también mantiene una o más conexiones establecidas con otros servidores/demonios. [ 5 ]

El término ircd originalmente se refería a un solo programa informático, [ 6 ] pero con el tiempo se convirtió en una referencia genérica a cualquier implementación de un demonio IRC. [ 7 ] [ 8 ] Sin embargo, la versión original todavía se distribuye con el mismo nombre, [ 9 ] y este artículo analiza ambos usos.

Historia

El IRCd original se conocía como 'ircd' y fue creado por Jarkko Oikarinen (WiZ en IRC) en 1988. [ 10 ] [ 11 ] Recibió ayuda de varias personas, como Markku Savela (msa en IRC), quien ayudó con el lanzamiento de 2.2+msa, etc.

En sus primeras versiones, IRC carecía de muchas características que hoy damos por sentadas, como los canales con nombre y los operadores de canal . Los canales estaban numerados —por ejemplo , el canal 4 y el canal 57— y el tema del canal describía el tipo de conversación que tenía lugar en él. Una característica que se conserva de esto es que unirse al canal 0 provoca que un cliente abandone todos los canales en los que se encuentre actualmente: «CHANNEL 0» era el comando original para abandonar el canal actual.

El primer cambio importante en IRC, en la versión 2.5, fue la adición de canales con nombre : "+channels". Posteriormente, en la versión 2.7, "+channels" fue reemplazado por "#channels", se eliminaron por completo los canales numéricos y se implementaron los bloqueos de canales (modo +b).

Alrededor de la versión 2.7, hubo una pequeña pero notable disputa que dio lugar a ircu , la bifurcación de ircd en Undernet .

irc2.8 añadió "&channels" (aquellos que existen solo en el servidor actual, en lugar de en toda la red) y "!channels" (aquellos que teóricamente están a salvo de sufrir las muchas formas en que un usuario podría explotar un canal "aprovechando un netsplit "), y es la versión base de la que derivan casi todas las implementaciones actuales.

Alrededor de la versión 2.8 surgió el concepto de apodo y retardo de canal, un sistema diseñado para ayudar a frenar prácticas abusivas como tomas de control y split riding. Esto no fue aceptado por la mayoría de los IRC modernos (EFnet, DALnet, Undernet, etc.), y por lo tanto, la versión 2.8 se dividió en varios demonios diferentes que utilizaban una teoría opuesta conocida como TS ( marca de tiempo), que almacenaba una marca de tiempo única con cada canal o apodo en la red para decidir cuál era el "correcto" que se debía conservar.

El sistema de sellado de tiempo se ha revisado varias veces para corregir diversos problemas de diseño. Las versiones más recientes de estos protocolos son:

  • el protocolo TS6, que es utilizado por EFnet y servidores basados ​​en Hybrid y Ratbox, entre otros.
  • el protocolo P10 , que es utilizado por los servidores basados ​​en Undernet e ircu.

Si bien los protocolos de cliente a servidor son al menos funcionalmente similares, los protocolos de servidor a servidor difieren ampliamente (los protocolos de servidor TS5, P10 y ND/CD son incompatibles), lo que dificulta enormemente la interconexión de dos implementaciones distintas del servidor IRC. Existen algunos servidores puente que permiten, por ejemplo, la interconexión de servidores 2.10 con servidores TS5, pero estos suelen estar sujetos a restricciones sobre qué partes de cada protocolo pueden utilizarse y no están ampliamente implementados.

Entre las novedades más importantes basadas en la versión 2.8 se incluyen:

  • 2.8.21+CS, desarrollado por Chris Behrens ( Comstud )
  • 2.8+, el conjunto de parches de Taner Halicioglu, que más tarde se convirtió en
    • Hybrid IRCd, desarrollado originalmente por Jon Lusky ( Rodder ) y Diane Bruce ( Dianora ) como 2.8/hybrid, posteriormente se unió un gran equipo de desarrollo.
  • 2.9, 2.10, 2.11, ... continúan el desarrollo del código base original,

El código fuente original continuó desarrollándose principalmente para su uso en la red IRCnet . Se introdujeron nuevos protocolos de servidor a servidor en la versión 2.10, publicada en 1998, y en la versión 2.11, publicada por primera vez en 2004 y vigente a fecha de 2007.Este demonio es utilizado por IRCnet y se puede encontrar en http://www.irc.org/ftp/irc/server/ . El ircd original es software libre , licenciado bajo la Licencia Pública General de GNU . Esta línea de desarrollo produjo los 4 RFC de IRC publicados después del RFC 1459, que documentan exclusivamente este protocolo de servidor.

2.8.21+CS e Hybrid IRCd se siguen utilizando en EFnet , con ircd-ratbox (una derivación de ircd-hybrid) desde 2004.siendo el más popular.

Versiones de flujo lateral

Diagrama de derivaciones y relaciones para implementaciones comunes de IRCd.

Más recientemente, se escribieron desde cero varios demonios de IRC, como ithildin, [ 12 ] InspIRCd, [ 13 ] csircd (también escrito por Chris Behrens), ConferenceRoom, [ 14 ] Microsoft Exchange Chat Service, WeIRCd, [ 15 ] o IRCPlus/IRCXPro. [ 16 ]

Estos intentos han tenido un éxito desigual y han generado un gran escepticismo en la comunidad de desarrollo de IRC. Con cada nuevo IRCd, se utiliza una versión ligeramente diferente del protocolo IRC, [ 17 ] [ 18 ] y muchos clientes y bots de IRC se ven obligados a sacrificar funcionalidades o a variar su implementación según el servidor al que se conectan. [ 19 ] Estas modificaciones suelen implementarse para mejorar la usabilidad, la seguridad, la separación de poderes o la facilidad de integración con otros servicios . Posiblemente una de las diferencias más comunes y visibles sea la inclusión o exclusión del estado de operador de canal de media operación (que no es un requisito de los RFC).

Características

Puertos

Los números de puerto asignados oficialmente son 194 ("irc"), 529 ("irc-serv") y 994 ("ircs"). [ 20 ] Sin embargo, estos puertos se encuentran en el rango privilegiado (0–1024), lo que en un sistema tipo Unix significa que el demonio históricamente tendría que tener privilegios de superusuario para abrirlos. Por diversas razones de seguridad , esto solía ser indeseable.

Los puertos comunes para un proceso IRCd son del 6665 al 6669, siendo el 6667 el valor predeterminado histórico. [ 21 ] Estos puertos pueden ser abiertos por un proceso que no sea de superusuario y se popularizaron.

Conexiones

Gestionar un servidor IRC de gran tamaño, con miles de usuarios simultáneos, requiere mantener abiertas numerosas conexiones TCP durante largos periodos. Muy pocos servidores IRC son multihilo, ya que prácticamente todas las acciones necesitan acceder (al menos leer y posiblemente modificar) el estado global.

El resultado es que las mejores plataformas para ircds son aquellas que ofrecen mecanismos eficientes para manejar grandes cantidades de conexiones en un solo hilo. Linux ofrece esta capacidad en forma de epoll , en series de kernel posteriores a 2.4.x. FreeBSD (desde 4.1) y OpenBSD (desde 2.9) ofrecen kqueue . Solaris ha tenido /dev/poll desde la versión 7, y desde la versión 10 en adelante tiene IOCP (Puertos de finalización de E/S). Windows ha sido compatible con IOCP desde Windows NT 3.5. La diferencia que hacen estas nuevas interfaces puede ser drástica. Los desarrolladores de IRCU han mencionado aumentos en la capacidad práctica por servidor de 10 000 usuarios a 20 000 usuarios.

TLS (Seguridad de la capa de transporte)

Algunos servidores IRCd admiten Transport Layer Security (TLS); para aquellos que no lo hacen, aún es posible usar SSL a través de Stunnel . El puerto no oficial, pero el más utilizado para las conexiones TLS en IRCd, es el 6697. Más recientemente, como mejora de seguridad y usabilidad, varios desarrolladores de clientes y servidores han comenzado a elaborar un estándar conocido como STARTTLS [ 22 ], que permite que las conexiones TLS y de texto plano coexistan en el mismo puerto TCP.

IPv4 e IPv6

Los demonios de IRC admiten IPv4 , y algunos también admiten IPv6 . En general, la diferencia entre las conexiones IPv6 e IPv4 a IRC es puramente teórica, y el servicio funciona de manera muy similar a través de ambos protocolos.

Agrupamiento

Las grandes redes IRC constan de múltiples servidores para fines de escalabilidad horizontal . Existen varias extensiones del protocolo IRC para estos fines. [ 23 ]

IRCX

IRCX (Internet Relay Chat eXtensions) es una extensión del protocolo IRC desarrollada por Microsoft.

P10

El protocolo P10 es una extensión del protocolo Internet Relay Chat para comunicaciones de servidor a servidor, desarrollada por el Undernet Coder Committee para su uso en el software de su servidor ircu. Su propósito es similar al de los protocolos IRCX y EFnet TS5/TS6, e implementa marcas de tiempo de nick y canal para gestionar colisiones de nick y el uso compartido de canales netsplit, respectivamente. Otros IRCd que utilizan esta extensión de protocolo incluyen beware ircd . [ 23 ] [ 24 ] [ 25 ]

TS6

El protocolo TS6 es una extensión del protocolo Internet Relay Chat ( IRC) para comunicaciones entre servidores, desarrollado inicialmente por los creadores de ircd-ratbox. Ha sido ampliado por diversos programas de IRC y cuenta con la característica de que las implementaciones adecuadas de TS6 pueden conectarse entre sí mediante la negociación de características, incluso si estas son diferentes.

Configuración

Jupe

El término " juping " se refiere a la práctica de bloquear dicho canal o apodo en el servidor o la red , o dicho servidor en la red. Una posible explicación del origen de este término es que proviene del operador llamado Júpiter, quien obtuvo el control del apodo NickServ en EFnet . [ 26 ] EFnet no ofrece servicios como NickServ; Júpiter obtuvo el control del apodo porque él (entre otros operadores) no creía que los apodos debieran ser propiedad de nadie. Hoy en día, los operadores de EFnet "juping" utilizan apodos que se emplean como servicios en otras redes.

Un alias o un jupe de servidor aprovecha el hecho de que ciertos identificadores son únicos; al usar un identificador, se adquiere un bloqueo exclusivo que impide que otros usuarios lo utilicen.

Las restricciones JUPE autorizadas oficialmente también pueden utilizar servicios u opciones de configuración del servidor para hacer cumplir la restricción, como cuando se aplica una restricción a un servidor comprometido para evitar que dañe la red.

En la práctica, los operadores de IRC ahora usan configuraciones jupe para inhabilitar administrativamente canales o apodos. [ 27 ] Un jupe de canal se refiere a una prohibición específica de un canal en un servidor determinado, lo que significa que no se puede acceder a un canal específico cuando se está conectado a un servidor concreto, pero otros servidores pueden permitir que un usuario se una al canal. Esta es una forma de prohibir el acceso a canales problemáticos.

Línea O

Una línea O (frecuentemente también escrita como O:line ; en los IRCd que admiten operadores locales, las líneas O de estos se denominan o:lines con una O minúscula ), abreviatura de Operator Line y derivada del archivo de configuración basado en líneas del IRCd original, es una línea de código en el archivo de configuración de un demonio IRC que determina qué usuarios pueden convertirse en operadores IRC y qué permisos obtienen al hacerlo. El nombre proviene del prefijo utilizado para la línea en el IRCd original, una O mayúscula. La línea O especifica el nombre de usuario, la contraseña, los indicadores de operador y las restricciones de máscara de host para un operador en particular. Un servidor puede tener varias líneas O dependiendo de las necesidades administrativas del servidor y la red. [ 28 ]

Las banderas de operador se utilizan para describir los permisos que se le otorgan a un operador. Si bien algunos operadores de IRC pueden estar a cargo del enrutamiento de la red, otros pueden estar a cargo del abuso de la red, lo que hace que sus necesidades de ciertos permisos sean diferentes. [ 4 ] Las banderas de operador disponibles varían ampliamente según el demonio de IRC que se utilice. Generalmente, los demonios de IRC con más funciones tienden a tener más banderas de operador, y los demonios de IRC más tradicionales tienen menos.

También se puede configurar una línea O para que solo los usuarios con una máscara de host o dirección IP específica puedan obtener el estado de operador de IRC mediante esa línea O. El uso de máscaras de host y direcciones IP en la línea O requiere que la dirección IP permanezca invariable, pero proporciona seguridad adicional.

Línea K

Cuando un usuario es bloqueado (abreviatura de "k-line ", línea de eliminación ), se le prohíbe el acceso a un servidor específico, ya sea por un tiempo determinado o de forma permanente. Una vez bloqueado, no se le permite volver a entrar en ese servidor. Esto se registra como una línea en el archivo de configuración del demonio IRC del servidor, con el prefijo "K", de ahí el término "K-line".

Algunos demonios de IRC, incluidos ircd-hybrid y sus derivados, pueden configurarse para propagar las líneas K a algunos o a todos los demás servidores de una red. En dicha configuración, las líneas K funcionan como bloqueos globales similares a las líneas G.

Si bien el motivo preciso de la desconexión varía de un caso a otro, las razones habituales tienen que ver con algún aspecto del cliente o del usuario al que se dirige.

Comportamiento del usuario
Las líneas K pueden asignarse debido a un comportamiento inapropiado por parte del usuario, como "colisión de apodos", "hackeo" de modo, inundación de múltiples canales, acoso a otros usuarios a través de funciones de mensajería privada , " spam ", etc., o en el caso de redes más antiguas sin marca de tiempo, split riding , que no se puede corregir solo mediante el uso de privilegios de operador de canal .
Software cliente
Algunos demonios de IRC pueden configurarse para escanear en busca de virus u otras vulnerabilidades en los clientes que se conectan a ellos, y reaccionarán de diversas maneras según el resultado. Por ejemplo, el software cliente obsoleto e inseguro podría bloquearse para proteger a otros usuarios de la red de posibles vulnerabilidades. Algunas redes desconectarán a los clientes que operen a través de proxies abiertos o que ejecuten un servidor web inseguro.
Ubicación geográfica
Una red IRC que opera con varios servidores en diferentes ubicaciones intentará reducir la distancia entre un cliente y un servidor. Esto se suele lograr desconectando (o bloqueando) a los clientes de ubicaciones distantes y priorizando los locales.

Existen otras "líneas" de red relacionadas con la línea K. Los demonios IRC modernos también permiten a los operadores de IRC configurar estas líneas durante el funcionamiento normal, cuando no se requiere acceso rutinario al archivo de configuración del servidor.

Línea G

Una G-line o línea de eliminación global (también escrita G:line ) es una prohibición global de la red aplicada a un usuario; el término proviene de Undernet , pero en DALnet se utilizaba un concepto similar conocido como AKill .

En ocasiones, las líneas G se almacenan en el archivo de configuración del servidor IRC, aunque algunas redes, que gestionan las líneas K a través de los servicios IRC , prefieren almacenarlas en los archivos de configuración de su servicio. Cuando una persona con una línea G intenta conectarse a la red IRC, los servicios o el demonio IRC desconectan automáticamente al cliente, mostrando a menudo un mensaje que explica el motivo del bloqueo.

Las líneas G son una variante de las líneas K, que funcionan de forma muy similar, con la diferencia de que las líneas K solo desconectan a los clientes de un servidor específico de la red. Las líneas G se aplican normalmente a un usuario que ha recibido una línea K en un servidor pero que continúa abusando de la red conectándose a través de otro servidor. Las líneas G suelen considerarse una medida extrema, que solo se utiliza en casos de abuso reiterado cuando se han realizado numerosos intentos de razonar con el usuario infractor. Por lo tanto, especialmente en redes grandes, a menudo solo los operadores globales de IRC de muy alto rango tienen permiso para configurarlas, mientras que las líneas K, que generalmente se consideran un asunto local, quedan a cargo de los operadores de cada servidor de la red.

Las líneas G funcionan de forma ligeramente diferente a las líneas K. Normalmente, las líneas G se configuran como *@IPaddress o *@host, siendo la primera la mejor opción. Si se utiliza la opción *@host, el servidor debe realizar una búsqueda DNS inversa del usuario y comparar el host devuelto con los hosts de la lista de la línea G. Esto genera una demora y, si la búsqueda DNS no arroja resultados correctos, el usuario bloqueado aún podría acceder a la red.

Línea Z

Una línea Z o línea zap (también escrita Z:line ) es similar a una línea K, pero se aplica al rango de direcciones IP de un cliente y se considera útil en casos extremos. Dado que una línea Z no necesita verificar nombres de usuario (identd) ni nombres de host resueltos , se puede aplicar a un usuario antes de que envíe datos al conectarse. Por lo tanto, una línea Z es más eficiente y consume menos recursos que una línea K o G al bloquear a un gran número de usuarios.

En algunos demonios de IRC , como ircd-hybrid, esto se denomina línea D (línea de denegación) o línea X.

En ocasiones, las líneas Z se almacenan en el archivo de configuración del servidor IRC, aunque algunas redes, que gestionan las líneas a través de los servicios IRC, prefieren almacenarlas en los archivos de configuración de su propio servicio. Cuando una persona con una línea Z intenta conectarse a la red IRC, los servicios o el demonio IRC desconectan automáticamente al cliente, mostrando a menudo un mensaje que explica el motivo del bloqueo.

Las líneas Z son una variante de las líneas K, que funcionan de forma muy similar. La mayoría de las líneas Z se otorgan a personas que abusan de la red en su conjunto (en redes más pequeñas, se emiten con mayor frecuencia por incidentes aislados).

Las líneas Z también funcionan de forma ligeramente diferente a las líneas K. Las líneas Z se suelen configurar como *@IP o *@host, siendo la primera la mejor opción. Las líneas Z no esperan una respuesta de identificación del usuario que se conecta, sino que cierran el socket inmediatamente una vez que la IP del usuario se compara con la lista de líneas Z y se encuentra una coincidencia. Si se utiliza la opción *@host, el servidor debe realizar una búsqueda DNS inversa del usuario y luego comparar el host devuelto con los hosts de la lista de líneas Z. Esto puede provocar retrasos o, si el DNS no devuelve una respuesta correcta, los usuarios bloqueados aún podrían acceder a la red. En realidad, la opción *@host es totalmente contraria a la finalidad de usar una línea Z, por lo que algunos programas de IRCd no permiten nada que no sea *@IP, permitiendo comodines (?,*) o longitudes de prefijo CIDR ( por ejemplo, /8) en la sección IP para bloquear subredes completas. Otra diferencia con respecto a las líneas K (que afectan solo a los clientes de IRC) es que si se bloquea una IP, nada, ni siquiera otros servidores, puede conectarse desde esa IP (o rango de IP, dependiendo de la máscara de bloqueo).

Una ventaja de usar líneas Z en lugar de líneas K y G, desde la perspectiva de un administrador de servidor o de red, es que una línea Z usa menos ancho de banda que una línea K, principalmente porque no espera una respuesta de identidad ni una consulta DNS .

Una desventaja de usar Z-line en lugar de K-line o G-line es que resulta más difícil bloquear proveedores de servicios de Internet (ISP) completos y direcciones IP muy dinámicas, comunes en algunas conexiones de acceso telefónico y DSL . Por ejemplo, si un administrador de red quiere bloquear todo el ISP example.com (con rangos de direcciones IP hipotéticos de 68.0.0.0 – 68.255.255.255 y 37.0.0.0 – 38.255.255.255), una G-line podría usar *@*example.com, mientras que una Z-line requeriría *@37.*.*.*, *@38.*.*.* y *@68.*.*.* para lograr lo mismo.

Las líneas Z también pueden ser globales, en cuyo caso se denominan líneas GZ . Las líneas GZ funcionan de la misma manera que las líneas Z, con la diferencia de que se propagan a todos los servidores de la red. Algunos demonios de IRC también pueden configurarse para compartir líneas Z con otros servidores.

Línea Q

En algunos IRCd, como UnrealIRCd, una línea Q prohíbe un apodo, o cualquier apodo que coincida con un patrón determinado. Esto se usa con mayor frecuencia para prohibir el uso de apodos de servicios (como "X" o NickServ ) o el uso de apodos de operadores de IRC por parte de usuarios que no son operadores. Algunos demonios de IRC pueden desconectar a los usuarios al aplicar la línea Q inicialmente, mientras que otros forzarán un cambio de apodo o no harán nada hasta que el usuario afectado por la línea Q se vuelva a conectar. Otros IRCd, como ircd-hybrid, usan el comando "RESV" ("reservar") en su lugar, manteniendo la letra Q en las estadísticas. El comando "RESV" también puede prohibir el uso de un canal.

Véase también

Referencias

  1. Kalt, C. (2000). "RFC 2810 - Internet Relay Chat: Arquitectura" . Tools.ietf.org. doi : 10.17487/RFC2810 . Recuperado el 3 de marzo de 2010 .{{cite journal}}: Para citar una revista se requiere |journal=( ayuda )
  2. Preguntas frecuentes sobre solicitudes de servidor IRC Archivadas el 22/04/2009 en Wayback Machine
  3. Kalt, C. (2000). "RFC 2810 – Internet Relay Chat: Arquitectura" . Tools.ietf.org. doi : 10.17487/RFC2810 . Recuperado el 3 de marzo de 2010 .{{cite journal}}: Para citar una revista se requiere |journal=( ayuda )
  4. 1 2 Oikarinen, J.; Caña, D. (1993). "RFC 1459: protocolo de chat de retransmisión de Internet" . Herramientas.ietf.org. doi : 10.17487/RFC1459 . Consultado el 3 de marzo de 2010 .{{cite journal}}: Para citar una revista se requiere |journal=( ayuda )
  5. ^ Oikarinen, J.; Caña, D. (1993). "RFC 1459: protocolo de chat de retransmisión de Internet" . Herramientas.ietf.org. doi : 10.17487/RFC1459 . Consultado el 3 de marzo de 2010 .{{cite journal}}: Para citar una revista se requiere |journal=( ayuda )
  6. Preguntas frecuentes de IRCD en irc.org
  7. "Búsqueda en IRC, descripción general de la versión IRCD" . Searchirc.com . Consultado el 3 de marzo de 2010 .
  8. "Directorio abierto – Computadoras: Software: Internet: Servidores: Chat: IRC" . Dmoz.org. 26 de febrero de 2010. Consultado el 3 de marzo de 2010 .
  9. "IRCD – el servidor" . Funet.fi . Consultado el 3 de marzo de 2010 .
  10. Historial de IRC en IRC.org
  11. Historia de IRC, Daniel Stenberg
  12. Ithildin IRCd
  13. Inspire IRCd
  14. "WebMaster Inc" . Archivado del original el 3 de marzo de 2016. Consultado el 20 de enero de 2020 .
  15. "WeIRCd" . Archivado del original el 14 de mayo de 2010. Consultado el 26 de marzo de 2009 .
  16. OfficeIRC – Software de servidor IRC, chat web, comunicaciones internas y mensajería instantánea (MI)
  17. Entrada de blog que menciona violaciones de RFC
  18. Diversidad numérica de diferentes demonios IRC
  19. Código fuente del cliente (DMDirc) que muestra las condiciones para diferentes servidores (por ejemplo, en la función que comienza en la línea 1523)
  20. IANA.org
  21. ^ Oikarinen, J.; Caña, D. (1993). "RFC 1459: protocolo de chat de retransmisión de Internet" . Herramientas.ietf.org. doi : 10.17487/RFC1459 . Consultado el 3 de marzo de 2010 .{{cite journal}}: Para citar una revista se requiere |journal=( ayuda )
  22. "Estándar STARTTLS" . Archivado del original el 24 de junio de 2008. Consultado el 20 de julio de 2008 .
  23. 1 2 Paul Mutton, Trucos de IRC , O'Reilly Media , 2004, ISBN 0-596-00687-X, págs. 371
  24. Advertencia: consulte la documentación P10
  25. Documentación de ircu P10
  26. "Respuesta al hilo "K-lined por intentar [ sic ] unirse al canal juped ?" en los foros de EFnet" . Consultado el 13 de marzo de 2013 . 
  27. "Freenode, Uso de la red" . Archivado del original el 26 de febrero de 2007. Consultado el 25 de febrero de 2007 .
  28. Versión 1.1.2 del operador IRC
  • irc.org – Recursos de IRC Archivados el 21/02/2011 en Wayback Machine
  • Comparación técnica de los mecanismos de retardo TS y de apodo
  • Manual de DarkFire IRC (específico de la red)
  • Preguntas frecuentes sobre las líneas K y G de Undernet. Archivado el 1 de abril de 2008 en Wayback Machine, con razones para su existencia, entre otras cosas.
  • Preguntas frecuentes de EFnet con explicación de varios términos de la línea -line
  • Preguntas frecuentes generales de Quakenet Línea G/K
  • Sintaxis de GLine, KLine, QLine y ELine