Planet Collab

🔒
❌ About FreshRSS
There are new articles available, click to refresh the page.
Today — December 1st 2021Your RSS feeds

RFC 9138: Design Considerations for Name Resolution Service in Information-Centric Networking (ICN)

L'ICN est l'idĂ©e (trĂšs contestable) qu'un rĂ©seau informatique sert Ă  accĂ©der Ă  du « contenu » et que le rĂ©seau doit donc ĂȘtre architecturĂ© autour de cette idĂ©e de contenu. Les noms identifient ainsi un contenu donnĂ©. Mais il faut bien ensuite trouver le contenu donc rĂ©soudre ces noms en quelque chose de plus concret. Ce RFC est le cahier des charges d'un tel systĂšme de rĂ©solution de noms pour les projets ICN. Comme beaucoup de cahier des charges, il est trĂšs « liste au PĂšre NoĂ«l », accumulant des desiderata sans se demander s'ils sont rĂ©alistes (et compatibles entre eux !)

Comme avec beaucoup de documents qui promeuvent l'ICN, ce RFC donne une description erronée du nommage et de l'adressage dans l'Internet d'aujourd'hui. Passons, et voyons ce que l'ICN propose. L'idée est que le contenu est stocké dans des NDO (Named Data Objects) et que toute activité dans le réseau coniste à récupérer des NDO. Les NDO sont identifiés par un nom. Il ne s'agit pas seulement d'un identificateur mis au-dessus d'un réseau architecturé sur d'autres concepts (comme le sont les URI) mais du concept de base du réseau ; les routeurs ne routent plus selon des adresses mais selon les noms des NDO. Le problÚme est évidemment qu'il faudra bien, à la fin, trouver l'objet désiré. Cela nécessite (cf. RFC 7927) :

  • Un mĂ©canisme de rĂ©solution des noms en de l'information plus concrĂšte (une localisation, un autre nom, etc),
  • un mĂ©canisme de routage vers l'endroit oĂč se trouve le NDO,
  • un mĂ©canisme de rĂ©cupĂ©ration du NDO.
Ce RFC se focalise sur le premier point, le NRS (Name Resolution Service), et en est le cahier des charges. Un futur RFC décrira l'architecture envisagée. Si vous voulez apprendre des choses sur les ICN en général et la résolution de noms en particulier, voir par exemple « A Survey of Information-Centric Networking » ou « A Survey of Information-Centric Networking Research ».

Si on compare avec l'Internet actuel, le NRS aura un rĂŽle analogue Ă  celui de BGP (plutĂŽt que du DNS, car le NRS sera au cƓur du rĂ©seau, et complĂštement insĂ©parable). Bon, ceci dit, c'est plus compliquĂ© que cela car, derriĂšre l'Ă©tiquette « ICN », il y a des tas de propositions diffĂ©rentes. Par exemple, certaines ressemblent plutĂŽt Ă  l'Internet actuel, avec une rĂ©solution de noms en localisateurs qui servent ensuite pour le routage (comme dans IDnet, cf. « IDNet: Beyond All-IP Network), alors que d'autres versions du concept d'ICN utilisent les noms pour le routage (comme le NDN ou le CCNx du RFC 8569). La section 2.4 du RFC compare ces approches.

La section 3 du RFC est ensuite le cahier des charges proprement dit. Malheureusement, elle plane au-dessus des rĂ©alitĂ©s quand elle affirme par exemple qu'il faut un NRS qui fonctionnera de la mĂȘme façon que l'espace de nommage soit plat ou hiĂ©rarchique. C'est trĂšs irrĂ©aliste, il n'y a pas de nette sĂ©paration entre la structure de l'espace de nommage et le mĂ©canisme de rĂ©solution. Ainsi, ce mĂ©canisme, dans le cas du DNS, est trĂšs liĂ© Ă  la structure des noms. Si on la change, tout le DNS serait Ă  refaire (et sans doute en moins efficace). Parmi les systĂšmes d'ICN qui utilisent un nommage hiĂ©rarchique (et rĂ©introduisent donc une forme de « localisation » dans les noms), on trouve NDN et CCNx.

Certains des mécanismes de résolution discutés ont déjà un RFC, par exemple le NI du RFC 6920, utilisé dans NetInf (cf. « Network of Information (NetInf) - An information-centric networking architecture »).

Bref, les principes du NRS :

  • Fonctionner avec des structures d'espaces de noms diffĂ©rentes (cf. ma critique ci-dessus),
  • accepter la mobilitĂ© des contenus,
  • passer Ă  l'Ă©chelle (ce qui est trivial avec des noms hiĂ©rarchiques, beaucoup moins avec des noms plats),
  • permettre la mĂ©morisation (caching),
  • accepter que les objets soient identifiĂ©s par un nom choisi ou par un condensat du contenu (ce que le RFC nomme les « objets sans nom », ce qui me semble accroitre encore la confusion),
  • permettre enfin de rĂ©cupĂ©rer des mĂ©tadonnĂ©es et pas seulement le localisateur.

