jeudi 29 décembre 2016

Prêt à porter

Je suis à peu près satisfait de mon application de bureau, qui me permet de naviguer librement à travers la bonne vieille cardioïde (mais pas trop profond, hein, c'est encore du flottant partout). J'en ai profité pour mettre du noir quand la suite ne converge pas, ce qui est plus joli (et plus correct). Maintenant, je suis prêt à porter la chose correctement sur le téléphone. Stress...

mercredi 14 décembre 2016

C'était facile, finalement

Une fois trouvé le petit bug qui faisait foirer le lissage des couleurs, je me suis rendu compte que c'était finalement très simple à implémenter (et nettement moins simple à comprendre). Voici le résultat:

Laisse moi zoom zoom zang

Dans ta fractale, fractale, fractale!

Après le contrôle de la palette, j'ai rajouté la navigation via la souris pour le déplacement, et la molette pour le zoom. L'on peut enfin explorer la fractale à volonté. C'est toujours d'une rapidité surprenante à calculer, au point que tout semble trop facile: je me sens presque floué de ne pas avoir à attendre plusieurs minutes pour voir une belle image. Mais pouvoir juste regarder un peu à côté de l'image, ou approcher un détail, est tellement confortable.

Maintenant, j'ai une application qui se tient à peu près. Quelques améliorations seront cependant les bienvenues:

  • Le lissage des couleurs en passant par des logarithmes
  • Une amélioration de la palette, peut-être avec du noir pour le centre
  • Une amélioration de la précision

Je développe un peu le dernier point. Mon visualiseur utilise des flottants simple précision, qui sont ce que le GPU préfère. C'est super pour les graphismes en général, mais sur du calcul de fractales, cette précision créé très rapidement une limite dans le zoom, au delà duquel l'image se retrouve composée de blocs disgracieux. La solution la plus simple pour franchir cette limite consiste à passer en double précision, ce qui est trivial pour un CPU, mais nettement plus périlleux pour un GPU, où l'augmentation de précision est une fonctionnalité très récente qui est encore mal supportée par le logiciel et le matériel.

L'autre solution est d'utiliser des nombres décimaux à précision illimitée. Avec un CPU, le temps de calcul devient rapidement exécrable, tandis que l'utilisation mémoire explose. Avec un GPU, je ne sais même pas si c'est possible...

vendredi 9 décembre 2016

Partageons

C'est toujours mieux quand on partage, donc j'ai mis une version très basique de mon explorateur de l'ensemble de Mandelbrot, version ordinateur de bureau, sur Github. C'est par ici que ça se passe.

Notez que j'ai trouvé une fonction pour transformer du HSV en RGB, histoire de fournir une coloration continue. Wikipedia l'explique mieux que moi, mais l'idée est que la composante H (la teinte) correspond à une position sur un cercle, l'ensemble HSV étant un cylindre, par opposition au RGB qui est un cube, et que la faire varier permet donc de changer de teinte aussi rapidement que souhaité sans jamais avoir de "saut" peu esthétique dans les couleurs.

lundi 28 novembre 2016

Une fractale sur mon téléphone

L'obstination a fini par payer, et j'arrive maintenant à afficher un bout de l'ensemble de Mandelbrot sur mon Ubuntu Touch ! Sans plus attendre, la démonstration en photo :

Les écueils furent nombreux, mais j'ai fini par à peu près comprendre comment approcher le problème. En particulier, le port vers OpenGL ES fut un poil tordu, mais j'ai maintenant une base qui fonctionne.

En termes de performances, mon téléphone calcule une image en 500ms. À comparer avec ma machine de bureau qui fait tourner (presque) le même programme en 1ms, ce qui est plutôt raisonnable si l'on considère que la carte graphique à elle seule coûte 2 fois le prix du téléphone.

Il va donc falloir revoir les performances d'une part (réduction de la précision, rafraîchir l'image le moins possible), et les fonctionnalités d'autre part: afficher l'ensemble de Mandelbrot, c'est bien, mais s'assurer que l'on a pas de déformations, que l'on peut zoomer, et qu'il y a un joli dégradé de couleurs, c'est mieux.

