Oui

Salut, connecte toi manuellement au serveur en dehors du programmes que tu développes, tu comprendras ce qu'il attend de toi

Je t'assure que ce qui te manque est sous ton nez et que tu as lu à ce sujet durant tes recherches pour résoudre l'épreuve

Dac, merci pour la réponse

Salut,
Je pense avoir découvert un bug avec le style Synthwave,
les caractères diacritiques liés au français et certains autres caractères dans les titres des épreuves ne sont pas affichés.

Exemples d'épreuves touchées:
https://www.newbiecontest.org/index.php?page=epreuve&no=256
https://www.newbiecontest.org/index.php?page=epreuve&no=25
https://www.newbiecontest.org/index.php?page=epreuve&no=325
https://www.newbiecontest.org/index.php?page=epreuve&no=241
https://www.newbiecontest.org/index.php?page=epreuve&no=64 (underscores manquants)

Salut,
j'ai un petit problème frustrant avec la résolution finale (?) de l'épreuve.
Le comportement dans gdb diffère du comportement dans le shell;
pourtant j'obtiens bien "Clé correct, voici votre shell !" dans le premier.

Ma clé ne serait donc pas la réponse à la grande question ?

EDIT: validé, merci pour m'avoir conforté dans mon raisonnement

Salut, bonne nouvelle, il n'y a rien à reconfigurer; le serveur local est indépendant de la config de la box

Salut,

Je ne vois pas spécialement comment il pourrait ralentir le téléchargement de quoi que ce soit

La désinstallation se fait avec le même outil que l'installation:

$ apt-get remove unbound

Ou en supprimant tous les fichiers de configuration avec:
$ apt-get purge unbound

Parfait ça marche tu vois en temps réel la résolution des noms. Si tu consultes un site et que rien ne s'affiche, c'est que le cache d'Unbound est utilisé ; tu peux ajouter le paramètre " -n" pour n'afficher que les adresses IP à l'écran.
Tu peux aussi jouer avec des filtres; tcpdump est très puissant ; mais ça c'est dans la doc :p
https://docs.netgate.com/pfsense/en/latest/book/packetcapture/using-tcpdump-from-the-command-line.html#tcpdump-filters

L'interface graphique correspondant à tcpdump s'appelle Wireshark ; c'est là aussi un outil d'audit réseau incontournable.

Bon courage 

Salut,

J'avoue sans honte avoir quand meme des soucis avec les lignes de codes   Admets quand meme que ce n'est pas simple

Effectivement, mais le réflexe doit être de lire les erreurs que les programmes te donnent. La plupart du temps c'est solutionnable instantanément.

Ex:
Erreur mentionnant le mot "permission": Tu lis, tu réfléchis, tu relis ce que tu viens d'écrire, et comme tu sais que c'est un problème de droits, tu regardes si tu as bien mis le sudo devant.
Ce temps de réflexion te permet aussi de réfléchir si ce que tu as écris est bien ce que tu voulais faire.
Les droits sous GNU/Linux peuvent paraître lourds, surtout quand on a l'habitude d'être en administrateur comme sous Windows, mais c'est une barrière pour faire réfléchir avant la validation d'erreurs irrattrapables.

=> Tu as fait plusieurs fois l'erreur du sudo oublié; cela veut dire que tu ne relis pas encore bien ce qui est écrit à l'écran  

je ne trouve pas la méthode pour enregistrer

Effectivement les symboles "^" affichés à l'écran signifient "Touche Ctrl" dans ce programme; j'ai oublié de le mentionner (je ne fais plus attention).


Cool que tu aies réussi à configurer les zones et accéder à ta box


