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.
Un problème fréquent avec DNSSEC est de
transmettre à sa zone parente les clés publiques de signature de
sa zone, pour que le parent puisse signer un lien qui va vers ces
clés (l'enregistrement de type DS). Le RFC 7344 apportait une solution partielle, avec ses
enregistrements CDS et CDNSKEY. Il y manquait deux choses : la
création du premier DS (activation initiale de DNSSEC), et le
retrait de tout les DS (on arrête de faire du DNSSEC). Ce nouveau
RFC 8078 comble ces deux manques (et, au passage,
change l'état du RFC 7344, qui passe sur le
Chemin des Normes).
Avant le RFC 7344, tout changement des
clés KSK (Key Signing Key) d'une zone
nécessitait une interaction avec la zone parente, par le biais
d'un mécanisme non-DNS (« out-of-band », par
exemple un formulaire Web). La solution du RFC 7344, elle, n'utilise que le DNS
(« in-band »). Ce nouveau
RFC complète le RFC 7344 pour les configurations initiales et
finales. (Le problème est complexe
car il peut y avoir beaucoup d'acteurs en jeu. Par exemple, le
BE n'est pas forcément l'hébergeur
DNS. Ces difficultés ont certainement nui
au déploiement de DNSSEC.)
Lorsqu'on change d'hébergeur DNS, la solution la plus propre
est de faire un remplacement des clés, depuis celle de l'ancien
hébergeur jusqu'à celle du nouveau. Cette solution préserve en
permanence la sécurité qu'offre DNSSEC. Mais
une des procédures mentionnées par notre RFC passe au contraire
par un état non sécurisé, où la zone n'est pas signée. C'est
dommage mais cela est parfois nécessaire si :
- Les logiciels utilisés ne permettent pas de faire
mieux, ou l'un des deux hébergeurs ne veut pas suivre la
procédure « propre »,
- Ou bien le nouvel hébergeur ne gère pas DNSSEC du tout, ou
encore le titulaire de la zone ne veut plus de DNSSEC.
Une zone non signée vaut certainement mieux qu'une signature
invalide. Mais le RFC oublie de dire que cela va casser certaines
applications de sécurité qui exigent DNSSEC comme
DANE (RFC 6698) ou
SSHFP (RFC 4255).
Avant de lire la suite de ce RFC, deux conseils :
- Lisez bien le RFC 7344. Vraiment.
- Rappelez-vous qu'il y a des tas d'acteurs possibles dans
le DNS. Le modèle RRR (Titulaire-BE-Registre,
Registrant-Registrar-Registry) n'est
pas le seul. Et il n'y a pas que les
TLD qui délèguent des zones ! Le RFC
parle donc uniquement de « parent » (responsable parental ?) pour désigner l'entité à
laquelle on s'adresse pour obtenir des changements dans la zone parente.
Les enregistrements CDS (Client-side Delegation
Signer) servent à trois choses (section 2 du RFC) :
- Installer le DS (Delegation Signer)
initial dans la zone parente,
- Remplacer (rollover) la clé publique de
signature des clés (KSK, Key-Signing Key)
dans la zone parente,
- Supprimer le DS de la zone parente, débrayant ainsi la
validation DNSSEC de la zone fille chez les résolveurs.
Avec le RFC 7344, seule la deuxième était
possible (c'est la moins dangereuse, qui ne nécessite aucun
changement dans les relations de confiance,notamment entre parente
et fille). Notre RFC 8078 permet désormais les deux
autres, plus délicates, car posant davantage de problèmes de sécurité.
La sémantique des enregistrements CDS (ou CDNSKEY) est donc
désormais « la publication d'un ou plusieurs CDS indique un
souhait de synchronisation avec la zone parente ; celle-ci est
supposée avoir une politique en place pour
accepter/refuser/vérifier ce ou ces CDS, pour chacune des trois
utilisations notées ci-dessus ». Quand des CDS différents des DS
existants apparaissent dans la zone fille, le responsable parental
doit agir.
D'abord, l'installation initiale d'un DS alors qu'il n'y en
avait pas avant (section 3 du RFC). La seule apparition du CDS ou
du CDNSKEY ne peut pas suffire car comment le vérifier, n'ayant
pas encore de chaîne DNSSEC complète ? Le responsable parental
peut utiliser les techniques suivantes :
- Utiliser un autre canal, extérieur au DNS, par exemple
l'API du responsable parental,
- Utiliser des tests de vraisemblance, du genre un
message de
confirmation envoyé au contact technique du domaine, ou bien
regarder si la configuration du domaine est stable,
- Attendre un certain temps, de préférence vérifier depuis plusieurs
endroits dans le réseau (pour éviter les
empoisonnements locaux),
puis considérer le CDS comme
valable s'il est resté pendant ce temps (l'idée est qu'un
piratage aurait été détecté, pendant ce délai),
- Envoyer un défi au titulaire de la zone fille, par exemple
génerer une valeur aléatoire et lui demander de l'insérer sous
forme d'un enregistrement TXT dans la zone (bien des
applications qui veulent vérifier le responsable d'un domaine
font cela, par exemple Keybase ou bien
Google webmasters),
- Accepter immédiatement s'il s'agit d'une nouvelle
délégation. Ainsi, le domaine sera signé et validable dès le
début.
La deuxième utilisation des CDS, remplacer une clé est, on l'a
vu, déjà couverte par le RFC 7344.
Et pour la troisième utilisation, la suppression de tous les DS
chez le parent ? Elle fait l'objet de la section 4 du RFC. Pour
demander cette suppression, on publie un CDS (ou un CDNSKEY) avec
un champ « algorithme » à zéro. Cette valeur n'est pas affectée
à un vrai algorithme dans le
registre officiel, elle est
réservée (cf. section 6 du RFC)
pour dire « efface ». (Le RFC 4398 utilisait
déjà le même truc.)
Pour éviter tout accident, le RFC est plus exigeant que cela et
exige cette valeur spécifique pour ces enregistrements :
DOMAINNAME IN CDS 0 0 0 0
ou bien :
DOMAINNNAME IN CDNSKEY 0 3 0 0
(Le 3 étant l'actuel numéro de version de DNSSEC, voir le
RFC 4034, section 2.1.2.)
Une fois le CDS (ou CDNSKEY) « zéro » détecté, et validé par
DNSSEC, le parent retire
le DS. Une fois le TTL passé, le fils peut
« dé-signer » la zone.
À noter que ce RFC a été retardé par la question du déplacement
du RFC 7344, de son état « pour
information », au Chemin des Normes. La demande était discrète, et
avait été raté par certains relecteurs, qui ont protesté ensuite
contre ce « cavalier ». L'« élévation » du RFC 7344 est désormais explicite.
RFC 9562: Universally Unique IDentifiers (UUIDs)
- 12 mai -
Ce RFC normalise les UUID, une famille d'identificateurs uniques, obtenus sans registre central. Il remplace l'ancienne norme, le RFC 4122, avec (...)
RFC 9490: Report from the IAB Workshop on Management Techniques in Encrypted Networks (M-TEN)
- 9 mai -
Aujourd'hui, l'essentiel du trafic sur l'Internet est chiffré, et pour d'excellentes raisons. Pas question de revenir là-dessus, mais, ceci dit, il (...)
RFC 9557: Date and Time on the Internet: Timestamps with Additional Information
- 29 avril -
Ce RFC modifie légèrement le format des estampilles temporelles du RFC 3339, changeant à la marge une définition et, surtout, permettant d'y attacher (...)
RFC 9567: DNS Error Reporting
- 27 avril -
Lorsqu'un résolveur DNS détecte un problème avec une zone, l'empêchant de résoudre les noms dans cette zone, il n'avait pas de moyen simple et (...)
RFC 9460: Service Binding and Parameter Specification via the DNS (SVCB and HTTPS Resource Records)
- 8 avril -
Ces deux nouveaux types d'enregistrement DNS, SVCB et sa variante HTTPS, permettent de donner des informations supplémentaires à un client réseau (...)