Je compte donc d'abord tenter d'unifier autant que possible mes programmes OpenGL et OpenGL ES, puis de développer sur le bureau, ce qui est quand même rudement plus confortable, avant de revenir sur le téléphone, et peut-être un jour publier l'application...

mardi 22 novembre 2016

Frustration

C'est frustrant, tout ça. J'ai l'impression qu'il y a une logique ésotérique que je n'arrive pas à saisir, et que toute approche un petit peu industrielle au développement d'une application sur mon Ubuntu Phone se solde par un échec.

Côté téléphone, il est vraiment très difficile de charger des bibliothèques tierces, ce qui est particulièrement frustrant lorsque l'on voit que dans les dépôts, tout est déjà compilé pour ARM, mais qu'il ne faut surtout pas l'utiliser, parce que les paquets Click, c'est le futur. OpenSceneGraph fonctionne jusqu'à ce que j'essaie de faire plus qu'afficher un écran blanc, puis plante. Les bibliothèques de chargement de sons dans SDL_mixer ont des tonnes de dépendances, non disponibles sur le téléphone. Argh !

Côté PC, ce n'est guère mieux. J'avais dans l'idée que je pouvais développer un programme en OpenGL ES 2 (la version apparemment présente sur le téléphone) sur PC, histoire de simplifier le déploiement et le débogage, et de le porter simplement ensuite sur le téléphone. Que nenni ! J'arrive bien à faire de l'OpenGL, mais pas de l'OpenGL ES. Ça n'affiche juste rien. Je ne sais pas si ce n'est juste pas possible, si c'est les drivers de ma carte qui sont foireux, ou si je suis juste bête.

Donc, parce qu'il ne manquerait plus que je me laisse abattre, j'essaie de développer un petit programme simple sous un "vrai" OpenGL, et je me battrai ensuite pour le porter sur le téléphone. Que de batailles épiques en perspective !

mardi 8 novembre 2016

Ubuntu Phone et SDL - Magie

Ça marche ! Rhaaaa ! Rhaaaaaaaaa ! Rhaaaaaaaaaaaaaaaaaaa !

Ça n'a pas été sans mal, mais j'ai enfin réussi à faire tourner un mini-programme utilisant la SDL. Quelle plaie ! On va tout reprendre depuis le début, et essayer d'expliquer comment y arriver.

La première épreuve est de télécharger une version de la SDL qui fonctionne avec la version de MIR, le serveur d'affichage de chez Ubuntu, disponible sur le téléphone. Alors c'est bien simple, SDL 2.0.5 a besoin d'une version de MIR trop récente (>= 0.25), et 2.0.4 a besoin d'une version de MIR trop vieille (0.14). Il faut donc aller trouver la bonne révision dans le dépôt SDL, pour aller chercher la SDL juste quand elle marchait avec MIR 0.24. Donc, dans votre répertoire courant, faites:

hg clone http://hg.libsdl.org/SDL -r 10361