Note: Après investigation, l'erreur "the anchor is NOT ok and could not be fixed" est a priori momentanée; il faut attendre quelques secondes pour que le serveur mette à jour ce fichier.
La validation DNSSEC se fait ensuite correctement (pas pu tester si c'est bien le cas quand cette erreur apparaît, car elle n'est pas systématique lors du démarrage; mais c'est une question à poser).

sudo netstat --inet -n -p -a | grep :53
je n'avais pas l'IP de ma BOX, cependant, depuis ce matin, elle apparaît, voire ci dessous

tcp        0      0 192.168.1.63:53674      74.125.71.189:443       ESTABLISHED 2181/firefox

Beaucoup de choses ici.

Tout d'abord, ce n'est pas l'ip de ta box mais celle de ton ordinateur sur ton réseau local: 192.168.1.63
L'expression régulière ":53" a aussi capturé ":53674"; ce n'est donc pas le port 53 que tu vois (comme quoi tu lis encore trop vite  ).

Ensuite, il faut savoir que les requêtes DNS sont stateless/sans état sur le protocole UDP, or netstat ne peut qu'afficher les connexions actives (établies, en écoute, etc.).
Tu vois donc les services et programmes qui utilisent le réseau avec les protocoles TCP/UDP, mais pas les logiciels qui FONT des requêtes UDP.

Quand bien même ça serait le cas, les requêtes DNS sont tellement rapides qu'il faudrait être réactif pour espérer les capturer avec netstat.

à la place:

Code:

sudo tcpdump -i eth0 port 53

où eth0 est le nom de l'interface réseau par laquelle tu es connecté (la plupart du temps eth0 pour ethernet / wlan0 pour le wifi).
C'est affiché avec la commande "sudo ifconfig".

Le retour de ce programme te permettra au passage de voir EXACTEMENT ce que voit quelqu'un/ton FAI à la sortie de ta box et sur ton réseau local...

Exemple:

Code:

2019-11-03 07:09:57.672893 IP 192.168.1.3.44790 > 192.168.1.1.53: 32586+ [1au] A? linuxfr.org. (52)
2019-11-03 07:09:57.708865 IP 192.168.1.1.53 > 192.168.1.3.44790: 32586 1/0/0 A 88.191.250.176 (45)

... c'est à dire tout.

Ce que permet Unbound:
- Valider via DNSSEC les réponses renvoyées par un serveur TLD. cad: sécuriser le message.
- Ne pas reposer sur les DNS menteurs des FAI.
- Réduire drastiquement le nombre de requêtes faites sur la box et donc chez les serveurs des FAI (au bout de quelques heures, grâce à son cache, Unbound permet d'économiser entre 50% et 95% des requêtes DNS faites sur le réseau).
- Réduire drastiquement la latence nécessaire à l'obtention de la réponse DNS (sauf pour la première consultation, c'est instantané car c'est en local sur l'ordinateur).

Ce qu'il ne permet pas:
- Chiffrer les communications DNS. cad qu'il ne sécurise pas le canal qui fait transiter le message.


Pour le chiffrement c'est une autre histoire. 3 technos se combattent actuellement: DNS over HTTPS, DNS over TLS, et DNSCrypt.
Chacune a ses avantages et inconvénients. Le pire inconvénient commun est probablement le faux sentiment d'invisibilité car les adresses IP des sites consultés sont évidemment visibles et les serveurs des sites qui sont encore en TLS1.2 divulguent toujours les noms des sites consultés dans les handshakes.

Voir https://lafibre.info/cryptographie/encrypted-sni/

DNS over TLS est le seul implémenté sur Unbound mais doit faire appel (comme tous ses concurrents) à des serveurs d'entités privées (Google, Cloudfare, etc.) pour résoudre les domaines car les TLD ne les supportent pas.

Voir les quelques services qui peuvent forwarder le DNS sur HTTPS ou sur TLS :
https://korben.info/1-1-1-1-ou-9-9-9-9-ou-8-8-8-8-quel-dns-choisir.html

Dans ce cas, Unbound n'a plus le rôle de serveur récursif-cache mais juste de validation-cache où il délègue la résolution à une autre entité.

Pour ma part je pense que les TLD n'ont pas à se précipiter sur l'implémentation de telle ou telle technologie poussée par les géants du Web. Ce sont eux qui font les normes actuellement et nous avons ici un exemple de la centralisation (2 services se déclarant aptes à prendre en charge le trafic DNS mondial) et du faux sentiment de sécurité qu'ils promettent.

Les vraies clés de l'invisibilité consistent à identifier clairement l'entité dont on veut se protéger (le FAI, Google, le voisin, le hotspot MacDo, le prestataire de VPN ?), d'être capable de faire fonctionner soi-même un maximum de services habituellement délégués au cloud, et éventuellement de passer par un VPN (de confiance...) pour la navigation quotidienne.

L'apprentissage suit une certaine chronologie, intimement liée à la scolarité traditionnelle, à moins d’être un autodidacte exceptionnel, eh encore, car en général, les bases sont obtenues par un raisonnement mathématique acquis jusqu'à la terminale S

Pas que, c'est aussi (pour beaucoup) une question de temps que l'on peut se permettre d'allouer à certains sujets...

Je me suis aussi aidé du forum de Ubuntu afin de savoir ce qu'étaient ces deux commandes

C'est moins sur le forum que sur la doc qu'il faut aller. Le lien que je t'ai donné expliquait clairement et en français ce que faisaient ces 2 paramètres...

Ajouter les 2 au fichier semble assez inutile si ce n'est contradictoire d'ailleurs.
Un fichier de conf s'édite avec les outils vim ou nano. "tee -a" ajoute la ligne à la fin du fichier et je ne conseille ça qu'à condition de savoir ce qu'on fait (càd qu'on est sûr que la directive n'existe pas déjà ou n'entre pas en conflit avec une autre; bref il toujours vérifier l'intégrité du fichier).

Donc:

Code:

sudo nano ton_fichier

Les raccourcis de ce logiciel ont l'avantage d'être affichés à l'écran.

Par ailleurs:

Il y a du nouveau, voici ce que donne cette commande, et je ne vois plus l'IP de mon PC

Avant de modifier le dhclient.conf, as-tu au moins essayé de cliquer sur le bouton "Automatique" de la section DNS de ton gestionnaire réseau comme je l'ai préconisé maintes fois ?

J'ai à nouveau ajouté les deux adresses IP FDN dans l'onglet IPV4, elles apparaissent de nouveau via la commande ci dessous

Fichier de conf ou GUI il faut choisir. Dans 6 mois tu auras oublié que tes fichiers de conf ont été modifiés alors qu'un coup d’œil dans la GUI est rapide.

host 192.168.1.254

Ok la box n'a donc pas de nom sur le réseau local. Il s'agit d'une redirection du domaine "bytel.fr" sur le serveur web de la box.
Oublie donc la configuration des zones.

Ça sera une simple redirection de domaine (sur Unbound toujours):

Code:

    local-zone: "bytel.fr" redirect
    local-data: "bytel.fr A 192.168.1.254"

(Inspiration par le blocage de pub présenté ici: https://calomel.org/unbound_dns.html)

Tu me conseilles donc de réaliser les commandes ci dessous ? et/ou de m'introduire au sein d'un fichier, et dans ce cas, lequel et à quel endroit du fichier indiquer ces lignes de code ? 
Est ce celui-ci /etc/dhcp/dhclient.conf ou celui ci /etc/unbound/unbound.conf ?

C'était marqué dans mon texte...

oct. 21 20:41:18 james14000-MS-7982 package-helper[1243]: fail: the anchor is NO
Quelle erreur, et que faire ?

Je ne sais pas, ton texte est coupé.
Je suppose que c'est "fail: the anchor is NOT ok". Je ne peux pas en dire plus que ce que tu as sous les yeux; il faut que tu apprennes à chercher ce que signifient les erreurs que les programmes te renvoient.
Si la commande unbound-checkconf te dit que tout va bien, c'est que le serveur Unbound est peut être lancé trop tôt au cours du démarrage (le système n'a pas peut-être pas eu le temps d'acquérir une heure fiable et la signature DNSSEC qui repose sur cet horodatage n'est donc pas possible). C'est une piste/supposition, sans plus d'investigation et à sans avoir un accès physique à ta machine, tu es la seule personne qui puisse résoudre ces petits soucis...

Tu peux/dois résoudre seul 90% des questions que tu poses :p Là tu utilises un intermédiaire humain comme moteur de recherche 

ca se complique concernant les explications du dessus

Prepend n'est pas ajouter mais ajouter avant le reste.
Les # en début de chaque ligne sont des commentaires/exemples; ces lignes ne sont pas prises en compte.

Comme toujours, la doc te montrera quelle est la différence entre ces 2 options:
http://www.delafond.org/traducmanfr/man/man5/dhclient.conf.5.html

C'est la même différence entre un DHCP par défaut et un DHCP seulement pour les adresses ip.

Je ne conseille pas de modifier ce fichier en première intention; c'est non flexible, ça persiste au travers des reboots et s'applique quelque-soit la config du réseau local.

Surtout qu'en fait l'option qui t'intéresse est sur la capture d'écran que tu donnes; c'est le bouton "Automatique"... Je pense qu'il suffisait de tester :p


Erratum:

L'adresse 127.0.0.53 qu'on voyait dans les posts précédent est l'adresse du service systemd-resolved qui gère les DNS à un plus haut niveau que tout le reste.
J'admets qu'entre ça, dnssec-trigger, unbound, dnsmasq, dhcp, c'est un gros gros bazar.

Ok , ce serveur fonctionne finalement :p

Pour la configuration tu pourrais ajouter l'une ou l'autre de ces lignes au fichier /etc/dhcp/dhclient.conf

Code:

prepend domain-name-servers 127.0.0.1;
supersede domain-name-servers 127.0.0.1;

Puis redémarrer le service réseau:

Code:

sudo systemctl restart networking

Mais d'une manière générale il est souvent déconseillé de modifier en dur des fichiers de configuration de services qui sont normalement administrables via une GUI.
Ça rend les modifications moins facilement réversibles.
Je pense que tu es passé à côté d'une option de ton gestionnaire de réseau.

C'est à dire, je vais planter la totalité de mon installation UBUNTU ?

Non pas facilement, mais c'est possible. Les logiciels des dépôts fonctionnent en harmonie.
Exemple: installation d'une librairie dont la version plus récente casse la compatibilité avec les versions antérieures. C'est assez rare mais ça existe.

Par contre, ce qui me surprend, c'est lorsque je stoppe l'action de UNboud via cette commande :
La commande DIG indique toujours le serveur de Unboud, en l’occurrence, IP 127.0.0.1 comme opérationnelle, alors que cela devrait laisser place au serveur de ma BOX ? ! Non ?

En effet "dig @127.0.0.1 www.newbiecontest.org" devrait retourner après un certain temps:

Code:

;; connection timed out; no servers could be reached

La commande suivante ne devrait pas faire apparaitre Unbound (peut être un autre service écoutant sur 0.0.0.0:53 ?)

Code:

sudo netstat --inet -n -p -a | grep :53

SERVER: 127.0.0.53#53(127.0.0.53)

C'est probablement dnssec-trigger qui prend en charge la résolution et comme ton Unbound est désactivé, il bascule sur un autre serveur (celui de la box ou ceux de FDN par ex).

je ne peux pas acceder à la page de configuration de ma Box, en revanche, une fois désactivée par cette fonction, la BOX est accessible par sa page ou son IP dans l'url.

Quelle est l'url d'accès à la box ?
Ton serveur Unbound ne fait pas autorité pour des noms de domaines farfelus comme ceux utilisés par les box pour simplifier leur usage (bbox.lan est censé être plus facile à retenir que 192.168.1.254).
Dans ce cas il faut configurer une zone dans ton Unbound pour rediriger ces noms vers un serveur qui sait quoi en faire (ta box).
Essaie quelque-chose comme ça ("home.lan" est à adapter selon le type de noms en vigueur sur ton réseau).

Code:

        private-domain: "home.lan"
        local-zone: "1.168.192.in-addr.arpa" nodefault

        # FORWARD lookup stub zone pointing to the NSD authoritative server
        # answer example: "192.168.1.1"
        # => vers serveur faisant autorité pour home.lan
        stub-zone:
            name: "home.lan"
            stub-addr: 192.168.1.254@53

        # REVERSE (rDNS) dns lookup for the home.lan zone.
        # answer example: "firewall.home.lan"
        stub-zone:
            name: "1.168.192.in-addr.arpa"
            stub-addr: 192.168.1.254

La deuxième stub-zone est destinée à faire du reverse DNS:
https://en.wikipedia.org/wiki/Reverse_DNS_lookup
https://nlnetlabs.nl/pipermail/unbound-users/2009-May/005982.html

Concrètement la commande suivante ne devrait pas donner ce résultat:

Code:

$ host 192.168.1.254
Host 254.1.168.192.in-addr.arpa. not found: 3(NXDOMAIN)

Salut, je manque de temps pour répondre rapidement;

Du coup je vais juste reprendre les points où tu fais fausse route, en ajoutant quelques conseils.
Il est certain que même si le tuto d'origine fait quelques dizaines de lignes, mettre en place un service de ce type sur une machine est bien plus compliqué qu'il n'y parait.
Néanmoins c'est très formateur, à tous les niveaux (shell, administration, sécurité, réseau, etc.) !

Il te manque des repères sur ce nouveau système comme la structure des dossiers et les commandes de base.
Au début tu auras l'impression de devoir jongler avec des fichiers dispersés sur tout le disque; avec le temps tout cela deviendra intuitif (les fichiers de configuration sont tous dans /etc par exemple).
Pour cela il faudrait que tu suives l'excellent cours d'openclassrooms sur le sujet:
https://openclassrooms.com/fr/courses/43538-reprenez-le-controle-a-laide-de-linux

Ce sont de très bonnes bases; tu peux commencer à partir du chapitre "la console, ça se mange ?".

---

Donc, si j'ai bien compris, je telecharge Unbound, puis je l'installe et le paremetre via des commandes UNIX ? !

Sur GNU/Linux on ne télécharge pas les programmes sur le Internet; il est très rare de devoir compiler ses logiciels depuis les sources.
Cela arrive quand on a vraiment besoin de la dernière version d'un logiciel qui ne se trouve pas sur les dépôts. C'est formateur mais ce n'est pas le moment lorsqu'on débute

Tu n'as pas besoin de compiler Unbound. De plus les distributions font le packaging des applications de façon à ce qu'elles s'intègrent au mieux dans l'écosystème des applications déjà installées.
Par exemple certains fichiers de configuration ne sont pas forcément au même endroit selon les distributions, etc.
Prendre un logiciel dans les dépôts permet de garantir son fonctionnement, et permet d'économiser du temps.

L'installation se fait donc par apt ou apt-get.
À partir du moment où tu installes un logiciel, tu accomplis une tâche d'administration et cela se fait avec sudo.

---

james14000@james14000-MS-7982:~$ sudo mkdir /var/log/unbound
mkdir: impossible de créer le répertoire «/var/log/unbound»: Le fichier existe

---


Comme le message d'erreur l'indique, mkdir refuse de créer un dossier s'il existe déjà. Pour passer outre ce détail l'option -p peut être utilisée (mkdir --help pour afficher les options comme sur la plupart des outils).

james14000@james14000-MS-7982:~$ touch /var/log/unbound.log
touch: impossible de faire un touch '/var/log/unbound.log': Permission non accordée
james14000@james14000-MS-7982:~$ chown unbound:unbound /var/log/unbound.log
chown: impossible d'accéder à '/var/log/unbound.log': Aucun fichier ou dossier de ce type

Sur GNU/Linux les droits sont importants.
Un utilisateur ne peut modifier/créer des fichiers n'importe où; la commande sudo est là pour demander les droits ponctuellement. C'est un garde-fou.
(PS: La tentation du chmod 777 peut être grande pour attribuer les droits maximaux à un fichier mais c'est surtout le meilleur moyen de s'apercevoir qu'on ne sait pas ce qu'on fait.)


Les commandes en question doivent être exécutées avec sudo devant.

---

Deux adresses IP se suivent, celle de mon FAI, et la fameuse 127.........  

Oui il faut que tu te débrouilles pour que le localhost (127.0.0.1) soit à la place de 192.168.1.254 ou au moins devant lui.

Sur KDE je vois une légère nuance dans les options disponibles, tu dois avoir quelquechose de similaire :
    - Configuration automatique: Possibilité d'ajouter un autre serveur DNS (cela ajoute le serveur à la liste des serveurs déjà définis lors de la récupération de l'adressage réseau auprès de la box).
    - Configuration automatique (seulement les adresses): Le serveur DNS vient cette fois écraser celui que la box retourne.