Et le cahier des charges à proprement parler est en section 4. Je ne cite pas tout mais la liste au PÚre Noël comprend :

  • Des rĂ©ponses rapides (« en un temps raisonnable »),
  • des rĂ©ponses correctes (on voit bien le ridicule de l'approche par cahier des charges, quand il faut prĂ©ciser explicitement des points aussi Ă©vidents), et Ă  jour (lĂ  encore, « raisonnablement »),
  • des rĂ©ponses justes, respectant un principe de neutralitĂ© (pas de censure ? L'ARCOM n'aimerait pas),
  • un fonctionnement satisfaisant sur des rĂ©seaux de grande taille (le RFC mentionne au moins 10^21 objets),
  • un systĂšme gĂ©rable (pouvant s'adapter avec par exemple l'ajout et le retrait de nƓuds),
  • la capacitĂ© Ă  ĂȘtre rĂ©ellement dĂ©ployĂ© (lĂ  encore, on a envie de dire « encore heureux »),
  • la rĂ©sistance aux pannes (la panne d'une machine ne doit pas arrĂȘter le NRS), et aux attaques par dĂ©ni de service,
  • la confidentialitĂ© des requĂȘtes (un problĂšme pour le DNS, cf. RFC 7626), mais aussi des donnĂ©es (le RFC mentionne des ACL sur les noms, chose qui n'existe pas vraiment dans le DNS)
  • l'authentification des serveurs, des producteurs de noms (par exemple pour que seule l'entitĂ© qui a enregistrĂ© un nom puisse modifier les donnĂ©es associĂ©es), et des donnĂ©es elle-mĂȘmes (ce que DNSSEC fournit au DNS),

Une conclusion ? Les projets regroupés sous le nom d'ICN sont assez anciens, n'ont rien fait de vraiment nouveau récemment, et il y a peu de chances que ce RFC soit suivi de réalisations concrÚtes.

RFC 9157: Revised IANA Considerations for DNSSEC

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.

Before yesterdayYour RSS feeds

Digital roots

Dans le débat public au sujet de l'Internet et du Web, il y a beaucoup de concepts qui sont discutés comme s'ils étaient nouveaux alors qu'ils ont en fait des racines anciennes (gouvernance, bulle de filtre, authenticité, participation d'amateurs
). Cet ouvrage collectif (en anglais) réunit plusieurs contributions qui analysent l'histoire d'un concept et ses origines, souvent bien antérieures au monde numérique.

Le livre a impliquĂ© de nombreuses contributrices et de nombreux contributeurs (celles et ceux cité·es au dĂ©but de cet article sont « juste » les coordinateurices). Chacun·e s'est attaquĂ© Ă  un concept particulier, montrant son historicitĂ©. Mon exemple favori a toujours Ă©tĂ© les soi-disant fake news, prĂ©sentĂ©es comme une nouveautĂ© du Web alors que le mensonge est aussi ancien que la communication. (Mais, en mettant le terme en anglais, on peut faire croire que c'est quelque chose de nouveau.) La version papier du livre est coĂ»teuse mais il est sous une licence Creative Commons et peut ĂȘtre tĂ©lĂ©chargĂ©.

Bien sûr, en insistant sur l'ancienneté d'un concept, et des débats qui l'ont toujours accompagné, il ne s'agit pas de dire que rien n'est nouveau, que tout existait déjà dans l'Antiquité. Mais juste de rappeler que la pression médiatico-commerciale a tendance à gommer le passé et à mettre en avant tous les mois un truc présenté comme nouveau.

Le livre commence logiquement par le concept de réseau, qui existait avant les réseaux informatiques, comme le réseau routier de l'empire romain (en étoile, « tous les chemins mÚnent à Rome », ce qui matérialisait la position dominante de la capitale), ou, plus récemment, le réseau télégraphique. Ces anciens réseaux ont déjà fait l'objet d'innombrables études et réflexions, rappelées par Massimo Rospocher et Gabriele Balbi. Certaines de ces études et réflexions s'appliquent toujours à l'Úre de l'Internet. Le concept de multimédia fait l'objet d'un passionnant article de Katie Day Good, qui évoque les espoirs qu'avaient fait naitre les nouveaux médias, par exemple dans le domaine de l'éducation. Les commerciaux des entreprises liées à la radio annonçaient sans rire que radio et autres médias nouveaux à l'époque allaient révolutionner l'enseignement. On retrouve dans les textes de la premiÚre moitié du XXe siÚcle bien des illusions technosolutionnistes d'aujourd'hui. Toujours dans la technique, l'intelligence artificielle est bien sûr à l'honneur, tant le concept est ancien mais ressort réguliÚrement comme solution miracle à tous les problÚmes (article de Paolo Bory, Simone Natale et Dominique Trudel).