Maintenant, ouvrez un shell sur la chroot de cross-compilation ARM (je rappelle pour ceux du fond qui ne suivent pas, dans QtCreator, c'est Tools => Options => Ubuntu => onglet Click => architecture armhf => Maintain). Dans ce shell, nous allons définir quelques variables d'environnement pour s'assurer que la cross-compilation est correctement configurée, en faisant pointer le compilo, l'éditeur de liens, et le PKG_CONFIG (pour MIR) au bon endroit.

export CC=/usr/bin/arm-linux-gnueabihf-gcc
export LD=/usr/bin/arm-linux-gnueabihf-ld
export AS=/usr/bin/arm-linux-gnueabihf-as
export CXX=/usr/bin/arm-linux-gnueabihf-g++
export PKG_CONFIG_PATH=/usr/lib/arm-linux-gnueabihf/pkgconfig/

Ensuite, on peut lancer la compilation en elle-même.

../SDL/configure --prefix=/usr/ --host=arm-linux-gnueabihf
make -j 4
make install

Tout se passe à peu près bien, et l'on peut vérifier que la bibliothèque est bien générée avec des instructions ARM

/usr/bin/arm-linux-gnueabihf-objdump -x /usr/lib/libSDL2.a | head -n 20

L'on voit de charmantes choses du genre "SDL.o: file format elf32-littlearm", qui sont quand même très bon signe.

Ensuite, construisons un programme SDL proprement dit. J'utilise un exemple tiré de StackOverflow, et j'ajuste l'édition de liens en ajoutant cette ligne au sein du fichier .pro pour lier SDL en statique :

LIBS += -l:libSDL2.a -ldl

Après, on lance, et miracle, j'ai des petits pixels qui s'affichent !

Alors, certes, ce n'est qu'une étape. Il est plaisant de voir que la cross-compile fonctionne, que SDL arrive à papoter avec MIR, et que l'on se trouve enfin en terrain connu.

Reste à compléter l'intégration. Dans mon programme d'exemple, la résolution est codée en dur, il faudrait arriver à récupérer la résolution du téléphone. Peut-on attraper l'événement de mise en arrière plan ? Peut-on attraper l'événement de rotation de l'écran ? Est-ce que les API SDL sont correctement reliées à la machine, et peut-on détecter un doigt, un geste, un geste à plusieurs doigts ? Est-ce que le son et la musique fonctionnent correctement ?

Mais ce sera pour un autre jour. Maintenant, dodo.

dimanche 6 novembre 2016

Développement d'applications avec Ubuntu Phone - Défaite partielle

Eh beh, mes tentatives de faire tourner quelque chose de vaguement 3D sur mon Ubuntu Phone se révèlent plus difficiles que prévu. J'ai compris beaucoup de choses, et réalisé que j'en ignorais encore plus. Petit topo.

Tout d'abord, dès que l'on commence à parler dépendances, il faut commencer par comprendre le système de paquets Ubuntu, appelé "click". C'est une nième réponse au problème des dépendances de paquet, et qui vise à fournir un petit paquet qui ne dépende que de l'installation par défaut. Le paquet doit donc fournir directement toutes les dépendances de l'application. J'ai trouvé les explications sur le sujet plutôt limitées, et le plus simple semble pour l'instant de faire de la compilation statique.

Ce que cela veut dire, c'est que l'on ne peut pas se reposer sur les paquets Ubuntu pour construire son application. En effet, ces paquets ne seront pas disponibles sur le téléphone, et même si vous arriviez à copier les bibliothèques dans le paquet click, elles dépendent certainement elles-mêmes de bibliothèques dynamiques.

Ensuite, parlons de l'environnement de cross-compilation : Le système lxd (voir post précédent) fournit une sorte de chroot, qui représente l'environnement du téléphone. Dans cette chroot, gcc, g++, ld, et tous les autres, sont en mode cross-compilation vers armhf.

Étant donné tout cela, l'approche qui semble fournir des résultats (c'est à dire, quelque chose d'autre qu'un crash immédiat) est de compiler soi-même au sein de la chroot toutes les dépendances nécessaires à l'application, vers des bibliothèques statiques.

Un exemple avec OpenSceneGraph : j'obtiens un shell vers la chroot (Tools => Options => Ubuntu => bouton "Maintain" de la "build target"). Depuis le chroot, l'on voit quand même son /home, j'y ai donc téléchargé le code d'OpenSceneGraph, et j'ai créé un répertoire build comme indiqué dans les instructions de compilation. Ensuite, l'on installe quelques en-têtes manquantes, et l'on compile OpenSceneGraph.

apt-get install libqt5opengl5-dev:armhf
aptitude install libgl1-mesa-dev:armhf
cmake ../OpenSceneGraph -DOPENGL_PROFILE="GLES2" \
-DCMAKE_INSTALL_PREFIX=/usr -DBUILD_OSG_APPLICATIONS:BOOL=OFF \
-DDYNAMIC_OPENSCENEGRAPH=OFF -DDYNAMIC_OPENTHREADS=OFF
make
make install

Une fois arrivé à ce niveau, j'ai ajouté la lignes LIBS += -losgViewer -losgDB -losgManipulator -losgGA -losgUtil -losgText -losg -lOpenThreads -ldl à mon fichier .pro, et j'ai copié un exemple d'intégration QT5 et OpenSceneGraph. Ça compile, youpie !