---

tar xvfz unbound-latest.tar.gz
unbound-1.9.4/
cd unbound-x.x.x/
bash: cd: unbound-x.x.x/: Aucun fichier ou dossier de ce type

L'archive que tu décompresses (comme un fichier zip ou rar) contient un dossier nommé "unbound-1.9.4".
"x.x.x" est ici le moyen que l'auteur du tuto a trouvé pour te dire d'aller dans le dossier qui vient d'être créé.


Le danger quand on débute est de suivre les tutos puis de copier/coller les commandes sans avoir une vraie idée de ce que l'on fait
Celui-ci est complexe car il te fait compiler Unbound.

En fait, pourquoi je déconseille cela ?
Tu vas peut-être réussir mais il s'agit là de la toute dernière version du logiciel, le code fait peut-être appel à des versions de librairies que ton système n'intègre pas encore. De fil en aiguille tu vas t'exposer à la recompilation entière de ton système. Un moment va arriver où tu vas être incapable de compiler une librairie et tu auras (presque) perdu ton temps.
On l'a tous fait...

---

J'ai l'impression que cela fonctionne, car je me suis fait aider par le forum UBUNTU.fr, néanmoins, je ne sais pas ce que j'ai fait pour activer unbound, j'y suis allé par déduction

Fais attention tu as une erreur là:

oct. 21 20:41:18 james14000-MS-7982 package-helper[1243]: fail: the anchor is NO

Il est possible que le fichier pointé par la clé "auto-trust-anchor-file" présente dans un des fichiers ".conf" dans les répertoires "/etc/unbound/" et/ou "/etc/unbound/unbound.conf.d/" ne soit pas présent.
Ce fichier est responsable de la validation DNSSEC.

Théoriquement:
/etc/unbound/unbound.conf.d/root-auto-trust-anchor-file.conf:
auto-trust-anchor-file: "/var/lib/unbound/root.key"

Le fichier /var/lib/unbound/root.key doit exister et appartenir à l'utilisateur unbound:

Code:

ls -la /var/lib/unbound/root.key
-rw-r--r-- 1 unbound unbound 759 oct.  27 14:57 /var/lib/unbound/root.key

(Vérifier les droits, et ajuster avec "chown unbound:unbound" ou "chmod 644" si besoin)

---

Comment puis je savoir si j'utilise le DNS 127.0.0.1 et non celui de ma BBOX ?

La commande suivante te permet de le savoir:

Code:

$ dig sci-hub.tw
; <<>> DiG Debian <<>> sci-hub.tw
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 11768
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;sci-hub.tw.                    IN      A

;; ANSWER SECTION:
sci-hub.tw.             179996  IN      A       186.2.163.90