AprĂšs la technique, la politique. « Gouvernance » est Ă©galement un concept prĂ©sentĂ© comme nouveau alors que la politique (arriver Ă  prendre des dĂ©cisions quand tout le monde n'a pas les mĂȘmes intĂ©rĂȘts et les mĂȘmes opinions) est Ă©tudiĂ©e depuis pas mal de siĂšcles. Comme le rappellent Francesca Musiani et ValĂ©rie Schafer, la politique sur l'Internet a des particularitĂ©s nouvelles, mais les questions politiques liĂ©es Ă  l'Ă©mergence d'un nouveau rĂ©seau ne sont pas, elles, une nouveautĂ©. On se posait des questions de gouvernance bien avant l'Internet, par exemple avec le tĂ©lĂ©graphe. De mĂȘme, l'usage de donnĂ©es pour gouverner (la « dataification »), analysĂ©e par Eric Koenen, Christian Schwarzenegger et Juraj Kittler, remonte Ă  longtemps, par exemple aux efforts de Jean-Baptiste Colbert en France pour que tout ce qui se passe en France lui soit transmis. On fichait dĂ©jĂ  tout, avant que l'arrivĂ©e des ordinateurs n'accĂ©lĂšre considĂ©rablement la quantitĂ© de donnĂ©es rĂ©coltĂ©es, et on en espĂ©rait dĂ©jĂ , avant qu'on parle de big data un gouvernement plus efficace. Évidemment, le concept de fake news a droit Ă  son article, et Monika Hanley et Allen Munoriyarwa font un intĂ©ressant historique de l'histoire de la tromperie et de la propagande mensongĂšre, remontant au second triumvirat de Rome, en 43 avant l'Ăšre commune, et passant par le XIXe siĂšcle, oĂč l'extension de la littĂ©ratie et la diffusion massive des journaux allait pouvoir faire dĂ©coller cette activitĂ© (un fait que les mĂ©dias d'aujourd'hui oublient quand ils critiquent les fake news diffusĂ©es sur le Web). MĂȘme regard critique de Maria Löblich et Niklas Venema sur les « bulles de filtre », qui ne sont pas apparues avec les « algorithmes » des rĂ©seaux sociaux.

Une autre section traite des utilisateurs et de leurs pratiques. JĂ©rĂŽme Bourdon traite le cas de la prĂ©sence et de la distance. Quand on communique « en prĂ©sentiel » et pas par courrier Ă©lectronique, est-ce qu'on communique « en vrai » ? Des gens avec qui on n'interagit qu'en ligne sont-ils de « vrais » ami·es ? Et, pour prendre un exemple rĂ©cent, une rĂ©union en ligne est-elle une vraie rĂ©union ? CicĂ©ron et Madame de SĂ©vignĂ© sont citĂ©s pour leurs rĂ©flexions Ă  ce sujet, montrant qu'Ă  chaque Ă©poque, des gens s'inquiĂ©taient de savoir ce qu'Ă©tait la prĂ©sence. Dans son article sur la solitude, Edward Brennan poursuit le mĂȘme genre de rĂ©flexions, ce qui permet de relativiser certaines inquiĂ©tudes sur « l'adolescent dans sa chambre qui n'interagit qu'en ligne ». Autre phĂ©nomĂšne social Ă©tudiĂ©, les fans et leurs pratiques (j'en profite pour vous recommander le livre de MĂ©lanie Bourdaa sur ce sujet des fans). Eleonora Benecchi et Erika Ningxin Wang dĂ©crivent le phĂ©nomĂšne du fandom. Par contre, il est curieux qu'elles commencent par brandir des Ă©tiquettes raciales et prĂ©tendent avoir une approche « dĂ©coloniale » quand les seuls exemples non-« occidentaux » citĂ©s sont ceux de pays qui n'ont pas Ă©tĂ© colonisĂ©s (Chine et Japon). Et puis commencer par dire que la Chine est diffĂ©rente de l'Occident pour donner ensuite comme exemple que les fans, en Chine, ont une relation affective avec le personnage de fiction qu'ils aiment
 Comme si ce n'Ă©tait pas le cas de tous les fans
 C'est l'avantage et l'inconvĂ©nient des ouvrages collectifs, il n'y a pas d'unitĂ©. Mais la quasi-totalitĂ© des articles sont excellents (je ne les ai pas tous citĂ©s ici).

Ce livre est écrit par des universitaires pour un public déterminé à s'accrocher un peu. Mais cela vaut la peine, j'y ai appris beaucoup de choses et j'ai bien perçu la profondeur de ces questions, qui agitent l'humanité depuis longtemps.

Les RFC les plus cités sur ce blog

Une statistique tout à fait inutile mais, bon, on est dimanche soir. Quels sont les RFC les plus cités sur ce blog ?

Je mentionne en effet trÚs souvent des RFC et je pointe vers l'article de résumé que j'ai écrit. La façon dont ce blog est écrit permet facilement d'écrire un petit programme pour voir quels RFC sont les plus fréquemment utilisés ici, un critÚre de tri qui en vaut bien d'autres :

 
% ./most-cited-rfcs.py 
RFC 1918: 66 times
RFC 5246: 66 times
RFC 1035: 63 times
...
  

