Greboca  

Suport technique et veille technologique

Aujourd’hui, les grandes entreprises et administrations publiques hésitent entre continuer à utiliser des logiciels propriétaires ou basculer vers les Logiciels Libres. Pourtant, la plupart des logiciels libres sont capables de bien traiter les données issues des logiciels propriétaire, et parfois avec une meilleur compatibilité.

C’est alors la barrière de la prise en main qui fait peur, et pourtant...

Les logiciels libres

L’aspect « Logiciel Libre » permet une évolution rapide et une plus grande participation des utilisateurs. Les aides et tutoriels foisonnent sur Internet ou sont directement inclus dans le logiciel lui-même.

Enfin, les concepteurs sont plus proches des utilisateurs, ce qui rend les logiciels libres plus agréable à utiliser et conviviaux.

Grâce à la disponibilité des logiciels libres, vous trouverez facilement des services de support techniques et la licence n’est plus un frein à l’utilisation de ces logiciels par votre personnel.

Notre support technique concerne essentiellement les logiciels libres, que ce soit sous forme de services ponctuels ou de tutoriels.

Blog de Stéphane Bortzmeyer  -  Problème DNSSEC au Libéria

 -  Juin 2024 - 

Le 12 juin, une panne (partielle ?) a touché le TLD .lr. Il s'agit d'un problème DNSSEC (qui a fait l'objet d'un retex détaillé par le gestionnaire technique.

L'alerte a été donné sur la liste de l'OARC. Au matin du 13 juin, on constate :

Les sondes RIPE Atlas sont d'accord pour dire que ça marche mais pas parfaitement :

% blaeu-resolve --requested 200 --type SOA --displayvalidation lr
[ (Authentic Data flag)  rip.psg.com. hostmaster.psg.com. 1718251170 345600 3600 2592000 14400] : 88 occurrences 
[rip.psg.com. hostmaster.psg.com. 1718251170 345600 3600 2592000 14400] : 85 occurrences 
[ERROR: SERVFAIL] : 13 occurrences 
[ERROR: NXDOMAIN] : 11 occurrences 
[ (Authentic Data flag)  rip.psg.com. hostmaster.psg.com. 1718225894 345600 3600 2592000 14400] : 1 occurrences 
[] : 1 occurrences 
Test #73322645 done at 2024-06-13T07:39:43Z
  

L'explication technique est probablement la suivante : en interrogeant tous les serveurs faisant autorité pour .lr, avec la requête lr/DNSKEY, on voit que certains envoient deux signatures (ayant le même identificateur de clé, 29984) :

lr.			86400 IN DNSKEY	257 3 8 (
				AwEAAbdBaOsz0xNn+L+8+GopcC0w9NneWhKl9GJyCR5d …
				) ; KSK; alg = RSASHA256 ; key id = 29984
lr.			86400 IN DNSKEY	256 3 8 (
				AwEAAci9weuAQKBbKsqkOYnm1H0C5a7ZX/8xoQDmNp8Y …
				) ; ZSK; alg = RSASHA256 ; key id = 42940
lr.			86400 IN RRSIG DNSKEY 8 1 86400 (
				20240626012025 20240611235025 29984 lr.
				YeZQ3KiSsDQD3jizNHXnTUYxRtzJwXl0aoctrgqDqajW …
lr.			86400 IN RRSIG DNSKEY 8 1 86400 (
				20240626205813 20240612192813 29984 lr.
				lDt9P1RZtcs+/SDilJZ6tNRsZr+F5EdisfmsNw7E62+1 …
  
Cela ne se voit pas à l'œil nu mais une des deux signatures est invalide (cf. les rapports de DNSviz et Zonemaster). Les résolveurs qui réussissent sont ceux qui sont tombés sur le serveur faisant autorité qui ne servait que la bonne signature, ou bien testaient les deux signatures (d'où l'importance de tester plus qu'une signature, malgré KeyTrap). Notez que, malgré cette différence des réponses, tous les serveurs faisant autorité ont le même numéro de série :
% check-soa lr
fork.sth.dnsnode.net.
	77.72.229.254: OK: 1718251170
	2a01:3f0:0:306::53: OK: 1718251170
ns-lr.afrinic.net.
	196.216.168.61: OK: 1718251170
	2001:43f8:120::61: OK: 1718251170
rip.psg.com.
	2001:418:1::39: OK: 1718251170
	147.28.0.39: OK: 1718251170
  

La commande pour interroger tous les serveurs est :

% for server in 77.72.229.254 2a01:3f0:0:306::53 2001:43f8:120::61 196.216.168.61 2001:418:1::39 147.28.0.39; do
  echo $server
  dig +dnssec @$server lr DNSKEY
done  > lr.txt
  
Comme elle est faite depuis un seul point de mesure (mon bureau), elle a ses limites, notamment, elle ne détectera pas les différences entre instances d'un même nuage anycast.

Y avait-il collision des identificateurs de clé comme en Russie en début d'année ? Comme vu plus loin, le problème était autre. Un indice : le Liban, qui a le même gestionnaire technique, avait le même problème.

Bref, les explications techniques complètes figurent dans cet article très détaillé ; une attaque par déni de service a déclenché une bogue assez bizarre dans le signeur, Knot.

par Stéphane Bortzmeyer

Blog de Stéphane Bortzmeyer

RFC 8738: Automated Certificate Management Environment (ACME) IP Identifier Validation Extension

 -  7 mars - 

Le protocole ACME, surtout connu via son utilisation par l'AC Let's Encrypt, permet de prouver la « possession » d'un nom de domaine, pour avoir un (...)


RFC 8594: The Sunset HTTP Header Field

 -  27 février - 

Un nouvel en-tête HTTP (et un nouveau type de lien) fait son apparition avec ce RFC : Sunset: (coucher de soleil) sert à indiquer la date où la (...)


Si Einstein avait su

 -  24 février - 

Alain Aspect raconte dans ce livre l'histoire des expériences qu'il a menées dans les années 1970-1980 et qui ont prouvé la violation des inégalités (...)


Recommandations DNS lorsqu'on change d'adresse IP

 -  21 février - 

Aujourd'hui, avec les mécanismes d'allocations d'adresses IP existants (cf. RFC 7020), il est relativement fréquent d'avoir à changer son adresse (...)


RFC 9609: Initializing a DNS Resolver with Priming Queries

 -  12 février - 

Un résolveur DNS ne connait au début, rien du contenu du DNS. Rien ? Pas tout à fait, il connait une liste des serveurs de noms faisant autorité (...)