;; AUTHORITY SECTION:
sci-hub.tw.             179996  IN      NS      ns2.cloud.organic.

;; Query time: 2 msec
;; SERVER: 192.168.1.3#53(192.168.1.3)
;; WHEN: Mon Oct 28 03:34:10 CET 2019
;; MSG SIZE  rcvd: 86

=> SERVER: 192.168.1.3 : c'est mon serveur.

Tu peux spécifier le serveur seul pour le tester sans avoir résolu ton problème de configuration réseau via:

Code:

dig @127.0.0.1 sci-hub.tw

---

Génial, cela fonctionne enfin, j'ai juste indiqué deux FDN dans les parametres reseau de UBUNTU

Oui mais là tu ne passes plus par ton Unbound :p
Néanmoins les DNS de FDN sont dignes d'une confiance absolue.

Dans les fonctions avancées de ma BOX, j'ai vu que l'on pouvait changer l'adresse IP de la BOX, mais que va-t-il se passer si je la change par l'IP 127.0.0.1 ?

En théorie tu devrais mettre l'ip du serveur; 127.0.0.1 c'est l'ip de ta machine (interface loopback). La box a elle aussi son ip localhost 127.0.0.1.
Ton serveur/Ta machine a une adresse IP sur ton réseau local du type 192.168.1.XX.