On trouve donc dans l'ordre décroissant des citations sur ce blog :

  • Le RFC 1918, sur les adresses IPv4 privĂ©es, souvent citĂ© car, tant que tout le monde ne se sera pas dĂ©cidĂ© Ă  dĂ©ployer IPv6, il reste indispensable, vu la pĂ©nurie des adresses IPv4.
  • Le RFC 5246, sur l'ancienne version du protocole de cryptographie TLS, la version 1.2. Depuis, la version 1.3 a Ă©tĂ© normalisĂ©e (dans le RFC 8446) et ce nombre de citations ne devrait donc pas augmenter.
  • Le RFC 1035, sur le DNS, qui normalise le format des enregistrements DNS et les dĂ©tails concrets du protocole. Il est logique qu'un RFC sur le DNS apparaisse dans cette liste en bonne position, le DNS Ă©tant Ă  la fois mon activitĂ© professionnelle et un sujet que je connais bien et dont je parle souvent.
  • Le RFC 4271, sur BGP. Avec le DNS, c'est l'autre grand protocole d'infrastructure sur l'Internet, ce qui explique sa prĂ©sence.
  • Le RFC 5226, sur les rĂšgles d'enregistrement dans les registres IANA. Ce RFC ne dĂ©crit donc pas un protocole, mais remplit un rĂŽle plus politico-bureaucratique. LĂ  aussi, il a Ă©tĂ© remplacĂ© par un RFC plus rĂ©cent, le RFC 8126, et devrait donc logiquement reculer dans le classement.
  • Le RFC 1034, Ă©galement sur le DNS. C'est le deuxiĂšme RFC de la norme originale (qui n'a pas Ă©tĂ© remplacĂ©e par des RFC plus rĂ©cents), consacrĂ© aux concepts.
  • Le RFC 3986, qui normalise les URI. Ces identificateurs sont une invention gĂ©niale, et un des trois piliers du Web, avec HTTP et HTML. Ils sont mĂȘme utilisĂ©s en dehors du Web, par exemple pour Gemini.
  • Le RFC 4862, sur l'auto-configuration sans Ă©tat (SLAAC, StateLess Address AutoConfiguration) d'IPv6, une des nouveautĂ©s d'IPv6 qui n'a pas vraiment d'Ă©quivalent dans IPv4 (alors que la plupart des concepts sont communs aux deux versions d'IP).
  • Le RFC 8415 dĂ©crit un autre moyen en IPv6 d'attribuer une adresse IP Ă  une machine, DHCP.
  • Le RFC 5322, est le RFC sur l'IMF (Internet Message Format), le format des messages de courrier Ă©lectronique (vous savez, les From:, Date:, Subject:
). L'importance du courrier Ă©lectronique explique sa bonne position dans cette liste. À noter que beaucoup de gens citent encore le RFC 822, qui n'est plus la norme de l'IMF depuis bien longtemps.
  • Le RFC 793 est toujours aujourd'hui le RFC sur TCP, le protocole de transport qui, malgrĂ© la concurrence rĂ©cente de QUIC, fait passer l'essentiel des octets qui circulent sur l'Internet. Il n'a pas Ă©tĂ© remplacĂ© mais bien d'autres RFC sont aujourd'hui nĂ©cessaires pour comprendre TCP, je vous recommande la liste du RFC 7414.
  • Et le RFC 7231, un des RFC sur HTTP 1, qui normalise notamment la sĂ©mantique des messages. LĂ  aussi, sa prĂ©sence est logique, vu l'importance de HTTP dans l'Internet d'aujourd'hui.

Évidemment, cette liste reflĂšte surtout les choix Ă©ditoriaux de l'auteur et n'indique donc pas une quelconque « importance » de tel ou tel RFC.

Python script – a simple crontab test to run your python code

November 26th 2021 at 05:56

jdoe@u20sn1:~/test_cron$ cat cron_test.py

  1. Write a simple code
from datetime import datetime

now = datetime.now()
current_time = now.strftime("%H:%M:%S")

file_path = "/home/jdoe/test_cron/cron_test_output.txt" # <<< use an absolute path!

with open(file_path, 'a') as f:
    f.write(current_time + " Hi World!\n")

2. Schedule


jdoe@u20sn1:~/test_cron$ crontab -e

* * * * * python3 /home/jdoe/test_cron/cron_test.py

jdoe@u20sn1:~/test_cron$ crontab -l

* * * * * python3 /home/jdoe/test_cron/cron_test.py

Note: “* * * * *” means, every minute. e.g) “*/5 * * * *” is for every 5 minutes and so on.

Check out https://crontab.guru/ to learn more about the cron schedule.

If you are using AWS server to schedule a task to run, visit their website for more information.

https://docs.aws.amazon.com/AmazonCloudWatch/latest/events/ScheduledEvents.html

I also discuss how to use corn to schedule Python applications in my book.

3. Check

jdoe@u20sn1:~/test_cron$ cat cron_test_output.txt
04:26:01 Hi World!
04:27:01 Hi World!
04:28:01 Hi World!
04:29:01 Hi World!
04:30:02 Hi World!
04:31:01 Hi World!

italchemy

Python script – a simple crontab test to run your python code

November 26th 2021 at 05:56

jdoe@u20sn1:~/test_cron$ cat cron_test.py

  1. Write a simple code
from datetime import datetime

now = datetime.now()
current_time = now.strftime("%H:%M:%S")

file_path = "/home/jdoe/test_cron/cron_test_output.txt" # <<< use an absolute path!

with open(file_path, 'a') as f:
    f.write(current_time + " Hi World!\n")

2. Schedule


jdoe@u20sn1:~/test_cron$ crontab -e

* * * * * python3 /home/jdoe/test_cron/cron_test.py

jdoe@u20sn1:~/test_cron$ crontab -l

* * * * * python3 /home/jdoe/test_cron/cron_test.py

Note: “* * * * *” means, every minute. e.g) “*/5 * * * *” is for every 5 minutes and so on.

Check out https://crontab.guru/ to learn more about the cron schedule.

If you are using AWS server to schedule a task to run, visit their website for more information.

https://docs.aws.amazon.com/AmazonCloudWatch/latest/events/ScheduledEvents.html

I also discuss how to use corn to schedule Python applications in my book.

3. Check

jdoe@u20sn1:~/test_cron$ cat cron_test_output.txt
04:26:01 Hi World!
04:27:01 Hi World!
04:28:01 Hi World!
04:29:01 Hi World!
04:30:02 Hi World!
04:31:01 Hi World!

RFC 9156: DNS Query Name Minimisation to Improve Privacy