Et là, j'ai eu un bel écran blanc, soit-disant parce que j'utilisais un composant QT5 non supporté, que l'application osait utiliser un shader, et un peu de baratin additionnel de la même farine.

Conclusion ? Je ne suis pas très sûr. Il faut certainement que je tente une autre approche pour intégrer QT5 et OpenSceneGraph. Mais peut-être est-ce voué à l'échec de faire de la 3D sur un téléphone bas de gamme ? Peut-être que de la 2D, en utilisant directement la SDL et sans passer par QT, serait plus simple ? Ais-je vraiment envie de me taper la compilation de la SDL ? Est-ce que Mir (le serveur graphique de chez Ubuntu) va me causer des soucis ? Est-ce que finalement, je ne suis pas plutôt fait pour la programmation sur desktop ?

jeudi 3 novembre 2016

Développement d'applications sur Ubuntu Phone - Installation de l'environnement

Utilisant maintenant Ubuntu comme système d'exploitation principal, rien de m'empêche d'installer l'environnement de développement Ubuntu Phone ! Youpie !

Dans les faits, ce fut un poil plus compliqué que prévu. Ce qui n'aide pas, c'est que manifestement (mais on s'en doutait un peu), le développement d'applications pour les téléphones Ubuntu reste un marché de niche, et qu'il y a donc très peu de ressources en dehors du site d'Ubuntu lui-même. Donc, si l'on se retrouve confronté à un problème dans leur tutoriel, il faudra lutter pour s'en sortir.

Les explications sont donc ici. Et après, c'est la jungle... Je me suis en particulier beaucoup battu avec lxd. Alors, lxd, je ne connaissais pas, mais il s'agit d'une sorte de chroot, qui semble être utilisé pour faire de la cross compilation. Jusqu'ici, tout va bien, mais la chose refusait de démarrer. Finalement, en bidouillant bien plus que de raison avec les logs de systemd, j'ai fini par comprendre qu'il y avait conflit entre lxd d'une part, et bind9 d'autre part (j'avais bien entendu installé bind9 et mis dnssec en place), lequel conflit peut se résoudre en forçant bind9 à n'écouter qu'en ipv4, sur le loopback, ce qui me convient (mais ne conviendra pas à quelqu'un qui veut fournir du DNS au reste de son réseau local, ou, pire, utiliser IPV6). J'ai donc à la fin de mon /etc/bind/named.conf.options :

listen-on-v6 { none; };
listen-on { 127.0.0.1; };

Une fois cette épreuve surmontée, et lxd démarré (il faut insister, apparemment), qcreator apparait ! Hourra ! Mais un dernier obstacle se dresse devant le développeur amaigri. En effet, il faut créer le "kit", qui permet la cross-compilation. Et si on le créé avant d'avoir connecté le téléphone, on est garanti de se planter, et de se retrouver avec des programmes C++ qui foirent lamentablement. D'ailleurs, n'essayez pas de connecter le téléphone à travers le Wifi, malgré l'impression que QCreator y arrive, utilisez un bon vieux cable USB et le tour est joué. Ensuite, depuis la page "Devices", vous pourrez créer un kit correspondant au téléphone, qui devrait fonctionner tout seul.

Les exemples de projet sont suffisamment complets pour pouvoir démarrer : en particulier, QCreator débarque avec un projet en QML pur, en QML avec un backend C++, et en C++ pur avec injection de QML.

Comme premier projet, j'aimerais bien voir si j'arrive à intégrer OpenSceneGraph à une application Ubuntu Phone.

mercredi 2 novembre 2016

Ubuntu, KVM et Windows

Maintenant que je suis passé à un processeur i5, le monde merveilleux de la virtualisation s'ouvre à moi. L'idée est de se débarrasser enfin du double boot, et de le remplacer par des machines virtuelles, plus flexibles et plus rapides à démarrer en cas de besoin. En particulier, ayant besoin parfois de faire du développement sous Windows, il me faut une machine virtuelle Windows.

La mort de mon précédent PC n'ayant normalement pas d'incidence sur ma license Windows Vista (oui, c'est vieux), j'ai essayé d'installer la chose sur KVM, le système de virtualisation qui vient avec le noyau. Bien que doté d'une interface un peu austère, il est extrêmement puissant. En particulier, il est possible d'obtenir une grosse amélioration des performances en utilisant des pilotes spécifiques pour l'accès au disque et au réseau au sein de l'OS virtualisé. Ça se passe très bien avec Debian, mais c'est un petit peu moins direct avec Windows.

Je vous la fait courte, avec Windows Vista, ça ne marche juste pas. J'ai tout essayé, mais je reste bloqué tout au début de l'écran de chargement.

En revanche, avec Windows 7, c'est nettement mieux. Le truc pour obtenir directement une installation rapide et cohérente, c'est de s'assurer que le disque virtuel est de type "virtio", de monter l'image du disque d'installation de Windows dans un premier lecteur virtuel, et de monter une image spéciale fournie par KVM et qui contient les pilotes dans un deuxième lecteur virtuel (ouf!).

Au démarrage, Windows 7 voit bien un D: contenant l'installation, et un E: contenant des pilotes, mais pas de C:. Il propose alors d'installer les pilotes. Une fois le bon pilote choisi depuis le E: dans la catégorie "virtblo", il voit alors un C:, et peut s'installer dessus tranquillement, et à toute berzingue si vous avez eu la bonne idée de le laisser tourner sur un SSD. Et à partir de là, vous avez un beau Windows qui tourne à une vitesse très proche d'une installation native (modulo les applications demandeuses en terme de graphisme, tels les jeux vidéos, la magie a quand même des limites).

Mais bon (troll inside), avec les pilotes graphiques libres et propriétaires de chez monsieur AMD, tripotée de jeux sur Steam, et un client Citrix qui fonctionne du tonnerre (ne me jugez pas, c'est le boulot!), a-t-on vraiment besoin de Windows?

mardi 1 novembre 2016

Nouveau PC

Mon ordinateur est mort! Après 8 ans de bons et loyaux services, la machine a rendu l'âme dans un dernier soubresaut. Je n'ai pas trop creusé les causes du décès, mais j'étais à peu près sûr que le disque était encore en forme, et mes données saines et sauves. Direction Tottenham Court Road, l'équivalent de notre bonne vieille rue Montgallet, mais en nettement moins impressionnant. Ma nouvelle bête est un i5 avec 8Go de RAM, un SSD de 124 Go et un disque dur de 1 To, et une carte graphique Radeon RX 480.

Je me suis un peu battu avec l'UEFI, et j'ai fini par abandonner l'installation de Debian pour une Ubuntu pour laquelle AMD fournit de beaux drivers propriétaires. Le tout fonctionne particulièrement bien, et le SSD change vraiment la vie. Le démarrage de la machine et des applications est démentiel.

À noter, j'ai décidé de mettre tout le disque sur le SSD, en ne mettant sur le HDD que la partition de swap, le /var/log, et une grosse partition "data" que j'accède via un lien symbolique et sur lequel je peux mettre le bousin un peu lourdingue (collection de photos, principalement).

lundi 3 octobre 2016

Ubuntu Phone 1 an après, mes impressions sur Linuxfr

J'ai fait un petit résumé de mes impressions après plus d'une année d'utilisation de mon Ubuntu Phone. Intéressantes réactions des inconditionnels et des moins convaincus.

dimanche 4 septembre 2016

Nested namespace definition

Entrée remarquée dans c++17 de la fonctionnalité de définition des espaces de noms imbriqués. C'est à dire qu'au lien de mettre des séries de "namespace a { namespace b { namespace c { ...", l'on peut directement écrire "namespace a::b::c { ...". Ça ne va pas changer la vie de qui que ce soit, mais pourquoi pas. Comme d'hab, le petit programme d'exemple:

#include <iostream>

namespace a::b::c // magie!!!!
{
  void f()
  {
    std::cout << "Ouh là, c'est profond!" << std::endl;
  }
}

int main()
{
  a::b::c::f();
  
  return 0;
}

vendredi 2 septembre 2016

Folding expressions

Youpie, gcc 6.1 a débarqué dans Debian! C'est une excellente occasion pour se plonger dans les nouveautés du standard. Parlons donc d'une fonctionnalité que j'avais complètement zappé, les "folding expression". L'idée est de fournir du sucre syntaxique pour permettre d'appliquer certains opérateurs à l'ensemble des paramètres variadiques d'une fonction. Dit comme ça, cela semble assez abstrait, mais puisque comme disait Napoléon, un petit bout de code vaut mieux que de grands discours, voici un exemple.

L'idée est donc d'écrire une fonction qui peut prendre un nombre quelconque d'arguments, et en retourner la somme. Avec une "folding expression", rien de plus simple! La syntaxe est un peu absconse, "(... [operator] args)" (ne pas oublier les parenthèses!), mais ça fait le boulot.

#include <iostream>

template<typename ...ARGS>
int variadicAdd(ARGS... args)
{
  return (... + args);
}

int main()
{
  std::cout << variadicAdd(3, 2, 7, 8, 4, 5) << std::endl;
  return 0;
}

Comme vous voyez, c'est tout bête. L'on aurait pu coder la même fonctionnalité avec des appels récursifs, mais c'est quand même beaucoup plus succinct comme ça. L'on peut "replier" les expressions avec tout un tas d'opérateurs, et j'attends avec impatience de voir ce que l'on va inventer avec cette construction.

dimanche 3 juillet 2016

Short String Optimisation

Enfin, ayant pu mettre la main sur la version 5.2 de gcc, m'empressais-je d'expérimenter un petit peu avec les short string optimisation (SSO), cette nouvelle implémentation de la classe std::string qui permet une grande amélioration des performances et de la mémoire pour la gestion des chaînes de caractères courtes. Historiquement, gcc implémentait std::string avec une autre optimisation, le "copy on write", qui est plus intéressant pour les grandes chaînes de caractères, mais de nouvelles contraintes dans le standard C++11 interdisent cette optimisation, et gcc doit donc passer à SSO.

Le principe est diablement intelligent: la classe std::string est typiquement implémentée avec un pointeur, vers l'espace mémoire alloué sur le tas et qui contient la chaîne en elle-même, et un entier correspondant à la taille de cette chaîne. L'idée est donc de dire que si la chaîne est suffisamment petite, plutôt que de l'allouer sur le tas, autant utiliser directement les octets du pointeur et de l'entier, en considérant le pointeur et l'entier comme un tableau de caractères.

Détails d'implémentation mis à part, cela nous donne effectivement un maximum de 15 octets (en 64 bits) sans aucune allocation. Et, sur certains programmes, cela fait une différence très significative.

Sur mon programme de test, qui est un générateur de code, c'est à dire un programme qui par définition passe sa vie à allouer des chaînes, l'on a diminué de moitié le nombre d'allocations, et diminué de moitié le temps d'exécution. Sur des programmes moins spécialisés, la différence est moins spectaculaire, mais cela reste très intéressant.

Alors, le souci est que cela casse la compatibilité binaire, et qu'il faut donc recompiler son programme toutes ses dépendances, ce qui, dans un environnement corporate avec des logiciels tiers propriétaires, peut poser des soucis. Mais si l'on peut, alors cela vaut vraiment le coup.

dimanche 24 avril 2016

RAM

Petit souci de PC, il y a quelques jours. La machine était contente sous Linux, mais le Windows était complètement pourri, refus de démarrer, erreur différente à chaque fois, restauration sans effet... Je m'apprêtais à blaster la partition et à réinstaller Windows au propre, lorsque l'entrée memtest86+ dans le menu de boot attira mon regard. Et en effet, c'était bien juste une barrette défectueuse... Après localisation et expulsion de la fautive, la machine avait repris du poil de la bête, et je me suis économisé une réinstallation complète.

dimanche 10 janvier 2016

Dnssec chez vous

Cela faisait un certain temps que j'avais installé un résolveur DNS sur ma machine, tout d'abord parce que le DNS de mon fournisseur d'accès à Internet avait la fâcheuse tendance à planter, et ensuite parce que ça le fait d'aller interroger directement les serveurs racine.

Il y a quelques jours, ayant lu un article sur Dnssec, je me suis donc demandé si mon installation utilisait ce système qui permet de sécuriser la résolution de nom en s'assurant que personne de bidouille l'info, typiquement pour nous router vers un site de malware plutôt que le site recherché. Une rapide recherche m'amena vers un site de test qui me démontra que non. Retroussons nous donc les manches!

Déjà, il faut vérifier que votre résolveur fonctionne avec dnssec. Un petit "dig +dnssec" pour résoudre un nom qui supporte ce standard nous informe que c'est bon:

$ dig +dnssec http://www.dnssec-deployment.org/

; <<>> DiG 9.9.5-12.1-Debian <<>> +dnssec http://www.dnssec-deployment.org/
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 62323
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 0, AUTHORITY: 6, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;http://www.dnssec-deployment.org/. IN  A

;; AUTHORITY SECTION:
.                       10797   IN      SOA     a.root-servers.net. nstld.verisign-grs.com. 2016011000 1800 900 604800 86400
.                       10797   IN      RRSIG   SOA 8 0 86400 20160120050000 20160110040000 54549 . MTlQxI92KqWfL5GsAk6eBL3T9KHsQIt3lWkC9jmiyYBl7+qCcOJUZOvG 4oEN1JizSsEhpp76oM0Fg9svRHryV5oZZr7Od2CHbI9jfuiYYPhvO16E o6EkPwoXZcnm6Y6JgLXKd/UOQK+J+WhlyqFP8swSgynv/FwvaRIFgkf/ cNw=
.                       10797   IN      RRSIG   NSEC 8 0 86400 20160120050000 20160110040000 54549 . uhX0FXBilUV7ZCP3sC/tPYVA5Srlu8MknbmGKZLLUf5FzRDH0tCk+HZb wy/2MGTnISsFnRftRgw4mR5tmBW6jgeYsR4PS46360GAqT1h5mvBAmHv gEE+5/g1kVsSi/MDJ075VduVHD+yMwCS5KZ/ynywsq7uj93gescPj+0V TbE=
.                       10797   IN      NSEC    aaa. NS SOA RRSIG NSEC DNSKEY
org.                    10797   IN      RRSIG   NSEC 8 1 86400 20160120050000 20160110040000 54549 . hPeKkCWTQbKtMBSDf/sGOnX1CHBXez4kuG2ulIc94USFgWR6Oz+R7OIs qCzjursXz+79hYd3HFrYFYX0KlWj08zpZHtTB4zz9TRoH1ep3ARoPWkR iyPDEkLgFyGlYnqQD3VuiIHQ478BUlgQ8vmKE/5REMsTXKIJxIG+kO95 YSs=
org.                    10797   IN      NSEC    organic. NS DS RRSIG NSEC

;; Query time: 0 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Sun Jan 10 15:40:46 GMT 2016
;; MSG SIZE  rcvd: 669

La présence de lignes RRSIG indique que la requête est revenue avec la signature demandée.

Maintenant, il suffit de configurer son résolveur pour que la résolution se fasse correctement. Avec bind9 sur Debian, c'est:

  • Ouvrir le fichier /etc/bind/named.conf.options
  • S'assurer que les 2 options dnssec-enable et dnssec-validation sont présentes
  • Mettre dnssec-enable à "yes" et dnssec-validation à "auto"

Mon fichier ressemble à cela:

options {
        directory "/var/cache/bind";
        dnssec-enable yes;
        dnssec-validation auto;
[...]

Notez que dnssec-validation doit être à "auto" et non à "yes", ce qui va lui permettre d'utiliser le fichier de signature présent avec la distribution. Avec l'option "yes", il faut en fournir un à la mimine.

Maintenant, redémarrez bind9. Un "dig www.dnssec-failed.org" devrait vous renvoyer un beau "status: SERVFAIL". Essayez également de visualiser le site depuis un navigateur, il devrait vous dire que le serveur n'a pu être trouvé. Yeah!

Petite astuce: assurez vous que le résolveur de noms de votre fournisseur est complètement ignoré, et pas simplement mis après votre résolveur local. Il m'a fallu enlever "domain-name-server" de mon dhclient.conf que la résolution DHCP ne charge pas le serveur DNS de mon fournisseur. Dans le doute, regardez votre resolv.conf.