Tu la verras avec

Code:

$ ip addr

En pratique aucune Box ne permet à ma connaissance de spécifier un serveur DNS de remplacement. On en revient à la petite nuance expliquée plus haut. En ajoutant des serveurs DNS, tu ne fais que ajouter des serveurs secondaires. En d'autres termes si ton FAI décide que le site n'existe pas, ta box n'ira pas consulter les autres DNS que tu auras configurés. C'est une illusion de configuration (ils appellent ça DNS secondaires ).

Lire: https://pro-domo.ddns.net/blog/censure-de-sci-hub-comment-retablir-lacces-au-site.html

Bon courage

En mettant en place ce serveur, les requêtes DNS de résolution de noms de domaine se feront sur ta machine plutôt que sur une machine de ton FAI susceptible de mentir sur la non-existence d'un site, ou sur sa localisation (cf conflit Free vs Youtube).

Avec un peu plus de configuration tu pourras profiter de DNSSEC qui établit une chaîne de confiance entre la racine DNS et le site consulté.
La France et ses opérateurs est largement dans le déploiement de cette technologie qui existe depuis plus de 10 ans.

Au final :
- La navigation sera plus rapide (la condition sine qua non pour qu'un site soit consulté est que la requête DNS soit satisfaite au préalable),
- Tu accéderas à des sites bloqués par décision de justice/censure dans ton pays (thepiratebay, t411, sci-hub, etc.),
- Tu seras protégé des attaques par empoisonnement du cache DNS.

Beaucoup d'informations; la citation de benjani est un résumé; mais tu peux déjà consulter ces liens :
Conf de Stéphane Bortzmeyer sur le DNS
https://www.youtube.com/watch?v=QHVK666TFUI
DNSSEC
https://fr.wikipedia.org/wiki/Domain_Name_System_Security_Extensions

Le reste est essentiellement de la recherche que tu dois faire de ton coté 


Pour le problème présent tu peux d'ores et déjà suivre ce tuto:
https://wiki.debian-fr.xyz/Utiliser_Unbound_avec_DNSSEC

... en s'aidant fortement de la documentation d'unbound :
https://nlnetlabs.nl/documentation/unbound/unbound.conf/

Si ta configuration d'unbound est mauvaise, le serveur ne démarrera pas. Il existe un outil installé avec unbound pour vérifier cela :

Code:

$ unbound-checkconf

N'oublie pas que le log doit être accessible par le serveur (c'est un point sur lequel j'avais buté) :

Code:

sudo mkdir /var/log/unbound
touch /var/log/unbound.log
chown unbound:unbound /var/log/unbound.log

Dans le tuto, l'installation de dnssec-trigger configure automatiquement dnssec.
Il apporte de plus un service qui permet de vérifier l'état du serveur en temps réel (c'est expliqué).

La vérification de la config DNSSEC se fait ici:
https://www.icann.org/resources/pages/dns-resolvers-updating-latest-trust-anchor-2018-06-27-fr
https://dnssec.vs.uni-due.de/


Avec cela je pense que tu devrais réussir à te débrouiller; bon courage !