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.
- Décembre 2021 -
Rien de très grave dans ce nouveau RFC, qui règle un problème surtout
bureaucratique, le fait que les politiques d'inclusion dans les
registres IANA pour certains algorithmes utilisés par
DNSSEC n'étaient pas parfaitement
alignées.
En effet, le RFC 6014 avait modifié la
politique d'enregistrement des algorithmes cryptographiques de
« Action de normalisation » à la plus laxiste « RFC nécessaire »
(rappelez-vous que tous les RFC ne sont pas des normes, voir le RFC 8126 qui décrit ces politiques possibles). Mais
cette « libéralisation » laissait de côté certains algorithmes, ceux
utilisés pour les enregistrements DS (RFC 4034), et ceux utilisés pour
NSEC3 (RFC 5155), qui
restaient en « Action de normalisation ». Notre nouveau RFC aligne
les politiques d'enregistrement des algorithmes utilisés pour les DS
et pour NSEC3 pour qu'ils soient eux aussi « RFC nécessaire ».
Il modifie également le RFC 8624 pour
préciser que les algorithmes normalisés dans des RFC qui ne sont pas
sur le chemin des normes sont également couverts par les règles du
RFC 8624 ; en gros, ils sont facultatifs
(MAY dans le langage du RFC 2119).
Les registres concernés sur celui
sur NSEC3 et celui sur DS. Ils portent
désormais la mention RFC Required.
Comme l'enregistrement d'algorithmes va, du fait de ce RFC, être
plus léger, cela facilitera l'enregistrement de bons algorithmes,
mais aussi de mauvais. Le programmeur qui met en œuvre DNSSEC, ou
l'administratrice système qui le déploie, ne doit donc pas
considérer que la présence dans un registre IANA vaut forcément
approbation de la solidité cryptographique de l'algorithme. Il
faut consulter la littérature technique avant d'utiliser ces
algorithmes.
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 (...)
