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 2015 -
L'Internet repose en grande partie sur
le DNS (si ce
dernier est en panne, presque plus rien ne fonctionne) et le DNS
doit à sa nature arborescente de dépendre de sa racine ou plus
exactement de ses serveurs
racine. La gestion de ces derniers est donc une
question cruciale, même si les débats sur la gouvernance de
l'Internet se focalisent plutôt sur des sujets moins
concrets comme la création (ou non) du TLD .vin. Ce très
court RFC
précise les obligations des serveurs racine en terme de protocoles réseau à
suivre. D'autres documents décrivent les exigences
opérationnelles. (Voir notamment le RSSAC
001: Service Expectation of Root Servers.)
Avant, ces obligations étaient dans un seul
RFC, le RFC 2870. Il
contenait des recommandations concernant les
protocoles, donc plutôt du ressort de
l'IETF, et d'autres concernant les règles
quotidiennes des opérations d'un serveur racine, considérées
aujourd'hui comme relevant plutôt du RSSAC
(Root Server System Advisory Committee, qui
publie ses propres recommandations dans le document nommé RSSAC-001). Ce RFC
est donc encore plus court que son prédécesseur, désormais
document historique.
À noter que les serveurs racine ne servent pas que la racine, mais aussi
root-servers.net, domaine dans lequel ils
sont nommés. Certains d'entre eux servent également .arpa.
Le cœur de notre RFC est la section 2 qui exige que les serveurs
racine :
- Suivent le protocole DNS (encore
heureux...),
- Soient capables de répondre en IPv4
et IPv6 (en octobre 2015, deux serveurs,
E et G, n'avaient toujours pas d'IPv6),
- Soient capables de répondre en UDP
et en TCP,
- Doivent gérer les sommes de
contrôle UDP,
- Doivent évidemment gérer DNSSEC,
pour pouvoir servir la racine, qui est signée,
- Doivent gérer EDNS (RFC 6891).
La plupart de ces règles vont de soi mais, en 2015, on rencontre
hélas encore des serveurs DNS qui n'ont pas EDNS ou bien qui n'ont
pas TCP (sans même parler d'IPv6...)
Moins liées aux protocoles, il y a deux autres exigences dans
la section 3 :
- Répondre à tous les clients (c'est un principe de neutralité du réseau, qui a
d'amusantes conséquences de gouvernance, par exemple les
serveurs gérés par l'armée US doivent
répondre aux requêtes venant
d'Iran...),
- Servir l'unique racine « officielle », cf. RFC 2826 et pas une éventuelle racine
alternative. Évidemment, cela implique de ne pas la modifier :
les serveurs racine sont des imprimeurs, pas des éditeurs.
Merci à Lancelot et Atlal (et Opale), qui savent pourquoi...
