Quand un utilisateur tape irc.libera.chat dans son client, il ne se connecte pas toujours au meme serveur. Derriere ce nom de domaine, il y a une dizaine de serveurs repartis dans le monde. Le DNS renvoie une IP differente selon l'emplacement de l'utilisateur, la charge des serveurs, et leur disponibilite. Ce mecanisme de distribution est invisible pour l'utilisateur mais essentiel pour la fiabilite du reseau.
Le probleme de la distribution
Un reseau IRC avec plusieurs serveurs a besoin d'un mecanisme pour distribuer les connexions clients entre les serveurs. Sans distribution, tous les utilisateurs se connectent au meme serveur, les autres restent vides, et la redondance est inutile.
Les solutions :
- DNS round-robin : Le plus simple. Le nom de domaine renvoie plusieurs IPs alternativement.
- GeoDNS : Le DNS renvoie l'IP du serveur le plus proche geographiquement.
- Anycast : Plusieurs serveurs partagent la meme IP. Le reseau route vers le plus proche.
- Load balancer TCP : Un proxy (HAProxy, Nginx) distribue les connexions. Possible mais ajoute une couche de complexite et un point de defaillance.
DNS round-robin
# Configuration DNS round-robin :
# Plusieurs records A pour le meme nom
irc.votredomaine.com. 300 A 203.0.113.10
irc.votredomaine.com. 300 A 198.51.100.20
irc.votredomaine.com. 300 A 192.0.2.30
# Le serveur DNS renvoie les 3 IPs dans un ordre
# different a chaque requete (rotation).
# Le client utilise generalement la premiere IP.
# TTL court (300 = 5 minutes) :
# Permet de retirer une IP rapidement si un
# serveur tombe. Apres 5 min, les clients
# ne recoivent plus l'IP retiree.
# Avantages :
# - Extremement simple
# - Fonctionne avec n'importe quel serveur DNS
# - Pas de logiciel supplementaire
# - Distribution raisonnablement equilibree
# Inconvenients :
# - Pas de health check (une IP morte reste dans le DNS
# jusqu'a ce que vous la retiriez manuellement)
# - Pas geographiquement intelligent
# - Certains resolvers DNS cachent le resultat
# et tous les clients d'un resolver vont au meme serveur
# - Le client peut ignorer l'ordre des IPs
Le DNS round-robin est suffisant pour un petit reseau (2-5 serveurs). Sa simplicite est son plus grand atout. Pour un reseau plus grand ou avec des exigences de fiabilite, GeoDNS ou anycast sont preferebles.
GeoDNS
# GeoDNS renvoie l'IP du serveur le plus proche
# de l'utilisateur (base sur l'IP source de la requete DNS)
# Avec PowerDNS + GeoIP backend :
# Zone geo :
$ORIGIN irc.votredomaine.com.
@ IN A 203.0.113.10 ; defaut
@ IN A 203.0.113.10 ; EU (Europe)
@ IN A 198.51.100.20 ; NA (Amerique du Nord)
@ IN A 192.0.2.30 ; AS (Asie)
# Configuration PowerDNS :
# pdns.conf :
launch=geoip
geoip-database-files=/usr/share/GeoIP/GeoLite2-Country.mmdb
geoip-zones-file=/etc/pdns/geo-zones.yaml
# geo-zones.yaml :
domains:
- domain: irc.votredomaine.com
records:
irc.votredomaine.com:
- a:
content: 203.0.113.10
weight: 100
countries: [EU]
- a:
content: 198.51.100.20
weight: 100
countries: [US, CA, MX]
- a:
content: 192.0.2.30
weight: 100
countries: [JP, KR, AU, IN]
# Services GeoDNS manges :
# - Cloudflare (gratuit avec proxy desactive)
# - AWS Route 53 (geolocation routing)
# - NS1
# Ces services ajoutent aussi des health checks.
Anycast
Anycast est une technique ou la meme adresse IP est annoncee (via BGP) depuis plusieurs points de presence. Le reseau route le trafic vers le point le plus proche.
# Fonctionnement anycast :
#
# IP 203.0.113.50 annoncee depuis :
# - Paris (serveur EU)
# - New York (serveur US)
# - Tokyo (serveur AS)
#
# Un utilisateur a Berlin se connecte a 203.0.113.50
# -> Le routage BGP l'envoie a Paris (le plus proche)
#
# Un utilisateur a Montreal se connecte a 203.0.113.50
# -> Le routage BGP l'envoie a New York
# Avantages :
# - Distribution automatique par proximite reseau
# - Si un serveur tombe, BGP retire l'annonce
# et le trafic est redirige vers le suivant
# - L'utilisateur ne change pas d'IP
# (contrairement au DNS round-robin)
# - Excellent pour absorber les DDoS
# (le trafic se dilue geographiquement)
# Inconvenients pour IRC :
# - Complexe a deployer (necessite du BGP,
# donc une ASN et des accords de peering)
# - Risque de rerouting : si le chemin BGP change
# pendant une session TCP, la connexion est coupee
# - Les sessions IRC sont longues (heures/jours)
# ce qui augmente le risque de rerouting
# - Cout eleve (IP provider, transit, equipement)
# En pratique, l'anycast pour IRC est reserve
# aux tres grands reseaux ou aux services
# qui passent par Cloudflare Spectrum.
L'anycast est la solution ideale pour les services web (requetes HTTP courtes), mais problematique pour IRC (connexions TCP longues). Un changement de route BGP coupe la connexion TCP. Pour IRC, GeoDNS avec health checks est generalement un meilleur compromis.
Health checks
# Le probleme du DNS sans health check :
# Si un serveur tombe, son IP reste dans le DNS.
# Les clients continuent d'essayer de se connecter
# a une IP morte pendant le TTL du DNS.
# Solution 1 : Script externe + API DNS
#!/bin/bash
# health_check.sh
SERVERS="203.0.113.10 198.51.100.20 192.0.2.30"
DOMAIN="irc.votredomaine.com"
for ip in $SERVERS; do
# Tester la connexion TCP sur le port 6697
if ! timeout 5 bash -c "echo | openssl s_client \
-connect $ip:6697 2>/dev/null | \
grep -q 'CONNECTED'"; then
echo "$ip DOWN - retrait du DNS"
# Appel API pour retirer l'IP du DNS
# (depend du provider DNS)
curl -X DELETE "https://api.dns.provider/records/$ip"
fi
done
# Executer toutes les minutes via cron
# Solution 2 : AWS Route 53 health checks
# Route 53 verifie la sante des endpoints
# et retire automatiquement les IPs mortes
# du DNS. Configuration via la console AWS
# ou l'API.
# Solution 3 : Script IRC specifique
# Se connecter en IRC et verifier que le serveur
# repond correctement (pas juste TCP ouvert)
import socket
import ssl
def check_irc(host, port=6697, timeout=10):
try:
sock = socket.create_connection((host, port), timeout)
ctx = ssl.create_default_context()
ssock = ctx.wrap_socket(sock, server_hostname=host)
data = ssock.recv(1024).decode()
ssock.close()
return ':' in data # Le serveur envoie un message
except Exception:
return False
Configuration pratique
# Pour un reseau de 3 serveurs, la config recommandee :
# 1. DNS round-robin avec TTL court :
irc.votredomaine.com. 120 A ip.serveur1
irc.votredomaine.com. 120 A ip.serveur2
irc.votredomaine.com. 120 A ip.serveur3
# 2. Records individuels pour acces direct :
eu.irc.votredomaine.com. A ip.serveur1 # Europe
us.irc.votredomaine.com. A ip.serveur2 # USA
as.irc.votredomaine.com. A ip.serveur3 # Asie
# 3. Health check toutes les minutes
# Script qui retire/ajoute les IPs du round-robin
# 4. Documentation dans le MOTD :
# "Si vous avez des problemes de connexion, essayez :
# eu.irc.votredomaine.com (Europe)
# us.irc.votredomaine.com (Amerique)
# as.irc.votredomaine.com (Asie)"
# Cette approche combine :
# - Distribution automatique (round-robin)
# - Choix utilisateur (records individuels)
# - Fiabilite (health checks)
# - Simplicite (pas de GeoDNS ni anycast)
Questions frequentes
HAProxy comme load balancer IRC ?
Possible mais deconseille pour la plupart des cas. HAProxy ajoute un point de defaillance et de la latence. Si HAProxy tombe, tout le reseau est inaccessible. Le DNS round-robin est plus resilient car il n'a pas de composant central. HAProxy est utile si vous avez besoin de fonctionnalites avancees (sticky sessions, TLS termination centralisee), mais pour IRC, le DNS suffit generalement.
Les clients IRC gerent-ils le failover DNS ?
La plupart des clients modernes (irssi, WeeChat, HexChat) essaient les IPs alternatives si la premiere echoue. Mais le comportement depend du client et de la configuration du resolveur DNS. Certains clients ne tentent que la premiere IP. Fournir des records individuels (eu.irc, us.irc) permet aux utilisateurs de choisir manuellement en cas de probleme.
Combien d'IPs dans un round-robin ?
3 a 5 est optimal. Au-dela, la distribution devient inegale (certains resolvers ne retournent pas toutes les IPs). En dessous de 3, la perte d'un serveur surcharge les restants (50% de charge en plus avec 2 serveurs, 33% avec 3). Avec 5 serveurs et un qui tombe, la surcharge n'est que de 25%.