ProtĂ©ger la vie privĂ©e sur l'Internet nĂ©cessite au moins deux techniques : chiffrer les donnĂ©es en transit pour Ă©viter leur lecture par des tiers et minimiser les donnĂ©es qu'on envoie, pour Ă©viter les abus par les rĂ©cepteurs des donnĂ©es. Ce deuxiĂšme point, pourtant bien mis en avant dans la loi Informatique & LibertĂ©s ou dans le RGPD est souvent oubliĂ©. Ce RFC applique ce principe au DNS : il ne faut pas envoyer aux serveurs faisant autoritĂ© le nom de domaine complet mais seulement la partie du nom de domaine qui lui est strictement nĂ©cessaire pour rĂ©pondre, le minimum. Cette norme succĂšde au RFC 7816, qui Ă©tait purement expĂ©rimental alors que cette minimisation de la requĂȘte (QNAME minimisation) est dĂ©sormais une norme. Le principal changement est la recommandation d'utiliser le type de donnĂ©es A (adresse IPv4) et plus NS (serveurs de noms).

Ce principe de minimisation, qui devrait ĂȘtre central dans toute approche de la protection de la vie privĂ©e est Ă©galement exposĂ© dans le RFC 6973, section 6.1. Le DNS violait ce principe puisque, traditionnellement, un rĂ©solveur DNS qui recevait une demande d'information sur www.foobar.example transmettait aux serveurs faisant autoritĂ© la question complĂšte, alors que, par exemple, les serveurs faisant autoritĂ© pour la racine ne connaissent que les TLD et que leur demander simplement des informations sur le TLD .example aurait suffi. (Voir le RFC 7626 pour une analyse complĂšte des relations entre le DNS et la vie privĂ©e.) Cette tradition (qui ne s'appuyait sur aucune norme technique) est remise en cause par la QNAME minimisation qui demande au contraire qu'on n'envoie aux serveurs faisant autoritĂ© que le nom minimal (example Ă  la racine, foobar.example aux serveurs du TLD .example, etc).

Cette minimisation est unilatérale, elle ne nécessite qu'un changement des résolveurs, sans toucher aux serveurs faisant autorité puisqu'elle ne change pas le protocole DNS. Depuis la sortie du RFC 7816, en 2016, elle a été largement déployée (si le résolveur que vous utilisez ne le fait pas, réclamez-le à votre service informatique !).

Le prĂ©cĂ©dent RFC sur cette technique, le RFC 7816 avait le statut d'expĂ©rimentation alors que notre RFC 9156 est dĂ©sormais une norme. En effet, une expĂ©rience considĂ©rable a Ă©tĂ© accumulĂ©e depuis le RFC 7816, qui a Ă©tĂ© mis en Ɠuvre dans pratiquement tous les rĂ©solveurs, et souvent activĂ©. Le FUD souvent entendu comme quoi la QNAME minimisation allait tuer Internet et des chatons a Ă©tĂ© largement rĂ©futĂ©. Les leçons tirĂ©es sont documentĂ©es dans « DNSThought QNAME minimisation results. Using Atlas probes », « Maximizing Qname Minimization: A New Chapter in DNS Protocol Evolution », « Measuring Query Name Minimization » et « A First Look at QNAME Minimization in the Domain Name System ».

Maintenant, la pratique, comment fait-on de la QNAME minimisation ? La question envoyĂ©e par le rĂ©solveur au serveur faisant autoritĂ© comprend un QNAME (Query Name, le nom demandĂ©) et un QTYPE (Query Type, le type de donnĂ©es, par exemple serveur de courrier, adresse IP, texte libre, etc). Avec la QNAME minimisation, le nom doit ĂȘtre le nom le plus court possible. Quand le rĂ©solveur interroge un serveur racine, il n'envoie comme QNAME que le TLD, par exemple. Trouver « le plus court possible » n'est pas forcĂ©ment trivial en raison des coupures de zone. Dans un nom comme miaou.foo.bar.example, foo.bar.example et bar.example font peut-ĂȘtre partie de la mĂȘme zone (et ont donc les mĂȘmes serveurs faisant autoritĂ©) et peut-ĂȘtre pas. Rien dans la syntaxe du nom ne l'indique. Contrairement Ă  une idĂ©e fausse et rĂ©pandue, il n'y a pas forcĂ©ment une coupure de zone pour chaque point dans le nom. Trouver les coupures de zone est expliquĂ© dans le RFC 2181, section 6. Un rĂ©solveur qui valide avec DNSSEC doit savoir trouver ces coupures, pour savoir Ă  qui demander les enregistrements de type DS. Les autres (mais quelle idĂ©e, en 2021, d'avoir un rĂ©solveur qui ne valide pas) doivent s'y mettre. Si, par exemple, foo.bar.example et bar.example sont dans la mĂȘme zone, le rĂ©solveur qui veut trouver des donnĂ©es associĂ©es Ă  miaou.foo.bar.example va envoyer le QNAME example Ă  la racine, puis bar.example au serveur du TLD, puis miaou.foo.bar.example au serveur de bar.example. (Avant la QNAME minimisation, il aurait envoyĂ© le QNAME miaou.foo.bar.example Ă  tout le monde.)

Cela, c'était pour le QNAME. Et le QTYPE ? On peut choisir celui qu'on veut (à l'exception de ceux qui ne sont pas dans la zone, comme le DS), puisque les délégations de zones ne dépendent pas du type. Mais, et c'est un sérieux changement depuis le RFC 7816, notre RFC recommande le type A (ou AAAA), celui des adresses IP, et plus le type NS (les serveurs de noms), que recommandait le RFC 7816. Deux raisons à ce changement :

  • Certaines middleboxes boguĂ©es jettent les questions DNS portant sur des types qu'elles ne connaissent pas. Le type A passe Ă  coup sĂ»r.
  • Le but de la QNAME minimisation Ă©tant la protection de la vie privĂ©e, il vaut mieux ne pas se distinguer et, notamment, ne pas dire franchement qu'on fait de la QNAME minimisation (les requĂȘtes explicites pour le type NS Ă©taient rares). Un serveur faisant autoritĂ©, ou un surveillant qui espionne le trafic, ne peut donc pas dĂ©terminer facilement si un client fait de la QNAME minimisation.

Vous voyez ici le schéma de la résolution DNS sans la QNAME minimisation puis avec :

Dans certains cas, la QNAME minimisation peut augmenter le nombre de requĂȘtes DNS envoyĂ©es par le rĂ©solveur. Si un nom comporte dix composants (ce qui arrive dans des domaines ip6.arpa), il faudra dans certains cas dix requĂȘtes au lieu de deux ou trois. Les RFC 8020 et RFC 8198 peuvent aider Ă  diminuer ce nombre, en permettant la synthĂšse de rĂ©ponses par le rĂ©solveur. Une autre solution est de ne pas ajouter un composant aprĂšs l'autre en cherchant le serveur faisant autoritĂ© mais d'en mettre plusieurs d'un coup, surtout aprĂšs les quatre premiers composants.

Un algorithme complet pour gérer la QNAME minimisation figure dans la section 3 du RFC.

Notez que, si vous voulez voir si votre résolveur fait de la QNAME minimisation, vous pouvez utiliser tcpdump pour voir les questions qu'il pose mais il y a une solution plus simple, la page Web de l'OARC (dans les DNS features).

Un test avec les sondes RIPE Atlas semble indiquer que la QNAME minimisation est aujourd'hui largement répandue (les deux tiers des résolveurs utilisés par ces sondes) :

% blaeu-resolve --requested 1000 --type TXT   qnamemintest.internet.nl 
["hooray - qname minimisation is enabled on your resolver :)!"] : 651 occurrences 
["no - qname minimisation is not enabled on your resolver :("] : 343 occurrences 
Test #33178767 done at 2021-11-05T14:41:02Z
  

Comme son prédécesseur, ce RFC utilise (prétend Verisign) un brevet. Comme la plupart des brevets logiciels, il n'est pas fondé sur une réelle invention (la QNAME minimisation était connue bien avant le brevet).

Ah, et vous noterez que le développement de ce RFC, par trois auteurs, a été fait sur FramaGit.

RFC 9141: Updating References to the IETF FTP Service

L'IETF distribuait un certain nombre de documents en FTP anonyme. Ce service, ftp.ietf.org, va ĂȘtre interrompu. Mais un certain nombre de RFC continuent Ă  le citer comme source. Comme on ne peut pas modifier un RFC aprĂšs publication, notre RFC 9141 fait la liste des mises Ă  jour Ă  lire pour corriger ces RFC et indiquer la nouvelle source des documents.

FTP, qui avait Ă©tĂ© le premier protocole de transfert de fichiers de l'Internet, avant mĂȘme l'adoption de TCP/IP, a Ă©tĂ© pendant longtemps le principal moyen de copier des fichiers Ă  travers le rĂ©seau. Une de ces fonctions, le FTP anonyme (qui n'Ă©tait en fait pas anonyme du tout) permettait d'accĂ©der aux fichiers, lorsque le serveur le voulait bien, sans avoir de compte sur le serveur. D'immenses archives de logiciels, de documents, d'images, ont Ă©tĂ© ainsi distribuĂ©es pendant des annĂ©es. Aujourd'hui, FTP n'est guĂšre plus utilisĂ© (entre autres parce qu'il fonctionne en clair, cf. la section 4 sur la sĂ©curitĂ©) et maintenir un service FTP anonyme n'a plus guĂšre de sens. D'oĂč la dĂ©cision de l'IETF en 2020 de fermer le sien (cf. l'annonce). Le plan Ă©laborĂ© Ă  cette occasion (une lecture recommandĂ©e sur les dĂ©tails de cette dĂ©cision, par exemple les statistiques d'utilisation) notait qu'il y avait trente RFC qui rĂ©fĂ©rençaient ce service, le dernier, le RFC 7241, datant de 2014. Tous ces RFC sont donc formellement mis Ă  jour par notre RFC 9141. (Comme le note GuB, « C'est pire que lĂ©gifrance cette histoire ».)

Par exemple, le RFC 2077 dit « Copies of RFCs are available on: ftp://ftp.isi.edu/in-notes/ » alors qu'il faudra désormais lire « Copies of RFCs are available on: https://www.rfc-editor.org/rfc/ ».

Voici par exemple, pour la nostalgie, le fonctionnement du serveur en novembre 2021, avant sa fermeture. On cherche les archives indiquées par le RFC 5098, et qui sont désormais en https://www.ietf.org/ietf-ftp/ietf-mail-archive/ipcdn/ :

% ncftp ftp.ietf.org    
NcFTP 3.2.5 (Feb 02, 2011) by Mike Gleason (http://www.NcFTP.com/contact/).

Copyright (c) 1992-2011 by Mike Gleason.
All rights reserved.

Connecting to 4.31.198.44...                                                                                                            
FTP server ready
Logging in...                                                                                                                           
Anonymous access granted, restrictions apply
Logged in to ftp.ietf.org.                                                                                                              
ncftp / > ls
charter/                         ietf/                            internet-drafts/                 slides/
concluded-wg-ietf-mail-archive/  ietf-mail-archive/               review/                          status-changes/
conflict-reviews/                ietf-online-proceedings/         rfc/                             yang/
ncftp / > 
ncftp / > cd ietf-mail-archive/ipcdn
ncftp /ietf-mail-archive/ipcdn > ls
...
1996-12               1999-07.mail          2001-09.mail          2003-11.mail          2006-01.mail          2008-03.mail
1997-01               1999-08.mail          2001-10.mail          2003-12.mail          2006-02.mail          2008-04.mail
1997-02               1999-09.mail          2001-11.mail          2004-01.mail          2006-03.mail          2008-05.mail
1997-03               1999-10.mail          2001-12.mail          2004-02.mail          2006-04.mail          2008-06.mail
...
  

ucCSI case: The unknown IVR with a random DTMF number

November 15th 2021 at 23:20
By: LuisR
We all love Mondays, but in the middle of the morning we just got a freaky urgent call. Fortunately this was a 2 hour episode and can be quickly explained Part 1: The issue The customer has an hybrid Contact


Continue reading →

luismramos

L'offre d'hébergement nua.ge

Je viens de tester un peu l'offre d'hébergement de serveurs Internet Nua.ge de la société Oxeva. Voici quelques retours d'expérience.

(J'ai bĂ©nĂ©ficiĂ© sans frais d'une offre gratuite de lancement mais notez que, pour en profiter, il faut laisser son adresse de courrier et son numĂ©ro de carte de crĂ©dit. Ceci dit, une panne de la Banque postale Ă  ce moment fait que la carte ne semble pas avoir Ă©tĂ© enregistrĂ©e mais le compte Nua.ge a Ă©tĂ© crĂ©Ă© quand mĂȘme.)

Le site Web de gestion est en nua.ge. Il est curieux qu'une entreprise qui communique beaucoup sur son caractĂšre français ait choisi le TLD de la GĂ©orgie. (La mĂȘme sociĂ©tĂ© dĂ©tient Ă©galement nuage.fr mais ne l'utilise pas, ce domaine est vide.) Le domaine a deux serveurs de noms, dont l'un est apparemment dans le rĂ©seau de la sociĂ©té :

% check-soa -i nua.ge    
ns1.reagi.com.
	195.60.188.254: OK: 2021111501 (1 ms)
ns2.reagi.com.
	87.98.186.69: OK: 2021111501 (5 ms)
  
On notera qu'aucun des deux n'a IPv6 (on ne trouve d'IPv6 nulle part sur ce réseau).

La création du compte est classique (on laisse plein de données personnelles, on reçoit un courrier avec un cookie, on visite le lien indiqué et on a son compte). Il ne semble pas y avoir d'authentification à deux facteurs disponible dans l'onglet « Sécurité » ce qui, pour une offre IaaS, est vraiment problématique.

J'ai ensuite créé une machine virtuelle, utilisant Debian. (Il ne semble pas y avoir de miroir Debian local à l'hébergeur, la machine est configurée pour aller chercher ses paquets sur le serveur Debian par défaut.) Cela n'a pas marché du premier coup (time out d'abord, puis refus d'authentification SSH avec la clé que j'avais donné). Il a fallu contacter le support (par un service de clavardage sur leur site Web) qui a rapidement réagi, détruit la machine et reconstruit une autre, sur laquelle je pouvais me connecter. (Le problÚme est admis mais pas encore corrigé.)

Ma machine actuelle a l'adresse 185.189.156.205. Et en IPv6 ? Comme dit plus haut, il n'y a d'IPv6 nulle part. En 2021, c'est incroyable (tous les fournisseurs français d'IaaS ont de l'IPv6 depuis longtemps), et rien que pour cela, je ne prolongerai pas l'essai au-delà de la période de test gratuite.

Autre problÚme, 185.189.156.205 n'est pas la vraie adresse IP de la machine. Les paquets entrants sont NATés vers une adresse privée (RFC 1918). Non seulement cela fait que la machine ne connait pas sa propre adresse IP, mais cela limite les protocoles utilisables à ceux reconnus par le routeur NAT (TCP, UDP et ICMP). Si vous voulez faire du SCTP ou autre protocole de transport, tant pis pour vous. Autant dire qu'on est trÚs loin d'un vrai service IaaS. Voici la liste des protocoles acceptés :

Ajoutez des instances à ce groupe uniquement si votre application nécessite des ouvertures particuliÚres.
RĂšgles	Protocol	Ports	IP Range
Autorise	UDP	0 - 0	0.0.0.0/0
Autorise	TCP	0 - 0	0.0.0.0/0
Autorise	ICMP	0 - 0	0.0.0.0/0

Question sécurité, tout est bloqué par défaut (ce qui n'est pas logique pour un serveur Internet) et il faut mettre la machine dans le groupe de sécurité « Autoriser tout le trafic entrant (non recommandé) » pour qu'on puisse superviser la machine et utiliser ping. Voici avec les sondes RIPE Atlas :

% blaeu-reach -r 200 185.189.156.205
198 probes reported
Test #33426048 done at 2021-11-16T12:53:50Z
Tests: 593 successful tests (100.0 %), 0 errors (0.0 %), 0 timeouts (0.0 %), average RTT: 67 ms
  
Cette supervision automatique a été trÚs utile, elle a permis de détecter une bogue dans Nua.ge, qui coupe les instances de temps en temps pour deux à trois minutes. (ProblÚme signalé et admis mais pas encore corrigé.)

Pour voir, j'ai mis sur cette machine perruche.bortzmeyer.org un trÚs simple serveur HTTP qui ne répond qu'à /hello et /date :

% curl  http://perruche.bortzmeyer.org/date
The time is 20:43:09.579900
  

Question DNS, on note que les machines reçoivent par dĂ©faut comme rĂ©solveur
 celui du gĂ©ant Ă©tatsunien Cloudflare ce qui, lĂ  encore, fait trĂšs bizarre pour une offre supposĂ©e « souveraine » :

% cat /etc/resolv.conf 
# Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)
#     DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN
# 127.0.0.53 is the systemd-resolved stub resolver.
# run "resolvectl status" to see details about the actual nameservers.

nameserver 1.1.1.1
nameserver 1.0.0.1
search int.nua.ge
  
Enfin, au moins, comme ça, on a DNSSEC, ce qui n'est pas le cas de tous les résolveurs français.

Je n'ai pas trouvé de moyen de configurer l'enregistrement DNS de type PTR (dans in-addr.arpa), qui m'aurait permis d'avoir un plus joli nom. Ce manque est ennuyeux si on veut héberger un serveur de messagerie.

Je n'ai pas lu les conditions d'utilisation et de gestion des données personnelles mais Aeris l'a fait, donc je vous renvoie à son récit.

Je n'ai pas trop suivi le mécanisme de facturation. Voici l'interface permettant de suivre sa consommation :

Je n'ai pas non plus regardé s'il y avait des API disponibles.

Pour résumer : le service fonctionne, mais ne correspond pas à ce que j'attends d'un service IaaS, surtout que le marché français dans ce domaine est trÚs riche et offre bien d'autres solutions. On ne voit pas ce que Nua.ge apporte de nouveau.

Autres articles sur ce service :

ucCSI case: The unknown IVR with a random DTMF number

November 15th 2021 at 23:20
By: LuisR
We all love Mondays, but in the middle of the morning we just got a freaky urgent call. Fortunately this was a 2 hour episode and can be quickly explained Part 1: The issue The customer has an hybrid Contact Center solution working with Teams. The call flow is the following: (1) the customers call [
]

Les Fans

Ce livre est consacrĂ© Ă  l'Ă©tude des fans, notamment de sĂ©rie tĂ©lĂ©. Souvent prĂ©sentĂ©s comme un peu bizarres, monomaniaques, fanatiques (cf. l'Ă©tymologie de « fan »), sans « vraie vie » et vivant dans l'imaginaire, les fans sont au contraire des sujets d'Ă©tudes dignes d'intĂ©rĂȘt.

J'ai dĂ©couvert dans ce livre qu'il existait mĂȘme une catĂ©gorie de SHS sur la question, les fan studies. Les fans ne sont pas une nouveautĂ© de l'Internet, l'auteure cite les regroupements de fans de Sherlock Holmes dĂšs le 19e siĂšcle. La thĂšse de l'auteure est que les fans ne sont pas des abrutis qui suivent passivement une sĂ©rie mais qu'ils interagissent, qu'ils critiquent, qu'ils utilisent la sĂ©rie dans tel ou tel but, par exemple politique (le sous-titre du livre est « publics actifs et engagĂ©s »). Le livre parle du militantisme autour des sĂ©ries (des fĂ©ministes utilisant Wonder Woman ou Leia comme rĂ©fĂ©rence), de crĂ©ation Ă  partir de sĂ©ries (fanfiction), etc.

J'ai eu du mal avec les rĂ©fĂ©rences, toutes Ă©tatsuniennes. Par exemple, la derniĂšre Ă©tude de cas couvre une sĂ©rie dont j'ignorais mĂȘme l'existence, Wynonna Earp, qui a apparemment un club de fans particuliĂšrement motivé·es et organisé·es. Il est parfois difficile de suivre le livre si on ne connait pas ces sĂ©ries.

Les fans sont, par dĂ©finition, passionnĂ©s par leur sujet et cela peut mener Ă  des comportements nĂ©gatifs, par exemple contre les fans d'autres sĂ©ries, ou contre les fans de la mĂȘme sĂ©rie, mais qui prĂ©fĂšrent tel personnage plutĂŽt que tel autre. L'auteur parle assez peu de ces aspects nĂ©fastes, qu'on peut facilement observer sur Twitter dans l'univers de la tĂ©lĂ©rĂ©alitĂ©, avec les insultes et menaces des fans de tel ou tel personnage.

Les fans peuvent aussi s'estimer en droit d'influencer la série et ses futurs épisodes, menant des campagnes, par exemple pour qu'on donne une place plus importante à tel personnage particuliÚrement apprécié (parfois pour des raisons politiques). Je trouve personnellement que le livre est un peu court sur l'analyse critique de ce phénomÚne, par exemple lorsqu'il cite des acteurs et actrices de séries qui tiennent publiquement des discours en accord avec celui de leur personnage dans la série : sincérité ou marketing ? Ce n'est pas étudié.

Les fans, on l'a dit, ne sont pas des spectateurs passifs. Une des parties les plus intéressantes du livre est consacré au travail que font certains fans autour de leur série favorite, par exemple en construisant des formidables encyclopédies en ligne comme le Wiki of Ice and Fire (non cité dans le livre, je crois) ou le Battlestar Galactica Museum. Un tel travail, avec ce qu'il implique, non seulement de temps passé, mais également de coordination dans le groupe, et de mentorat des nouveaux, est bien loin de l'image du fan asocial claquemuré dans sa chambre et s'adonnant au binge-watching. Bref si, comme moi, vous ne connaissez pas tellement ce monde des fans, vous apprendrez plein de choses dans ce livre.

Autre article, plus détaillé, sur ce livre, celui de Christine Hébert.

❌